summaryrefslogtreecommitdiffstats
path: root/video/filter/vf_vavpp.c
Commit message (Collapse)AuthorAgeFilesLines
* vf_vavpp: select best quality deinterlacing algorithm by defaultwm42018-02-131-5/+22
| | | | | | | | This switches the default away from "bob" to the best algorithm reported as supported by the driver. This is convenient for users, and there is no reason to use something worse by default. Untested.
* video: make --deinterlace and HW deinterlace filters always deinterlacewm42018-02-131-1/+1
| | | | | | | | | | | | | | | | Before this, we made deinterlacing dependent on the video codec metadata (AVFrame.interlaced_frame for libavcodec). So even if --deinterlace=yes was set, we skipped deinterlacing if the flag wasn't set. This is very unreliable and there are many streams with flags incorrectly set. The potential problem is that this might upset people who alwase enabled deinterlace and hoped it worked. But it's likely these people were screwed by this setting anyway. The new behavior is less tricky and easier to understand, and this preferable. Maybe one day we could introduce a --deinterlace=auto, which does the right thing, but of course this would be hard to implement (esecially with hwdec). Fixes #5219.
* video: rewrite filtering glue codewm42018-01-301-177/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.
* video: remove some more hwdec legacy stuffwm42017-12-021-5/+16
| | | | | | | | | Finally get rid of all the HWDEC_* things, and instead rely on the libavutil equivalents. vdpau still uses a shitty hack, but fuck the vdpau code. Remove all the now unneeded remains. The vdpau preemption thing was not unused anymore; if someone cares this could probably be restored.
* vf_vavpp: restrict allowed sw upload formats to nv12/yuv420pwm42017-09-301-20/+3
| | | | | | | | | | | | | | | | | | | | We allowed any input format that was generally supported by libva, but this is probably nonsense, as the actual surface format was always fixed to nv12. We would have to check whether libva can upload a given pixel format to a nv12 surface. Or we would have to use a separate frame pool for input surfaces with the exact sw_format - but then we'd also need to check whether the vaapi VideoProc supports the surface type. Hardcode nv12 and yuv420p as input formats, which we know can be uploaded to nv12 surfaces. In theory we could get a list of supported upload formats from libavutil, but that also require allocating a dummy hw frames context just for the query. Add a comment to the upload code why we can allocate an output surface for input. In the long run, we'll probably want to use libavfilter's vaapi deinterlacer, but for now this would break at least user options.
* vf_vavpp: use error checking macrowm42017-09-291-19/+11
|
* vf_vavpp: use libavutil hw frames API for frame pool and uploadwm42017-09-291-25/+83
| | | | | Another step to get rid of the legacy crap in vaapi.c. (Most is still kept, because it's in use by vo_vaapi.c.)
* video: change --deinterlace behaviorwm42017-08-221-7/+0
| | | | | | | | | | | | This removes all GPL only code from it, and that's the whole purpose. Also happens to be much simpler. The "deinterlace" option still sort of exists, but only as runtime changeable option. The main change in behavior is that the property will not report back the actual deint state. Or in other words, if inserting or initializing the filter fails, the deinterlace property will still return "yes". This is in line with most recent behavior changes to properties and options.
* vf_vavpp: fix first-field modewm42017-02-281-3/+3
| | | | It didn't deinterlace at all. Oops.
* vf_vavpp: add advanced deint bug compatibility for Intel vaapi driverswm42017-02-281-4/+20
| | | | | | | | | | | | | | | I'm not sure what's going on here, but it appears kodi switches forward and backwards references for advanced VPP deinterlacing modes. This in turn makes deinterlacing with these modes apparently work. If you don't switch the directions, you get a stuttering mess. As far as the libva trace dump is concerned, this makes mpv's libva deinterlacing API use behave like kodi's, and appears to reproduce smooth video with advanced libva deinterlacing enabled. I'm hearing that Mesa actually does it correctly, and I'm not sure what will happen there. For now, passing "reversal-bug=no" as sub-option to the vavpp filter will undo this behavior.
* vf_vavpp: minor fixeswm42017-02-281-2/+4
| | | | | | | Fully initialize two structs (not doing so may or may not have been a bug). Actually destroy the VABufferID we create (moderate memory leak).
* vf_vavpp: always limit forward/backward surfaces to requested numberwm42017-02-271-3/+7
| | | | | | Don't give the driver more forward/backward refernces than it requested in num_forward_references/num_backward_references. This shouldn't matter, I'm just trying to play it safe.
* vf_vavpp: remove apparently broken change-detectionwm42017-02-271-2/+0
| | | | | | This is probably wrong. Just don't bother with it. The only potentially negative effect is from calling vaQueryVideoProcPipelineCaps() every frame.
* vf_vavpp: get rid of mp_refqueue_is_interlaced()wm42016-07-151-1/+1
| | | | | | | | | This makes the difference between passing VA_FRAME_PICTURE or VA_BOTTOM_FIELD for progressive frames (that should be force- deinterlaced) to VAProcPipelineParameterBuffer.flags. VA-VPP doesn't really seem to care, and we can get rid of mp_refqueue_is_interlaced() entirely. It could be argued it's better to pass field flags instead of the progressive flag.
* mp_image: split colorimetry metadata into its own structNiklas Haas2016-07-031-1/+1
| | | | | | | | | | | | | | | | | | This has two reasons: 1. I tend to add new fields to this metadata, and every time I've done so I've consistently forgotten to update all of the dozens of places in which this colorimetry metadata might end up getting used. While most usages don't really care about most of the metadata, sometimes the intend was simply to “copy” the colorimetry metadata from one struct to another. With this being inside a substruct, those lines of code can now simply read a.color = b.color without having to care about added or removed fields. 2. It makes the type definitions nicer for upcoming refactors. In going through all of the usages, I also expanded a few where I felt that omitting the “young” fields was a bug.
* vf_vdpaupp: use refqueue helperwm42016-05-271-0/+1
| | | | | | | | | | | This makes vf_vdpaupp use the deinterlacer helper code already used by vf_vavpp. I nice side-effect is that this also removes some traces of code originating from vo_vdpau.c, so we can switch it to LGPL. Extend the refqueue helper with a deint setting. If not set, mp_refqueue_should_deint() always returns false, which slightly simplifies vf_vdpaupp. It's of no consequence to vf_vavpp (other than it has to set it to get expected behavior).
* vf_vavpp: make refqueue logic field-basedwm42016-05-251-56/+42
| | | | | | | Abstracts the annoying framerate-doubling behavior. Same deal as with refqueue introduction: the code size blows up, but at least it can be reused for other filters.
* vf_vavpp: minor simplificationwm42016-05-251-4/+6
|
* vf_vavpp: simplify update_pipeline() usagewm42016-05-251-13/+18
| | | | | | | | | | | | | Calling this right at start of filter_ext() also fixes a small regression from previous commit. The change in reference surfaces due to the first update_pipeline() with deinterlacing enabled changed behavior of mp_refqueue_next() and mp_refqueue_has_output(). Since update_pipeline() was called between those, the frame output logic got inconsistent, and the first deinterlaced frame was duplicated from the previous non-deinterlaced frame. Also reset the number of ref-frames when switching back to non-deint mode.
* vf_vavpp: move frame handling to separate filewm42016-05-251-57/+30
| | | | | | | | | | | | | | Move the handling of the future/past frames and the associated dataflow rules to a separate source file. While this on its own seems rather questionable and just inflates the code, I intend to reuse it for other filters. The logic is annoying enough that it shouldn't be duplicated a bunch of times. (I considered other ways of sharing this logic, such as an uber- deinterlace filter, which would access the hardware deinterlacer via a different API. Although that sounds like kind of the right approach, this would have other problems, so let's not, at least for now.)
* video: refactor how VO exports hwdec device handleswm42016-05-091-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or documented where not), which makes the whole thing saner and cleaner. In particular, thread-safety rules become less subtle and more obvious. The new internal API makes it easier to support multiple OpenGL interop backends. (Although this is not done yet, and it's not clear whether it ever will.) This also removes all the API-specific fields from mp_hwdec_ctx and replaces them with a "ctx" field. For d3d in particular, we drop the mp_d3d_ctx struct completely, and pass the interfaces directly. Remove the emulation checks from vaapi.c and vdpau.c; they are pointless, and the checks that matter are done on the VO layer. The d3d hardware decoders might slightly change behavior: dxva2-copy will not use the VO device anymore if the VO supports proper interop. This pretty much assumes that any in such cases the VO will not use any form of exclusive mode, which makes using the VO device in copy mode unnecessary. This is a big refactor. Some things may be untested and could be broken.
* vf_vavpp: reindentwm42016-04-111-8/+6
|
* vaapi: determine surface format in decoder, not in rendererwm42016-04-111-10/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, we have made the assumption that a driver will use only 1 hardware surface format. the format is dictated by the driver (you don't create surfaces with a specific format - you just pass a rt_format and get a surface that will be in a specific driver-chosen format). In particular, the renderer created a dummy surface to probe the format, and hoped the decoder would produce the same format. Due to a driver bug this required a workaround to actually get the same format as the driver did. Change this so that the format is determined in the decoder. The format is then passed down as hw_subfmt, which allows the renderer to configure itself with the correct format. If the hardware surface changes its format midstream, the renderer can be reconfigured using the normal mechanisms. This calls va_surface_init_subformat() each time after the decoder returns a surface. Since libavcodec/AVFrame has no concept of sub- formats, this is unavoidable. It creates and destroys a derived VAImage, but this shouldn't have any bad performance effects (at least I didn't notice any measurable effects). Note that vaDeriveImage() failures are silently ignored as some drivers (the vdpau wrapper) support neither vaDeriveImage, nor EGL interop. In addition, we still probe whether we can map an image in the EGL interop code. This is important as it's the only way to determine whether EGL interop is supported at all. With respect to the driver bug mentioned above, it doesn't matter which format the test surface has. In vf_vavpp, also remove the rt_format guessing business. I think the existing logic was a bit meaningless anyway. It's not even a given that vavpp produces the same rt_format for output.
* Change 3 more files to LGPLwm42016-01-201-7/+7
|
* vf_vavpp: allocate output surfaces with the same size as inputwm42015-09-231-1/+4
| | | | | | | | | | | | | This can happen if the hw decoder allocates padded surfaces (e.g. mod16), but the VPP output surface was allocated with the exact size. Apparently VPP requires matching input and output sizes, or it will add artifacts. In this case, it added mirrored pixels to the bottom few pixels. Note that the previous commit should have fixed this. But it didn't work, while this commit does. Fixes #2320.
* va_vavpp: set input/output processing regionwm42015-09-231-2/+2
| | | | | | | | If not set, VPP will use the whole surface. This is a problem if the surfaces are padded, and especially if the surfaces are padded by different amounts. This is an attempt to fix #2320, but it appears to do nothing at all.
* vf_vavpp: don't attempt to deinterlace progressive frameswm42015-07-081-0/+7
|
* vf_vavpp: provide future/past frames to driverwm42015-06-011-30/+97
| | | | | | | | | | | | | This was missing for extended deinterlacer. Unfortunately, these deinterlacer still do not work. The provided future frame (which is all the deinterlacers want) seems to be correct, though. One minor behavioral change is that this always keeps the previous frame for PTS computations. This could be avoided (in order to keep exactly the same behavior as before), but it seems more elegant and should not do any harm. (Also, if we really cared about reducing hw frame refs, a more worthy goal is producing the field output incrementally.)
* vf_vavpp: move vaMapBuffer() closer to its usewm42015-06-011-4/+4
| | | | | | | | The mapped data (pointed to by the param variable) is not needed before, so the call can be moved down. Also, this prevents that the buffer remains mapped forever if the other vaMapBuffer() call above fails (the cleanup code forgets to unmap the buffer - this commit makes it unnecessary).
* vf_vavpp: remove dummy loop, unindentwm42015-06-011-51/+61
| | | | | | | This used a do-while loop, which runs only once, as replacement for a cleanup goto. While this is ok, doing a goto directly is easier to follow and is closer to idiomatic C. But mainly remove it so that the indentation can be reduced.
* vf_vavpp: cosmeticswm42015-06-011-10/+10
| | | | Adjust coding style. Get rid of some useless consts too.
* vf_vavpp: minor simplificationwm42015-06-011-29/+24
| | | | Slightly easier to follow.
* vf_vavpp: fix bob deinterlacing for bottom field first videosFilip Milivojevic2015-05-301-0/+2
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vf_vavpp: do not pretend to support referenceswm42015-05-291-3/+5
| | | | | | | | | | | | | | | We do not fill them, so we would pass random IDs to the driver. The code was originally written to handle bob deinterlacing only, so I guess it originally passed always 0 anyway, despite having code for reference surface list allocation. Also, move down the vaUnmapBuffer() call. This call actually "unmaps" the param pointer, so accessing it after the unmap call would be undefined behavior. The "example" in <va/vavpp.h> does this too, but it's most likely an error. (Additionally, not even bob deinterlacing worked correctly in my test, sigh.)
* vf_vavpp: simplify surface list allocationwm42015-05-291-14/+2
|
* Remove trailing whitespacesMichael Vetter2015-05-151-2/+2
|
* vf_vavpp: fix deinterlacingFilip Milivojevic2015-03-081-0/+8
| | | | | | | Add filter parameters to VAAPI deinterlacing filter to actually process bottom fields instead of deinterlacing top field twice. Signed-off-by: wm4 <wm4@nowhere>
* vf_vavpp: add more deinterlacing algorithmswm42015-01-231-7/+22
| | | | | | These are untested due to lack of hardware. From what I've heard, the drivers are pretty buggy, so it's not clear how well this works, if at all.
* video: have a generic context struct for hwdec backendswm42015-01-221-1/+3
| | | | | | | | | | | Before this commit, each hw backend had their own specific struct types for context, and some, like VDA, had none at all. Add a context struct (mp_hwdec_ctx) that provides a somewhat generic way to pass the hwdec context around. Some things get slightly better, some slightly more verbose. mp_hwdec_info is still around; it's still needed, but is reduced to its role of handling delayed loading of the hwdec backend.
* vaapi: minor simplificationwm42015-01-211-1/+1
|
* video: don't drop last frame when deinterlacing with yadifwm42014-04-281-0/+2
| | | | | | | | | | | | | | | | | | Or in other words, add support for properly draining remaining frames from video filters. vf_yadif is buffering at least one frame, and the buffered frame was not retrieved on EOF. For most filters, ignore this for now, and just adjust them to the changed semantics of filter_ext. But for vf_lavfi (used by vf_yadif), real support is implemented. libavfilter handles this simply by passing a NULL frame to av_buffersrc_add_frame(), so we just have to make mp_to_av() handle NULL arguments. In load_next_vo_frame(), we first try to output a frame buffered in the VO, then the filter, and then (if EOF is reached and there's still no new frame) the VO again, with draining enabled. I guess this was implemented slightly incorrectly before, because the filter chain still could have had remaining output frames.
* vaapi: make struct va_surface privatewm42014-03-171-11/+11
| | | | | | It's not really needed to be public. Other code can just use mp_image. The only disadvantage is that the other code needs to call an accessor to get the VASurfaceID.
* vaapi: replace image pool implementation with mp_image_poolwm42014-03-171-17/+26
| | | | | | | | | | | | Although I at first thought it would be better to have a separate implementation for hwaccels because the difference to software images are too large, it turns out you can actually save some code with it. Note that the old implementation had a small memory management bug. This got painted over in commit 269c1e1, but is hereby solved properly. Also note that I couldn't test vf_vavpp.c (due to lack of hardware), and I hope I didn't accidentally break it.
* vaapi: mp_msg conversionswm42013-12-211-29/+36
| | | | | | This ended up a little bit messy. In order to get a mp_log everywhere, mostly make use of the fact that va_surface already references global state anyway.
* Move options/config related files from mpvcore/ to options/wm42013-12-171-1/+1
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* vf: redo conversion filter insertion/format negotiationwm42013-12-071-5/+6
| | | | | | | | | | | | | | | | | Remove the inconsistent, duplicated, and insufficient scale filter insertion code, and do it in one place instead. This also compensates for the earlier removal of vf_match_csp() (which was in fact duplicated code). The algorithm to determine where to insert a filter etc. is probably the same, though it also comes with some changes that should make debugging easier when trying to figure out why a chain is failing to configure. Add an "in" pseudo filter, which makes insertion of conversion filters easier. Also change the vf->reconfig signature. At a later point, I'll probably change format negotiation such that the generic filter code will choose the output format, so having separate in and out params will be useful.
* video/filter: make vf->control non-recursivewm42013-12-071-1/+1
| | | | | | Reason: I never liked it being recursive. Generally, this seems to cause more problems than trouble, and is less flexible for access outside of the chain.
* video: create a separate context for video filter chainwm42013-12-071-4/+2
| | | | | | This adds vf_chain, which unlike vf_instance refers to the filter chain as a whole. This makes the filter API less awkward, and will allow handling format negotiation better.
* video/filter: remove legacy option handling hackswm42013-12-041-1/+1
| | | | | | | | | All filters now either use the generic option parser, or don't have options. This finally finishes a transition started in 2003 (see git commit 33b62af94760186c). Why are MPlayer devs so monumentally lazy? Sorry, but this takes the cake. You had 10 years.
* vaapi: remove unused hw image formats, simplifywm42013-11-291-1/+1
| | | | | | | | | | PIX_FMT_VDA_VLD and PIX_FMT_VAAPI_VLD were never used anywhere. I'm not sure why they were even added, and they sound like they are just for compatibility with XvMC-style decoding, which sucks anyway. Now that there's only a single vaapi format, remove the IMGFMT_IS_VAAPI() macro. Also get rid of IMGFMT_IS_VDA(), which was unused.
*