H264 через сбор RTP

http://blog.sina.com.cn/u/465bdf0b010002t1 (что-то не так)

Формат полезной нагрузки H264 через RTP / RTCP, я делал это давным-давно, и я чуть не забыл об этом, поторопитесь и просмотрите его, или я верну его ... это не должно быть учителем, хе-хе.

RTP Baotou все еще выкладывается, выглядит удобно:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| V = 2 | P | X | CC | M | PT | порядковый номер |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| отметка времени |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| идентификатор источника синхронизации (SSRC) |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| идентификаторы источника (CSRC) |
| .... |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

Больше об этом говорить не буду :)

Далее идет заголовок H264.

Первый - тип блока NAL, 8 байт.

+ ---------------------- +
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ - + - + - + - + - + - + - + - +
| F | NRI | Тип |
+ ---------------------- +

F: определяется как 0

NRI (nal_ref_idc): 00 не является опорным кадром, используемым для построения предсказания I-кадра.
Non-00 используется для поддержания целостности системы отсчета.

(Что это, я все равно не понимаю, да и не нужно. В следующий раз сделаю кодек. Я видел много концепций и не понимаю, извините. )

Тип (nal_unit_type): как показано в таблице ниже

Тип | Тип пакета | имя

Объяснять:

H264 через RTP в основном делится на три типа:

1. Единичный единичный пакет NAL - это фактический тип NAL, который можно понимать как пакет - это кадр данных H264, что больше на практике.

2. Пакет агрегации Пакет данных содержит несколько кадров H264. Его также можно подразделить, как описано ниже.

3. Блок фрагментации. Один кадр данных делится на несколько пакетов RTP, что также очень часто, особенно для ключевых кадров.

Разбейте пакет агрегации:

Пакет агрегации можно разделить на четыре типа:

Кадры в пакете STAP-A содержат одно и то же время NALU без DON.

Кадры в пакете STAP-B содержат одно и то же время NALU с DON

Кадры в пакете MTAP16 содержат разное время NALU, смещение временной метки = 16.

Кадры в пакете MTAP24 содержат разное время NALU, смещение временной метки = 24.

Фактически используются 1-23. STAP-A (24) и FU-A (28) не встречались с другими типами, поэтому я их не изучал.Разумеется, я имею в виду клиента. Если вы хотите сделать отправителя, вы можете заказать его самостоятельно.

Данные, полученные из RTP, не имеют заголовка NAL. Значение заголовка NAL в документах RFC3984 и ITUTH264 кажется другим. Это была путаница вначале, и это было долгое время. Я забыл подробности, больше не ищу, и заполню, когда увижу в следующий раз. Фактическое приложение - добавить заголовок H264 STREAM.

h264_stream_head = 0x00, 0x00, 0x00, 0x01 4 байта

Далее следует тип блока NAL, который относится к типу NAL, определенному в H264. Есть небольшая разница, особенно когда речь идет о FU, который будет обсуждаться ниже.

Единичный единичный пакет NAL (1-23)

Это очень просто, пакет - это кадр данных. h264_stream_head + NAL_unit_type ... отправляется непосредственно на декодирование.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| F | NRI | тип | |
+ - + - + - + - + - + - + - | |
| Байт 2..n одного блока NAL |
| |
| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| : ... ДОПОЛНИТЕЛЬНОЕ заполнение RTP |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

STAP-A (24)

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Заголовок RTP |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| STAP-A NAL HDR | НАЛУ 1 Размер | NALU 1 HDR |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Данные НАЛУ 1 |
::
+ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| | НАЛУ 2 Размер | NALU 2 HDR |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Данные НАЛУ 2 |
::
| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| : ... ДОПОЛНИТЕЛЬНОЕ заполнение RTP |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

Эта структура должна быть очень четкой. Во-первых, длина 16 бит, вы можете получить кадр, h264_stream_head + NALU 1 HDR ... отправить его для декодирования. Подсчитайте следующий кадр. Обратите внимание, что это не обязательно 32-битное выравнивание.

Следует отметить, что этот размер NALU не включает сами 2 байта.

FU-A (28)

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Индикатор FU | Заголовок FU | |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |
| |
| Полезная нагрузка FU |
| |
| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| : ... ДОПОЛНИТЕЛЬНОЕ заполнение RTP |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

Индикатор FU

+ ---------------------- +
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ - + - + - + - + - + - + - + - +
| F | NRI | Тип |
+ ---------------------- +

Заголовок FU

+ ---------------------- +
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ - + - + - + - + - + - + - + - +
| S | E | R | Тип |
+ ---------------------- +

S: 1 означает начальный пакет кадра

E: 1 означает конечный пакет кадра, который согласуется с битом маркера RTP.

R: 0 должен

Здесь следует отметить, что тип блока NAL должен объединять первые четыре байта индикатора FU + последние четыре байта заголовка FU. То есть поле типа находится в заголовке FU

nal_unit_type = (fu_indicator & 0xe0) | (fu_header & 0x1f)

