Протокол потокового видео — обработка фрагментации

Недавно я пытался транслировать живое видео, снятое веб-камерой, по UDP. Подход, который я использовал, заключался в том, чтобы прочитать один кадр, отправить его по udp, прочитать данные на стороне получателя и отобразить их.

Теперь я понимаю, что отправка данных по udp/tcp приводит к фрагментации, которая происходит случайным образом в зависимости от MTU транспортного уровня, а базовый IP-протокол не гарантирует количество кадров, которые будут доставлены. Минимальный MTU любого уровня данных считается равным 1500 байтам.

Однако каждый мой кадр имеет размер 1 МБ (~ 1048576 байт). Таким образом, учитывая фрагментацию данных в 1500 байт, один кадр может быть фрагментирован, и получатель получит около 700 пакетов (1048576/1500). Теперь приемнику нужно собрать данные всех этих 700 пакетов всего за один кадр, что требует дополнительной обработки. Это что-то нормальное, 700 пакетов всего за 1 кадр данных!!. Если я хочу сохранить частоту кадров всего 24 кадра в секунду, это означает, что приемник должен обрабатывать 700 * 24 = 16800 пакетов в секунду, что кажется невыполнимым.

Я хочу понять, как работают другие потоковые сайты, они точно не обрабатывают 16800 пакетов данных в секунду. Они будут использовать другие протоколы потоковой передачи, такие как RTSP, однако они построены поверх UDP/TCP, что означает, что этот протокол также должен обрабатывать фрагментацию. В наши дни потоковые веб-сайты могут передавать видео в формате 4K, и размер каждого кадра будет намного больше 1 МБ, но MTU по-прежнему составляет 1500 байт. Они также должны выполнять сжатие данных, но в какой степени. Даже если им каким-то образом удастся уменьшить размер кадра на 50% (что также необходимо распаковать на стороне получателя, что означает дополнительную обработку), им все равно потребуется обрабатывать ~ 8000 пакетов данных в секунду для видео низкого качества с частотой 24 кадра в секунду. Как они с этим справляются, как справляются с фрагментацией данных в таких масштабах.


tcp udp video-streaming rtsp ip-fragmentation
person DUDE_MXP    schedule 17.10.2020    source источник
comment
Потоковое видео обычно не выполняется путем отправки каждого кадра независимо от другого. Это не масштабируется. Вместо этого используется сжатие как самого кадра, так и различий между кадрами, что может быть довольно эффективным, поскольку кадры обычно не сильно различаются. Таким образом, необходимая полоса пропускания значительно уменьшается, а также количество пакетов, которые необходимо обработать. Дополнительные сведения см. в Википедии.   -  person Steffen Ullrich    schedule 17.10.2020

Ответы (1)


arrow_upward
4
arrow_downward

Несжатые данные очень редко отправляются по сетям. Принятые в настоящее время видеокодеки, такие как H.264 AVC, H.265 HEVC, H.266 VVC, VP8, VP9, AV1 обеспечивает потрясающую степень сжатия, которая зависит от ряда параметров, включая разрешение, частоту кадров, целевой битрейт, требования к точности воспроизведения, требования к реальному времени и пропускную способность сети хранения или доставки. назвать пару.

Все потоковые веб-сайты, на которые вы ссылаетесь, используют сжатие не только для доставки видео, но и для хранения контента в различных контейнерах, таких как файлы avi, mp4 или mkv.

Выбор потоковых протоколов также зависит от требований к реальному времени (миллисекунды или секунды), требований к инфраструктуре, требований к масштабируемости и сложности решений, а также от целевых клиентских устройств и возможностей (например, компьютера, планшета, телефона). Например, протоколы потоковой передачи на основе HTTP позволяют повторно использовать хорошо протестированную и понятную инфраструктуру и программное обеспечение HTTP и включают в себя такие преимущества, как кэширование, полезное для масштабирования количества запросов, которые могут быть обслужены.

Потоковое вещание в реальном времени, используемое для случаев использования с малой задержкой, таких как видеосвязь (например, WebRTC), где задержку необходимо удерживать менее ~150 мс, обычно выполняется через RTP/UDP. Для сигнализации посмотрите на RTSP, SIP и WebRTC. Другие протоколы (не относящиеся к IETF) включают RTMP, который был разработан Adobe, но в течение нескольких лет он находился в упадке (AFAIR).

Как вы утверждаете, даже сжатые кадры могут иметь размер в несколько тысяч байт. При потоковой передаче по RTP/UDP большие закодированные кадры разделяются на несколько пакетов/датаграмм с использованием форматов полезной нагрузки RTP, например. RFC6184, RFC7741, RFC7798, которые определяют, как кадр можно фрагментировать.

Адаптивная потоковая передача на основе HTTP имеет менее строгие требования к задержке, и здесь HTTP управляет кадрированием вашего сообщения. Протоколы включают потоковое вещание по HTTP, MPEG DASH и многие другие.

Даже если им каким-то образом удастся уменьшить размер кадра на 50% (который также необходимо распаковать на стороне приемника, что означает дополнительную обработку)

Упомянутые кодеки обеспечивают более высокую степень сжатия, дополнительная обработка незначительна, а для широко используемых кодеков кодирование/декодирование обычно поддерживается аппаратно. Ваш телефон, скорее всего, имеет аппаратное обеспечение для очень эффективного декодирования H.264.

person Ralf    schedule 17.10.2020