временная метка h264 RTP

Question

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

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

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

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

Answer 1

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

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

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

Для этого не существует простой формулы.

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

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

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

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

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

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

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