Когда кадры получены, добавьте H264_streaming_head + nal_unit_type .... для декодирования

Некоторые из них невозможно запомнить, все они вытеснены из кода, и вы должны записать их в следующий раз, когда посмотрите на них. Очень утомительно писать после работы, 88

Справочные материалы:

1. RFC3984 - формат полезной нагрузки RTP для видео H.264

Расчет частоты дискретизации звука и отметки времени

Для ffmpeg интервал временной отметки равен: presentation_time = frame_size / sample_rate;

frame_size: количество байтов, соответствующих каждому кадру данных

sample_rate: частота дискретизации, которая относится к количеству выборок амплитуды звуковой волны в секунду при оцифровке аналоговой звуковой волны.

Presentation_time: Интервал времени, то есть продолжительность воспроизведения кадра данных, в секундах, если вы используете миллисекунды в качестве единицы, умножьте на 1000

презентация_время = размер_фрейма * 1000 / частота_выборки;

Например: количество байтов, соответствующих каждому кадру данных AAC, равно 1024, если sample_rate == 32K, соответствующий временной интервал составляет 1024 * 1000/32000 = 32 мс.

Количество байтов, соответствующих каждому кадру данных mp3, равно 1152, если smple_rate == 8k, соответствующий временной интервал составляет 1152 * 1000/8000 = 144 мс.

Метод отметки времени видео и аудио

http://blog.csdn.net/wfqxx/article/details/5497138

1. Отметка времени видео

pts = inc ++ * (1000 / fps); где inc - статическое состояние, начальное значение равно 0, а временная метка inc увеличивается на 1.

В ffmpeg код в

pkt.pts = m_nVideoTimeStamp ++ * (m_VCtx-> time_base.num * 1000 / m_VCtx-> time_base.den);

2. Отметка времени аудио

pts = inc ++ * (размер_фрейма * 1000 / частота_выборки)

Код в ffmpeg:

pkt.pts = m_nAudioTimeStamp ++ * (m_ACtx-> frame_size * 1000 / m_ACtx-> sample_rate);

Частота дискретизации означает количество выборок амплитуды звуковой волны в секунду при оцифровке аналоговой звуковой волны.

. Частотный диапазон нормального человеческого слуха составляет около 20 Гц ~ 20 кГц.Согласно теории дискретизации Найквиста, чтобы гарантировать, что звук не искажается, частота дискретизации должна быть около 40 кГц. Обычно используемые частоты дискретизации звука: 8 кГц, 11,025 кГц, 22,05 кГц, 16 кГц, 37,8 кГц, 44,1 кГц, 48 кГц и т. Д. Если используется более высокая частота дискретизации, качество звука DVD также может быть достигнуто.

При декодировании звука AAC с частотой дискретизации 44,1 кГц время декодирования одного кадра должно контролироваться в пределах 23,22 миллисекунды.

жизненный опыт:

(Исходный кадр AAC содержит 1024 выборки и соответствующие данные за период времени)

анализ:

1 AAC

Время воспроизведения аудиокадра = количество выборок, соответствующих кадру AAC / частоте дискретизации (единица измерения: с)

1024 выборки на кадр. Частота дискретизации составляет 44100 кГц, 44100 отсчетов в секунду, поэтому, согласно формуле, время воспроизведения аудиокадра = количество отсчетов отсчетов, соответствующих кадру AAC / частоте дискретизации.

Текущее время воспроизведения одного кадра AAC = 1024 * 1000000/44100 = 22,32 мс (единица измерения - мс).

2 MP3

Каждый кадр mp3 составляет 1152 байта, тогда:

frame_duration = 1152 * 1000000 / частота_выборки

Например: когда sample_rate = 44100HZ, рассчитанная продолжительность составляет 26,122 мс, поэтому часто слышимое время воспроизведения mp3 на кадр фиксировано на 26 мс.

Принцип синхронизации аудио и видео (воспроизведение)

Каждый кадр аудио или видео имеет продолжительность: продолжительность:
частота дискретизации означает, сколько раз амплитуда звуковой волны дискретизируется в секунду при оцифровке аналоговой звуковой волны.
. Частотный диапазон нормального человеческого слуха составляет около 20 Гц ~ 20 кГц.Согласно теории дискретизации Найквиста, чтобы гарантировать, что звук не искажается, частота дискретизации должна быть около 40 кГц. Обычно используемые частоты дискретизации звука - 8 кГц,

