То, что показывает YouTube в прямых трансляциях -- это не совсем реальное время. Достаточно посмотреть трансляцию какого-нибудь футбольного матча и его интернет-версию: гол в интернете случается на полминуты-минуту позже. Это HLS, HDS, MPEG-DASH -- способы доставки потоков для массовой аудитории с заметной буферизацией и поверх протокола HTTP, то есть, без существенных отличий от обычных веб-страниц.
Но видеопроизводство и доставка контента требуют передачи если не в реальном времени, как в аналоговом телевидении, то хотя бы с допустимой задержкой.
200 мс. Считается, что задержки меньше этого значения человек не замечает.1 кадр. При 25 кадрах в секнду это 40 мс. Рассинхронизация изображения и звука в 2-3 кадра -- это плохо, но возможно, большую задержку увидит даже нетренированный зритель.250-500 мс. Такие задержки доставки потоков дают IP-камеры RTSP. Но и на видеовыходе они тоже дают задержку -- большинство цифровых камер в принципе работают не совсем в реальном времени.На рисунке ниже показан путь от камеры до зрителя, режиссера (на микшере) и оператора (если камера управляется удаленно через веб-инструменты. Это частный случай, в общем можно назвать больше протоколов и вариантов управления. Но рассмотрим именно его, тем более, что он реализован в МИЭМе.
Каждый этап задействует свои протоколы. В этот раз рассмотрим получение потоков с источников (здесь это камера) и передачу выходного потока (эфирной программы) на стриминговую платформу. В качестве такой платформы по умолчанию в этом курсе будем рассматривать Youtube, но на его месте может быть и VK, OK, Facebook, Twitch и т.д. Можно запустить и собственный сервер. Обобщенно всё стриминговое производство описывается так:
RTSP — Real-Time Streaming Protocol. 1998
RTMP — Real-Time Messaging Protocol. 2009, но использовался ранее
В нашем частном (!) случае мы рассматриваем в качестве источников RTSP устройства: это камеры, кодеры или программные серверы потоков RTSP.
То есть, RTSP-камеры бесполезны, если мы не можем "достучаться" до них по сети. Например, если такая камера находится в локальной сети, снаружи она доступна только если:
Пример бесполезности работы с RTSP камерой: вы можете поставить соответствующее приложение на ваш смартфон, но работать с такой камерой вы сможете только внутри локальной сети. Например, постримить народные гуляния с улицы не получится -- у вас нет прямого IP адреса в сети мобильного оператора.
Как все-таки решить задачу стриминга RTSP из общественных сетей: Если подключиться к VPN, то ваш поток можно будет увидеть на микшере -- у смартфона будет прямой адрес и даже в локальной сети.
Зачем может понадобиться RTSP стриминг, если любая стриминговая платформа предлагает приложения RTMP-стриминга без всяких VPN? Дело в том, что отправить поток -- это половина дела. Нужно его ещё принять. Если вы используете известные платформы, то туда вы отправите, а принять этот же поток для монтажа на микшере уже не сможете. Если даже поставить свой сервер RTMP, вы получите задержку от двух секунд, причем, эта задержка может меняться по ходу трансляции из-за накапливающихся ошибок и других помех.
Этот протокол изначально был закрытым проприетарным протоколом Adobe Flash-медиасервера. Здесь важно не путать Flash как технологию графики и анимации в браузерах и Flash Video (FLV), которое по сей день применяется для доставки видеопотоков.
Flash-анимацию официально похоронили в 2020, причём, хоронили почти 10 лет, начиная с мобильных устройств, где с ней было особенно много проблем.
В 2009 году Adobe опубликовала спецификацию протокола, но хитро -- она была неполная. Существуют разные серверы, в т.ч. модуль для прокси-сервера NGINX, с ним имеет смысл познакомиться, если хотите работать со стримингом.
Что нужно знать про RTMP: