summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* x11: add window iconwm42013-09-013-0/+105
| | | | | | | | | | | | | | | | | | | | | The png file added to etc/ are taken from the link mentioned in commit 303096b, except that they have been converted to 16 bit, sRGB (with color profile info dropped, if there was one), and transparent pixels reset for better compression. The file x11_icon.bin is generated by gen-x11-icon.sh. I'm adding it to the git repo directly, because the script requires ImageMagick, and we don't want to make building even more complicated. The way how this is done is basically a compromise between effort required in x11_common.c and in gen-x11-icon.sh. Ideally, x11_icon.bin would be directly in the format as required by _NET_WM_ICON, but trying to write the binary width/height values from shell would probably be a nightmare, so here we go. The zlib code in x11_common.c is lifted from demux_mkv.c, with some modifications (like accepting a gzip header, because I don't know how to make gzip write raw compressed data).
* input: deal with spurious X11 LeaveNotify eventswm42013-09-013-4/+21
| | | | | | | | | | | | | | | | | | | | | If the mpv window is unfocus, clicking on the OSC should focus the window (done by the window manager) and allow interaction with the OSC. But somehow X sends a spurious LeaveNotify event, immediately followed by an EnterNotify event. This happens at least with IceWM. The result is that the OSC will disappear (due to receiving MOUSE_LEAVE). The OSC will stay invisible, because EnterNotify isn't handled, and there's nothing that could make the OSC appear again. Solve this by handling EnterNotify. We cause a redundant MOUSE_MOVE event to be sent, which triggers the code to make the OSC visible. We have to remove the code from input.c, which ignores redundant mouse move events. Since the code ignoring redundant mouse move events is still needed on Windows, move that code to w32_common.c. The need for this is documented in the code, also see commit 03fd2fe. (The original idea was to save some code by having this code in the core, but now it turns out that this didn't quite work out.)
* input: add some more X11 multimedia/internet keyswm42013-09-011-0/+3
| | | | | | | | These keys can be found on various "multimedia" and "internet" keyboard. X defines many keycodes, so I'm not adding all, just what I found on my own keyboard. Other key codes can be added on request.
* cocoa_common: enable click-through on the video viewStefano Pigozzi2013-09-011-0/+1
| | | | | | Generate a mouse down event on the first click so that one can interact with the OSC directly as opposed to wasting the first click in order to focus the window.
* cocoa_common: track mouse move events when not focusedStefano Pigozzi2013-09-011-1/+1
| | | | | This is really only important with the OSC and makes the tracking code behave more consistently with the X11 one.
* video: add unscaled mode with --video-unscaledwm42013-09-011-3/+17
|
* gl_video: don't crash if no FBOs are availablewm42013-08-281-4/+6
| | | | | | | | This probably has been broken since bbc865a: a test was added that uses a FBO, but it's always run, even if FBOs were not detected. On the other hand, fbotex_init() just runs into an assert. Fix the test that triggered this condition, and make fbotex_init() "nicer" by just failing if FBOs are not available.
* wayland/shm: rework format handlingAlexander Preisinger2013-08-261-47/+76
| | | | Use a linked list for all supported formats and make the format table const.
* wayland: fix memory leaksAlexander Preisinger2013-08-262-2/+8
|
* cocoa_common: autohide dock when autohiding menubarStefano Pigozzi2013-08-261-1/+5
| | | | A cocoa bug doesn't allow to do otherwise. Will open a radar later.
* wayland: don't create our own log contextAlexander Preisinger2013-08-263-19/+14
| | | | This was more problematic than useful ([vo/wayland/wayland])
* wayland/shm: use opaque regionsAlexander Preisinger2013-08-261-0/+10
| | | | | | Make use of opaque regions on non-alpha formats. This allows the compositor to improve the drawing of the surface, because he can discard everything behind the window when drawing.
* gl_video: fix odd video sizes with PBOswm42013-08-261-0/+4
| | | | | | | | | Odd video sizes if pixel formats with chroma subsampling and PBOs were used, garbage was rendered. This was because the PBO path created buffers with an unpadded size, and then tried to upload a padded image to it. Fix it by explicitly setting the padded size. (As with the non-PBO path, we rely that image allocations are somehow padded, which is normally the case.)
* wayland: shm based software renderingAlexander Preisinger2013-08-252-0/+649
| | | | | | | | | | | | | | | | | | | | A wayland output based on shared memory. This video output is useful for x11 free systems, because the current libGL in mesa provides GLX symbols. It is also useful for embedded systems where the wayland backend for EGL is not implemented like the raspberry pi. At the moment only rgb formats are supported, because there is still no compositor which supports planar formats like yuv420p. The most used compositor at the moment, weston, supports only BGR0, BGRA and BGR16 (565). The BGR16 format is the fastest to convert and render without any noticeable differences to the BGR32 formats. For this reason the current (very basic) auto-detection code will prefer the BGR16 format. Also the weston source code indicates that the preferred format is BGR16 (RGB565). There are 2 options: * default-format (yes|no) Which uses the BGR32 format * alpha (yes|no) For outputting images and videos with transparencies
* wayland: remove shm listener for the backendAlexander Preisinger2013-08-252-16/+0
| | | | | | The obtained information from the shm listener isn't used by anything and is also wrong now in wayland git master branch because of new shm formats which need a different way of saving the supported formats.
* wayland/egl: rework resizing (again)Alexander Preisinger2013-08-253-88/+90
| | | | | | | | | Moves a good chunk of the resizing code to wayland_common.c. This makes it possible to share it with future video drivers. It doesn't resizit it immediatly, it calcutlates the new position and size and then shedules a resizing event. This removes the ugly callback and void pointer from the wayland data structure.
* vo_corevideo: use dwidth/dheight for window dimensionsStefano Pigozzi2013-08-251-1/+1
| | | | | In the previous commit I wrongly used params->d_h/d_w which happened to work by chance.
* vo_corevideo: convert to use reconfig instead of configStefano Pigozzi2013-08-251-7/+6
|
* vo_corevideo: don't set colormatrix on direct rendering pathStefano Pigozzi2013-08-251-23/+49
| | | | | | | | | | | The current code uses GL_YCBCR_422_APPLE texture format. This allows to handle transparently the conversion to RGB but always use BT.601 colormatrix [1]. Hopefully I can adapt gl_video to take CVPixelBuffers soon so that `vo=opengl` can be used instead of `vo=corevideo` with `hwdec=vda` [1]: http://www.opengl.org/registry/specs/APPLE/ycbcr_422.txt http://www.opengl.org/registry/specs/APPLE/rgb_422.txt
* vo_corevideo: fix regression in colormatrix handlingStefano Pigozzi2013-08-251-40/+22
| | | | | | | | | | Regression since 18b6c01d92. That commit changed the colorspace handling to always reinit the video output. Since the CVPixelBuffers are lazily created, VOCTRL_SET_YUV_COLORSPACE was always called when the CVPixelBufferRef was NULL. Since CoreVideo functions do not complain when called on NULL, no one noticed that CVBufferSetAttachment, which stored the color matrix meta data was called on NULL.
* video: handle video output levels with mp_image_paramswm42013-08-244-18/+7
| | | | | | | | | | | | 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.
* vo_image: simplifywm42013-08-241-28/+2
|
* video/out: don't require VOs to handle screenshot aspect speciallywm42013-08-243-8/+2
| | | | | | | | | | | | | | | | 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.
* vo_vaapi: potentially fix screenshot colorspace issueswm42013-08-241-0/+1
| | | | | | mp_image_set_params() doesn't check whether the colorspace parameters are consistent (e.g. setting YUV colorspaces with RGB formats), and shouldn't need to.
* Some more mp_msg conversionswm42013-08-236-214/+179
| | | | | Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
* x11/out: mp_msg conversionAlexander Preisinger2013-08-231-29/+21
|
* cocoa_common: avoid locking calls when not neededStefano Pigozzi2013-08-231-2/+2
| | | | | | | | | | cocoa_common contains some locking calls to support video outputs that support live resizing (at this moment only vo=opengl). These should not be used unless the VO declares it is multithreaded by registering the resize_redraw callback used for live resizing. Fixes #200
* video: add vda decode support (with hwaccel) and direct renderingStefano Pigozzi2013-08-221-105/+309
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Decoding H264 using Video Decode Acceleration used the custom 'vda_h264_dec' decoder in FFmpeg. The Good: This new implementation has some advantages over the previous one: - It works with Libav: vda_h264_dec never got into Libav since they prefer client applications to use the hwaccel API. - It is way more efficient: in my tests this implementation yields a reduction of CPU usage of roughly ~50% compared to using `vda_h264_dec` and ~65-75% compared to h264 software decoding. This is mainly because `vo_corevideo` was adapted to perform direct rendering of the `CVPixelBufferRefs` created by the Video Decode Acceleration API Framework. The Bad: - `vo_corevideo` is required to use VDA decoding acceleration. - only works with versions of ffmpeg/libav new enough (needs reference refcounting). That is FFmpeg 2.0+ and Libav's git master currently. The Ugly: VDA was hardcoded to use UYVY (2vuy) for the uploaded video texture. One one end this makes the code simple since Apple's OpenGL implementation actually supports this out of the box. It would be nice to support other output image formats and choose the best format depending on the input, or at least making it configurable. My tests indicate that CPU usage actually increases with a 420p IMGFMT output which is not what I would have expected. NOTE: There is a small memory leak with old versions of FFmpeg and with Libav since the CVPixelBufferRef is not automatically released when the AVFrame is deallocated. This can cause leaks inside libavcodec for decoded frames that are discarded before mpv wraps them inside a refcounted mp_image (this only happens on seeks). For frames that enter mpv's refcounting facilities, this is not a problem since we rewrap the CVPixelBufferRef in our mp_image that properly forwards CVPixelBufferRetain/CvPixelBufferRelease calls to the underying CVPixelBufferRef. So, for FFmpeg use something more recent than `b3d63995` for Libav the patch was posted to the dev ML in July and in review since, apparently, the proposed fix is rather hacky.
* cocoa_common: fix window positioning with `--geometry`Stefano Pigozzi2013-08-221-10/+5
| | | | | | | | | | | Regression since ff3b98d11c. The window positioning code relied on the visibleFrame's height without taking into account the dock's presence. Also moved the constraining code to the proper method that overrides the original NSWindow behaviour. This avoids having to check for border since the constraining is performed by Cocoa only for titled windows. Fixes #190
* wayland: separate shm and cursor contextAlexander Preisinger2013-08-192-9/+15
| | | | | | The display, window, keyboard and cursor structures are now cleanly and logically separated. Also could prevent a future bug where no shm format is set when the cursor image is loaded (Never happened until now).
* video: make it possible to scale/pan the video by arbitrary amountswm42013-08-191-1/+7
| | | | | | | | | | | Add --video-align-x/y, --video-pan-x/y, --video-scale options and properties. See the additions to the manpage for description and semantics. These transformations are intentionally done on top of panscan. Unlike the (now removed) --panscanrange option, this doesn't affect the default panscan behavior. (Although panscan itself becomes kind of useless if the new options are used.)
* options: remove --panscanrange optionwm42013-08-191-8/+3
| | | | | | This option allowed you to extend the range of the panscan controls, so that you could essentially use it to scale the video. This will be replaced by a separate option to set the zoom factor directly.
* vo_vdpau: add RGB supportwm42013-08-181-14/+154
| | | | | | | | | | | | | | | | | | | | | Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
* vo_vdpau: fix screenshots if panscan is usedwm42013-08-181-4/+5
| | | | | | | When panscan was used, i.e. the video is cropped to make the video fill the screen if video and screen aspects don't match, screenshots contained only the visible region of the source video, stretched to original video size.
* vo_vdpau: remove unused variablewm42013-08-181-2/+0
| | | | | It was used to manage video surface in the software decoding path, but now surface management shares the code with hardware decoding.
* vo_vdpau: use color close to black as default colorkey (instead of green)wm42013-08-171-1/+4
| | | | | | | | | | | | | | | | | | The VDPAU default colorkey, although it seems to be driver specific, is usually green. This is a pretty annoying color, and you usually see it briefly (as flashes) if the VDPAU window resizes. Change it to some shade of black. The new default color is close to what MPlayer picks as colorkey (and apparently it worked well for them): VdpColor vdp_bg = {0.01, 0.02, 0.03, 0}; Since our OPT_COLOR can set 8 bit colors only, we use '#020507' instead, which should be the same assuming 8 bit colors. Obviously, you can't use black, because black is a way too common color, and would make it too easy to observe the colorkey effect when e.g. moving a terminal with black background over the video window.
* vo_vdpau: allow setting colorkeywm42013-08-171-0/+15
| | | | | | | Formally, this sets the "background color" of the presentation queue. But in practice, this color is also used as colorkey. This commit doesn't change the VDPAU default yet.
* vo_corevideo: add uyvy422 pixel format supportStefano Pigozzi2013-08-151-0/+5
| | | | | Looks like the vda_h264_dec in ffmpeg likes to output this format and it inserted swscale to do pixfmt conversion to yuyv422.
* x11: fix --ontopwm42013-08-141-3/+3
| | | | Apply it after mapping.
* cocoa_common: add precise scrolling supportStefano Pigozzi2013-08-131-16/+11
| | | | | | This adds precise scrolling support. I ran some tests and it seems a little bit smoother and well.. precise. The defaults are rebindable using: AXIS_UP, AXIS_DOWN, AXIS_LEFT and AXIS_RIGHT.
* Revert "sub: support straight alpha additionally to premultiplied alpha"wm42013-08-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | This reverts commit 689a25003fc8098e5fdfbb2faefc0e18365d3acb, with some adjustments to code that was added after that commit. I just messed up big time. We don't need this, and in fact the commit confused straight and premultiplied alpha at one point (just a simple inverted condition due to an oversight), which is why it looked like it was working. In commit 2827295 I wrote: Also, libva can't decide whether it accepts straight or premultiplied alpha for OSD sub-pictures [...] That was just me messing up and being severely confused by my own bugs. VA API uses premultiplied alpha, which by the way is nice and thoughtful of the VA API devs. Well, this was stupid. But in the end, I'm glad that I could actually reduce codesize by a good amount again.
* vo: fix build with #ifdef -> #ifwm42013-08-121-1/+1
| | | | | Whoever had the idea of introducing mixed conventions for these preprocessor symbols should be shot.
* video: add vaapi decode and output supportwm42013-08-123-1/+1059
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is based on the MPlayer VA API patches. To be exact it's based on a very stripped down version of commit f1ad459a263f8537f6c from git://gitorious.org/vaapi/mplayer.git. This doesn't contain useless things like benchmarking hacks and the demo code for GLX interop. Also, unlike in the original patch, decoding and video output are split into separate source files (the separation between decoding and display also makes pixel format hacks unnecessary). On the other hand, some features not present in the original patch were added, like screenshot support. VA API is rather bad for actual video output. Dealing with older libva versions or the completely broken vdpau backend doesn't help. OSD is low quality and should be rather slow. In some cases, only either OSD or subtitles can be shown at the same time (because OSD is drawn first, OSD is prefered). Also, libva can't decide whether it accepts straight or premultiplied alpha for OSD sub-pictures: the vdpau backend seems to assume premultiplied, while a native vaapi driver uses straight. So I picked straight alpha. It doesn't matter much, because the blending code for straight alpha I added to img_convert.c is probably buggy, and ASS subtitles might be blended incorrectly. Really good video output with VA API would probably use OpenGL and the GL interop features, but at this point you might just use vo_opengl. (Patches for making HW decoding with vo_opengl have a chance of being accepted.) Despite these issues, decoding seems to work ok. I still got tearing on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also tested with the vdpau vaapi wrapper on a nvidia system; however this was rather broken. (Fortunately, there is no reason to use mpv's VAAPI support over native VDPAU.)
* x11_common: get hack for Motif Window Manager out of the waywm42013-08-111-1/+11
| | | | | | | | Disable the hack by default, because it's interfering with some more modern WMs. MWM (Motif Window Manager) is probably pretty dead, but we still allow enabling the old hack with "--fstype=mwm_hack". See github issue #179.
* vo: unref waiting image before destroying VO driverwm42013-08-111-1/+1
| | | | | | | | This is in theory more correct with respect to hardware decoding. With hardware decoding, the VOs play the role of the video surface allocator, and nothing is allowed to reference surfaces past the VO lifetime. But in theory waiting_mpi could be a reference to a HW video surface, so it should be relased before the VO is uninitialized.
* wayland: add support for precise scrollingAlexander Preisinger2013-08-071-2/+14
| | | | | | | | The default value for a standard mouse is 10.0. Because we don't want to multiply the value in the input config file we scale it down to 1.0. Hopefully this should work for more precise mousewheels or touchpad, but I don't have access to such hardware.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-0624-76/+76
| | | | Followup commit. Fixes all the files references.
* gl_video: handle non-mod-2 4:2:0 YUV video correctlywm42013-08-061-2/+10
| | | | | | | | | | | | | | | | Allocate textures big enough to include the bottom/right borders (so the chroma texture sizes are rounded up instead of down). Make the texture large enough to include the additional luma border. Conceptually, we pretend that the video frame is fully aligned, and then crop away the unwanted borders. Filtering (even just bilinear) will access the borders anyway, so it's possible that we might need to switch to "harder" cropping instead, but at least pixels not close to the border should be displayed correctly now. Add a comment to mp_image.c about this luma border. These semantics are kind of subtle, and the image allocation code handle this in a subtle way too, so it's better to document this explicitly. The libavutil image allocation code does similar things.
* vo_corevideo: use new log APIStefano Pigozzi2013-08-011-15/+5
| | | | | Also removes the printing of the OpenGL info when using verbose mode since gl_common already does that.
* vo_corevideo: move to C from Objective-CStefano Pigozzi2013-08-012-41/+11
| | | | | This file was alredy written in C. The only remaining part was the file exension and `#import`s.
* cocoa_common: use new log APIStefano Pigozzi2013-08-011-7/+11
|
* wayland: switch to the new mp_msg apiAlexander Preisinger2013-07-313-8/+23
|
* video/out: use new mp_msg stuff for vo.c and vo_openglwm42013-07-317-82/+96
| | | | The first step; also serves as example.
* options: handle presets directly in m_configwm42013-07-311-4/+2
| | | | | This means that "mpv -vo opengl-hq:help" will actually show the correct defaults, instead those of plain vo_opengl.
* cocoa_common: simplify resize codeStefano Pigozzi2013-07-301-51/+16
| |<