Должен ли трек в фрагментированном MP4 начинаться с ключевого кадра?

Я принимаю поток RTMP и конвертирую его во фрагментированный файл MP4 на JavaScript. На работу ушла неделя, но я почти закончил с этой задачей. Я генерирую действительный атом ftyp, атом moov и атом moof, и первый кадр видео фактически воспроизводится (со звуком), прежде чем он перейдет в бесконечную буферизацию без ошибок, перечисленных в chrome://media-internals

Подключив видео к ffprobe, я получаю сообщение об ошибке, подобное следующему:

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x558559198080] Failed to add index entry
    Last message repeated 368 times
[h264 @ 0x55855919b300] Invalid NAL unit size (-619501801 > 966).
[h264 @ 0x55855919b300] Error splitting the input into NAL units.

Это привело меня к массовой охоте на проблемы с выравниванием данных или недопустимые байтовые смещения в моих атомах tfhd и trun, однако независимо от того, куда я смотрел или как я разрезал данные, я не мог найти никаких проблем в атоме moof.

Затем я взял исходный файл FLV и преобразовал его в MP4 в ffmpeg с помощью следующей команды:

ffmpeg -i ~/Videos/rtmp/big_buck_bunny.flv -c copy -ss 5 -t 10 -movflags frag_keyframe+empty_moov+faststart test.mp4

Я открыл и MP4, который я создавал, и MP4, выводимый ffmpeg в файле парсинга атома, и сравнил их:

Первое, что мне бросилось в глаза, это то, что сгенерированный ffmpeg файл содержит несколько видеосэмплов на каждый moof. В частности, каждый moof начинался с 1 ключевого кадра, затем содержал все разностные кадры до следующего ключевого кадра (который использовался как начало следующего атома moof)

Сравните это с тем, как я создаю свой MP4. Я создаю атом moof каждый раз, когда приходит пакет FLV VIDEODATA. Это означает, что мой moof может не содержать ключевого кадра (и обычно его нет).

Может быть, поэтому у меня проблемы? Или мне что-то еще не хватает?

Рассматриваемые видеофайлы можно скачать здесь:

• Файл, созданный ffmpeg: test.mp4
• созданный вручную файл: invalid-nal-size.mp4

Еще одна проблема, которую я заметил, заключалась в частом использовании ffmpegbase_data_offset в атоме tfhd. Однако, когда я попытался отследить общее количество добавленных байтов и самостоятельно настроить base_data_offset, я получил ошибку в Chrome примерно следующего содержания: «MSE не поддерживает base_data_offset». Согласно спецификации ISO / IEC 14996-10:

If not provided, the base-data-offset for the first track in the movie fragment is the position of the first byte of the enclosing Movie Fragment Box, and for second and subsequent track fragments, the default is the end of the data defined by the preceding fragment.

Эта формулировка заставляет меня полагать, что data_offset в первом атоме trun должен быть равен размеру атома moof, а data_offset во втором атоме trun должен быть 0 (0 байтов от конца данных, определенных предыдущим фрагментом) . Однако, когда я попробовал это, я получил ошибку, что видео данные не могут быть проанализированы. То, что сделал привело к данным, которые можно было проанализировать, было длиной атома moof плюс общая длина первой дорожки (как если бы базовое смещение было первым байтом окружающего блока moof, как и первая дорожка)