ts nalu в mp4 mdat, похоже, не содержит ни nalu, ни avcc

Я создал java-программу для анализа сегментов mp4 и ts. Я мультиплексировал фрагмент ts с помощью ffmpeg в mp4. Я пытаюсь понять, почему ffmpeg сформировал mdat таким, какой он есть.

Вот исходные 4 NALU, извлеченные из TS-PES в шестнадцатеричном формате, упорядоченные по стартовым кодам (рис.1):

00 00 00 01 |09 e0
00 00 00 01 |67 42 c0 0d 96 56 1e 33 7f e0 08 00 05 be a0 a0 a0 be 00 00 07 d0 00 00 ea 61 28
00 00 00 01 |68 da 8f 20
00 00 00 01 |65 88 80 40 20 7f 3e 21 11 c2 18 78 b0 00 40 81 0e 04 1a 24 05 48 09 84 67 36 61 14 33 8f eb 05 d6 a5 e4 1e 34 d1 f8 65 08 8c 00 f0 00 ...

Судя по моему парсеру, они выглядят как настоящие NALU (рис. 2):

fzb:false nri:0x0 nut:9 [[DATA]] : 09 E0
fzb:false nri:0x3 nut:7 seq_parameter_set_rbsp [[DATA]] : 67 42 C0 0D 96 56 1E 33 7F E0 08 00 05 BE A0 A0 A0 BE 00 00 07 D0 00 00 EA 61 28
fzb:false nri:0x3 nut:8 pic_parameter_set_rbsp [[DATA]] : 68 DA 8F 20
fzb:false nri:0x3 nut:5 slice_layer_without_partitioning_rbsp() fmis:0 st:7(I_2) ppsi:0x0 [[DATA]] : 65 88 80 40 20 7F 3E 21 11 C2 18 78 B0 00 40 81 0E 04 1A 24 05 48 09 84 67 36 61 14 33 8F EB 05 D6 A5 E4 1E 34 D1 F8 65 08 8C 00 F0 00

Затем мой мультиплексированный mp4 mdat, разделенный SampleTableBox, содержит эти шестнадцатеричные данные, упорядоченные по тому, что выглядит как деформированное NALU (рис. 3):

00 00 00 02 |09 e0
00 00 00 1b |67 42 c0 0d 96 56 1e 33 7f e0 08 00 05 be a0 a0 a0 be 00 00 07 d0 00 00 ea 61 28
00 00 00 04 |68 da 8f 20
00 00 1e ac |65 88 80 40 20 7f 3e 21 11 c2 18 78 b0 00 40 81 0e 04 1a 24 05 48 09 84 67 36 61 14 33 8f eb 05 d6 a5 e4 1e 34 d1 f8 65 08 8c 00 f0 00

Обратите внимание на сокращенную ссылку на приведенные выше данные из ITU-T H264 7.4.1 как:

fbz = forbidden_zero_bit
nri = nal_ref_idc
nut = nal_unit_type
fmis = first_mb_in_slice
st = slice_type
ppsi = pic_parameter_set_id

Также обратите внимание, что полезная нагрузка одинакова.

Я предполагаю, что mp4 правильный, потому что он правильно работает в любом плеере. Но я не уверен, что мультиплексирование mdat сделало со стартовыми кодами NALU. Я немного новичок в этом, и мне было трудно понять, почему это может быть.

Они не похожи на NALU, потому что начальный код не заканчивается на 01.

Было высказано предположение, что это AvcC (ISO/IEC 14996-15 5.2.4.1.1), но первый байт в каждом наборе данных начинается с 00, как и NALU, и не пройдет тест configurationVersion (первый байт 01).

Я хотел бы знать, как в этом случае указывается mdat. Если бы кто-нибудь мог указать мне правильное направление или неопровержимый том, это было бы очень признательно. Спасибо!


person nilgirian    schedule 06.11.2016    source источник


Ответы (1)


Похоже, вы пытаетесь проанализировать mdat MP4 как формат Приложения B для H.264, что неверно, поскольку MP4 использует формат AVCC для H.264. Было хорошее объяснение этих форматов в Возможные местоположения для набора параметров последовательности/изображения для потока H.264

person nobody555    schedule 06.11.2016
comment
Большое спасибо! - person nilgirian; 06.11.2016
comment
Кажется, они тоже не в формате AvcC :( Я все еще ищу ответ. - person nilgirian; 12.11.2016
comment
Похоже, вы что-то путаете (вероятно, NALU в стиле AVCC и экстраданные AVCC). Это простые 4-байтовые поля NALU-длины (зависит от значения NALULengthSizeMinusOne, но обычно это 4 байта), поэтому нет необходимости в каком-либо тесте configurationVersion (первый байт 01). Не исправляйте здесь имя AVCC, потому что это не официальное имя и может называться кодировкой NALU в стиле MP4. - person nobody555; 12.11.2016
comment
Ой! Так что мне кажется, что NALULengthSizeMinusOne исходит из AVCConfigurationBox, а материал в mdat - это просто параметрSetNALLengths и параметрSetNALUnits.. это действительно кажется ответом, который я ищу.. спасибо за уточнение. Действительно очень полезно. - person nilgirian; 13.11.2016