summaryrefslogtreecommitdiffstats
path: root/video/filter
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | | | | This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
* vf: print error if filtering a frame failswm42014-04-301-1/+4
| | | | | The filters don't always print an error on their own, and printing an error is better than silently dropping the frame.
* vf_lavfi: reset metadata in reset()Kevin Mitchell2014-04-291-0/+4
| | | | | | It might have been nice not to do this so that metadata could accumulate accross seeks, but it seems libavfilter looses its copy anyway on recreate_graph.
* vf-metadata: fix handling of NULL metadataKevin Mitchell2014-04-291-4/+7
| | | | | | lavfi would segfault due to a NULL dereference if it was asked for its metadata and none had been allocated (oops). This happens for libav which has no concept of filter metadata.
* vf_vapoursynth: add more VS frame propertieswm42014-04-281-0/+26
| | | | | | | We only support them for input. The frame properties of output frames are ignored (except frame durations). Properties not set for now: _ChromaLocation, _Field, _FieldBased
* vf_vapoursynth: use frame durations instead of _AbsoluteTimewm42014-04-281-6/+25
| | | | | | | | | | | | | Set _DurationNum/_DurationDen on each VS frame, instead of _AbsoluteTime. The duration is the difference between the timestamp of the frame and the next frame, and when receiving filtered VS frames, we convert them back to an absolute PTS by summing them. We pass the timestamps with microsecond resolution. mpv uses double for timestamps internally, so we don't know the "real" timebase or FPS. VS on the other hand uses fractions for frame durations. We can't pass through the numbers exactly, but microseconds ought to be enough to be even safe from accumulating rounding errors.
* vf_vapoursynth: fix memory leak on errorwm42014-04-281-1/+3
| | | | | | Since this leaks video images, and the player keeps feeding new images to the fitler even if it fails, this would probably have disastrous consequences.
* vf_vapoursynth: remove incorrect copyright noticewm42014-04-281-2/+0
| | | | | This file merely started out by copy&pasting vf_lavfi.c and removing everything to have a basic skeleton.
* vf_lavfi: distinguish real errors from other stateswm42014-04-281-2/+11
| | | | Don't just hide real errors, should a filter return them.
* video: don't drop last frame when deinterlacing with yadifwm42014-04-287-6/+32
| | | | | | | | | | | | | | | | | | 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.
* vf_vapoursynth: use official AbsoluteTime propertywm42014-04-271-2/+2
| | | | | | | | I thought the "_" in "_AbsoluteTime" was part of the documentation markup. This still doesn't help us with VS filters that change timing; apparently you must use frame durations instead.
* vf_vapoursynth: keep pixel aspect ratiowm42014-04-271-3/+3
| | | | | | | | | | | | Make the filter apply the pixel aspect ratio of the input to the output. This is more useful than forcing 1:1 PAR when playing anamorphic video such as DVDs. VapourSynth itself actually allows passing through the aspect ratio, but it's in a not very useful form for us: it's per video-frame instead of constant (i.e in VSVideoInfo). As long as we don't have a way to allow a filter to spontaneously change output parameters, we can't use this. (And I don't really feel like making this possible.)
* vf_pp: PP_PICT_TYPE_QP2 is always definedwm42014-04-251-4/+0
|
* vf: print all image parameter information in verbose outputwm42014-04-221-0/+5
|
* vf: remove autoinserted filters on reconfigwm42014-04-212-0/+8
| | | | | | | When using rotation with hw decoding, and the VO does not support rotation, vf_rotate is attempted to be inserted. This will go wrong, and after that it can't recover because a vf_scale filter was autoinserted. Just removing all autoinserted filters before reconfig fixes this.
* vf: add function to remove a filter from the chainwm42014-04-212-0/+14
|
* video: make mp_image use mp_image_params directlywm42014-04-211-15/+7
| | | | | Minor cleanup, so that we can stuff more information into mp_image_params later.
* vf_rotate: support all multiples of 90 degreeswm42014-04-212-92/+23
| | | | | | | | | | | | | This couldn't rotate by 180°. Add this, and also make the parameter in degrees, instead of magic numbers. For now, drop the flipping stuff. You can still flip with --vf=flip or --vf=mirror. Drop the landscape/portrait stuff - I think this is something almost nobody will use. If it turns out that we need some of these things, they can be readded later. Make it use libavfilter. Its vf_transpose implementation looks pretty simple, except that it uses slice threading and should be much faster.
* Fix some libav* include statementswm42014-04-193-3/+4
| | | | | | | | | | | | | Fix all include statements of the form: #include "libav.../..." These come from MPlayer times, when FFmpeg was somehow part of the MPlayer build tree, and this form was needed to prefer the local files over system FFmpeg. In some cases, the include statement wasn't needed or could be replaced with mpv defined symbols.
* Remove CPU detection and inline asm handlingwm42014-04-191-2/+5
| | | | | | | | | | | | | | Not needed anymore. I'm not opposed to having asm, but inline asm is too much of a pain, and it was planned long ago to eventually get rid fo all inline asm uses. For the note, the inline asm use that was removed with the previous commits was almost worthless. It was confined to video filters, and most video filtering is now done with libavfilter. Some mpv filters (like vf_pullup) actually redirect to libavfilter if possible. If asm is added in the future, it should happen in the form of external files.
* vf_pp: fix include statementwm42014-04-191-1/+1
|
* vf_pp: use native libpostproc CPU detectionwm42014-04-191-5/+1
|
* vf_divtc: remove inline asmwm42014-04-191-50/+0
| | | | | | Becomes a bit slower (tested with progressive solid color video only), but this filter is pretty obscure and I'm not even sure what it's useful for.
* vf_pullup: remove inline asmwm42014-04-193-218/+0
| | | | | | No change in speed (or even slightly faster, though I tested with progressive solid color video only), and normally we use libavformat's vf_pullup anyway.
* vf_noise: remove line asmwm42014-04-191-130/+4
| | | | | | | | I didn't test the speed, but by default, this filter diverts to libavfilter already. So this would help only if libavfilter is disabled, or libavfilter doesn't have vf_noise (like on Libav). For these cases, we still provide the (possibly but not necessarily) slower C implementation of vf_noise.
* vf_ilpack: remove inline asmwm42014-04-191-277/+4
| | | | | | | | This makes it multiple times slower. However, the output format (packed YUV) isn't handled efficiently by anything to begin with, and I have no clue we even have this filter. I guess it's one of these filters which find some use sometimes, but are not of higher importance, which justifies removing the faster inline asm.
* vf_eq: remove slow inline asmwm42014-04-191-75/+0
| | | | | Compiled with -O2, the C code runs just as far (or even slightly faster) then the MMX inline asm.
* vf_vapoursynth: handle destruction more gracefullywm42014-04-141-7/+8
| | | | | | | | | | | | | | We were relying on vsscript_freeScript() to take care of proper termination. But it doesn't do that: it doesn't wait for the filters to finish and exit at all. Instead, it just destroys all objects, which causes the worker threads to crash sometimes. Also, we're supposed to wait for the frame callback to finish before freeing the associated node. Handle this by explicitly waiting as far as we can. Probably fixes crashes on seeking, although VapourSynth itself might also need some work to make this case completely stable.
* vf_vapoursynth: wipe vapoursynth state completely on reloadingwm42014-04-141-40/+55
| | | | | | | | Before this commit, the filter attempted to keep the vsscript state (p->se) even when the script was reloaded. Change it to destroy the script state too on reloading. Now n