Около недели назад здесь была интересная статья о методах организации видеотрансляций с минимально возможной задержкой, и в комментариях прозвучал ряд закономерных вопросов, на многие из которых я не увидел полноценного и содержательного ответа. В своём посте я хотел бы дополнить материал коллег, и поделиться с читателями своими мыслями по следующим вопросам:
Зачем вообще нужна минимальная задержка?
Как можно просто и наглядно замерять задержку при трансляции видеосигнала?
Какие элементы видеотракта влияют на увеличение задержки?
Наш топовый результат — FullHD сигнал пролетел до сервера и обратно менее чем за полсекунды.
Интересно? Тогда читайте дальше.
Итак, зачем вообще нужна минимальная задержка?
Моя компания занимается организацией онлайн-видеотрансляций, и в последнее время мы очень активно развиваем тему телемедицины — устраиваем трансляции хирургических мастер-классов, и организовываем почти что полноценные телемосты между операционными и конференц-залами: из оперблока транслируется картинка с внешних камер и медицинских аппаратов (эндоскопов, лапароскопов, роботов-хирургов), зрители сидят в комфортных креслах в другом конце города, смотрят на здоровом экране FullHD-картинку, и по мере необходимости задают вопросы врачам. При таком сценарии заказчикам оказался очень важен комфорт в общении — все привыкли к телефону и скайпу, и даже 3-4-ёх секундная задержка существенно усложняет взаимодействие зала и операционной, и очень отвлекает хирургов, которые делают самые настоящие операции.
Вот типовые условия, в которых нам приходится работать:
— сигнал 720p или 1080i, чаще всего в формате SDI, получаемый или напрямую с камеры или медицинской стойки, или с программного выхода видеомикшера;
— чаще всего достаточно медленный интернет, или полное его отсутствие — немалую часть проектов мы делаем через сети 4G;
— отсутствие внешних IP;
— высокодинамичная и крайне детализированная картинка, необходимость сохранить адекватную цветопередачу;
Скажу сразу: варианты Skype и систем ВКС (видеоконференцсвязи) мы изучали, тестировали, и благополучно похоронили.
Главные проблемы Скайпа — невозможность ручной настройки параметров качества видео, и свой «слишком умный» алгоритм кодирования, который может самостоятельно начать ухудшать качество картинки, если вдруг решит что ему не хватает ширины интернет-канала. Ну и завести в Скайп картинку с SDI-выхода видеомикшера это отдельное колдунство, не всякому маглу подвластное…
С ВКС тоже оказалось не всё гладко — существенные требования к пропускной способности канала, наличие внешних IP, отсутствие профессиональных видео и аудиовходов, совершенно конский ценник как на покупку, так и на аренду, и при этом «никакое» качество. Да, возможно, ВКС позволяют красиво показать дядь и тёть в костюмах, сидящих в модно отделанном митинг-руме, но когда на одном статусном медмероприятии наши конкуренты запустили трансляцию с лапароскопической стойки через ВКС, картинка пришла ужасающая — система просто не могла быстро кодировать весьма динамичный видеосигнал с высокой детализацией, и вместо FullHD на экранах был совершенно инфернальный калейдоскоп, больше всего напоминающий трейлер к фильму «Пиксели».
Качество картинки на наших массовых трансляциях, проводимых через собственные сервера на базе Wowza, было намного лучше чем и на Скайпе и на ВКС, плюс у нас накопился приличный парк кодировщиков — мощных компактных компьютеров с SDI-платами видеозахвата, что позволяло без нервов делать несколько проектов одновременно.
Я поставил перед своими инженерами задачу «выжать» из Wowza максимум возможной скорости, и сразу же встал вопрос — как и чем измерять задержку? Скажу честно — думали долго, и потому еще более забавным выглядит результат, в очередной раз подтверждая что всё гениальное — просто.
Мы взяли за основу классический «обратный отсчёт», используемый (вернее, давно уже не используемый) в кино- телепроизводстве, сделав его чуть более информативным и детализированным.
Процедура измерения до смешного проста: включаем в плеере ролик, прогоняем через весь видеотракт, ставим рядом экраны передающего и принимающего компьютера, банально фотографируем на телефон оба экрана, вычитаем из большей цифры меньшую, и получаем длительность задержки с точностью до кадра. Соответственно, если точки передачи и приёма удалены, то можно отправить сигнал с площадки А, принять его на площадке Б, сразу отправить его обратно на площадку А, аналогично сфотографировать, и полученный результат поделить на два. Крутящийся таймкод и кандыбающийся туда-сюда красный квадрат позволяют наглядно мониторить возможные косячки передачи видеопотока типа «залипов» и «подрывов» картинки.
Используя этот нехитрый инструмент мы провели тотальную ревизию своего видеотракта, поколдовали с настройками сервера, и буквально по миллисекундам выжали все задержки, получив весьма недурственный результат — при трансляции через «выделенку» мы получали скорость пролёта FullHD видео с битрейтом 4-5 Мбит/сек в 11-16 кадров (примерно полсекунды). При трансляции через сети 4G и при передаче на большие расстояния (например, тестили Санкт-Петербург — Астана) задержка возрастала ещё примерно на полсекунды. Здесь, конечно, уже начинает сказываться сложная маршрутизация между точками передачи и приёма.
Нюансы «тюнинга» вещательного сервера я по понятным причинам раскрывать не буду, но хочу обратить внимание на немаловажный нюанс — зачастую ощутимые задержки дают «железные» элементы видеотракта, о которых при подготовке проекта мало кто думает. Например, делаем телемост с конференц-залом в отеле, где вся коммутация по проекторам сделана на VGA, а у вас весь приёмный тракт на SDI или HDMI — можете быть уверены, что микшер и конвертация в VGA вам еще минимум полсекунды добавят. Допотопный проектор подключеный по «композиту»? Секунда. В точке передачи поставили дешевенькую камеру с HDMI выходом, и скотчем прикрутили к ней конвертер SDI-HDMI? Потеряли три кадра. Посчитайте сколько у вас в тракте таких конвертеров, сплиттеров и прочих железяк, и получите очень внушительные цифры, нередко сводящие на нет все усилия инженеров трансляции. Вывод простой — оптимизируйте тракт, убирая все лишние преобразования сигнала.
А для тестирования можете смело использовать наш ролик, его можно свободно скачать по этой ссылке.
P.S. Для любителей простеньких лабиринтов — блок-схема коммутации с одного из наших медицинских проектов.
Зачем вообще нужна минимальная задержка?
Как можно просто и наглядно замерять задержку при трансляции видеосигнала?
Какие элементы видеотракта влияют на увеличение задержки?
Наш топовый результат — FullHD сигнал пролетел до сервера и обратно менее чем за полсекунды.
Интересно? Тогда читайте дальше.
Итак, зачем вообще нужна минимальная задержка?
Моя компания занимается организацией онлайн-видеотрансляций, и в последнее время мы очень активно развиваем тему телемедицины — устраиваем трансляции хирургических мастер-классов, и организовываем почти что полноценные телемосты между операционными и конференц-залами: из оперблока транслируется картинка с внешних камер и медицинских аппаратов (эндоскопов, лапароскопов, роботов-хирургов), зрители сидят в комфортных креслах в другом конце города, смотрят на здоровом экране FullHD-картинку, и по мере необходимости задают вопросы врачам. При таком сценарии заказчикам оказался очень важен комфорт в общении — все привыкли к телефону и скайпу, и даже 3-4-ёх секундная задержка существенно усложняет взаимодействие зала и операционной, и очень отвлекает хирургов, которые делают самые настоящие операции.
Вот типовые условия, в которых нам приходится работать:
— сигнал 720p или 1080i, чаще всего в формате SDI, получаемый или напрямую с камеры или медицинской стойки, или с программного выхода видеомикшера;
— чаще всего достаточно медленный интернет, или полное его отсутствие — немалую часть проектов мы делаем через сети 4G;
— отсутствие внешних IP;
— высокодинамичная и крайне детализированная картинка, необходимость сохранить адекватную цветопередачу;
Скажу сразу: варианты Skype и систем ВКС (видеоконференцсвязи) мы изучали, тестировали, и благополучно похоронили.
Главные проблемы Скайпа — невозможность ручной настройки параметров качества видео, и свой «слишком умный» алгоритм кодирования, который может самостоятельно начать ухудшать качество картинки, если вдруг решит что ему не хватает ширины интернет-канала. Ну и завести в Скайп картинку с SDI-выхода видеомикшера это отдельное колдунство, не всякому маглу подвластное…
С ВКС тоже оказалось не всё гладко — существенные требования к пропускной способности канала, наличие внешних IP, отсутствие профессиональных видео и аудиовходов, совершенно конский ценник как на покупку, так и на аренду, и при этом «никакое» качество. Да, возможно, ВКС позволяют красиво показать дядь и тёть в костюмах, сидящих в модно отделанном митинг-руме, но когда на одном статусном медмероприятии наши конкуренты запустили трансляцию с лапароскопической стойки через ВКС, картинка пришла ужасающая — система просто не могла быстро кодировать весьма динамичный видеосигнал с высокой детализацией, и вместо FullHD на экранах был совершенно инфернальный калейдоскоп, больше всего напоминающий трейлер к фильму «Пиксели».
Качество картинки на наших массовых трансляциях, проводимых через собственные сервера на базе Wowza, было намного лучше чем и на Скайпе и на ВКС, плюс у нас накопился приличный парк кодировщиков — мощных компактных компьютеров с SDI-платами видеозахвата, что позволяло без нервов делать несколько проектов одновременно.
Я поставил перед своими инженерами задачу «выжать» из Wowza максимум возможной скорости, и сразу же встал вопрос — как и чем измерять задержку? Скажу честно — думали долго, и потому еще более забавным выглядит результат, в очередной раз подтверждая что всё гениальное — просто.
Мы взяли за основу классический «обратный отсчёт», используемый (вернее, давно уже не используемый) в кино- телепроизводстве, сделав его чуть более информативным и детализированным.
Процедура измерения до смешного проста: включаем в плеере ролик, прогоняем через весь видеотракт, ставим рядом экраны передающего и принимающего компьютера, банально фотографируем на телефон оба экрана, вычитаем из большей цифры меньшую, и получаем длительность задержки с точностью до кадра. Соответственно, если точки передачи и приёма удалены, то можно отправить сигнал с площадки А, принять его на площадке Б, сразу отправить его обратно на площадку А, аналогично сфотографировать, и полученный результат поделить на два. Крутящийся таймкод и кандыбающийся туда-сюда красный квадрат позволяют наглядно мониторить возможные косячки передачи видеопотока типа «залипов» и «подрывов» картинки.
Используя этот нехитрый инструмент мы провели тотальную ревизию своего видеотракта, поколдовали с настройками сервера, и буквально по миллисекундам выжали все задержки, получив весьма недурственный результат — при трансляции через «выделенку» мы получали скорость пролёта FullHD видео с битрейтом 4-5 Мбит/сек в 11-16 кадров (примерно полсекунды). При трансляции через сети 4G и при передаче на большие расстояния (например, тестили Санкт-Петербург — Астана) задержка возрастала ещё примерно на полсекунды. Здесь, конечно, уже начинает сказываться сложная маршрутизация между точками передачи и приёма.
Нюансы «тюнинга» вещательного сервера я по понятным причинам раскрывать не буду, но хочу обратить внимание на немаловажный нюанс — зачастую ощутимые задержки дают «железные» элементы видеотракта, о которых при подготовке проекта мало кто думает. Например, делаем телемост с конференц-залом в отеле, где вся коммутация по проекторам сделана на VGA, а у вас весь приёмный тракт на SDI или HDMI — можете быть уверены, что микшер и конвертация в VGA вам еще минимум полсекунды добавят. Допотопный проектор подключеный по «композиту»? Секунда. В точке передачи поставили дешевенькую камеру с HDMI выходом, и скотчем прикрутили к ней конвертер SDI-HDMI? Потеряли три кадра. Посчитайте сколько у вас в тракте таких конвертеров, сплиттеров и прочих железяк, и получите очень внушительные цифры, нередко сводящие на нет все усилия инженеров трансляции. Вывод простой — оптимизируйте тракт, убирая все лишние преобразования сигнала.
А для тестирования можете смело использовать наш ролик, его можно свободно скачать по этой ссылке.
P.S. Для любителей простеньких лабиринтов — блок-схема коммутации с одного из наших медицинских проектов.
