отметка времени RTP h264

Question

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

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

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

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

Answer 1

Не имеет значения, кодирует ли ваш кодировщик видео со скоростью 10FPS или 30FPS, с помощью метки времени 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

Нет простой формулы для этого.

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

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

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

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

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

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

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