Как вы получаете точную продолжительность данного потока h264 (Silverlight)?

Question

Справочная информация: Я кодировал необработанный файл h264 с помощью ffmpeg.Я пытаюсь создать свой собственный контейнер, например, как Smooth Streaming работает с фрагментированными контейнерами mp4.Я не доволен безопасностью плавного потока, поскольку любой может полностью скопировать файл из IIS с соответствующей аутентификацией.

Проблема В любом случае у меня есть «любопытное» воспроизведение моего потока h264 с помощью MediaStreamSource в Silverlight с включенным ssl, но я не могу получить правильную метку времени для чаков, которые я отправляюна стороне сервера к MediaStreamSource в клиенте silverlight.Между порциями данных h264 есть задержка, которую я проанализировал с помощью sps Nals.Я видел этот вопрос для получения продолжительности.Интересно, есть ли простой способ подсчета кадров в потоке h264 и получения продолжительности, чтобы я мог передать точную метку времени в MediaSampleSource.Если кто-то может A: направьте меня в сторону счетчика кадров с открытым исходным кодом или дайте мне какой-нибудь псевдокод для разбора кадров (может быть, несколько советов по синтаксическому анализу Hex).Или, может быть, у кого-то есть опыт с этой конкретной проблемой, которая была бы великолепна.Любая помощь будет очень признателен.Заранее спасибо.

Answer 1

Это на самом деле немного кроличья нора. Начните с ISO 14496 часть 10 и перейдите к разделу 7.3 для синтаксиса.

В первом приближении используется частота поля в параметрах vui_parameters (num_units_in_tick / time_scale) и число slice_header () с.

Это ломается, если вы имеете дело с HD-контентом, и ваш кодировщик использует несколько slice_header () для каждого изображения (тогда вы должны проверить first_mb_in_slice == 0).

Вам придется обратить внимание на frame_mbs_only_flag и field_pic_flag.

Другой шарик представляет собой таблицу D-1, которая интерпретирует поле pic_struct в SEI-сообщении pic_timing. Это охватывает такие вещи, как повторение поля (TBT или BTB), удвоение кадра и утроение кадра.

Если у вас есть транспортный поток, вы можете обойти его, проверив значения DTS в заголовках PES (ISO 13818 часть 1) для первого и последнего блока доступа.

Answer 2

Я просмотрел документацию ISO 14496-10 и нашел несколько шестнадцатеричных строк для поиска кадров в необработанном потоке h264:

0x00000141, 0x00000101, 0x00000165

Если вы пройдете через свой поток и посчитаете эти шестнадцатеричные строки и свою кодировку с помощью ffmpeg и libx264, это должно дать вам довольно солидный счетчик кадров. (Пожалуйста, кто-нибудь исправит меня, если я ошибаюсь). Таким образом, если у вас есть общая продолжительность видео h264, и у вас есть FPS, который вы сможете легко получить из ffmpeg, тогда вы можете использовать количество кадров, рассчитанное в любом данном фрагменте данных, которые передаются MediaStreamSource, чтобы получить очень точная метка времени для вас MediaSampleSource. Надеюсь, это кому-нибудь поможет, потому что пару дней назад меня действительно расстраивало, когда мое воспроизведение было прерывистым.

Редактировать

Поскольку я протестировал свою функцию воспроизведения в DirectShow, я заметил, что она не идеальна и работает только для упрощенно кодированных потоков h264, использующих ffmpeg. h264 имеет переменные частоты кадров и битрейты. Хотя видео работает довольно плавно, проницательный глаз может видеть, что при более сложных последовательностях в видео время немного неловко. Я думаю, что для грубого проигрывателя потокового видео это хороший метод, особенно если часто используются ключевые кадры. Я подумал, что было бы справедливо добавить это, прежде чем я нажал на кнопку ответа.