h264 RTP timestamp

Question

У меня есть путаница в отношении метки времени h264 RTP-пакета. Я знаю, что настенная тактовая частота видео составляет 90 кГц, которую я определил в SIP SDP. Частота кадров моего кодировщика не равна 30 FPS, она является переменной. Он варьируется от 15 FPS до 30 FPS на лету. Поэтому я не могу использовать фиксированную метку времени.

Может ли кто-нибудь сказать мне временную метку следующего закодированного пакета.
После 0-миллисекундного времени RTP timestamp = 0 (Пусть стартовая временная метка 0)
После 50-миллисекундной временной метки RTP =?
После 40-миллисекундной временной метки RTP =?
После 33-миллисекундного времени RTP timestamp =?

Какова формула, когда кодированная частота кадров является переменной?

Заранее спасибо.

Answer 1

Не имеет значения, кодирует ли ваш кодировщик видеосигнал с частотой 10FPS или 30FPS, с меткой времени RTP вы указываете приемнику, как долго это пауза между двумя кадрами. Таким образом, вы определяете это на лету для каждого кадра. Таким образом, вы можете отправить 10 кадров за одну секунду (10 кадров в секунду), а в другой секунде вы можете отправить 30 кадров (30 кадров в секунду). Вам нужно только установить метку времени RTP правильно. И если у меня возникнет вопрос, вы сомневаетесь, как это сделать ...

Пусть отметка времени начала равна 0, вы добавляете время настенных часов в миллисекундах, умноженное на 100 на последнюю метку времени RTP, или вы можете используйте любой желаемый масштаб времени. Для того, чтобы декодер расшифровывает 10fps видео при 30 кадрах в секунду, добавьте 333000 на РТП метку времени для каждого пакета ... но давайте посмотрим на ваш пример:

Frame #  RTP Time Time between frames [ms] 
[ 1]    0 0 
[ 2]   50000 50 
[ 3]   90000 40 
[ 4]   420000 33 

Так что, если вы установите метку времени RTP, как этот (Time in ms * 100000) вы будете делать нагрузки декодера и декодировать кадр 1, а затем загружать и декодировать кадр 2, но он будет спать в течение 50 мс (разница во времени между кадрами 1 и кадра 2), прежде чем он рисует рамку 2, и так далее ...

И как вы можно видеть, что декодер использует метки времени RTP, чтобы знать, когда отображать их, и это не имеет значения, если видео было закодировано в 30 или 10 кадров в секунду.

Кроме того, если видеоролик составляет 30 кадров в секунду, это не означает, что в течение каждой секунды будет 30 пакетов RTP. Иногда их может быть больше 100, поэтому у вас не может быть формулы, которая обеспечивает правильный расчет времени RTP.

Я думаю, что это то, что вам нужно ... надеюсь, что я помог, то не -1 меня, если я не ... =)

Answer 2

Там не простая формула для этого.

Момент, используемый для выборки кадра перед кодированием, называется PTS (временная метка презентации). Это выходит за рамки кодировщика, вы должны помнить об этом в потоке данных при захвате фреймов.

Оттуда, у Вас есть 2 возможности:

1. Кодер H264 не генерируют B-кадра, то метка времени RTP должна быть ВТС + случайное смещение (то же самое для всех потокового сессии)
2. Если кодер генерирует B-кадры (или B-фрагменты), тогда порядок декодирования должен быть изменен, так как B-кадр требует, чтобы следующий кадр был декодирован, поэтому его необходимо отправить раньше.

В последнем случае RFC6184 заявляет, что у вас есть несколько способов потока закодированных блоков NAL.

В большинстве потоковых программ будет использоваться режим «Non interleaved», в котором вы должны установить временную метку RTP для смещения PTS +, но отправить их в порядке декодирования, чтобы временная метка не увеличивалась монотонно. Это также означает, что клиент должен будет декодироваться в полученном порядке и не изменять порядок кадров в заказе PTS.

Я не использую этот термин DTS здесь по причине, потому что вам не нужно расшифровывать метку времени для этого работать, только порядок.

Последний режим, описанный в RFC6184, представляет собой так называемый чередующийся порядок, в котором вы можете изменить порядок единиц NAL. В этом случае вам необходимо реализовать некоторую логику приложения для изменения порядка единиц, см. RFC6184.