summaryrefslogtreecommitdiffstats
path: root/DOCS/man/en/changes.rst
diff options
context:
space:
mode:
authorStefano Pigozzi <stefano.pigozzi@gmail.com>2013-08-14 15:47:18 +0200
committerStefano Pigozzi <stefano.pigozzi@gmail.com>2013-08-22 12:13:30 +0200
commita9cb2dc1b86c0f3e12231abc776009fe0a8bcf0e (patch)
treec08b89a3fd99fdd7dcfa3cc86fe597eac6357e52 /DOCS/man/en/changes.rst
parent94b4a80d455ee30e258b761290f8a87c57c7bd29 (diff)
downloadmpv-a9cb2dc1b86c0f3e12231abc776009fe0a8bcf0e.tar.bz2
mpv-a9cb2dc1b86c0f3e12231abc776009fe0a8bcf0e.tar.xz
video: add vda decode support (with hwaccel) and direct rendering
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.
Diffstat (limited to 'DOCS/man/en/changes.rst')
-rw-r--r--DOCS/man/en/changes.rst2
1 files changed, 2 insertions, 0 deletions
diff --git a/DOCS/man/en/changes.rst b/DOCS/man/en/changes.rst
index 4a843cb882..386275377d 100644
--- a/DOCS/man/en/changes.rst
+++ b/DOCS/man/en/changes.rst
@@ -100,6 +100,8 @@ General Changes for mplayer2 to mpv
* Allow changing/adjusting video filters at runtime. (This is also used to make
the ``D`` key insert vf_yadif if deinterlacing is not supported otherwise.)
* Native VAAPI support
+* OSX: VDA support using libavcodec hwaccel API insted of FFmpeg's decoder. Up
+ to 2-2.5x reduction in CPU usage.
* General bug fixes and removal of long-standing issues
* General code cleanups (including refactoring or rewrites of many parts)
* Many more changes