diff options
author | Aman Gupta <aman@tmm1.net> | 2018-05-04 15:41:30 -0700 |
---|---|---|
committer | Aman Gupta <aman@tmm1.net> | 2018-05-18 19:16:34 -0700 |
commit | 2884575d97cb6a52045f3ed68443c8e42bc7a914 (patch) | |
tree | efc2cb9690dd5bcfe59b1fd94575259c21192e69 /tests | |
parent | 76716518a8174ca4931cb673e70c6fdc24302e88 (diff) | |
download | ffmpeg-2884575d97cb6a52045f3ed68443c8e42bc7a914.tar.gz |
avcodec/videotoolbox: fix decoding of some HEVC videos
In a normal hwaccel, the AVHWFramesContext sets AVFrame.hw_frames_ctx
when it initializes a new AVFrame in av_hwframe_get_buffer().
But the VT hwaccel doesn't know what hw_frames_ctx to assign when
the AVFrame is first created, because it depends on the format of
the pixbuf that the decoder eventually decides to return. Thus
newly created AVFrames always have a NULL hw_frames_ctx, and the
hwaccel would only assign the ctx once a frame was done decoding.
This worked fine with the H264 decoder, but with the HEVC decoder
the frame's data may be moved to another empty AVFrame. Since the
empty AVFrame never had hw_frames_ctx set, a frame with a NULL
ctx could be returned to the API user.
This patch works around the issue by moving the derived
hw_frames_ctx from the AVFrame to a new VTHWFrame which now holds
both the CVPixelBufferRef and the AVBuffer. The hw_frames_ctx
is only copied to the AVFrame right before it is about to be
returned to the user in videotoolbox_postproc_frame() (since
in the case of VT, the hw_frames_ctx is only there for the API
user anyway).
Fixes playback on macOS and iOS of some hevc videos like
https://s3.amazonaws.com/tmm1/videotoolbox/germany-hevc-zdf.ts
Signed-off-by: Aman Gupta <aman@tmm1.net>
(cherry picked from commit 8f146b526ff8d63adc02e1c5db15850f4589230b)
Diffstat (limited to 'tests')
0 files changed, 0 insertions, 0 deletions