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

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

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


c#-4.0 h.264 silverlight-4.0
person shibbybird    schedule 21.02.2012    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

0x00000141, 0x00000101, 0x00000165

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

Изменить

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

person shibbybird    schedule 24.02.2012

arrow_upward
0
arrow_downward

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

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

Это не работает, если вы имеете дело с 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) для первой и последней единицы доступа.

person Mutant Bob    schedule 02.05.2012