summaryrefslogtreecommitdiffstats
path: root/video/filter
Commit message (Collapse)AuthorAgeFilesLines
* build: add preliminary LGPL modewm42017-09-211-4/+5
| | | | | | | See "Copyright" file for caveats. This changes the remaining "almost LGPL" files to LGPL, because we think that the conditions the author set for these was finally fulfilled.
* mp_image: include config.h directlyJames Ross-Gowan2017-08-261-1/+0
| | | | | | | | | This is needed for HAVE_SSE4_INTRINSICS. config.h used to be included as a transitive dependency of vf.h, but the include statement was removed from vf.h in 8f2ccba71bb4. Also silence an unused variable warning that was introduced in the same commit.
* video: change --deinterlace behaviorwm42017-08-224-28/+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.
* video: redo video equalizer option handlingwm42017-08-222-26/+0
| | | | | | | | | | | | | | | | | | | | | | | I really wouldn't care much about this, but some parts of the core code are under HAVE_GPL, so there's some need to get rid of it. Simply turn the video equalizer from its current fine-grained handling with vf/vo fallbacks into global options. This makes updating them much simpler. This removes any possibility of applying video equalizers in filters, which affects vf_scale, and the previously removed vf_eq. Not a big loss, since the preferred VOs have this builtin. Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and vo_xv. I'm not going to waste my time on these legacy VOs. vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which exists _only_ to trigger a redraw. This seems silly, but for now I feel like this is less of a pain. The rest of the equalizer using code is self-updating. See commit 96b906a51d5 for how some video equalizer code was GPL only. Some command line option names and ranges can probably be traced back to a GPL only committer, but we don't consider these copyrightable.
* vf_eq: remove this filterwm42017-08-222-450/+0
| | | | | | | | | Both the video equalizer command/option glue, which drives this filter, as well as the filter itself are slightly GPL contaminated. So it goes. After this commit, "--vf=eq" will actually use libavfilter's vf_eq (if FFmpeg was compiled in GPL mode), but it has different options and will not listen to the equalizer VOCTRLs.
* video: add metadata handling for spherical videowm42017-08-212-1/+16
| | | | | | | | | | | | | | This adds handling of spherical video metadata: retrieving it from demux_lavf and demux_mkv, passing it through filters, and adjusting it with vf_format. This does not include support for rendering this type of video. We don't expect we need/want to support the other projection types like cube maps, so we don't include that for now. They can be added later as needed. Also raise the maximum sizes of stringified image params, since they can get really long.
* vf_vapoursynth: fix inverted sign and restore 10 bit supportwm42017-08-071-1/+1
| | | | Fixes #4720, I think.
* video: drop some more IMGFMT aliaseswm42017-06-292-27/+52
| | | | | | | | | | | For vo_opengl and vo_direct3d, these are supported in a generic way. For vf_vapoursynth, we could probably map its VSFormat struct in a generic way, but for now do some bullshit. vf_eq.c actually loses support for these formats. We could add generic support too (anything that has 8 bit planes will work), but why bother. The filter is deprecated anyway.
* vf_format: also reset gamma-related attributes when changing gammaNiklas Haas2017-06-181-1/+9
| | | | | | This prevents nasty surprises like the sig-peak still being left at 1.0 when reinterpreting SDR as HDR, or the OOTF for HLG being left as display-referred.
* vo_opengl: implement support for OOTFs and non-display referred contentNiklas Haas2017-06-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces (yet another..) mp_colorspace members, an enum `light` (for lack of a better name) which basically tells us whether we're dealing with scene-referred or display-referred light, but also a bit more metadata (in which way is the scene-referred light expected to be mapped to the display?). The addition of this parameter accomplishes two goals: 1. Allows us to actually support HLG more-or-less correctly[1] 2. Allows people playing back direct “camera” content (e.g. v-log or s-log2) to treat it as scene-referred instead of display-referred [1] Even better would be to use the display-referred OOTF instead of the idealized OOTF, but this would require either native HLG support in LittleCMS (unlikely) or more communication between lcms.c and video_shaders.c than I'm remotely comfortable with That being said, in principle we could switch our usage of the BT.1886 EOTF to the BT.709 OETF instead and treat BT.709 content as being scene-referred under application of the 709+1886 OOTF; which moves that particular conversion from the 3dlut to the shader code; but also allows a) users like UliZappe to turn it off and b) supporting the full HLG OOTF in the same framework. But I think I prefer things as they are right now.
* video: refactor HDR implementationNiklas Haas2017-06-181-4/+5
| | | | | | | | | | | | | | | List of changes: 1. Kill nom_peak, since it's a pointless non-field that stores nothing of value and is _always_ derived from ref_white anyway. 2. Kill ref_white/--target-brightness, because the only case it really existed for (PQ) actually doesn't need to be this general: According to ITU-R BT.2100, PQ *always* assumes a reference monitor with a white point of 100 cd/m². 3. Improve documentation and comments surrounding this stuff. 4. Clean up some of the code in general. Move stuff where it belongs.
* vf_dlopen: remove this filterwm42017-06-183-447/+0
| | | | | | | | | | | | | | | | It was an attempt to move some MPlayer filters (which were removed from mpv) to external, loadable filters. That worked well, but then the MPlayer filters were ported to libavfilter (independently), so they're available again. Also there is a more widely supported and more advanced loadable filter system supported by mpv: vapoursynth. In conclusion, vf_dlopen is not useful anymore, confusing, and requires quite a bit of code (and probably wouldn't survive the rewrite of the mpv video filter chain, which has to come at some point). It has some implicit dependencies on internal conventions, like possibly the format names dropped in the previous commit. We also deprecated it last release. Drop it.
* af, vf: improvements to libavfilter bridgewm42017-05-312-1/+8
| | | | | | Add the "lavfi-" prefix (details see manpage additons). Tag the filter name as "(lavfi)" in the verbose filter list output.
* vf.c, vf.h: change license to LGPLwm42017-05-112-14/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most authors have agreed. Like with vo.c, we don't take module declarations into consideration (see 0e09533c73dc0). Notable issues: 115bfb9762: the author has (probably) not agreed. The vf.c changes were removed with the removal of filter DR, though (see c54fc507da8e). 7b25afd742: the same author adds VOCTRLs for deinterlacing switching at runtime. Put them under a HAVE_GPL ifdef just to be sure. (It looks like we could remove the VOCTRLs immediately, as they're needed only for some compatibility things, but no need to do that yet.) 02b199e5e9: the author had a conditional agreement to LGPL, which doesn't allow us to change it just yet, but the code added here was completely removed anyway. (These days, the pts is passed as mp_image field, and put_image is gone.) 3532cd532e: same author, but code removed with DR removal. f0626e2f8d: same author, but code was moved to mp_image.c. e5b4b495c3: agreed to LGPLv3+ only, but the code was removed in cfa1f9e082 anyway. 086c324692: author was not asked - minor warning fix, but no mpv includes malloc.h anymore. e9d0a1d609: author was not asked - removed again in 33b62af947. c260a1139d: author could not be reached - but this code was removed when mpv changed the image allocation code to essentially use FFmpeg's pixdesc.
* d3d11: change mp_image plane pointer semanticswm42017-05-041-5/+5
| | | | | | | | Until now, the texture pointer was stored in plane 1, and the texture array index was in plane 2. Move this down to plane 0 and plane 1. This is to align it to the new WIP D3D11 decoding API in Libav, where we decided that there is no reason to avoid setting plane 0, and that it would be less weird to start at plane 0.
* vf_lavfi, af_lavfi: remove unused/deprecated includewm42017-04-051-1/+0
| | | | | Looks like Libav is going to drop it, unnecessarily making compilation fail.
* vf: fix another broken case of conversion filter auto-insertionwm42017-04-051-0/+37
| | | | | | | | | | | | | | | | | | | | If the VO doesn't support a format output by vf_lavfi, no conversion filter was inserted, and filter chain creation failed. This is because vf_lavfi doesn't properly follow the format negotiation model, which means the format negotiation pass does not catch all cases where conversion is needed. Specifically, vf_lavfi supports that all output formats are supported for any given input format, but then does not actually call vf_next_query_format() in reconfig() to check which format it uses, but outputs whatever it gets from libavfilter. I think this is ok to avoid excessive complexity in vf_lavfi.c, but it also means adding more kludges to vf.c. I justify this (and the code duplication) with the idea that the current filter chain code will die anyway at some point. The .log field additions for c->first/c->last are strictly speaking not needed, but useful for debugging.
* video: support positional arguments for automatic lavfi option bridgewm42017-04-031-1/+1
| | | | | | Now e.g. --vf=pad=1000:1000 works. All in all pretty ugly and hacky. Just look away.
* video: add automatic libavfilter bridge to option parsingwm42017-04-022-15/+106
| | | | | | | | | | Now you can for example do "--vf=hue=h=60" - there is no "hue" filter in mpv, so libavfilter's will be used. This has certain caveats (see manpage). The point of this is providing a relatively smooth transition path to removing our own filter stuff.
* video: deprecate almost all video filterswm42017-04-0218-1/+53
| | | | | | | | | | | | | The plan is to nuke the custom filter chain completely. It's not clear what will happen to the still needed builtin filters (mostly hardware deinterlacing and vf_vapoursynth). Most likely we'll replace them with different filter chain concept (whose main purpose will be providing builtin things and bridging to libavfilter). The undocumented "warn" options are there to disable deprecation warnings when the player inserts filter automatically. The same will be done to audio filters, at a later point.
* command: add better runtime filter toggling methodwm42017-03-251-0/+3
| | | | | | | | | | Basically, see the example in input.rst. This is better than the "old" vf-toggle method, because it doesn't require the user to duplicate the filter string in mpv.conf and input.conf. Some aspects of this changes are untested, so enjoy your alpha testing.
* options: add M_OPT_FILE to some more file optionsPhilip Sequeira2017-03-061-1/+1
| | | | (Helps shell completion.)
* 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_lavfi: don't crash with VOs without hardware decoding supportwm42017-01-251-5/+7
| | | | | | | | | When playing with VOs which do not provide mp_hwdec_ctx, vf->hwdec_devs will remain NULL. This would make it crash on hwdec_devices_get_first(), even if no hardware decoding or filters using hardware decoding were involved. Fixes #4064.
* build: replace some FFmpeg API checks with version checkswm42017-01-241-1/+1
| | | | | | The FFmpeg versions we support all have the APIs we were checking for. Only Libav missed them. Simplify this by explicitly checking for FFmpeg in the code, instead of trying to detect the presence of the API.
* video: support filtering hardware frames via libavfilterwm42017-01-163-6/+49
| | | | | | | | | | | | | | | | | | | | | | | | Requires a bunch of hacks: - we access AVFilterLink.hw_frames_ctx. This is not a public API in FFmpeg and Libav. Newer FFmpeg provides an accessor (av_buffersink_get_hw_frames_ctx), but it's not available in Libav or the current FFmpeg release or Libav. We need this value after filter graph creation, so We have no choice but to access this. One alternative is making filter creation and format negotiation fully lazy (i.e. delay it and do it as filters are output), but this would be a huge change. So for now, we knowingly violate FFmpeg's and Libav's ABI and API constraints because they don't provide anything better. On newer FFmpeg, we use the (quite ugly) accessor, though. - mp_image_params doesn't (and can't) have a field for the frames context AVBufferRef. So we pass it via vf_set_proto_frame(), and even more hacks. - if a filter needs a hw context, but we haven't created one yet (because normally we create them lazily), it will fail at init. - we allow any hw format now, although this could go horrible wrong. Why all this effort? We could move hw deinterlacing filters etc. to FFmpeg, which is a very worthy goal.
* vf_lavfi: switch to AVBufferSrcParameterswm42017-01-161-7/+20
| | | | | | Instead of using the awful older "API" that passed the parameters formatted as string. AVBufferSrcParameters is also a prerequisite for hardware frame filtering support.
* vf_lavfi: remove pixel format whitelistwm42017-01-131-22/+2
| | | | Pointless now.
* af_lavfi, vf_lavfi: work around recent libavfilter EOF bugwm42017-01-021-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | Looks quite like a bug. If you have a filter chain with only the dynaudnorm filter, and send call av_buffersrc_add_frame(s, NULL), then subsequent av_buffersink_get_frame() calls will return EAGAIN instead of EOF. This was apparently caused by a recent change in FFmpeg. Some other circumstances (which I didn't fully analyze and which is due to the playloop's absurd temporary-EOF behavior on seeks) then led the decoder loop to send data again, but since libavfilter was stuck in the EOF state now, it could never recover. It kept sending new input (due to missing output), until the demuxer refused to return more audio packets. Each time a filter error was printed. Fortunately, it's pretty easy to workaround. We just mark the p->eof flag as we send an EOF frame to libavfilter. The p->eof flag is used only to recover from temporary EOF: it resets the filter if new data is available again. We don't care much about av_buffersink_get_frame() returning a broken EAGAIN state in this situation and essentially ignore it, meaning if we get EAGAIN after sending EOF, we assume effectively that EOF was fully reached.
* vf_vdpaurb: remove this filterwm42016-11-222-112/+0
| | | | Was deprecated, superseded by --hwdec=vdpau-copy.
* vf_vdpaurb: deprecate this filterwm42016-10-201-0/+3
|
* win32: build with -DINITGUIDJames Ross-Gowan2016-09-281-1/+0
| | | | | | | | | | | | We always want to use __declspec(selectany) to declare GUIDs, but manually including <initguid.h> in every file that used GUIDs was error-prone. Since all <initguid.h> does is define INITGUID and include <guiddef.h>, we can remove all references to <initguid.h> and just compile with -DINITGUID to get the same effect. Also, this partially reverts 622bcb0 by re-adding libuuid.a to the build, since apparently some GUIDs (such as GUID_NULL) are not declared in the source file, even when INITGUID is set.
* m_config: add helper function for initializing af/ao/vf/vo suboptionswm42016-09-021-4/+4
| | | | | | | | Normally I'd prefer a bunch of smaller functions with fewer parameters over a single function with a lot of parameters. But future changes will require messing with the parameters in a slightly more complex way, so a combined function will be needed anyway. The now-unused "global" parameter is required for later as well.
* options: make mp_vo_opts options an actual sub-option groupwm42016-08-301-1/+1
| | | | | | | | | | | Just a minor refactor along the planned option change. This commit will make it easier to update (i.e. copy) the VO options without copying _all_ options. For now, behavior should be equivalent, though. (The VO options were put into a separate struct quite early - when all global variables were removed from the source code. It wasn't clear whether the separate struct would have any actual purpose, but it seems it will now. Awesome, huh.)
* vf_rotate: allow arbitrary rotationwm42016-08-191-2/+9
| | | | | | | vf_rotate selects the correct filter for 90° rotation, but it can be extended to use lavfi's vf_rotate as fallback. See #3434.
* video: don't discard video frames after endptswm42016-08-182-0/+8
| | | | | | | | | | | | Instead of letting it keep decoding by trying to find a new frame, "plug" the frame queue by not removing it. (Or actually, by putting it back instead of discarding it.) Matters for seamless looping (following commits), and possibly some other corner cases. The added function vf_unread_output_frame() is a bit of a sin, but still reasonable, since its implementation is trivial.
* vf_vavpp: get rid of mp_refqueue_is_interlaced()wm42016-07-153-11/+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.
* vf_d3d11vpp: fix interlaced-only=no modewm42016-07-151-2/+2
| | | | | | "Real" frame flag vs. what we pretend it to be. It always used the real flag, and thus never deinterlaced unflagged frames, even if the suboption was set to "no".
* vf_d3d11vpp: add video processor selectionwm42016-07-151-5/+20
| | | | | Unfortunately completely useless. I still don't know how to force a video processor to use a specific algorithm, if it's even possible.
* vd_d3d11vpp: remove nonsensical flush callwm42016-07-081-5/+0
| | | | | | | | I made this call up because I sort of thought this makes senssssse. I'm now convinced that it does not, and even is actively harmful. I'm still quite in the dark how the DirectD 11 video API is supposed to work with synchronization, but at least for normal graphics this call would not make much sense.
* vf, af: print filter labels in verbose modewm42016-07-061-0/+2
|
* vf: mark filter chain as uninitialized when mutating itwm42016-07-061-0/+2
| | | | | Sounds fair. Can be used to determine if the filter chain was mutated at all, and avoiding unconditional reinit if it wasn't.
* vf: don't clobber input params on reconfigure failurewm42016-07-061-1/+1
| | | | I think this is more robust, and future commits will rely on it.
* vf_d3d11vpp: fix output image format if not doing any filteringwm42016-07-041-2/+5
| | | | | | | For example it should be set to IMGFMT_D3D11NV12 if it isn't already. Otherwise, an assertion in vf.c could trigger. This probably couldn't be provoked yet.
* vo_opengl: generalize HDR tone mapping mechanismNiklas Haas2016-07-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
* mp_image: split colorimetry metadata into its own structNiklas Haas2016-07-035-17/+17
| | | | | | | | | | | | | | | | | | 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_vdpaurb: use new common nv12 download codewm42016-06-211-15/+5
| | | | | | |