summaryrefslogtreecommitdiffstats
path: root/video/filter/vf.c
Commit message (Collapse)AuthorAgeFilesLines
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-1/+1
|
* Move options/config related files from mpvcore/ to options/wm42013-12-171-3/+3
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* Replace mp_tmsg, mp_dbg -> mp_msg, remove mp_gtext(), remove set_osd_tmsgwm42013-12-161-4/+4
| | | | | | | | | The tmsg stuff was for the internal gettext() based translation system, which nobody ever attempted to use and thus was removed. mp_gtext() and set_osd_tmsg() were also for this. mp_dbg was once enabled in debug mode only, but since we have log level for enabling debug messages, it seems utterly useless.
* video: move VO reinit from filter chain to playerwm42013-12-101-19/+30
| | | | | | | | | This gets rid of the vf_vo pseudo-filter. It ends the idea of MPlayer's architecture that the VO is just a (terminating) video filter. It didn't really work for us with respect to video timing (the "end" of the video chain isn't really made for video timing, and making it do so would be awkward), and now we're removing it entirely. We will be able to fix some things, such as properly draining video on reconfiguration.
* vf: redo conversion filter insertion/format negotiationwm42013-12-071-122/+128
| | | | | | | | | | | | | | | | | Remove the inconsistent, duplicated, and insufficient scale filter insertion code, and do it in one place instead. This also compensates for the earlier removal of vf_match_csp() (which was in fact duplicated code). The algorithm to determine where to insert a filter etc. is probably the same, though it also comes with some changes that should make debugging easier when trying to figure out why a chain is failing to configure. Add an "in" pseudo filter, which makes insertion of conversion filters easier. Also change the vf->reconfig signature. At a later point, I'll probably change format negotiation such that the generic filter code will choose the output format, so having separate in and out params will be useful.
* video/filter: make vf->control non-recursivewm42013-12-071-10/+13
| | | | | | Reason: I never liked it being recursive. Generally, this seems to cause more problems than trouble, and is less flexible for access outside of the chain.
* vf: remove flags from filter format statuswm42013-12-071-23/+19
| | | | | | | | I don't think we need these flags anymore. Simplify the code and get rid of the vf_format struct. There still is the vf_format.configured field, but this can be replaced by checking for a valid image format.
* video: create a separate context for video filter chainwm42013-12-071-57/+132
| | | | | | This adds vf_chain, which unlike vf_instance refers to the filter chain as a whole. This makes the filter API less awkward, and will allow handling format negotiation better.
* video/filter: remove vf_match_csp()wm42013-12-071-54/+0
| | | | | | | | | This function improves automatic filter insertion, but this really should be done by the generic filter code. Remove vf_match_csp() and all code using it as preparation for that. This commit temporarily makes handling of filter insertion worse for now, but it will be fixed with the following commits.
* vf: remove unused functionwm42013-12-071-22/+0
|
* vf: print error when creating filter failswm42013-12-071-0/+1
| | | | Before that we relied on the filters printing their own error messages.
* vf: cleanup removed filter entrywm42013-12-051-1/+0
|
* options: remove legacy hacks for sub-option handlingwm42013-12-041-17/+8
|
* video/filter: remove legacy option handling hackswm42013-12-041-5/+3
| | | | | | | | | All filters now either use the generic option parser, or don't have options. This finally finishes a transition started in 2003 (see git commit 33b62af94760186c). Why are MPlayer devs so monumentally lazy? Sorry, but this takes the cake. You had 10 years.
* video/filter: remove vf_down3drightwm42013-12-041-2/+0
| | | | | | | | Apparently you can get this with: stereo3d=ab[2]{l,r}:sbs[2]{l,r} So it seems the filter is redundant and can be removed. Also see FFmpeg commit 2f11aa141a01.
* options: add options that set defaults for af/vf/ao/vowm42013-12-011-0/+2
| | | | | | | | There are some use cases for this. For example, you can use it to set defaults of automatically inserted filters (like af_lavrresample). It's also useful if you have a non-trivial VO configuration, and want to use --vo to quickly change between the drivers without repeating the whole configuration in the --vo argument.
* options: implement --pphelp differentlywm42013-11-231-0/+1
| | | | Make it work via --vf=pp:help instead.
* configure: uniform the defines to #define HAVE_xxx (0|1)Stefano Pigozzi2013-11-031-4/+4
| | | | | | | | | | | | | | | | | | | | | The configure followed 5 different convetions of defines because the next guy always wanted to introduce a new better way to uniform it[1]. For an hypothetic feature 'hurr' you could have had: * #define HAVE_HURR 1 / #undef HAVE_DURR * #define HAVE_HURR / #undef HAVE_DURR * #define CONFIG_HURR 1 / #undef CONFIG_DURR * #define HAVE_HURR 1 / #define HAVE_DURR 0 * #define CONFIG_HURR 1 / #define CONFIG_DURR 0 All is now uniform and uses: * #define HAVE_HURR 1 * #define HAVE_DURR 0 We like definining to 0 as opposed to `undef` bcause it can help spot typos and is very helpful when doing big reorganizations in the code. [1]: http://xkcd.com/927/ related
* video/filter: remove useless vf_info fieldswm42013-10-231-2/+2
| | | | | This time I didn't bother to move the contents of the author field to the file headers. "git log" is your friend.
* vd: move aspect calculation to a functionwm42013-09-261-0/+15
| | | | | | | | 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-251-0/+4
| | | | | | | | 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-241-0/+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.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-4/+4
| | | | Followup commit. Fixes all the files references.
* vf: fix unintended overwriting of image infowm42013-07-281-2/+3
| | | | | | 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).
* 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.
* options: use m_config for options instead of m_structwm42013-07-211-43/+46
| | | | | | | | | | | | | | | | | | 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-211-20/+5
|
* 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.
* video: redo how colorspaces are handledwm42013-07-161-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-151-0/+5
| | | | | 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-281-35/+57
| | | | | | | | | | | | | | | | | | 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.
* m_option, vf: add label supportwm42013-05-231-1/+14
| | | | | | | | | | | | | | | | | 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.
* video/filter: fix option parser memory leakwm42013-05-181-0/+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.
* vf_lavfi: add libavfilter bridgewm42013-04-211-0/+4
| | | | | | | | | | | | | | | | | 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.
* core: simplify OSD capability handling, remove VFCAP_OSDwm42013-03-011-4/+1
| | | | | | | | | | | | | | | | | | | 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.)
* screenshot: minor simplification, prefer VF over VOwm42013-01-301-2/+0
| | | | | | | | | | | | | Remove screenshot_force and associated logic. Always try to use the screenshot video filter before trying taking screenshots with the VO, which means that --vf=screenshot now takes the role of --vf=screenshot_force. (To make this clear, not adding a video filter is still the recommended way to take screenshots; we just change how VF screenshots are forced.) Preferring VO over VF and having --vf=screenshot_force used to make sense when not all VOs supported screenshots, and some VOs had somewhat broken screenshots (like vo_xv taking screenshots with OSD in it). But all these issues are fixed now, so just get rid of the cruft.
* video: move handling of -x/-y/-xy options to VOwm42013-01-231-9/+5
| | | | | | | | | Now the calculations of the final display size are done after the filter chain. This makes the difference between display aspect ratio and window size a bit more clear, especially in the -xy case. With an empty filter chain, the behavior of the options should be the same, except that they don't affect vo_image and vo_lavc anymore.
* video: reset filters on seekwm42013-01-201-0/+7
| | | | | | | | | | | | | | | | Drop queued frames on seek. Reset the internal state of some filters that seem to need it as well: at least vf_divtc still produced some frames using the previous PTS. This fixes weird behavior with some filters on seeking. In particular, this could lead to A/V desync or apparent lockups due to the PTS of filtered frames being too far away from audio PTS. This commit does only the minimally required work to fix these PTS related issues. Some filters have state dependent on previously filtered frames, and these are not automatically reset with this commit (even vf_divtc and vf_softpulldown reset the PTS info only). Filters that actually require a full reset can implement VFCTRL_SEEK_RESET.
* video: print filter chain in verbose modewm42013-01-141-2/+32
| | | | | Somewhat useful to see where filters are auto-inserted and which formats they take.
* vf: add vf_rescale_dsize()wm42013-01-131-0/+15
| | | | | | | | Needed because mplayer* basically tracks DAR, which makes it harder for filters which want to keep the SAR. The contents of this function are duplicated in a few filters, and will be used instead of custom code as the filters are updated later.
* video: cleanup: move and rename vf_mpi_clear and vf_clone_attributeswm42013-01-131-73/+0
| | | | | | | | These functions weren't specific to video filters and were misplaced in vf.c. Move them to mp_image.c. Fix the big endian test in vf_mpi_clear/mp_image_clear, which has been messed up in 74df1d.
* mp_image: change how palette is handledwm42013-01-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | According to DOCS/OUTDATED-tech/colorspaces.txt, the following formats are supposed to be palettized: IMGFMT_BGR8 IMGFMT_RGB8, IMGFMT_BGR4_CHAR IMGFMT_RGB4_CHAR IMGFMT_BGR4 IMGFMT_RGB4 Of these, only BGR8 and RGB8 are actually treated as palettized in some way. ffmpeg has only one palettized format (AV_PIX_FMT_PAL8), and IMGFMT_BGR8 was inconsistently mapped to packed non-palettized RGB formats too (AV_PIX_FMT_BGR8). Moreover, vf_scale.c contained messy hacks to generate a palette when AV_PIX_FMT_BGR8 is output. (libswscale does not support AV_PIX_FMT_PAL8 output in the first place.) Get rid of all of this, and introduce IMGFMT_PAL8, which directly maps to AV_PIX_FMT_PAL8. Remove the palette creation code from vf_scale.c. IMGFMT_BGR8 maps to AV_PIX_FMT_RGB8 (don't ask me why it's swapped), without any palette use. Enabling it in vo_x11 or using it as vf_scale input seems to give correct results.
* video: remove things related to old DR codewm42013-01-131-19/+11
| | | | | | | | | | | | | | | Remove mp_image.width/height. The w/h members are the ones to use. width/height were used internally by vf_get_image(), and sometimes for other purposes. Remove some image flags, most of which are now useless or completely unused. This includes VFCAP_ACCEPT_STRIDE: the vf_expand insertion in vf.c does nothing. Remove some other unused mp_image fields. Some rather messy changes in vo_opengl[_old] to get rid of legacy mp_image flags and fields. This is left from when vo_gl supported DR.
* video/filter: change filter API, use refcounting, remove filter DRwm42013-01-131-243/+91
| | | | | | | | | | | | | | | | | | | | Change the entire filter API to use reference counted images instead of vf_get_image(). Remove filter "direct rendering". This was useful for vf_expand and (in rare cases) vf_sub: DR allowed these filters to pass a cropped image to the filters before them. Then, on filtering, the image was "uncropped", so that black bars could be added around the image without copying. This means that in some cases, vf_expand will be slower (-vf gradfun,expand for example). Note that another form of DR used for in-place filters has been replaced by simpler logic. Instead of trying to do DR, filters can check if the image is writeable (with mp_image_is_writeable()), and do true in-place if that's the case. This affects filters like vf_gradfun and vf_sub. Everything has to support strides now. If something doesn't, making a copy of the image data is required.
* video: remove slice based filtering and video outputwm42013-01-131-42/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Slices allowed filtering or drawing video in horizontal bands or blocks. This allowed working on the video in smaller units. In theory, this could bring a performance win by lowering cache pressure, as you didn't have to keep the whole video frame in cache while filtering, only the slice. In practice, the slice code path was barely used for the following reasons: - Multithreaded decoding with ffmpeg didn't use slices. The ffmpeg slice callback was disabled, because it can be called from another thread, and the mplayer video chain is not thread-safe. - There was nothing that would turn "full" images into appropriate slices, so slices were rarely used. - Most filters didn't actually support slices. On the other hand, supporting slices lead to code duplication and more complex code in general. I made some experiments and didn't find any actual measurable performance improvements when using slices. Even ffmpeg removed slices based filtering from libavfilter in favor of simpler code. The most broken thing about the slices code path is that slices can't be queued, like it is done for images in vo.c.
* video/filter: rename vf_eq2 to vf_eqwm4