diff options
author | Stefano Pigozzi <stefano.pigozzi@gmail.com> | 2013-08-14 15:47:18 +0200 |
---|---|---|
committer | Stefano Pigozzi <stefano.pigozzi@gmail.com> | 2013-08-22 12:13:30 +0200 |
commit | a9cb2dc1b86c0f3e12231abc776009fe0a8bcf0e (patch) | |
tree | c08b89a3fd99fdd7dcfa3cc86fe597eac6357e52 /DOCS/man/en/changes.rst | |
parent | 94b4a80d455ee30e258b761290f8a87c57c7bd29 (diff) | |
download | mpv-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.rst | 2 |
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 |