aboutsummaryrefslogtreecommitdiffstats
path: root/libavfilter/qsvvpp.c
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 12:38:51 -0700
commit8f146b526ff8d63adc02e1c5db15850f4589230b (patch)
tree7200951812f25ae226daf81618367e20d4949a6b /libavfilter/qsvvpp.c
parente24d768a76b14a1cbea0ec622c89573f7d06fdee (diff)
downloadffmpeg-8f146b526ff8d63adc02e1c5db15850f4589230b.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>
Diffstat (limited to 'libavfilter/qsvvpp.c')
0 files changed, 0 insertions, 0 deletions