Какова лучшая стратегия для потокового вещания в реальном времени?

Question

Я не имею в виду, какая транспортная технология (например, WebRT C, Web Socket, стандарт HTTP и c.) Является лучшей для потоковой передачи в реальном времени с веб-камер и т. Д., Но c., Но Общая стратегия ( с точки зрения самого программирования ).

В моем тестировании я обнаружил, что лучше всего будет:

1. Просто передавать кадр за кадром ( потоковое изображение JPEG напрямую), по крайней мере, со скоростью 30 мс / кадр, однако это довольно интенсивно использует пропускную способность. (Скажем, каждый кадр имеет в среднем 50 КБ, для 1-секундного видео это 500 КБ, а это около 30 МБ в минуту, так что в час, который будет отдавать или брать 1,8 ГБ), возможно, решение заключается не в использовании JPEG, а в чем-то вроде AVIF Сжатие изображения , которое, когда я тестировал размер и качество, было очень оптимальным. Это может привести к снижению пропускной способности при покадровой потоковой передаче в реальном времени. Сводка для этого подхода в том, что он действительно в реальном времени, быстрый и плавный, но потребляет большую пропускную способность.
2. Я также тестировал с MJPEG (сначала кодирует кадры, а затем отправляет их кусками) - контейнер AVI, но изображения внутри являются сжатыми изображениями JPEG. Частота кадров гладкая, но локальный возврат уже имеет задержку в 1 секунду, поэтому, если это будет отправлено по сети (через UDP, TCP / HTTP / Websocket и т. Д. c.), Не проверял, но я предполагаю, что это добавит дополнительные задержка, скажем, 1 секунда. Я исследовал существующую потоковую передачу и обнаружил, что общая задержка составляет 3 секунды, так что примерно так, как сейчас. Сводка для MJPEG, я не думаю, что это вообще экономит полосу пропускания, поскольку, в конце концов, внутри контейнера AVI все еще остаются изображения JPEG, то, что было сохранено, было количеством сетевых запросов (не уверен, что это даже плюс)
3. Наконец, аналогично подходу MJPEG, но используйте кодеры / декодеры, такие как MPEG1, MPEG4, WEBM et c. определенно сэкономит пропускную способность из-за лучшего алгоритма сжатия, но определенно увеличит задержку, поскольку MJPEG с просто необработанной упаковкой JPEG внутри контейнера, этот подход добавит дополнительную нагрузку на процессор для обработки дальнейшего сжатия. Итак, в итоге для этого подхода он экономит полосу пропускания, но добавляет большую задержку.

Учитывая 3 сценария ios выше, я бы предположил, что лучшая стратегия для потоковой передачи в реальном времени это вообще не сжимать, наименьшее - это сжимать в JPEG и упаковывать JPEG в контейнер (например, 3-4 кадра в упаковке) за 100 мс и передавать байты в сеть. Тем не менее, для эксперта по потоковой передаче в реальном времени, какова лучшая стратегия для потоковой передачи в реальном времени?

Answer 1

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

Web Socket, стандартный HTTP будет работать примерно так же, но WebRT C будет работать значительно лучше, если вы правильно его используете. WebRT C не сделал ничего нового для решения этой проблемы, но он использует существующую технологию RTP / RTCP, которая позволяет отправителям и получателям сообщать о состоянии передачи мультимедиа. Отправитель может на ходу регулировать битрейт или даже изменять сложность кодирования, если получатель запрашивает это.

У меня нет хорошего единого документа для всего этого, но требования rmcat хорошо объясняет это!

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