summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* video: add vda decode support (with hwaccel) and direct renderingStefano Pigozzi2013-08-226-112/+541
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* vf_eq: fix behavior when changing parameterswm42013-08-201-4/+14
| | | | | | | | | | | | | | | Using -vf eq and changing brightness, contrast, etc. using key bindings with e.g. "add brightness 1" didn't work well: with step width 1, the property gets easily "stuck". This is a rounding problem: e.g. setting gamma to 3 would actually make it report that gamma is set to 2, so the "add" command will obviously never reach 3 with a step width of 1. Fix this by storing the parameters as integers. This was broken in cac7702. This commit effectively changed these properties to use the value as reported by vf_eq, instead of the previously set value for the "add" command. This was more robust, but not very correct either, so we keep the new behavior and make vf_eq report its parameters more accurately.
* 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.
* vaapi: use highest available profile, instead of mapping it exactlywm42013-08-191-41/+38
| | | | | | | Now the code does the same as the original MPlayer VAAPI patch, instead of trying to map the profiles exactly. See previous commit for justification and discussion.
* vdpau: don't try to match codec profileswm42013-08-191-27/+11
| | | | | | | | | | | | | | | | Instead, do what MPlayer did all these years. It worked for them, so there's probably no reason to change this. Apparently fixes playback with some files, where the VDPAU decoder does not formally support a profile, but decoding works with a more powerful profile anyway. Though note that MPlayer did this because it couldn't do it in a better way (no decoder reported profiles available when creating the VDPAU decoder), so it's not entirely clear whether this is a good idea. An alterbative implementation might try to map the profiles exactly, and do some fall backs if the exact profile is not available. But this hack-solution works too.
* 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-172-0/+17
| | | | | | | 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.
* vdpau_old: add forgotten probe callbackwm42013-08-151-0/+1
| | | | Could make it crash if the VO didn't support vdpau decoding.
* vdpau: fix compilation on Libavwm42013-08-151-0/+1
| | | | | | Libav's <libavcodec/vdpau.h> header uses some libavocdec symbols without forward-declaring them and without including the headers declaring them. FFmpeg's header for this is fine.
* video/decode: change fix_image callbackwm42013-08-153-5/+7
| | | | | This might make it slightly easier when trying to implement surface read-back for hardware decoding.
* vd_lavc: fix comment, document hwdec video frame size trickinesswm42013-08-151-1/+4
| | | | | | | | | About this issue, it would be better if the surfaces could be allocated with the real size, and the vdpau video mixer could be created with that size as well. That would be a bit hard, because the real surface size had to be communicated to vdpau. So I'm going with this solution. vaapi seems to be fine with either surface size, so there's hopefully no problem.
* video/decode: pass parameters directly to hwdec allocate_image callbackwm42013-08-155-20/+14
| | | | | | Instead of passing AVFrame. This also moves the mysterious logic about the size of the allocated image to common code, instead of duplicating it everywhere.
* 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.
* vaapi: fix typowm42013-08-141-2/+2
|
* 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-1211-3/+1572
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
* img_convert: add function to scale RGBA OSD imageswm42013-08-122-0/+4
|
* video: redo hw decoding initialization, add --hwdec=autowm42013-08-114-99/+195
| | | | | | | | | | | | | | | | Change how the HW decoding stuff is organized, the way it's initialized in particular. Instead of duplicating the list of supported codecs for hwaccel decoders, add a probe function which allows each decoder to report whether it supports a given codec. Add an "auto" choice to the --hwdec option, which automatically enables hardware decoding if libavcodec and/or the VO supports it. What mpv prints on the terminal changes a bit. Now it will just print a single line whether hw decoding is used or not (and nothing at all if no hw decoding at all was requested). The pretty violent fallback from hw decoding to software decoding is still quite verbose and evil-looking though.
* 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-0667-161/+161
| | | | Followup commit. Fixes all the files references.
* gl_video: handle non-mod-2 4:2:0 YUV video correctlywm42013-08-062-2/+14
| | | | | | | | | | | | | | | | 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
| | | | | | | | | | This introduces some changes in resize behaviour. Most importantly the window frame is not constrained to it's screen's `visibleFrame`. Anyone who still wants that kind of behaviour when opening a video, can use `--autofit-larger`. Even though the size of the window is not constrained, it's position is, so that the titlebar will always be visible. When using `--no-border` even the position will not be constrained in any way.
* vd_lavc: print warning if hardware decoding API is not availablewm42013-07-301-0/+3
| | | | | At least currently, this case pretty much happens only in the case vdpau is requested, but not compiled in.
* vd_lavc: fix CONFIG_VDPAU checkwm42013-07-301-1/+1
| | | | | | CONFIG_VDPAU was just defined to 0, instead of undefined when vdpau was unavailable. I blame the old mplayer code, which apparently can't have consistent conventions.
* build: fix build with vdpau, simplifywm42013-07-293-2/+43
| | | | | | | | | | | | Instead of generating vdpau_template.c with a Perl script, just include the generated file in git. This is ok because it changes very rarely, and the script is larger than the output it generates. It also simplify the Makefile, and fixes the build. The problem was that transitive dependencies do not work with generated files: there is no dependency information yet when building it the first time. I overlooked this because I didn't delete the .d files for testing (which contained the correct dependencies, but only _after_ a first successful build).
* vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel APIwm42013-07-2815-315/+866
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
* lavc_dr1: make reference counting thread-safewm42013-07-281-4/+39
| | | | | | | | See previous commits. This time, the lock is kept for rather long times (e.g. for the duration of a big image memory allocation), but this (probably) still doesn't matter at all. This also affects legacy code only (pre-refcounting libavcodec).
* mp_image_pool: make reference counting thread-safewm42013-07-282-40/+70
| | | | | | | | See previous commits. Also simplify this thing: 2 flags per pool image are enough to avoid a weird central refcount and an associated shared object keeping the refcount. We could even just store these two flags in the mp_image itself (like in mp_image.flags or mp_image.priv), but let's not for the sake of readability.
* mp_image: make reference counting thread-safewm42013-07-281-3/+27
| | | | | | | | | | This hasn't been done yet, because pthreads is still an optional dependency, so this is a bit annoying. Now doing it anyway, because maybe we will need this capability in the future. We keep it as simple as possible. We (probably) don't need anything more sophisticated, and keeping it simple avoids introducing weird bugs. So, no atomic instructions, no fine grained locks, no cleverness.
* m_config: refactor some thingswm42013-07-281-6/+6
| | | | | | | | | | | | | | Change how m_config is initialized. Make it more uniform; now all m_config structs are intialized in exactly the same way. Make sure there's only a single m_option[] array defining the options, and keep around the pointer to the optstruct default value, and the optstruct size as well. This will allow reconstructing the option default values in the following commit. In particular, stop pretending that the handling of some special options (like --profile, --v, and some others) is in any way elegant, and make them explicit hacks. This is really more readable and easier to understand than what was before, and simplifies the code.
* mp_image: pass through colorspace info to libavfilterwm42013-07-281-0/+8
| | | | | | | | | | | | | This change affects vf_lavfi. Until recently, libavfilter was not colorspace aware at all. This changed with the addition of colorspace fields to AVFrame. libavfilter's vf_scale picks them up (as of recent ffmpeg git). Since this support is still kind of wonky and not part of the normal format negotiation, this won't set the correct output colorspace, though. Not adding a separate test for HAVE_AVFRAME_COLORSPACE. This is slightly unclean, but on the other hand adding an explicit test seems like a waste of effort.
* vf: fix unintended overwriting of image infowm42013-07-282-4/+5
| | | | | | The symptom was that "-vf scale,format=rgba" broke the vsfilter colorspace hack in sd_ass. vf->reconfig is allowed to overwrite its input parameter for convenience (maybe that was a bad idea).
* gl_video: make sure image parameters are correctly set on screenshotswm42013-07-261-7/+8
| | | | Makes sure the chroma_location