11,025 кГц, 22,05 кГц, 16 кГц, 37,8 кГц, 44,1 кГц, 48 кГц и т. Д. Если используется более высокая частота дискретизации, качество звука DVD также может быть достигнуто
. При декодировании звука AAC с частотой дискретизации 44,1 кГц декодирование время одного кадра должно быть Control в пределах 23,22 миллисекунды.
Общие сведения:
(Исходный кадр AAC содержит 1024 выборки и соответствующие данные за период времени)
Анализ:
1)
Время воспроизведения аудиокадра AAC = количество выборок, соответствующих кадру AAC / частоте дискретизации (единица измерения: с )
один кадр 1024 отсчета. Частота дискретизации составляет 44100 кГц, 44100 отсчетов в секунду, поэтому согласно формуле время воспроизведения аудиокадра = количество отсчетов отсчетов, соответствующих кадру AAC / частоте дискретизации.
Текущее время воспроизведения одного кадра AAC = 1024 * 1000000/44100 = 22,32 мс (Единица: мс)
2)
Каждый кадр MP3 mp3 составляет 1152 байта, тогда:
frame_duration = 1152 * 1000000 / sample_rate
Например: когда sample_rate = 44100HZ, рассчитанная длительность составляет 26,122 мс. слышно mp3 каждые Время начала воспроизведения кадра установлено на 26 мс.
3)
Время воспроизведения видео H264 связано с частотой кадров frame_duration = 1000 / fps.
Например: fps = 25.00, расчетное значение обычно составляет 40 мсек, что соответствует 40 мсек на один кадр видеоданных.

Теоретическая синхронизация аудио и видео (воспроизведения) выглядит следующим образом:
получается длительность каждого кадра данных, а аудио и видео чередуются в контейнере: ось
времени: ось времени: 0 22,32 40 44,62 66,96 80 89,16 111,48 120 . ...............
Аудио: 0 22.32 44.62 66.96 89.16 111.48 ......
Видео: 0 40 80120 ..... ........
Это То есть продолжительность видео добавляется, а продолжительность аудио добавляется для сравнения, в зависимости от того, что меньше записано.

Но реальная ситуация (игра) не соответствует действительности.

1. Сначала решите проблему

Почему вы не воспроизводите аудио и видео? В приведенном выше примере будет воспроизводиться один кадр звука с задержкой 22,32 мс, а кадр видео - с задержкой 40 мс.

Потому что эти 22,32 мс или 40 мс не являются точными или отличаются от времени вещания звуковой карты . Здесь вам нужно знать, сколько времени требуется звуковой карте для воспроизведения кадра / звука в формате buf.

2: звуковая карта воспроизводит по одной точке выборки вместо одного кадра. Звук можно услышать, когда точка дискретизации потеряна, а видео - нет.

3: Режим синхронизации аудио и видео: 1 ---- режим обратного вызова

Предположим, что звуковая карта имеет два буфера, каждый из которых хранит звуковой PCM, который будет воспроизводиться, и воспроизводит буфер «B». Сначала определите несколько моментов.

(1) Размер буфера фиксирован, поэтому время воспроизведения буфера фиксировано и составляет 30 мс;

(2) При воспроизведении буфера «B» буфер «buf» израсходован, а затем снова воспроизводится буфер «A», чтобы гарантировать, что звук в формате pcm всегда является непрерывным.

(3) Когда воспроизводится buf, это означает, что система (звуковая карта) прошла 30 мс. В это время возможно, что реальное время прошло 40 мс (здесь все равно), и здесь вы получаете время 30 мс через обратный вызов;

(4) Затем используйте 30 мс видео, соответствующее аудио, время в это время точное:

Временная шкала: 0 30 60
90120 ...... Аудио: 0 22.32 44.62 66.96 89.16 111.48 ......
Видео: 0 40 80120 ......

(5) Здесь возникает вопрос, как рассчитать 10 мс между 30 и 40 мс в видео, это не проблема, потому что человеческий глаз не может видеть это за 10 мс.

То есть, когда звук вызывается один раз в 30 мс, может воспроизводиться второй кадр видео, как показано на рисунке выше.

Первый обратный вызов (30 мс) --- трансляция (40 мс) видео,

Первый обратный вызов (60 мс) --- трансляция (80 мс) видео,

Первый обратный вызов (90 мс) --- видео нет,

Первый обратный вызов (120 мс) - трансляция (120 мс) видео.

4: Режим синхронизации аудио и видео: 1 ---- режим блокировки

Еще посмотрите на картинку выше

(1) buf «B» воспроизводится все время, внешний буфер buf, переданный в buf «A», отправляет данные в buf «A», а затем не возвращается немедленно, дождитесь воспроизведения buf «B» и затем вернитесь,

В настоящее время время от входящей до исходящей блокировки составляет buf, например, выше 30 мс.

(2) После воспроизведения buf «A» внешний буфер buf, переданный в buf «B», передает данные в buf «B», а затем он не возвращается немедленно, дождитесь воспроизведения buf «A» и затем вернитесь,

В настоящее время время от входящей до исходящей блокировки составляет buf, например, выше 30 мс.

(3) Выполните цикл выше (1) (2) и получите то же время 30 мс, что и метод обратного вызова. Следующее совпадает с методом обратного вызова, см. Метод обратного вызова (4) (5).

Отправлено с http://blog.csdn.net/zhuweigangzwg/article/details/25815851

H264 Over RTP и расчет частоты дискретизации звука и отметки времени

H264 через сбор RTP

Расчет частоты дискретизации звука и отметки времени

Метод отметки времени видео и аудио

Принцип синхронизации аудио и видео (воспроизведение)

рекомендация