VideoToolbox will report a BadDataErr if you send a RASL frame just after a CRA one
Originator: | Nitz.Carola | ||
Number: | rdar://45552472 | Date Originated: | 25.10.2018 |
Status: | open | Resolved: | |
Product: | VideoToolbox | Product Version: | |
Classification: | other bug | Reproducible: | Always |
Summary: When trying to play back the following sample file on newer devices, VideoToolbox reports a kVTVideoDecoderBadDataErr when a RASL frame was encountered just after a CRA https://streams.videolan.org/streams/ts/test3_hevc_CRA_only.ts Currently we work around this by dropping the frames ourself. (https://git.videolan.org/?p=vlc.git;a=commitdiff;h=4997acdf9fedbc0b4588c9f16cb003407223aae4) This also happens with other files(mkv) whenever we were seeking and unluckily land on a CRA followed by RASL. Note that this file plays fine on older devices Steps to Reproduce: 1. Create VTDecompressionSession 2. Feed https://streams.videolan.org/streams/ts/test3_hevc_CRA_only.ts video to session via VTDecompressionSessionDecodeFrame Expected Results: The decoder handles this case by itself and VTDecompressionSessionDecodeFrame() succeeds Actual Results: VT reports kVTVideoDecoderBadDataErr Version/Build: 10O23u and 10.14
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!
The response from engineering on 45552472:
You cannot decode a RASL frame if you send CRA followed by RASL. The way to inform the decoder that a seek just happened and that it should skip the RASL frames is to attach kCMSampleBufferAttachmentKey_ResetDecoderBeforeDecoding to the sample buffer holding the IRAP.