H.265 (HEVC) Decoding on iOS - what is the correct NALU order before frames can be decoded

1.7k views Asked by At

I recently got HEVC / H.265 decoding working using VideoToolbox api in iOS. The incoming RTP stream came from FFMPEG using the x265 codec in libx265.

After much tinkering, I created my CMFormatDescription using the incoming VPS, SPS and PPS nalus - then I waited for a CRA_NUT nalu (21) keyframe. Once that came through, I could decode the next wave of video packets received. Great!

However I want to now accept an RTP stream encoded by Nvidia's Video Coding SDK. The difference is though that instead of a CRA_NUT nalu arriving after the sequence parameters - I am now receiving an IDR_W_RADL (19) which VideoToolbox doesn't seem to like - as a result i get kVTVideoDecoderBadDataErr from my decompression session's callback.

Since the documentation is quite sparse for VideoToolbox - it's quite difficult to debug. Does VideoToolBox always expect a CRA_NUT nalu as a keyframe? Or is there any way to make it accept an IDR_W_RADL keyframe? Is there a standard sequence VideoToolbox expects?

Conversely, is there any way to configure the nvidia video codec sdk to return a CRA_NUT keyframe? I've looked through the api but can't find anything - i always seem to get IDR_W_RADL along with the sequence parameters.

1

There are 1 answers

0
John M On BEST ANSWER

Ok, the issue isn't with VideoToolbox - I had a silly logic error on my part which blocked certain frames getting through to the decoder! VideoToolBox accepts IDR_W_RADL frames with no bother! Works a charm.