summaryrefslogtreecommitdiffstats
path: root/video/filter/vf_scale.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-2/+2
| | | | | | | | | 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.
* vf: redo conversion filter insertion/format negotiationwm42013-12-071-23/+19
| | | | | | | | | | | | | | | | | 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-3/+1
| | | | | | 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.
* video/filter: remove legacy option handling hackswm42013-12-041-1/+1
| | | | | | | | | 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.
* Take care of some libavutil deprecations, drop support for FFmpeg 1.0wm42013-11-291-2/+2
| | | | | | | | | | | | | | PIX_FMT_* -> AV_PIX_FMT_* (except some pixdesc constants) enum PixelFormat -> enum AVPixelFormat Losen some version checks in certain newer pixel formats. av_pix_fmt_descriptors -> av_pix_fmt_desc_get This removes support for FFmpeg 1.0.x, which is even older than Libav 9.x. Support for it probably was already broken, and its libswresample was rejected by our build system anyway because it's broken. Mostly untested; it does compile with Libav 9.9.
* video/filter: remove useless vf_info fieldswm42013-10-231-5/+3
| | | | | This time I didn't bother to move the contents of the author field to the file headers. "git log" is your friend.
* vf_scale: fix get/set confusionwm42013-10-161-1/+1
| | | | This caused the equalizer controls to appear stuck.
* vf_scale: factor out libswscale equalizer controlwm42013-09-301-23/+2
| | | | Will be used by vo_x11.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-3/+3
| | | | Followup commit. Fixes all the files references.
* Fix some -Wshadow warningswm42013-07-231-4/+4
| | | | | | 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).
* 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-211-19/+12
| | | | | | | | | | | | | | | | | | 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.
* 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_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-161-45/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* video/filter: fix option parser memory leakwm42013-05-181-1/+0
| | | | | | | 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.
* video: add XYZ supportwm42013-05-011-0/+1
| | | | Needed for the ffmpeg j2k decoder.
* 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_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_scale: fix warningwm42013-01-271-1/+0
|
* video: move handling of -x/-y/-xy options to VOwm42013-01-231-4/+0
| | | | | | | | | 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: decouple internal pixel formats from FourCCswm42013-01-131-23/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* mp_image: change how palette is handledwm42013-01-131-52/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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/filter: change filter API, use refcounting, remove filter DRwm42013-01-131-24/+8
| | | | | | | | | | | | | | | | | | | | 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-41/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 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.
* video: add support for 12 and 14 bit YUV pixel formatsStephen Hutchinson2012-12-031-0/+12
| | | | | | | | | | | | Based on a patch by qyot27. Add the missing parts in mp_get_chroma_shift(), which allow allocation of such images, and which make vo_opengl automatically accept the new formats. Change the IMGFMT_IS_YUVP16_LE/BE macros to properly report IMGFMT_444P14 as supported: this pixel format has the highest numerical bit width identifier (0x55), which is not covered by the mask ~0xfc. Remove 1 bit from the mask (makes it 0xf8) so that IMGFMT_IS_YUVP16(IMGFMT_444P14) is 1. This is slightly risky, as the organization of the image format IDs (actually FourCCs + mplayer internal IDs) is messy at best, but it should be ok.
* sws_utils: remove unused helperwm42012-11-241-1/+5
| | | | | | | | sws_getContextFromCmdLine_hq() was used by the screenshot code, which now uses mp_image_swscale(). Also move the mp_sws_set_colorspace() declaration from sws_utils.h to vf_scale.c.
* options, vo_x11: remove -zoom option, make it defaultwm42012-11-161-27/+1
| | | | | | | | | | | | | | The -zoom option enabled scaling with vo_x11. Remove the -zoom option, and make its behavior default. Since vo_x11 has to use libswscale for colorspace conversion anyway, which doesn't do actual extra scaling when vo_x11 is run in windowed mode, there should be no speed difference with this change. The code removed from vf_scale attempted to scale the video to d_width/ d_height, which matters for anamorphic video and the --xy option only. vo_x11 can handle these natively. The only case for which the removed vf_scale code could matter is encoding with vo_lavc, but since that didn't set VOFLAG_SWSCALE, nothing actually changes.
* Rename directories, move files (step 2 of 2)wm42012-11-121-11/+11
| | | | | | | | | | | | Finish renaming directories and moving files. Adjust all include statements to make the previous commit compile. The two commits are separate, because git is bad at tracking renames and content changes at the same time. Also take this as an opportunity to remove the separation between "common" and "mplayer" sources in the Makefile. ("common" used to be shared between mplayer and mencoder.)
* Rename directories, move files (step 1 of 2) (does not compile)wm42012-11-121-0/+718
Tis drops the silly lib prefixes, and attempts to organize the tree in a more logical way. Make the top-level directory less cluttered as well. Renames the following directories: libaf -> audio/filter libao2 -> audio/out libvo -> video/out libmpdemux -> demux Split libmpcodecs: vf* -> video/filter vd*, dec_video.* -> video/decode mp_image*, img_format*, ... -> video/ ad*, dec_audio.* -> audio/decode libaf/format.* is moved to audio/ - this is similar to how mp_image.* is located in video/. Move most top-level .c/.h files to core. (talloc.c/.h is left on top- level, because it's external.) Park some of the more annoying files in compat/. Some of these are relicts from the time mplayer used ffmpeg internals. sub/ is not split, because it's too much of a mess (subtitle code is mixed with OSD display and rendering). Maybe the organization of core is not ideal: it mixes playback core (like mplayer.c) and utility helpers (like bstr.c/h). Should the need arise, the playback core will be moved somewhere else, while core contains all helper and common code.
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-10 07:48:42 +0000