summaryrefslogtreecommitdiffstats
path: root/video/filter
Commit message (Collapse)AuthorAgeFilesLines
* 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-7/+21
| | | | | | | | | Use the option parser instead of sscanf. Remove the parameter changing the field dominance (it has been marked deprecated for ages). Add a new suboption "enabled", which can be used to disable the filter by default, until it's enabled at runtime: mpv -vf yadif=enabled=no
* vf_scale: remove video dimension presets ("presize" suboption)wm42013-02-231-41/+0
| | | | | This wasn't really useful, and the option preset mechanism is awfully complex.
* vf_stereo3d: get rid of m_obj_presets_t usagewm42013-02-231-49/+3
| | | | The code becomes amazingly simpler.
* core: redo how codecs are mapped, remove codecs.confwm42013-02-101-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use codec names instead of FourCCs to identify codecs. Rewrite how codecs are selected and initialized. Now each decoder exports a list of decoders (and the codec it supports) via add_decoders(). The order matters, and the first decoder for a given decoder is preferred over the other decoders. E.g. all ad_mpg123 decoders are preferred over ad_lavc, because it comes first in the mpcodecs_ad_drivers array. Likewise, decoders within ad_lavc that are enumerated first by libavcodec (using av_codec_next()) are preferred. (This is actually critical to select h264 software decoding by default instead of vdpau. libavcodec and ffmpeg/avconv use the same method to select decoders by default, so we hope this is sane.) The codec names follow libavcodec's codec names as defined by AVCodecDescriptor.name (see libavcodec/codec_desc.c). Some decoders have names different from the canonical codec name. The AVCodecDescriptor API is relatively new, so we need a compatibility layer for older libavcodec versions for codec names that are referenced internally, and which are different from the decoder name. (Add a configure check for that, because checking versions is getting way too messy.) demux/codec_tags.c is generated from the former codecs.conf (minus "special" decoders like vdpau, and excluding the mappings that are the same as the mappings libavformat's exported RIFF tables). It contains all the mappings from FourCCs to codec name. This is needed for demux_mkv, demux_mpg, demux_avi and demux_asf. demux_lavf will set the codec as determined by libavformat, while the other demuxers have to do this on their own, using the mp_set_audio/video_codec_from_tag() functions. Note that the sh_audio/video->format members don't uniquely identify the codec anymore, and sh->codec takes over this role. Replace the --ac/--vc/--afm/--vfm with new --vd/--ad options, which provide cover the functionality of the removed switched. Note: there's no CODECS_FLAG_FLIP flag anymore. This means some obscure container/video combinations (e.g. the sample Film_200_zygo_pro.mov) are played flipped. ffplay/avplay doesn't handle this properly either, so we don't care and blame ffmeg/libav instead.
* vf_stereo3d: add support for green-magenta and yellow-blue duboiscehoyos2013-02-031-1/+11
| | | | | | | | | | | | | | Add more vf_stereo3d output formats. Adds high quality green-magenta and yellow-blue dubois anaglyph 3D output support. Patch by thomas schorpp, thomas.schorpp gmail git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35906 b3059339-0415-0410-9bf9-f77b7e298cf2 Conflicts: video/filter/vf_stereo3d.c
* vf_dlopen: fix external pixel format nameswm42013-02-031-7/+35
| | | | | "yv12" stopped working a while ago, and so did other FourCC-like names. Make "yv12" work again, so that the examples in TOOLS/vf_dlopen/ work.
* screenshot: minor simplification, prefer VF over VOwm42013-01-302-13/+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.
* vf_scale: fix warningwm42013-01-271-1/+0
|
* video: move handling of -x/-y/-xy options to VOwm42013-01-239-26/+14
| | | | | | | | | 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-204-0/+31
| | | | | | | | | | | | | | | | 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.
* vf_format: fix forcing output formatwm42013-01-171-1/+11
| | | | | This failed with an assert, because the format of the format of the output image was not set correctly.
* video: print filter chain in verbose modewm42013-01-142-3/+34
| | | | | Somewhat useful to see where filters are auto-inserted and which formats they take.
* vf_sub: allow more formats, simplify codewm42013-01-131-82/+15
| | | | | | | | | In theory, vf_sub could take any format supported by swscale. But to be sure that it's reasonably fast, only 420P was allowed. However, other similar 8 bit planar formats will be just as fast and there's no reason to exclude them. Even for completely different formats there doesn't seem to be any significant advantage to force vf_sub to convert to a simpler/more common format.
* vf_expand: support more image formatswm42013-01-131-68/+33
| | | | | | | | | | | This did random things with some image formats, including 10 bit formats. Fixes the mp_image_clear() function too. This still has some caveats: - doesn't clear alpha to opaque (too hard with packed RGB, and is rarely needed) - sets luma to 0 for mpeg-range YUV, instead of the lowest possible value (e.g. 16 for 8 bit)
* vf_rotate: support more image formatswm42013-01-131-34/+25
|
* vf_softpulldown: reject unsupported image formats, fix code duplicationwm42013-01-131-47/+24
| | | | Not really tested.
* vf_yadif: Y8 is not supportedwm42013-01-131-1/+0
| | | | Crashes.
* vf_swapuv: support more image formatswm42013-01-131-12/+8
|
* vf_pullup: remove check for MP_IMGFLAG_PLANARwm42013-01-131-4/+0
| | | | It supports 420p only, so the check is useless.
* vf_phase: reject unsupported image formatswm42013-01-131-21/+20
| | | | Also don't use MP_IMGFLAG_PLANAR.
* vf_mirror: rewritewm42013-01-131-65/+52
| | | | | Properly handle odd image sizes. Probably makes it work with more image formats.
* vf_gradfun: does not work with NV pixel formatswm42013-01-131-2/+0
|
* vf_flip: make it work with more image formatswm42013-01-131-15/+15
|
* vf_divtc: reduce code duplicationwm42013-01-131-14/+7
|
* vf_crop: make it work with more image formatswm42013-01-131-39/+20
|
* vf: add vf_rescale_dsize()wm42013-01-132-0/+18
| | | | | | | | 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.
* sub: do not copy the target image if there is no OSD/subswm42013-01-131-5/+3
| | | | | | | | | | | | | | | | | | | | | It's not easy to tell whether the OSD/subs are empty, or if something is drawn. In general you have to use osd_draw() with a custom callback. If nothing is visible, the callback is never invoked. (The actual reason why this is so "hard" is the implementation of osd_libass.c, which doesn't allow separating rendering and drawing of OSD elements, because all OSD elements share the same ASS_Renderer.) To simplify avoiding copies, make osd_draw_on_image() instead of the caller use mp_image_make_writeable(). Introduce osd_draw_on_image_p(), which works like osd_draw_on_image(), but gets the new image allocation from an image pool. This is supposed to be an optimization, because it reduces the frequency of large allocations/deallocations for image data. The result of this is that the frequency of copies needed in conjunction with vf_sub, screenshots, and vo_lavc (encoding) should be reduced. vf_sub now always does true pass-through if no subs are shown. Drop the pts check from vf_sub. This didn't make much sense.
* video: remove img_format compat hackswm42013-01-132-2/+2
| | | | | | | | | | | | | | | | | Remove the strange things the old mp_image_setfmt() code did to the image format parameters. This includes setting chroma shift to 31 for gray (Y8) formats and more. Y8 + vo_opengl_old didn't actually work for unknown reasons (regression in this branch). Fix this. The difference is that Y8 is now interpreted as gray RGB (LUMINANCE texture) instead of involving YUV (and levels) conversion. Get rid of distinguishing RGB and BGR. There wasn't really any good reason for this. Remove mp_get_chroma_shift() and IMGFMT_IS_YUVP16*(). mp_imgfmt_desc gives the same information and more.
* video: decouple internal pixel formats from FourCCswm42013-01-1321-127/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
* video: cleanup: move and rename vf_mpi_clear and vf_clone_attributeswm42013-01-133-82/+6
| | | | | | | | 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-136-56/+5
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* vf_screenshot: simplifywm42013-01-132-52/+20
| | | | | | | | | | Instead of using a callback to "capture" the image next time the filter function is called, do it the other way around: on every filter invocation, create a reference to the image, and return it if a screenshot is requested. This also fixes the 1-frame delay when taking screenshots with the filter. This also allows simplifying screenshot.c.
* video: remove things related to old DR codewm42013-01-136-31/+18
| | | | | | | | | | | | | | | 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-1331-1122/+519
| | | | | | | | | | | | | | | | | | | | 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.
* mp_image: require using mp_image_set_size() for setting w/hwm42013-01-131-5/+3
| | | | | | | | | | | | | | Setting the size of a mp_image must be done with mp_image_set_size() now. Do this to guarantee that the redundant fields (like chroma_width) are updated consistently. Replacing the redundant fields by function calls would probably be better, but there are too many uses of them, and is a bit less convenient. Most code actually called mp_image_setfmt(), which did this as well. This commit just makes things a bit more explicit. Warning: the video filter chain still sets up mp_images manually, and vf_get_image() is not updated.
* video: make vdpau hardware decoding not use DR code pathwm42013-01-132-11/+3
| | | | | | vdpau hardware decoding used the DR (direct rendering) path to let the decoder query a surface from the VO. Special-case the HW decoding path instead, to make it separate from DR.
* video: remove slice based filtering and video outputwm42013-01-1313-301/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: make vdpau hardware decoding not use slices code pathwm42013-01-132-3/+3
| | | | | | | | | | | | | | For some reason, libavcodec abuses the slices rendering code path for hardware decoding: in that case, the only purpose of the draw callback is to pass a vdpau video surface object to video output. (It is unclear to me why this had to use the slices code, instead of just returning an AVFrame with the required vdpau state.) Make this code separate within mpv, so that the internal slices code path is not used for hardware decoding. Pass the vdpau state with VOCTRL_HWDEC_DECODER_RENDER instead. Remove the mencoder specific VOCTRLs.
* video/out: replace VOCTRL_QUERY_FORMAT with vo_driver.query_formatwm42013-01-131-1/+1
|
* video/out: make draw_image mandatory, remove VOCTRL_DRAW_IMAGEwm42013-01-131-12/+1
| | | | | | | | | | | | | Remove VOCTRL_DRAW_IMAGE and always set vo_driver.draw_image in VOs. Make draw_image mandatory: change some VOs (like vo_x11) to support it, and remove the image-to-slices fallback in vf_vo. Remove vo_driver.is_new. This member indicated whether draw_image is supported unconditionally, which is now always the case. draw_image_pts is a hack until the video filter chain is changed to include the PTS as field in mp_image. Then vo_vdpau and vo_lavc will be changed to use draw_image.
* configure: remove check for .align semanticswm42013-01-134-8/+8
| | | | | | | | | | | | | | | | | | | | | The check determined whether the argument for .align is in bytes, or log2(bytes). Apparently it's always in bytes for ELF i386 systems, and this check is used for x86 inline assembler only. Even if this assumption should be wrong, it likely won't cause much damage: the existing code uses it only in the form ".align 4", which means in the worst case it will try to align to 16 bytes, which doesn't cause any problems (unless the object file format does not support such a high alignment). Update the filters that used this. Quoting the GNU as manual: For other systems, including ppc, i386 using a.out format, arm and strongarm, it is the number of low-order zero bits the location counter must have after advancement. For example `.align 3' advances the location counter until it a multiple of 8. If the location counter is already a multiple of 8, no change is needed.
* vf_scale: prefer 420P10 -> YV12 instead of 444Pwm42012-12-281-0/+1
| | | | | | Strictly speaking, 444P is higher quality than YV12, but doing this is not very useful when playing 10 bit video with -vo opengl-old on a GPU that doesn't support 16 bit textures.
* vf_scale: support more pixel formatsRudolf Polzer2012-12-281-0/+4
| | | | | The RGBA, ARGB, BGRA, ABGR were previously not always supported, depending on system endianness.
* options: move -ass-bottom-margin/-ass-top-margin options to vf_subwm42012-12-121-10/+15
| | | | | These options might be useful sometimes, but they are not that important, and work with vf_sub only. Make them vf_sub sub-options.
* vf_sub: fix aspect ratio when using marginswm42012-12-121-3/+3
|
* video: add support for 12 and 14 bit YUV pixel formatsStephen Hutchinson2012-12-031-0/+12
| | | | | | | | | | | | Based