summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* 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
* 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.
* 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.
* 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.
* mp_image: remove mp_image.bppwm42013-01-131-1/+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.
* 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-131-1/+0
| | | | | | | | | | | | | | | | | | | | | 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-135-70/+68
| | | | | | | | | | | | | | | | | 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-1310-41/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1310-27/+25
| | | | | 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-131-5/+2
| | | | | | | | 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-132-10/+7
| | | | | | | | | | | | | | | | | | | | | | | | | 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/out: replace VFCAP_TIMER with vo->untimed, fix vo_image and vo_lavcwm42013-01-133-0/+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.
* video: remove things related to old DR codewm42013-01-135-72/+54
| | | | | | | | | | | | | | | 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-134-45/+59
| | | | | | | | | | | | | | | | | | | | 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.
* vo_caca: accept any stride for output imagewm42013-01-131-3/+10
| | | | Similar to previous commit.
* vo_corevideo: use stridewm42013-01-131-1/+1
| | | | | | The code was entirely correct, as the VO doesn't report VFCAP_ACCEPT_STRIDE in query_format. Add stride capability in preparation for changing the video chain: soon all VOs will have to support arbitrary strides.
* vo_corevideo: correct stride usagewm42013-01-131-5/+6
| | | | | | | | | | The code assumed mp_image_alloc() would allocate an image large enough for corevideo's stride, which doesn't have to be the case. If corevideo's stride was larger than the stride of mp_image, the memcpy() would write beyond the mp_image allocation. This probably didn't actually happen, but fix the code to be more correct anyway.
* mp_image: require using mp_image_set_size() for setting w/hwm42013-01-139-32/+16
| | | | | | | | | | | | | | 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-16/+7
| | | | | | 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.
* vo_direct3d: simplifywm42013-01-131-198/+55
|
* vo_xv: simplifywm42013-01-131-47/+2
| | | | We can do this because slice support has been removed.
* video: remove slice based filtering and video outputwm42013-01-1312-119/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-4/+7
| | | | | | | | | | | | | | 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-1314-40/+32
|
* video/out: make draw_image mandatory, remove VOCTRL_DRAW_IMAGEwm42013-01-1314-81/+61
| | | | | | | | | | | | | 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.
* vo_sdl: fix for rename of a function in SDL2's interfaceRudolf Polzer2013-01-121-2/+4
|
* vo_sdl: add a "sw" flag like in openglRudolf Polzer2013-01-101-36/+75
| | | | | | Also, rework the renderer creation for the flag being generally effective even if the "SW renderer" is detected only after creating a context.
* vo_xv: fix compilation when shared memory header files are not availablewm42013-01-061-5/+2
| | | | | This is an extremely obscure situation, but can actually happen on OpenBSD.
* cocoa_common: add support for `--no-border`Stefano Pigozzi2012-12-311-0/+1
| | | | Draw a window with style NSBorderlessWindow when the user uses `--no-border`.
* vo_sdl: support -geometry properlyRudolf Polzer2012-12-311-2/+7
| | | | Now the x and y origin options (-geometry WxH+X+Y) are supported too.
* vo_sdl: some OSD optimizationsRudolf Polzer2012-12-281-23/+41
| | | | | | | | | | | | | | | | The premultiplied-alpha hack is changed: - The first stage now uses a colormod of black with an unmodified texture. This saves on applying the AND mask of 0xFF000000 to keep alpha only. - The second stage no longer uses an AND mask, but only an OR mask of 0xFF000000 to cancel out alpha. - The texture uploads are no longer done using SDL_LockTexture, SDL_ConvertPixels, SDL_UnlockTexture when the mpv pixel format matches the OSD's pixel format. Instead, SDL_UploadTexture is used, which saves a copy when using the "opengl" renderer.
* vo_opengl_old: reject 9-15 bit formats if textures have less than 16 bitwm42012-12-283-1/+22
| | | | | | | | | | | | | | | | | | | For 9-15 bit material, cutting off the lower bits leads to significant quality reduction, because these formats leave the most significant bits unused (e.g. 10 bit padded to 16 bit, transferred as 8 bit -> only 2 bits left). 16 bit formats still can be played like this, as cutting the lower bits merely reduces quality in this case. This problem was encountered with the following GPU/driver combination: OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) 915GM x86/MMX/SSE2 OpenGL version string: 1.4 Mesa 9.0.1 It appears 16 bit support is rather common on GPUs, so testing the actual texture depth wasn't needed until now. (There are some other Mesa GPU/driver combinations which support 16 bit only when using RG textures instead of LUMINANCE_ALPHA. This is due to OpenGL driver bugs.)
* gl_common: properly reject old OpenGL versionswm42012-12-281-11/+20
| | | | | | | | | | | | | | | | | | | The extension checking logic was broken, which reported OpenGL 3 if the OpenGL .so exported OpenGL 3-only symbols, even if the reported OpenGL version is below 3.0. Fix it and simplify the code a bit. Also never fail hard if required functions are not found. The caller should check the capability flags instead. Give up on the idea that we should print a warning if essential functions are not found (makes loading of ancient legacy-only extensions easier). This was experienced with the following version strings: OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) 915GM x86/MMX/SSE2 OpenGL version string: 1.4 Mesa 9.0.1 (Possibly reports a very old version because it has no GLSL support, and thus isn't even GL 2.0 compliant.)
* vo_opengl: use more precise gamma for BT.709 with color managementnand2012-12-282-5/+5
| | | | | | | | | | Change from gamma 2.2 to the slightly more precise 1/0.45 as per BT.709. https://www.itu.int/rec/R-REC-BT.709-5-200204-I/en mentions a value of γ=0.45 for the conceptual non-linear precorrection of video signals. This is approximately the inverse of 2.22, and not 2.20 as the code had been using until now.
* sdl, encode_lavc: fix copyright headersRudolf Polzer2012-12-282-6/+5
| | | | | | Some of them had changes in 2012; extend their header. Fix project name.
* vdpau: silence a clang warningRudolf Polzer2012-12-281-1/+2
| | | | It's just some braces...
* vo/ao: SDL 1.2+ audio driver, SDL 2.0+ accelerated video driverRudolf Polzer2012-12-282-0/+1008
| | | | | | | | | | | This mainly serves as a fallback for platforms where nothing better is available; also as a debugging help. Both the audio and video driver are not first class - the audio driver lacks delay detection, and the video driver only supports a single YUV color space. Configure options: --disable-sdl2 to disable SDL 2.0+ detection, --disable-sdl to disable SDL 1.2+ detection. Both options need to be specified to turn off SDL support entirely.
* core: make WAKEUP_PERIOD overridable by the voRudolf Polzer2012-12-192-0/+4
| | | | | | | | | | | | This is better than having just the operating system type decide the wakeup period, as e.g. when compiling for Win32/cygwin, a wakeup period of 0.5 would work perfectly fine. Instead, the default wakeup period is now only decided by availability of a working select() system call (which is the case on cygwin but not mingw and MSVC) AND a vo that can provide an event file descriptor or a similar hack (vo_corevideo). vos that cannot do either need polling for event handling and now can set the wakeup period to 0.02 in the vo code.
* vo_xv: try harder to get correctly aligned pointers/strideswm42012-12-031-4/+6
| | | | | | | | | | | | | | | | | | | | To get guaranteed alignment for the chroma planes with typical YV12 playback, we have to double the alignment on the image width, as the chroma planes have half the image width. Clear the image with black instead of green to hide scaling artifacts on the right border of the screen. (It might be possible to create the image layout ourselves by not calling XvShmCreateImage(), and filling in our own image width and exact strides, but that's probably too risky: the Xv client library sends an X protocol request to query the real image dimension and strides. It is unknown to me whether X servers or drivers would generally accept an image with mismatching parameters, even if the image is conceptually valid.) Allocate the image with av_malloc() in the non-SHM case. I suspect the non-SHM case doesn't matter much, though.
* osx_common: Avoid deprecated Gestalt callsStefano Pigozzi2012-12-021-16/+26
| | | | | | | | Gestalt is deprecated since 10.8. Change the code to read the OS version from a system plist file. As mentioned http://stackoverflow.com/a/11072974/499456 Apple engineers are suggesting this plist reading approach.
* vo_xv: allocate Xv images with aligned stridewm42012-11-221-4/+5
| | | | | | | | | | | | | | | This is required, as the Xv image is directly used for rendering OSD and taking screenshots. These involve libswscale, which wants aligned strides. There doesn't seem to be an easy way to request aligned strides from Xv. Simply request an image with an aligned width, which usually results in an aligned stride. The padding border remains invisible. One caveat is that if padding is added, there might be scaling artifacts on the right pixel border of the screen. This is at least the case with nvidia binary drivers. Since we consider vo_xv a sensible choice only on crappy/slow hardware, performance is more important than quality.
* video: fix bogus uses of mp_image.w/widthwm42012-11-211-2/+2
| | | | | | | | | | | | | | | | | mp_image has this confusing distinction between the w/h and width/height fields. w/h are the actual width and height, while width/height have a very special meaning inside the video filter code: it's the actually allocated width, which is also used for stride padding. Screenshot related code abused the w/h fields to store the aspect corrected size. Some code confused the role of w/h and width/height. Fix these issues. For aspect corrected size, display_w/h are used, while width/height should never be use