H.265 (HEVC) Декодирование на iOS - каков правильный порядок NALU перед декодированием кадров - PullRequest
0 голосов
/ 02 ноября 2018

Недавно я получил декодирование HEVC / H.265, работающее с использованием VideoToolbox API в iOS. Входящий поток RTP поступил из FFMPEG с использованием кодека x265 в libx265.

После долгих переделок я создал свое CMFormatDescription, используя входящие VPS, SPS и PPS nalus, а затем дождался ключевого кадра CRA_NUT nalu (21). Как только это произошло, я мог декодировать следующую волну полученных видео пакетов. Отлично!

Однако теперь я хочу принять поток RTP, закодированный с помощью SDK Video Coding от Nvidia. Разница в том, что вместо CRA_NUT nalu, прибывающего после параметров последовательности - теперь я получаю IDR_W_RADL (19), который VideoToolbox, похоже, не нравится - в результате я получаю kVTVideoDecoderBadDataErr из моего обратного вызова сеанса декомпрессии.

Поскольку документация для VideoToolbox довольно скудная, ее довольно сложно отлаживать. Всегда ли VideoToolBox ожидает CRA_NUT nalu в качестве ключевого кадра? Или есть ли способ заставить его принять ключевой кадр IDR_W_RADL? VideoToolbox ожидает стандартную последовательность?

И наоборот, есть ли способ настроить видеокодек nvidia sdk для возврата ключевого кадра CRA_NUT? Я просмотрел API, но ничего не могу найти - мне всегда кажется, что я получаю IDR_W_RADL вместе с параметрами последовательности.

1 Ответ

0 голосов
/ 03 ноября 2018

Хорошо, проблема не в VideoToolbox - у меня была глупая логическая ошибка с моей стороны, которая блокировала определенные кадры, попадающие в декодер! VideoToolBox принимает кадры IDR_W_RADL без проблем! Работает шарм.

...