summaryrefslogtreecommitdiffstats
path: root/video/filter
Commit message (Collapse)AuthorAgeFilesLines
* vf_gpu: render subtitleswm42019-11-301-1/+9
| | | | | | | Pretty annoying affair. The vo_gpu code could of course not trigger rendering from filters yet, so it needed to be extended. Also, this uses some icky stuff made for vf_sub (and this was the reason I marked vf_sub as deprecated), so everything is terrible.
* vf_gpu: add video filter using vo_gpu's rendererwm42019-11-291-0/+364
| | | | | | | | | Probably pretty useless in this form (see: the wall of warnings), but someone wanted this. I think this should be useful to perform some automated tests, maybe. Fixes: #7194
* sws_utils, zimg: destroy vo_x11 and vo_drm performancewm42019-10-311-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Raise swscale and zimg default parameters. This restores screenshot quality settings (maybe) unset in the commit before. Also expose some more libswscale and zimg options. Since these options are also used for VOs like x11 and drm, this will make x11/drm/etc. much slower. For compensation, provide a profile that sets the old option values: sw-fast. I'm also enabling zimg here, just as an experiment. The core problem is that we have a single set of command line options which control the settings used for most swscale/zimg uses. This was done in the previous commit. It cannot differentiate between the VOs, which need to be realtime and may accept/require lower quality options, and things like screenshots or vo_image, which can be slower, but should not sacrifice quality by default. Should this have two sets of options or something similar to do the right thing depending on the code which calls libswscale? Maybe. Or should I just ignore the problem, make it someone else's problem (users who want to use software conversion VOs), provide a sub-optimal solution, and call it a day? Definitely, sounds good, pushing to master, goodbye.
* filters: extend vf_format so that it can convert color parameterswm42019-10-211-36/+52
| | | | | | | | | | | | | | | | | | | | | | | | | Form some reason (and because of my fault), vf_format converts image formats, but nothing else. For example, setting the "colormatrix" sub-parameter would not convert it to the new value, but instead overwrite the metadata (basically "reinterpreting" the image data without changing it). Make the historical mistake worse, and go all the way and extend it such that it can perform a conversion. For compatibility reasons, this needs to be requested explicitly. (Maybe this would deserve a separate filter to begin with, but things are messed up anyway. Feel free to suggest an elegant and simple solution.) This demonstrates how zimg can properly perform some conversions which swscale cannot (see examples added to vf.rst). Stupidly this requires 2 code paths, one for conversion, and one for overriding the parameters. Due to the filter bullshit (what was I thinking), this requires quite some acrobatics that would not be necessary without these abstractions. On the other hand, it'd definitely be more of a mess without it. Oh whatever.
* vf_fingerprint: don't print fallback warning on each framewm42019-10-211-2/+0
| | | | | | | | f_reset, which is called on seeks, was a good place for resetting the warning flag (so the warning would be print again). Except some other code abused f_reset when all metadata was read (in both cases you want to clear the metadata). Instead of spending more time on getting this flag reset correctly, just never reset it.
* vf_fingerprint: remove single-plane optimizationwm42019-10-201-31/+1
| | | | | | | | | | | | | | According to the zimg author, YUV->GREY conversion does not even read the chroma planes, as long as no matrix conversion is involved. Since we try to avoid the latter anyway by forcing the source parameters on the target image, passing only the Y plane will not help with anything. An unscientific test seems to confirm this, so remove this. This would probably help with libswscale (I didn't test this), but on the other hand, libswscale will rarely be used in cases where we can extract the Y plane. (Except nv12, which should probably be added to the zimg wrapper's unpacking.)
* vf_fingerprint: use generic zimg wrapperwm42019-10-201-79/+29
| | | | | Don't duplicate the API usage. The result should be approximately the same.
* video, demux: rip out unused spherical metadata codewm42019-10-171-14/+0
| | | | | | This was preparation into something that never happened. Spherical video is a shit idea anyway.
* video: remove mp_image_params.hw_flags fieldwm42019-10-171-1/+0
| | | | | | | | This was speculatively added 2 years ago in preparation for something that apparently never happened. The D3D code was added as an "example", but this too was never used/finished. No reason to keep this.
* vf_d3d11vpp: remove RGB conversion hackwm42019-10-161-49/+5
| | | | | | | With the previous commit, this is dead code. This also makes the f_autoconvert.c code for this dead code (fortunately). Will probably remove this later.
* vf_fingerprint: fix an obvious memory leakwm42019-10-031-4/+12
| | | | | | Leaks the entire zimg state on filter deinit. Not sure what I was thinking; with some luck, I just didn't give a shit about this case, but most likely I was thinking the same thing as always: nothing.
* vf_vapoursynth: fix crashing memory management mistakewm42019-10-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As pointed out by @olifre in #7016, this line of code was wrong. p->opts at this point is a struct allocated and managed by m_config. opts->file is a string, and m_config explicitly frees it on destruction. The line of code in question replaced the opts->file value, and made both the old and new value children of the talloc allocation, so they were _also_ freed on destruction. This crashed due to a double-free. First, talloc auto-freeing freed the string, then m_config explicitly called talloc_free() on the stale pointer again. As @v-fox pointed out, commit 36dd2348a1e1 seems to have triggered the crash. I suspect this code merely worked out of coincidence, since it allowed m_config to free the value first. This removed it from the auto-free list, and thus did not result in a double-free. The change in order of calling alloc destructors changed the order of these calls. There is no strong reason why new behavior (as introduced by commit 36dd2348a1e1) would be wrong (it feels like cleaner behavior). On the other hand, what the vf_vapoursynth code did is clearly unclean and going by the m_config API, you're not at all supposed to do this. m_config manages all memroy referenced by option structs, the end. @olifre's suggested fix also would have been correct (not just hiding the issue), I prefer my fix, as it doesn't mess with the option struct in tricky ways. This wouldn't have happened if mpv were written in Haskell.
* vf_vapoursynth: do not call vsscript_finalize() if init failedwm42019-10-031-1/+5
| | | | | If vsscript_finalize() is not matched by a successful vsscript_init(), an assert in the vsscript library triggers. Makes sense, I guess.
* vf_vapoursynth: remove some Lua backend remainswm42019-10-031-6/+0
| | | | Pretty funny.
* video: remove vf_vavpp from automatic deinterlace propertywm42019-10-021-9/+0
| | | | | | | | | | | | | | This reverts commit 6385a5fd1b8a67c051b82d48c993a6591e8f93c6, and in addition removes the code that automatically inserts the vavpp filter. The reason is the same as the commit that is being reverted: this filter seems to trigger driver bugs. It can cause GPU freezes or just doesn't work. This variant of disabling the filter is better. There was no way to add the "force" parameter to the automatically inserted filter, so the old approach just made manual filter insertion (with the --vf option or "vf" command) more cumbersome.
* vf_fingerprint: remove extraneous single quote from descriptionJan Ekström2019-09-211-1/+1
| | | | | | This happened to break ZSH completion and seemed to be extraneous. Reported by LaserEyess on IRC.
* vf_fingerprint: use aligned_alloc instead of posix_memalignwm42019-09-191-2/+2
| | | | | | | | | | | I was assuming posix_memalign was the most portable function to use, but MinGW does not provide it for some reason. Switch to C11 aligned_alloc() which someone suggested was provided by MinGW (but actually isn't, someone probably confused it with the incompatible _aligned_malloc), and add a configure check. Even though it turned out that MinGW doesn't provide it, the function is slightly more elegant than posix_memalign(), so stay with it.
* video: add vf_fingerprint and a skip-logo scriptwm42019-09-191-0/+293
| | | | | | | | | | | | | | | | | | | | | | | | | skip-logo.lua is just what I wanted to have. Explanations are on the top of that file. As usual, all documentation threatens to remove this stuff all the time, since this stuff is just for me, and unlike a normal user I can afford the luxuary of hacking the shit directly into the player. vf_fingerprint is needed to support this script. It needs to scale down video frames as part of its operation. For that, it uses zimg. zimg is much faster than libswscale and generates more correct output. (The filter includes a runtime fallback, but it doesn't even work because libswscale fucks up and can't do YUV->Gray with range adjustment.) Note on the algorithm: seems almost too simple, but was suggested to me. It seems to be pretty effective, although long time experience with false positives is missing. At first I wanted to use dHash [1][2], which is also pretty simple and effective, but might actually be worse than the implemented mechanism. dHash has the advantage that the fingerprint is smaller. But exact matching is too unreliable, and you'd still need to determine the number of different bits for fuzzier comparison. So there wasn't really a reason to use it. [1] https://pypi.org/project/dhash/ [2] http://www.hackerfactor.com/blog/index.php?/archives/529-Kind-of-Like-That.html
* vf_vapourynth: remove Lua backendwm42019-09-191-241/+1
| | | | | | | | | | | | | | | I once created this because someone wanted to use vapoursynth without the Python dependency. No idea if anyone ever actually used it. It's sort of icky (it calls itself "lazy" to preempt complaints about how much it sucks), and complicates the build process. Kill it. It seems much more promising to have something like this: https://github.com/vapoursynth/vapoursynth/issues/386 This would either solve the build distribution problem by relaxing the Python dependency, and/or allow a Lua backend to be included without pain.
* vf_vavpp: disable this filterwm42019-09-151-0/+9
| | | | | Might be unreasonable, but I'm angry at the shit driver freezing my machine.
* vf_vapoursynth: allow multithreaded writing of source framesChainik2019-07-081-0/+3
|
* vf_vapoursynth: allow multithreaded reading of returned framesChainik2019-07-081-8/+9
|
* vf_vapoursynth: correctly signal error on script init failurewm42018-04-291-0/+1
| | | | Otherwise it will do nothing, waiting on nothing forever.
* video: remove internal stereo_out flagwm42018-04-291-5/+1
| | | | | | Also rename stereo3d to stereo_in. The only real change is that the vo_gpu OSD code now uses the actual stereo 3D mode, instead of the --video-steroe-mode value. (Why does this vo_gpu code even exist?)
* video: pass through container fps to filterswm42018-04-191-6/+4
| | | | | | | | | | | | This means vf_vapoursynth doesn't need a hack to work around the filter code, and libavfilter filters now actually get the frame_rate field on input pads set. The libavfilter doxygen says the frame_rate field is only to be set if the frame rate is known to be constant, and uses the word "must" (which probably means they really mean it?) - but ffmpeg.c sets the field to mere guesses anyway, and it looks like this normally won't lead to problems.
* vf_vapoursynth: fix freezewm42018-02-201-5/+7
| | | | | | | Commit 59f9547fb56b missed this case, in which we can't make new progress and have to exit. Fixes #5548.
* 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-133-3/+3
| | | | | | | | | | | | | | | | 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.
* vf_vapoursynth: always keep input frame array filledwm42018-02-031-1/+3
| | | | | | | | In theory (and practice), this is not needed, because the VS filter get frame callback will cause the process function to be called again if there's not enough data. But it's still a bit weird to just add one more frame on each iteration, so make it cleaner and make it request frames until the input array is full.
* vf_vapoursynth: fix lockingwm42018-02-031-1/+2
| | | | | | | | This was obviously nonsense, and a previous "fix" to this code was nonsense too. What is really needed here is temporarily dropping the lock while calling destroy_vs()/reinit_vs(). Fixes #5470.
* vf_vapoursynth: fix obscure/impossible leakwm42018-02-031-0/+1
| | | | | | | Unknown frames were not freed properly. Although this doesn't really happen anyway, because we're never going to feed audio frames to a video filter chain. Since it's theoretically possible, and all other filters handle this consistently, fix it anyway.
* vf_vapoursynth: fix output colorspace flags and other attributeswm42018-02-031-0/+2
| | | | | | | Properly initialize the output frame parameters other than image format and size. This includes colorspace hints. (We're still not reading them back from VapourSynth if it sets them, though. Usually it doesn't anyway.)
* vf_vapoursynth: fix potential deadlock on init failurewm42018-02-031-1/+1
| | | | | When VS initialization failed, it could hang due to forgetting to release the mutex.
* vf_vapoursynth: initialize start timestamp properlywm42018-02-031-1/+1
| | | | | | | | | VapourSynth can't pass through timestamps, only frame durations. So we need to remember the timestamp of the very first frame passed to it. This was accidentally set to 0 instead of NOPTS on init, so inserting the filter during playback could show strange behavior. Might be part of #5470.
* video: rewrite filtering glue codewm42018-01-3012-2583/+1031
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* sws_utils: don't force callers to provide option structwm42018-01-181-1/+1
| | | | | | | mp_sws_set_from_cmdline() has the only purpose to respect the --sws- command line options. Instead of forcing callers to get the option struct containing these, let callers pass mpv_global, and get it from the option core code directly. This avoids minor annoyances later on.
* video: change some mp_image_pool semanticswm42018-01-132-2/+2
| | | | | | | | | | Remove the max_count creation parameter, because it's pointless and rarely ever did anything. Add a talloc parent parameter instead (which is something completely different, but convenient, and all callers needs to be changed anyway). Instead of clearing the pool when the now removed maximum is reached, clear it on image parameter changes instead.
* vf_vdpaupp: fix error handling and software input modewm42017-12-271-5/+9
| | | | | | | | Crashed when no vdpau device was loaded. Also there was a mistake of not setting p->ctx, which broke software surface input mode. This was not found before, because p->ctx is not needed for anything else. Fixes #5294.
* msg: reinterpret a bunch of message levelsNiklas Haas2017-12-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | I've decided that MP_TRACE means “noisy spam per frame”, whereas MP_DBG just means “more verbose debugging messages than MSGL_V”. Basically, MSGL_DBG shouldn't create spam per frame like it currently does, and MSGL_V should make sense to the end-user and provide mostly additional informational output. MP_DBG is basically what I want to make the new default for --log-file, so the cut-off point for MP_DBG is if we probably want to know if for debugging purposes but the user most likely doesn't care about on the terminal. Also, the debug callbacks for libass and ffmpeg got bumped in their verbosity levels slightly, because being external components they're a bit less relevant to mpv debugging, and a bit too over-eager in what they consider to be relevant information. I exclusively used the "try it on my machine and remove messages from MSGL_* until it does what I want it to" approach of refactoring, so YMMV.
* vf_buffer: remove this filterwm42017-12-122-87/+0
| | | | | It has been deprecated for a while and is 100% useless. It was forgotten in the recent filter purge. Get rid of it.
* vf_convert: default to limited range when converting RGB to YUVwm42017-12-111-0/+5
| | | | | | | | | | Full range YUV causes problems everywhere. For example it's usually the wrong choice when using encoding mode, and libswscale sometimes messes up when converting to full range too. (In this partricular case, we found that converting rgba->yuv420p16 full range actually seems to output limited range.) This actually restores a similar heueristic from the late vf_scale.c.
* video: remove some more hwdec legacy stuffwm42017-12-023-11/+47
| | | | | | | | | 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: remove a stray HAVE_GPLwm42017-11-301-3/+0
| | | | These were determined to be LGPL a few commits ago.
* vf_lavfi: remove old internal wrapper API stuffwm42017-11-292-117/+0
| | | | | This was for filters "redirecting" to vf_lavfi. All filters using it have been removed.
* vf_sub, vf_format: change license to LGPLwm42017-11-292-24/+15
| | | | | | | | | | | | They were added to the "to deleted" list and never relicensed, because I thought I'd delete them early. But it's possible that they'll stay in mpv for a longer time, so relicense them. Still leaving them as deprecated and scheduled for removal, so they can still be dropped once there is a better way to deal with them, if they get annoying, or if a better mechanism is found that makes them unnecessary. All contributors agreed. There are some minor changes by people who did not agree, but these are all not relevant or have been removed.
* vf: remove most GPL video filterswm42017-11-2913-1500/+0
| | | | | | | | | | | | | Almost all of them had their guts removed and replaced by libavfilter long ago, but remove them anyway. They're pointless and have been scheduled for deprecation. Still leave vf_format (because we need it in some form) and vf_sub (not sure). This will break some builtin functionality: lavfi yadif defaults are different, auto rotation and stereo3d downconversion are broken. These might be fixed later.
* vf: add vf_convert as interim replacement for vf_scalewm42017-11-292-2/+132
| | | | | | | | | | | We want to drop vf_scale, but we still need a way to auto convert between imgfmts. In particular, vf.c will auto insert the "scale" filter if the VO doesn't support a pixfmt. To avoid chaos, create a new vf_convert.c filter, based on vf_scale.c, but without the unrelicensed code parts. In particular, this filter does not do scaling and has no options. It merely converts from one imgfmt to another, if needed.
* Get rid of deprecated AVFrame accessorswm42017-10-301-1/+1
| | | | | | Fist we were required to use them for ABI compat. reasons (and other BS), now they're deprecated and we're supposed to access them directly again.
* video: add mp_image_params.hw_flags and add an examplewm42017-10-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems this will be useful for Rokchip DRM hwcontext integration. DRM hwcontexts have additional internal structure which can be different depending on the decoder, and which is not part of the generic hwcontext API. Rockchip has 1 layer, which EGL interop happens to translate to a RGB texture, while VAAPI (mapped as DRM hwcontext) will use multiple layers. Both will use sw_format=nv12, and thus are indistinguishable on the mp_image_params level. But this is needed to initialize the EGL mapping and the vo_gpu video renderer correctly. We hope that the layer count is