summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo_xv: always try to use native bit depthwm42013-01-231-5/+2
| | | | | | Exactly the same issue as with the previous commit. Just like the vdpau code, this was apparently copy-pasted from the vo_x11 code, even though it doesn't make much sense.
* vo_vdpau: always try to native bit depth (makes 30 bit work)wm42013-01-231-5/+2
| | | | | | | | | | | | | Using vdpau on an X server configured to a bit depth of 30 (10 bit per component) failed finding a visual. The cause was a hack that tried to normalize the bit depth to 24 if it was not a known depth. It's unknown why/if this is needed, but the following things speak against it: - it prevented unusual bit depths like 30 bit from working - it wasn't needed with normal bit depth like 24 bit - it's probably copy-pasted from vo_x11 (where this code possibly makes sense, unlike in vo_vdpau) Just remove this code and look for a visual with native depth.
* video: remove -x/-y/-xy optionswm42013-01-231-32/+0
| | | | | | | | | | | | | | | -x/-y were rather useless and obscure. The only use I can see is forcing a specific aspect ratio without having to calculate the aspect ratio float value (although --aspect takes values of the form w:h). This can be also done with --geometry and --no-keepaspect. There was also a comment that -x/-y is useful for -vm, although I don't see how this is useful as it still messes up aspect ratio. -xy is mostly obsolete. It does two things: a) set the window width to a pixel value, b) scale the window size by a factor. a) is already done by --autofit (--autofit=num does exactly the same thing as --xy=num, if num >= 8). b) is not all that useful, so we just drop that functionality.
* video: add --autofit and --autofit-larger optionswm42013-01-231-2/+33
| | | | | | | | | --autofit=WxH sets the window size to a maximum width and/or height, without changing the window's aspect ratio. --autofit-larger=WxH does the same, but only if the video size is actually larger than the window size that would result when using the --autofit=WxH option with the same arguments.
* options: move -geometry parsing to m_option.cwm42013-01-238-159/+11
| | | | | | | | | This also means the option is verified on program start, not when the VO is created. The actual code becomes a bit more complex, because the screen width/height is not available at program start. The actual parsing code is still the same, with its unusual sscanf() usage.
* video: move handling of -x/-y/-xy options to VOwm42013-01-2311-88/+94
| | | | | | | | | 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.
* cocoa_common: improved trackpad scrollingMad Fish2013-01-201-5/+45
|
* cocoa_common: handle all pending events instead of just oneMad Fish2013-01-201-19/+24
|
* 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.
* options: also accept ffmpeg pixel format nameswm42013-01-172-6/+20
| | | | | | | | | | | | Options that take pixel format names now also accept ffmpeg names. mpv internal names are preferred. We leave this undocumented intentionally, and may be removed once libswscale stops printing ffmpeg pixel format names to the terminal (or if we stop passing the SWS_PRINT_INFO flag to it, which makes it print these). (We insist on keeping the mpv specific names instead of dropping them in favor of ffmpeg's name due to NIH, and also because ffmpeg always appends the endian suffixes "le" and "be".)
* osxbundle: cocoa_common: change playlist on fileopen eventsStefano Pigozzi2013-01-163-0/+42
| | | | | | | When opening new files in Finder when `mpv` is running from an application bundle, the new files will now replace the current playlist. Fixes #14
* Silence two compiler warningswm42013-01-161-1/+0
| | | | Both should be harmless.
* vo_opengl_old: add missing include statementwm42013-01-151-0/+1
| | | | | | <ctype.h> is needed at least for isalnum(). Most time this worked, because some ffmpeg or Libav versions recursively include this header from libavutil/common.h. Fix it so it always works.
* vo_sdl: I think the XVidmode hack is no longer neededRudolf Polzer2013-01-151-5/+0
| | | | I can no longer reproduce the XVidmode related hang.
* vo_sdl: request "desktop" fullscreen mode if -vm is not usedRudolf Polzer2013-01-151-8/+7
| | | | | This is a lot cleaner than our current workaround that first queries the desktop resolution.
* vo_corevideo: make compile with recent changesStefano Pigozzi2013-01-151-1/+1
| | | | Width and height were removed from mp_image. Use w and h instead.
* video: print filter chain in verbose modewm42013-01-143-10/+42
| | | | | Somewhat useful to see where filters are auto-inserted and which formats they take.
* img_format: do not mark hwaccel formats as planar yuv formatswm42013-01-141-7/+8
|
* gl_common: move things used by vo_opengl_old.c only to vo_opengl_old.cwm42013-01-133-1244/+1241
| | | | Having this in gl_common is confusing.
* vd_lavc: remove -lavdopts vstats suboptionwm42013-01-132-97/+0
| | | | | | This printed per-frame statistics into a file, like bitrate or frame type. Not very useful and accesses obscure AVCodecContext fields (danger of deprecation/breakage), so get rid of it.
* vd_lavc: remove lowres decodingwm42013-01-131-11/+2
| | | | | | | | | | This was a "broken misfeature" according to Libav developers. It wasn't implemented for modern codecs (like h264), and has been removed from Libav a while ago (the AVCodecContext field has been marked as deprecated and its value is ignored). FFmpeg still supports it, but isn't much useful due to aforementioned reasons. Remove the code to enable it.
* vo_x11: use two buffers like XvRudolf Polzer2013-01-131-71/+94
|
* vo_x11, vo_xv: XShmCompletion event supportRudolf Polzer2013-01-134-16/+73
| | | | This fixes OSD flicker with vo_xv at high frame rates.
* vo_direct3d: remove 2ch hack for 10 bit playbackwm42013-01-133-261/+5
| | | | | | | | | | | This was an awkward hack that attempted to avoid the use of 16 bit textures, while still allowing rendering 10-16 bit YUV formats. The idea was that even if the hardware doesn't support 16 bit textures, an A8L8 textures could be used to convert 10 bit (etc.) to 8 bit in the shader, instead of doing this on the CPU. This was an experiment, disabled by default, and was (probably) rarely used. I've never heard of this being used successfully. Remove it.
* vo_sdl: avoid copying just for taking screenshotswm42013-01-131-5/+3
| | | | Use reference counting instead.
* vd_lavc: prefer AVFrame over AVCodecContext fieldswm42013-01-131-18/+17
| | | | | | This is more correct. Not all frame specific fields are in AVFrame, such as colorspace and color_range, and these are still queried through the decoder context.
* mp_image: remove mp_image.bppwm42013-01-135-12/+5
| | | | | | | | This field contained the "average" bit depth per pixel. It serves no purpose anymore. Remove it. Only vo_opengl_old still uses this in order to allocate a buffer that is shared between all planes.
* imgfmt: add more ffmpeg pixel formatswm42013-01-133-2/+136
| | | | | | Most of these probably don't have much actual use, but at least allow images of these formats to be handed to swscale, should any decoder output them.
* img_format: change meaning of MP_IMGFLAG_PLANARwm42013-01-132-2/+2
| | | | | | | | | | | | | This used to mean that there is more than one plane. This is not very useful: IMGFMT_Y8 was not considered planar, but it's just a Y plane, and could be treated the same as actual planar formats. On the other hand, IMGFMT_NV12 is partially packed, and usually requires special handling, but was considered planar. Change its meaning. Now the flag is set if the format has a separate plane for each component. IMGFMT_Y8 is now planar, IMGFMT_NV12 is not. As an odd special case, IMGFMT_MONO (1 bit per pixel) is like a planar RGB format with a single plane.
* 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-134-109/+88
| | | | | | | | | | | 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-132-39/+24
|
* 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.
* mp_image: add mp_image_crop()wm42013-01-134-0/+33
| | | | Actually stolen from draw_bmp.c.
* vo_image: render subswm42013-01-131-15/+36
| | | | | | | | This makes it behave like vo_lavc. Unfortunately, the code for setting up the OSD dimensions (mp_osd_res) is copied from vo_lavc, but it doesn't look like something that should be factored out.
* vo_xv: fix OSD redrawing flickerwm42013-01-131-13/+11
| | | | | | | | redraw_frame() copied the image into the currently visible buffer. This resulted in flicker when doing heavy OSD redrawing (like changing the subtitle size to something absurdly large). Use the same logic as draw_image instead.
* vo_xv, vo_x11: simplify OSD redrawingwm42013-01-132-30/+38
| | | | | | | | | | | | | In order to support OSD redrawing for vo_xv and vo_x11, draw_bmp.c included an awkward "backup" mechanism to copy and restore image regions that have been changed by OSD/subtitles. Replace this by a much simpler mechanism: keep a reference to the original image, and use that to restore the Xv/X framebuffers. In the worst case, this may increase cache pressure and memory usage, even if no OSD or subtitles are rendered. In practice, it seems to be always faster.
* sub: do not copy the target image if there is no OSD/subswm42013-01-132-6/+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.
* vo_lavc: use reference countingwm42013-01-131-17/+4
| | | | Helps avoiding additional copies.
* video: remove img_format compat hackswm42013-01-1310-210/+85
| | | | | | | | | | | | | | | | | 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.
* draw_bmp: better way to find 444 formatwm42013-01-132-0/+17
| | | | | | | | | | | | | Even though #ifdef ACCURATE is removed, the result should be about the same. The fallback is only used by packed YUV formats (YUYV, NV12), and doing 16 bit for them instead of 8 bit is not useful. A side effect is that Y8 (gray) is not converted drawing subs, and for alpha formats, the alpha plane is not removed. This means the number of planes after upsampling can be 1-4 (1: gray, 2: gray+alpha, 3: planar, 4: planar+alpha). The code has to be adjusted accordingly to work on the color planes only. Also remove the workaround for the chroma shift 31 hack.
* video: decouple internal pixel formats from FourCCswm42013-01-1338-576/+500
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: replace old mp_image function nameswm42013-01-1313-35/+28
| | | | | mp_image_alloc() also changes argument order compared to alloc_mpi(). The format now comes first, then width/height.
* video: cleanup: move and rename vf_mpi_clear and vf_clone_attributeswm42013-01-137-96/+80
| | | | | | | | 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-1314-91/+19
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* mp_image: simplify image allocationwm42013-01-133-104/+45
| | | | | | | | | | | | | | | | | | | | | | | | mp_image_alloc_planes() allocated images with minimal stride, even if the resulting stride was unaligned. It was the responsibility of vf_get_image() to set an image's width to something larger than required to get an aligned stride, and then crop it. Always allocate with aligned strides instead. Get rid of IMGFMT_IF09 special handling. This format is not used anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was mainly used for - this is still supported.) Get rid of swapped chroma plane allocation. This is not used anywhere, and VOs like vo_xv, vo_direct3d and vo_sdl do their own swapping. Always round chroma width/height up instead of down. Consider 4:2:0 and an uneven image size. For luma, the size was left uneven, and the chroma size was rounded down. This doesn't make sense, because chroma would be missing for the bottom/right border. Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not used anymore, except in draw_bmp.c. (It's still allowed to setup mp_images manually, you just can't allocate image data with them anymore - this is also done in draw_bmp.c.)
* video: use libavutil pixel format descriptorswm42013-01-134-264/+307
| | | | | | | Replace the internal pixel format stuff with code that queries the libavutil list of pixel format descriptors. Trying to map IMGFMT_IS_RGB() etc. turned out extremely hacky.
* 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/out: replace VFCAP_TIMER with vo->untimed, fix vo_image and vo_lavcwm42013-01-134-2/+4
| | | | | | | | VFCAP_TIMER disables any additional waiting done by mpv in the playloop. Remove VFCAP_TIMER, but re-use the idea for vo_image and vo_lavc. This means --untimed doesn't have to be passed when using --vo=image.
* vd_lavc: make non-reference frames writeablewm42013-01-131-1/+18
| | | | | | | | | | |