summaryrefslogtreecommitdiffstats
path: root/video/filter
Commit message (Collapse)AuthorAgeFilesLines
* vf_scale: fix get/set confusionwm42013-10-201-1/+1
| | | | This caused the equalizer controls to appear stuck.
* cosmetics: replace "CTRL" defines by enumswm42013-10-021-13/+15
| | | | Because why not.
* vf_scale: factor out libswscale equalizer controlwm42013-09-301-23/+2
| | | | Will be used by vo_x11.
* vd: move aspect calculation to a functionwm42013-09-262-0/+16
| | | | | | | | This function would probably be useful in other places too. I'm not sure why vd.c doesn't apply the aspect if it changes size by less than 4 pixels. Maybe it's supposed to avoid ugly results with bad scalers if the difference is too small to be noticed normally.
* vaapi: add vf_vavpp and use it for deinterlacingxylosper2013-09-254-0/+413
| | | | | | | | Merged from pull request #246 by xylosper. Minor cosmetic changes, some adjustments (compatibility with older libva versions), and manpage additions by wm4. Signed-off-by: wm4 <wm4@nowhere>
* vf: fix filter initialization error checkwm42013-09-201-1/+1
| | | | | vf_open returns 0 on error, 1 on success. Oops. Accidentally broken with 6629a95.
* video: handle video output levels with mp_image_paramswm42013-08-243-6/+1
| | | | | | | | | | | | Until now, video output levels (obscure feature, like using TV screens that require RGB output in limited range, similar to YUY) still required handling of VOCTRL_SET_YUV_COLORSPACE. Simplify this, and use the new mp_image_params code. This gets rid of some code. VOCTRL_SET_YUV_COLORSPACE is not needed at all anymore in VOs that use the reconfig callback. The result of VOCTRL_GET_YUV_COLORSPACE is now used only used for the colormatrix related properties (basically, for display on OSD). For other VOs, VOCTRL_SET_YUV_COLORSPACE will be sent only once after config instead of twice.
* video/out: don't require VOs to handle screenshot aspect speciallywm42013-08-241-0/+1
| | | | | | | | | | | | | | | | This affects VOs which just reuse the mp_image from draw_image() to return screenshots. The aspect of these images is never different from the aspect the screenshots should be, so there's no reason to adjust the aspect in these cases. Other VOs still need it in order to restore the original image attributes. This requires some changes to the video filter code to make sure that the aspect in the passed mp_images is consistent. The changes in mplayer.c and vd_lavc.c are (probably) not strictly needed for this commit, but contribute to consistency.
* vf_eq: fix behavior when changing parameterswm42013-08-201-4/+14
| | | | | | | | | | | | | | | Using -vf eq and changing brightness, contrast, etc. using key bindings with e.g. "add brightness 1" didn't work well: with step width 1, the property gets easily "stuck". This is a rounding problem: e.g. setting gamma to 3 would actually make it report that gamma is set to 2, so the "add" command will obviously never reach 3 with a step width of 1. Fix this by storing the parameters as integers. This was broken in cac7702. This commit effectively changed these properties to use the value as reported by vf_eq, instead of the previously set value for the "add" command. This was more robust, but not very correct either, so we keep the new behavior and make vf_eq report its parameters more accurately.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-0632-65/+65
| | | | Followup commit. Fixes all the files references.
* vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel APIwm42013-07-282-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
* vf: fix unintended overwriting of image infowm42013-07-282-4/+5
| | | | | | The symptom was that "-vf scale,format=rgba" broke the vsfilter colorspace hack in sd_ass. vf->reconfig is allowed to overwrite its input parameter for convenience (maybe that was a bad idea).
* Fix some -Wshadow warningswm42013-07-236-17/+13
| | | | | | In general, this warning can hint to actual bugs. We don't enable it yet, because it would conflict with some unmerged code, and we should check with clang too (this commit was done by testing with gcc).
* options: make legacy hacks for AFs/VFs more explicitwm42013-07-221-0/+1
| | | | | This means that AOs/VOs with no options set do not take the legacy option parsing path, but instead report that they have no options.
* vf_scale: actually respect param and param2 suboptionswm42013-07-221-0/+3
| | | | This was forgotten in commit b81f5e2.
* options: use m_config for options instead of m_structwm42013-07-2114-252/+179
| | | | | | | | | | | | | | | | | | For some reason, both m_config and m_struct are somewhat similar, except that m_config is much more powerful. m_config is used for VOs and some other things, so to unify them. We plan to kick out m_struct and use m_config for everything. (Unfortunately, m_config is also a bit more bloated, so this commit isn't all that great, but it will allow to reduce the option parser mess somewhat.) This commit also switches all video filters to use the option macros. One reason is that m_struct and m_config, even though they both use m_option, store the offsets of the option fields differently (sigh...), meaning the options defined for either are incompatible. It's easier to switch everything in one go. This commit will allow using the -vf option parser for other things, like VOs and AOs.
* vf: remove unnecessary indirectionwm42013-07-212-26/+5
|
* video: remove fullscreen flags chaoswm42013-07-181-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a MPOpts fullscreen field, a mp_vo_opts.fs field, and VOFLAG_FULLSCREEN. Remove all these and introduce a mp_vo_opts.fullscreen flag instead. When VOs receive VOCTRL_FULLSCREEN, they are supposed to set the current fullscreen mode to the state in mp_vo_opts.fullscreen. They also should do this implicitly on config(). VOs which are capable of doing so can update the mp_vo_opts.fullscreen if the actual fullscreen mode changes (e.g. if the user uses the window manager controls). If fullscreen mode switching fails, they can also set mp_vo_opts.fullscreen to the actual state. Note that the X11 backend does almost none of this, and it has a private fs flag to store the fullscreen flag, instead of getting it from the WM. (Possibly because it has to deal with broken WMs.) The fullscreen option has to be checked on config() to deal with the -fs option, especially with something like: mpv --fs file1.mkv --{ --no-fs file2.mkv --} (It should start in fullscreen mode, but go to windowed mode when playing file2.mkv.) Wayland changes by: Alexander Preisinger <alexander.preisinger@gmail.com> Cocoa changes by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
* sws_utils: don't recursively include libswscale headerwm42013-07-181-0/+2
| | | | Add libswscale includes where they are actually needed instead.
* vf_scale: use new swscale wrapperwm42013-07-181-157/+60
|
* vf: make sure less important image params are set before/after filterswm42013-07-181-14/+21
| | | | | | | | Image parameters like colorspace, color levels, and chroma location are generally less important, and many filters don't set them correctly. Force them instead in the generic VF code, which is probably better and more convenient over all. So we designate this is a proper solution, instead of a dirty hack.
* vf_scale: remove rounding of sizes to 2 with 4:2:0wm42013-07-181-11/+0
| | | | | | | | | libswscale doesn't seem to require this (anymore?), and libavfiltert's vf_scale doesn't do it either. Moreover, this wasn't done for most other subsampled formats, not even very old ones. So just remove it. (It'd be quite easy to align on chroma boundaries with all pixel formats, though.)
* vf_scale: try to support all pixel formatswm42013-07-181-1/+25
| | | | | | | | | Until now, vf_scale only tried formats listed in the outfmt_list array. Extend this and try every pixel format supported by mpv if trying outfmt_list doesn't lead to success. Also add some checks whether swscale really supports a given input or output format. This was implicitly done with outfmt_list before.
* vf_scale: don't byte-swap palette on big endian architectureswm42013-07-181-8/+0
| | | | | | ffmpeg's and the internal palette format used to have different endianess, but that is not the case anymore. This code was forgotten when that change was made.
* vf_scale: uncrustifywm42013-07-181-186/+207
|
* video: redo how colorspaces are handledwm42013-07-163-57/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of handling colorspaces with VFCTRLs/VOCTRLs, make them part of the normal video format negotiation. The colorspace is passed down like other video params with config/reconfig calls. Forcing colorspaces (via the --colormatrix options and properties) is handled differently too: if it's changed, completely reinit the video chain. This is slower and requires a precise seek to the same position to perform an update, but it's simpler and less bug-prone. Considering switching the colorspace at runtime by user-interaction is a rather obscure feature, this is a good change. The colorspace VFCTRLs and VOCTRLs are still kept. The VOs rely on it, and would have to be changed to get rid of them. We'll do that later, and convert them incrementally instead of in one go. Note that controlling the output range now always works on VO level. Basically, this means you can't get vf_scale to output full-range YUV for whatever reason. If that is really wanted, it should be a vf_scale option. the previous behavior didn't make too much sense anyway. This commit fixes a few bugs (such as playing RGB video and converting that to YUV with vf_scale - a recent commit broke this and forced the VO to display YUV as RGB if possible), and might introduce some new ones.
* vf: add vf_control wrapperwm42013-07-152-0/+6
| | | | | Slightly cleaner, although rather redundant. But still, why wasn't this added 10 years ago?
* build: change vf_dlopen testwm42013-07-121-1/+1
| | | | Didn't work on Windows. Apparently, WIN32 is not set in the Makefile.
* configure: add libdl detection to ladspa, vf_dlopenRudolf Polzer2013-07-091-0/+2
|
* vo_opengl: handle chroma locationwm42013-06-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the video decoder chroma location flags and render chroma locations other than centered. Until now, we've always used the intuitive and obvious centered chroma location, but H.264 uses something else. FFmpeg provides a small overview in libavcodec/avcodec.h: ----------- /** * X X 3 4 X X are luma samples, * 1 2 1-6 are possible chroma positions * X X 5 6 X 0 is undefined/unknown position */ enum AVChromaLocation{ AVCHROMA_LOC_UNSPECIFIED = 0, AVCHROMA_LOC_LEFT = 1, ///< mpeg2/4, h264 default AVCHROMA_LOC_CENTER = 2, ///< mpeg1, jpeg, h263 AVCHROMA_LOC_TOPLEFT = 3, ///< DV AVCHROMA_LOC_TOP = 4, AVCHROMA_LOC_BOTTOMLEFT = 5, AVCHROMA_LOC_BOTTOM = 6, AVCHROMA_LOC_NB , ///< Not part of ABI }; ----------- The visual difference is literally minimal, but since videophiles apparently consider this detail as quality mark of a video renderer, support it anyway. We don't bother with chroma locations other than centered and left, though. Not sure about correctness, but it's probably ok.
* video: add a new method to configure filters and VOswm42013-06-285-68/+95
| | | | | | | | | | | | | | | | | | The filter chain and the video ouputs have config() functions. They are strictly limited to transfering the video size and format. Other parameters (like color levels) have to be transferred separately. Improve upon this by introducing a separate set of reconfig() functions, which use mp_image_params to carry format parameters. This struct contains all image format related parameters from config(), plus additional parameters such as colorspace. Change vf_rotate to use it, as well as vo_opengl. vf_rotate is just an example/test case, but vo_opengl will need it later. The intention is also to get rid of VOCTRL_SET_YUV_COLORSPACE. This information is now handed to the VOs via reconfig(). The getter, VOCTRL_GET_YUV_COLORSPACE, will still be needed though.
* vf_rotate: fix params >= 4wm42013-06-281-0/+2
|
* fix compile, sorryRudolf Polzer2013-06-161-0/+1
|
* vf_dlopen filters: add an "ildetect" filter that detects interlacingRudolf Polzer2013-06-161-4/+21
| | | | | The filter analyzes each frame for combing, and decides at the end whether the content is likely interlaced, telecined or progressive.
* vf_delogo: copy in non-direct case, fix double-freewm42013-05-261-9/+1
| | | | | | | | | If the image is not writeable, the image actually has to be copied beforehand. This was overlooked when converting the video chain to reference counted images. Fix a double free issue. This was overlooked when vf.c was changed to free filter priv data automatically.
* vf_lavfi: allow setting avoptswm42013-05-261-0/+9
|
* m_option, vf: add label supportwm42013-05-232-1/+18
| | | | | | | | | | | | | | | | | Can be used to refer to filters by name. Intended to be used when the filter chain is changed at runtime. A label can be assigned to a filter by prefixing it with '@name:', where 'name' is an user-chosen identifier. For example, a filter added with '-vf-add @label1:gradfun=123' can be removed with '-vf-del @label1'. If a filter with an already existing label is added, the existing filter is replaced with the new filter (this happens for both -vf-add and -vf-pre). If a filter is replaced, the new filter takes the position of the old filter, instead of being appended/prepended to the filter chain as usual. For -vf-toggle, labels are compared if at least one of the filters has a label; otherwise they are compared by filter name and arguments (like before). This means two filters are never considered equal if one has a label and the other one does not.
* dec_video: get rid of two global variableswm42013-05-211-2/+0
|
* vf_lavfi: remove redundant statementswm42013-05-211-4/+0
|
* video/filter: fix option parser memory leakwm42013-05-186-16/+3
| | | | | | | This happens only if an option actually allocates memory (like strings). Change filter API such that vf->priv is free'd by vf.c instead by the filters. vf.c will free the option values as well.
* Fix some cppcheck / scan-build warningswm42013-05-062-2/+2
| | | | | | | | These were found by the cppcheck and scan-build static analyzers. Most of these aren't interesting (the 2 previous commits fix some interesting cases found by these analyzers), and they don't nearly fix all warnings. (Most of the unfixed warnings are spam, things MPlayer never cared about, or false positives.)
* vf_yadif: actually set PTS for output frameswm42013-05-061-0/+1
| | | | The original frame PTS was used instead. Oops...
* vf_rotate: fix for some obscure pixel formatswm42013-05-031-7/+6
| | | | | Repurpose the 3 byte case for any unhandled pixel width. Fixes rotation with e.g. rgb48. Very inefficient, but works.
* video: add XYZ supportwm42013-05-011-0/+1
| | | | Needed for the ffmpeg j2k decoder.
* vf_lavfi: move compat crap to the start of the filewm42013-04-261-18/+18
|
* vf_lavfi: silence stupid deprecation warningwm42013-04-261-2/+12
| | | | | | | | | | | | | | | | | | | libavfilter changed the way a format list is passed to vf_format. Now you have to separate formats with "|" instead of ":". If you use "|", it prints an annoying message on every reinit: [format @ 0x8bbaaa0]This syntax is deprecated. Use '|' to separate the list items. ...and it will probably stop working without warning at some point in the future. We need some very annoying ifdeffery to detect this case, because libavfilter version numbers are just plain incompatible between Libav and ffmpeg. There is no other way to detect this. (Sometimes I wonder whether ffmpeg and especially Libav actually like causing unnecessary pain for their users, and intentionally break stuff in the most annoying way possible. Sigh...)
* vf_lavfi: recreate filter graph on seekwm42013-04-251-14/+41
| | | | | | | | | | | | | | Resetting the filter graph helps dealing with filters which save state between frames. This is important especially if they modify frame timing or emit additional frames. Unfortunately the libavfilter API doesn't have a way to do this directly, so we have to use a dirty trick: we recreate the whole graph, including format negotiation down and filter string parsing. ffplay does this too. If libavfilter somehow decides to change output format or size from what the first run in config() returned, mpv will explode. The same applies to vf_next_query_format() return values (although this could be mitigated, should it really happen).
* vf_lavfi: add libavfilter bridgewm42013-04-212-0/+315
| | | | | | | | | | | | | | | | | Requires recent FFmpeg/Libav git versions. Earlier versions will not be supported, as the API is different. (A libavfilter version that uses AVFrame instead of AVFilterBuffer is needed.) Note that this is sort of useless, because the option parser prevents you from making use of the full libavfilter graph syntax. This has to be fixed later. Most of the filter creation code (half of the config() function) has been taken from avplay.c. This code is not based on MPlayer's vf_lavfi. The MPlayer code doesn't compile as it hasn't been updated through multiple libavfilter API changes, making it completely useless as a starting point.
* vf_divtc, vf_phase: Fix handling of subsampled formatsMartin Herkt2013-04-102-3/+4
| | | | | | These filters incorrectly calculated the amount of bytes per line in each plane for chroma subsampled formats, causing undefined behavior.
* vf_flip: move flipping code to mp_image.cwm42013-03-011-4/+1
|
* vf_vo: remove pointless NULL checkswm42013-03-011-4/+0
| | | | The filter refuses to initialize if the video_out is NULL.
* core: simplify OSD capability handling, remove VFCAP_OSDwm42013-03-015-13/+6
| | | | | | | | | | | | | | | | | | | VFCAP_OSD was used to determine at runtime whether the VO supports OSD rendering. This was mostly unused. vo_direct3d had an option to disable OSD (was supposed to allow to force auto-insertion of vf_ass, but we removed that anyway). vo_opengl_old could disable OSD rendering when a very old OpenGL version was detected, and had an option to explicitly disable it as well. Remove VFCAP_OSD from everything (and some associated logic). Now the vo_driver.draw_osd callback can be set to NULL to indicate missing OSD support (important so that vo_null etc. don't single-step on OSD redraw), and if OSD support depends on runtime support, the VO's draw_osd should just do nothing if OSD is not available. Also, do not access vo->want_redraw directly. Change the want_redraw reset logic for this purpose, too. (Probably unneeded, vo_flip_page resets it already.)
* video/out: remove video mode switching (--vm)wm42013-02-261-2/+1
| | | | | | | | | | | | | | | | | | | | This allowed making the player switch the monitor video mode when creating the video window. This was a questionable feature, and with today's LCD screens certainly not useful anymore. Switching to a random video mode (going by video width/height) doesn't sound too useful either. I'm not sure about the win32 implementation, but the X part had several bugs. Even in mplayer-svn (where x11_common.c hasn't been receiving any larger changes for a long time), this code is buggy and doesn't do the right thing anyway. (And what the hell _did_ it do when using multiple physical monitors?) If you really want this, write a shell script that calls xrandr before and after calling mpv. vo_sdl still can do mode switching, because SDL has native support for it, and using it is trivial. Add a new sub-option for this.
* vf_yadif: remove dead codewm42013-02-261-2/+0
| | | | Commit 2e1063d changed the option parsing, and args is always NULL now.
* demux_mf: support .xbmwm42013-02-241-0/+1
| | | | | | | And support the PIX_FMT_MONOWHITE pixel format. (This is really weird: unlike PIX_FMT_MONOBLACK, it uses white pixels. I have no idea why libavcodec doesn't just convert the pixel format on the fly, instead of bothering everyone with really special pixel formats.)
* vf_yadif: switch to option parser, allow disabling by defaultwm42013-02-231