summaryrefslogtreecommitdiffstats
path: root/video/filter
Commit message (Collapse)AuthorAgeFilesLines
* video: move formatting of image parameters to separate functionwm42014-11-121-21/+2
|
* vf: minor simplificationwm42014-11-122-16/+9
| | | | | | | | Remove the extra vf_chain.output field - there's absolutely no need for it, because there is always a last filter which will buffer the output. For some reason, vf_chain.last was never set, which we now need to fix too.
* vf_sub: fix previous commitwm42014-11-111-3/+3
| | | | | | The previous fix breaks another obscure case: if the second vf_sub adds margins, the image is accidentally not extended, which would return in an assertion failure when returning the bogus image.
* vf_sub: don't crash if no subtitle context is availablewm42014-11-111-0/+3
| | | | Happens with --vf=sub,sub (only the first one gets the context).
* video: remove swapped-endian image format aliaseswm42014-11-051-32/+16
| | | | | Like the previous commit, this removes names only, not actual support for these formats.
* vf_vapoursynth: add debug message when returning error from GetFramewm42014-10-131-0/+1
| | | | | Some filters still (or will) behave badly on these errors, so explicitly log when it happens.
* vf_vapoursynth: don't error if invoke() doesn't return a clipwm42014-10-121-3/+2
| | | | | Not all functions are for creating filters. Consider for example LoadPlugin.
* vf_vapoursynth: resolve paths relative to home/configwm42014-10-121-0/+3
| | | | | This affects the script filename passed to the filter. Resolve "~" (and some other variants) as described in the "Paths" section of mpv.rst.
* vf_vapoursynth: add standalone Lua scriptingwm42014-10-122-1/+262
|
* vf_vapoursynth: abstract scripting backendwm42014-10-121-28/+87
| | | | | | In theory, vsscript should be doing it, but it's not there yet, neither did there seem to be any interest in making it flexible enough to handle more than 1 scripting language.
* vf_vapoursynth: return dummy frames if frames are requested during initwm42014-10-111-1/+12
| | | | | | An attempt at fixing #1168. I see black frames flashing, so it's certainly not perfect.
* vf_vapoursynth: factor stuffwm42014-10-111-13/+25
|
* vf_vapoursynth: when seeking, recreate only if it's already createdwm42014-10-111-1/+2
|
* vf_vapoursynth: fail gracefully if filter init requests frameswm42014-10-111-0/+10
| | | | | | | | | | | | | | | | | Some VS filters will requests frames from their parent filters while they're initialized. Thy do this in a blocking manner, and initialization will not succeed until the frame request is satisfied. This deadlocked mpv, because we can feed frames to the filter only after initialization is finished. Return an error instead of deadlocking. Note that we (probably) can handle frames being requested during init fine, as long as the requests don't block initialization. But we can distinguish this situation, and a simple test seems to indicate VS usually doesn't do this. See #1168.
* vf_lavfi: proper rounding for lavfi->mpv aspect ratiowm42014-10-091-2/+3
| | | | Or so I think. Not like it matters anyway.
* vf_lavfi: fix compilation failurewm42014-10-081-1/+0
| | | | | | Apparently this fails to compile with clang6. Patch by someone else. CC: @mpv-player/stable
* vf_stereo3d: fix "auto" input format with libavAlessandro Ghedini2014-10-041-1/+1
|
* Fix build with libavfilter disabledwm42014-09-281-1/+1
| | | | Although I'm not sure why we even support this.
* video: change automatic rotation and 3D filter insertionwm42014-09-272-11/+111
| | | | | | | | | | | | | | | | | | | | | We inserted these filters with fixed parameters, which was ok. But this also didn't change image parameters for the filters down the filter chain and the VO. For example, if rotation by 90° was requested by the file, we would insert a filter and rotate the video, but the VO would still receive image parameters that direct rotation by 90°. This wasn't a problem, but it could become one. Fix this by letting the filters automatically pick up the image params. The image params are reset on application. (We could probably also always try to apply and reset image params in a filter, instead of having special "auto" parameters. This would probably work, and video.c would insert a "rotate=0" filter. But I'm afraid this would be confusing and the current solution is cosmetically slightly nicer.) Unfortunately, the vf_stereo3d.c change turned out a big mess, but once the "internal" filter is fully replaced with libavfilter, most of this can be radically simplified.
* vf_lavfi: make chaining from other filters more flexiblewm42014-09-273-26/+45
| | | | | | | | | Some filters exists only to create a specific lavfi graph. Allow these filters to reset the graph exactly on reconfig, and allow them to modify some image parameters too. Also make vf_lw_update_graph() behave like vf_lw_set_graph() - they had a subtitle difference with filter==NULL. Useful for the following commit.
* Remove mpbswap.hwm42014-09-251-3/+4
| | | | | | This was once central, but now it's almost unused. Only vf_divtc still uses it for extremely weird and incomprehensible reasons. The use in stream.c is trivial. Replace these, and remove mpbswap.h.
* vf_vapoursynth: make it possible to get filter output incrementallywm42014-09-231-27/+77
| | | | | | | | | | | | | | | | | Until now, we always required the playback core to decode a new frame to get more output from the filter. That seems to be completely unnecessary, because filtered results may arrive before that. Add a filter_out callback, and restructure the code such that it can return any filtered frames, or block if it hasn't read at least one frame. In the worst case, it still can happen that bursts of input requests and output requests happen. (This commit tries to reduce burst-like behavior, but it's not entirely possible due to the indeterministic nature of VS threading.) This is a similar change as with 95bb0bb6.
* vf_lavfi: fetch output frames incrementallywm42014-09-181-22/+24
| | | | | | | Uses the new mechanism introduced in the previous commit. Depending on the actual filter, this distributes CPU load more evenly over time, although it probably doesn't matter.
* video/filter: allow better dataflowwm42014-09-182-2/+20
| | | | | | | | | Consider a filter which turns 1 frame into 2 frames (such as an deinterlacer). Until now, we forced filters to produce all output frames at once. This was done for simplicity. Change the filter API such that a filter can produce frames incrementally.
* video: initial Matroska 3D supportwm42014-08-301-0/+2
| | | | | | | | | | | | | | | | | | | | | This inserts an automatic conversion filter if a Matroska file is marked as 3D (StereoMode element). The basic idea is similar to video rotation and colorspace handling: the 3D mode is added as a property to the video params. Depending on this property, a video filter can be inserted. As of this commit, extending mp_image_params is actually completely unnecessary - but the idea is that it will make it easier to integrate with VOs supporting stereo 3D mogrification. Although vo_opengl does support some stereo rendering, it didn't support the mode my sample file used, so I'll leave that part for later. Not that most mappings from Matroska mode to vf_stereo3d mode are probably wrong, and some are missing. Assuming that Matroska modes, and vf_stereo3d in modes, and out modes are all the same might be an oversimplification - we'll see. See issue #1045.
* vf_softpulldown: handle null mpi_image correctlyshdown2014-08-301-3/+3
| | | | Check if mpi is NULL before accessing mpi->fields.
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-292-2/+1
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* vf_vapoursynth: add more VS frame propertiesBin Jin2014-08-221-0/+8
| | | | Add the missing frame properties in 48587e88.
* vf_vapoursynth: add display resolution supportBin Jin2014-08-221-0/+5
| | | | | | | | | | | | Add two new script environment variables 'video_in_dw' and 'video_in_dh', representing the display resolution of video. Along with video resolution, sample ratio aspect can be calculated in scripts. Currently it's impossible to change sample ratio aspect with single vapoursynth filter since '_SARNum' and '_SARDen' frame properties from output clip will be ignored. A following 'dsize' filter is necessary for this purpose.
* vf_vapoursynth: print more diagnostics on errorwm42014-08-111-3/+9
|
* Improve setting AVOptionswm42014-08-021-9/+6
| | | | | | | | Use OPT_KEYVALUELIST() for all places where AVOptions are directly set from mpv command line options. This allows escaping values, better diagnostics (also no more "pal"), and somehow reduces code size. Remove the old crappy option parser (av_opts.c).
* video/filter: add vf_bufferwm42014-07-302-0/+95
| | | | Mostly useful for debugging.
* Remove some mp_msg calls with no trailing \nwm42014-07-131-18/+22
| | | | | | | The final goal is all mp_msg calls produce complete lines. We want this because otherwise, race conditions could corrupt the terminal output, and it's inconvenient for the client API too. This commit works towards this goal. There's still code that has this not fixed yet, though.
* vf_vapoursynth: reset error state on seekingwm42014-07-051-0/+1
| | | | | | | | | | | | When seeking, we violently destroy the filter, because vapoursynth has no proper API for terminating a video with unknown frame count. This looks like an error to vapoursynth, and the error is returned via the frame callbacks. The bug is that we remember this error state across reinitialization, so on the first filter call after reinitialization, we thought filtering the current frame failed. This caused a shift by 1 frame on each seek. CC: @mpv-player/stable
* vf_dlopen: fix the order of the arguments to mp_image_allocMarcoen Hirschberg2014-06-191-2/+2
|
* video: correct spelling: mp_image_params_equals -> mp_image_params_equalwm42014-06-171-3/+3
| | | | | The type is struct mp_image_params, so the "params" should have a "s". "equals" shouldn't, because it's plural for 2 params. Important.
* video: check image parameterswm42014-06-171-0/+6
| | | | | | | | | Make sure every video filter has valid parameters for input and output. (This also ensures we don't take possibly invalid decoder output, or feed invalid decodr/filter output to VOs.) Also, the updated image size check now (almost) works like the corresponding check in FFmpeg.
* video: introduce failure path for image allocationswm42014-06-1719-11/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, failure to allocate image data resulted in a crash (i.e. abort() was called). This was intentional, because it's pretty silly to degrade playback, and in almost all situations, the OOM will probably kill you anyway. (And then there's the standard Linux overcommit behavior, which also will kill you at some point.) But I changed my opinion, so here we go. This change does not affect _all_ memory allocations, just image data. Now in most failure cases, the output will just be skipped. For video filters, this coincidentally means that failure is treated as EOF (because the playback core assumes EOF if nothing comes out of the video filter chain). In other situations, output might be in some way degraded, like skipping frames, not scaling OSD, and such. Functions whose return values changed semantics: mp_image_alloc mp_image_new_copy mp_image_new_ref mp_image_make_writeable mp_image_setrefp mp_image_to_av_frame_and_unref mp_image_from_av_frame mp_image_new_external_ref mp_image_new_custom_ref mp_image_pool_make_writeable mp_image_pool_get mp_image_pool_new_copy mp_vdpau_mixed_frame_create vf_alloc_out_image vf_make_out_image_writeable glGetWindowScreenshot
* video: synchronize mpv rgb pixel format names with ffmpeg nameswm42014-06-141-6/+6
| | | | | | | | | | | This affects packed RGB formats up to 16 bits per pixel. The old mplayer names used LSB-to-MSB order, while FFmpeg (and some other libraries) use MSB-to-LSB. Nothing should change with this commit, i.e. no bit order or endian bugs should be added or fixed. In some cases, the name stays the same, even though the byte order changes, e.g. RGB8->BGR8 and BGR8->RGB8, and this affects the user-visible names too; this might cause confusion.
* video: automatically strip "le" and "be" suffix from pixle format nameswm42014-06-141-2/+3
| | | | | | | | | | | | | These suffixes are annoying when they're redundant, so strip them automatically. On little endian machines, always strip the "le" suffix, and on big endian machines vice versa (although I don't think anyone ever tried to run mpv on a big endian machine). Since pixel format strings are returned by a certain function and we can't just change static strings, use a trick to pass a stack buffer transparently. But this also means the string can't be permanently stored by the caller, so vf_dlopen.c has to be updated. There seems to be no other case where this is done, though.
* vf_noise: remove global variableswm42014-06-111-9/+4
|
* vf_divtc: remove a global variablewm42014-06-111-5/+1
|
* Add more constwm42014-06-113-3/+3
| | | | | | | While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
* options: remove global variables for swscale options; rename themwm42014-06-113-1/+3
| | | | | | Additionally to removing the global variables, this makes the options more uniform. --ssf-... becomes --sws-..., and --sws becomes --sws- scaler. For --sws-scaler, use choices instead of magic integer values.
* vf_vdpaupp: cosmetics: rename functionwm42014-05-251-5/+5
|
* vf_dlopen: update usage message to new-style argsKevin Mitchell2014-05-151-1/+1
|
* vf_dlopen: remove buggy private name -> imgfmt conversionKevin Mitchell2014-05-152-34/+18
| | | | | This was presumably for backward compatibility, but it was preventing the use of the new names.
* vf_vapoursynth: fix debug outputwm42014-05-151-1/+4
|
* vf_vapoursynth: add more debug outputwm42014-05-151-18/+21
| | | | | Also, move num_requested() to where it's used. Remove newlines from VS error messages. Remove an assert(0) on an error path.
* vf_vapoursynth: avoid unnecessary waitingwm42014-05-141-1/+1
| | | | | | | It could in theory happen that the filter loop will enter a blocking wait, even though it could make progress by emptying the list of already-filtered images. I'm not quite sure if this could actually cause a real issue - probably not.
* vf_vapoursynth: allow parallel processingwm42014-05-141-37/+81
| | | | | | | | VapourSynth won't just filter multiple frames at once on its own. You have to request multiple frames at once manually. This is what this commit introduces: a sub-option controls how many frames will be requested at once. This also changes the semantics of the maxbuffer sub- option, now renamed to buffered-frames.
* vf: print for which filter initialization failedwm42014-05-042-4/+11
|
* vf_vdpaupp: make code clarity improvementswm42014-05-041-8/+8
| | | | | This shouldn't change anything functionally, except that it buffers 1 frame less in the first-field deinterlacing mode.
* vdpau: deduplicate video surface upload codewm42014-05-041-36/+5
| | | | | | | This was a minor code duplication between vf_vdpaupp.c and vo_vdpau.c. (In theory, we could always require using vf_vdpaupp with vo_vdpau, but I think it's better if vo_vdpau can work standalone.)
* vf_vapoursynth: fix aspect ratio passed to vapoursynthwm42014-05-031-2/+8
| | | | | | This was recently either changed or clarified in vapoursynth. Pass the aspect ratio as pixel aspect to VS.
* video: removed unused stuffwm42014-05-022-7/+0
|
* video: handle colorspace and aspect overrides separatelywm42014-05-022-7/+22
| | | | | Now the video filter code handles these explicitly, which should increase robustness (or at least find bugs earlier).
* vf: sanitize filter input, instead of overriding itwm42014-05-021-1/+2
| | | | | | | | | vf_fix_img_params() takes care of overwriting image parameters that are normally not set correctly by filters. But this makes no sense for input images. So instead, check that the input is correct. It still has to be done for the first input image, because that's used to handle some overrides (see video_reconfig_filters()).
* vf: add alternate functions for retrieving filter outputwm42014-05-022-13/+57
| | | | | | | These replace vf_read_output_frame(), although we still emulate that function. This change is preparation for another commit (and this is basically just to reduce the diff and signal/noise ratio in that commit).
* vf: expose input parameters; clear parameters on failurewm42014-05-022-2/+3
| | | | Preparation (and simplification) for following commits.
* vf: mark auto-inserted conversion filters in verbose outputwm42014-05-021-0/+2
| | | | | Nota that this flag is not set for other auto-inserted filters (like deinterlacing or rotation).
* vf_lavfi: reinit after libavfilter EOFwm42014-05-021-13/+25
| | | | | | Basically, if we feed the filter a new image even after the EOF state has been reached (e.g. because the input stream "recovered"), we want the filter to restart, instead of returning an error forever.
* vf_vdpaupp: always provide past and future fieldswm42014-05-021-1/+1
| | | | | | | | | | | Some non-deinterlacing filters (potentially denoising) also use additional frames for filtering. The vdpau docs suggest providing at least 1 future and 2 past _fields_, which means we need to provide 1 past frame (the future field is already the other field of the current field, and both fields are in the same frame). We can easily achieve this by buffering an additional frame in the non- deint case.
* vf_vdpaupp: allow toggling deinterlacewm42014-05-021-4/+19
| | | | | Basically makes the 'D' key work again. (But only if the filter is already inserted.)
* vf_vdpaupp: allow non-vdpau inputwm42014-05-021-5/+42
| | | | | | | So you can use vdpau deinterlacing without using vdpau hardware decoding. vf_vavpp does something similar.
* vdpau: add a postprocessing pseudo-filterwm42014-05-022-0/+239
| | | | | | | | | | |