aboutsummaryrefslogtreecommitdiffstats
path: root/tests/fate/cdxl.mak
diff options
context:
space:
mode:
authorAman Gupta <aman@tmm1.net>2018-05-04 15:41:30 -0700
committerAman Gupta <aman@tmm1.net>2018-05-18 19:16:34 -0700
commit2884575d97cb6a52045f3ed68443c8e42bc7a914 (patch)
treeefc2cb9690dd5bcfe59b1fd94575259c21192e69 /tests/fate/cdxl.mak
parent76716518a8174ca4931cb673e70c6fdc24302e88 (diff)
downloadffmpeg-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/fate/cdxl.mak')
0 files changed, 0 insertions, 0 deletions