Ниже приведены мои ответы на недавнюю панельную дискуссию Streaming Media на тему «Задержка и потоковое вещание в масштабе».

Низкая задержка, сверхнизкая задержка, сверхнизкая задержка, потоковая передача почти в реальном времени — что означают все эти термины и в чем между ними разница?

Низкая задержка означает что-то свое для каждого. Поскольку скорость доставки становится все быстрее и быстрее, определение низкой задержки со временем меняется. Раньше низкая задержка означала менее 30 секунд, затем 10 секунд, а затем 5 секунд. Мы пытаемся использовать термин «реальное время» для вещей, которые составляют доли секунды по сравнению с секундами.

Мы все время сталкиваемся с вопросами об этих терминах в LiveSwitch, потому что наши клиенты всегда требуют, чтобы хотя бы какой-то компонент их приложения работал в режиме реального времени, доставляя видео от ведущего к зрителю в течение 200 миллисекунд или меньше. Когда люди спрашивают: У вас низкая задержка? Я говорю: Ну, что ты имеешь в виду? Вам действительно нужна доля секунды или вы согласны с 30-секундной задержкой подачи?

Всегда ли низкая задержка является главным приоритетом для обеспечения высокого качества работы?

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

Если это действительно односторонний опыт, односторонняя подача, низкая задержка не имеет значения. Но этот односторонний опыт становится менее желанным из-за аппетита к социальным аспектам наряду с прямой трансляцией.

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

Я провожу свою жизнь во втором мире, и в этом мире прямо сейчас WebRTC является королем, предпочтительным протоколом. Благодаря тому, что Google, Mozilla, Apple и Microsoft поддерживают WebRTC, заявляя, что они поддерживают его, и что это готовый стандарт для всех их браузеров, это позволяет WebRTC получить широкое распространение.

Тем не менее, мы предоставляем SDK для AR/VR, и я не думаю, что эта область еще окончательно закрепилась. Может быть какой-то другой протокол, который станет стандартом в этом мире. У нас есть WebRTC, работающий в этой среде, но это не значит, что что-то не появится и не будет лучше или иначе подходить для этого.

Многие другие протоколы больше подходят для односторонней, чем для интерактивной потоковой передачи.

Можем ли мы для прямых трансляций требовать разных клиентов для конечных пользователей для разных вариантов использования?

Это зависит от вашего клиента. У нас было много клиентов в сфере телемедицины, которые выбрали нашу платформу по одной причине — загрузка не требуется. В некоторых случаях у них было приложение, и они пытались предоставить его клиентам для удаленной телемедицины, а потребители не могли получить доступ к приложению, чтобы загрузить его. Демография для этого обычно старше или имеет языковые и / или технические барьеры. Они забыли свой пароль от магазина приложений или не смогли заставить его работать по какой-то другой причине. Возможность просто «щелкнуть мышью» и принять участие в сеансе была крайне важна для всего рабочего процесса. Эти клиенты очень отличаются от геймеров, например, для которых загрузка — это абсолютно то, на что они тратят время. Это просто другое.

Как вы решаете проблему масштабирования потокового вещания с малой задержкой?

Это внутренне решаемая проблема. В LiveSwitch мы очень хорошо справляемся с масштабированием.

Как вы справляетесь с другими проблемами масштабирования, даже с другими протоколами?

Во многих случаях ответом является дополнительная инфраструктура или глобальная инфраструктура, изменение вашего приема и некоторое перераспределение (например, 200 миллисекунд между точками, но мы в порядке с 250 миллисекундами, если мы ретранслируем на каскадные серверы).

Планирование мощностей, безусловно, также имеет значение. В идеале вы хотите иметь немного предиктивных возможностей; вы должны знать, ожидаете ли вы, что на мероприятие придут 10 000 человек или 100 000 человек. Если будет 100 000 человек, возможно, вы захотите иметь немного больше возможностей, чтобы справиться с этим наплывом. Или, если вы видите, что начинается рост, предскажите скорость. Самая большая проблема, как правило, связана именно с этой начальной точкой шока, если у вас тяжелый старт.

К счастью, когда мы начали проводить очень масштабные мероприятия и трансляции, мы обнаружили, что посещаемость обычно не сопровождается огромным всплеском, а имеет тенденцию к увеличению и уменьшению. Редко когда 10 000 человек приходят одновременно. Тем не менее, на уровне программного обеспечения мы должны были выяснить, как предварительно распределить ресурсы, чтобы, если 10 000 действительно появятся, мы могли убедиться, что сигнализация может иметь место для этих людей, и что мы могли сделать ленту доступной для них в этот таймфрейм доли секунды.

По сути, проблемы, связанные с масштабированием, часто необходимо решать путем сочетания разработки программного обеспечения, планирования емкости и масштабирования с прогнозированием.

Как вы планируете различные аппаратные/технические настройки конечных пользователей?

Когда к вам присоединяются люди из публики, вы многое не можете контролировать — вы понятия не имеете, с каких устройств они будут присоединяться. У вас может быть кто-то с гигантским 40-дюймовым экраном Mac и нисходящей связью 10 ГБ, а кто-то еще использует 4G на своем телефоне Android. Можем ли мы предоставить такой же опыт этим людям? Должны ли мы даже пытаться? Как вы справляетесь с одним входным потоком и разделением его на такое количество людей, и все еще пытаетесь сделать это за 200 мс? Там есть много проблем с пользовательским интерфейсом и масштабированием, не только с технологической точки зрения, но и с точки зрения планирования емкости и ресурсов. Лучшее предложение, которое у меня есть, заключается в том, что если вы проводите мероприятие и ожидаете миллион человек, оцените, что вы ожидаете, что X процентов будут конечными пользователями с заданной установкой, Y процентов будут конечными пользователями другого типа и т. д., и исходите из этого.

Что, по вашему мнению, научила индустрия в плане уменьшения задержки при потоковой передаче?

Самое важное, что я бы сказал, произошло за последний год или около того, это то, что многие крупные игроки, такие как Microsoft, Akamai, Adobe и т. д., которые какое-то время занимались потоковой передачей, признали привлекательность сверхнизкой задержки в создании изначально лучшего опыта для конечных пользователей и осознание того, что люди готовы платить за лучший опыт.

Маржа в историческом мире с низкой задержкой была невелика, но при создании интерактивного опыта, добавлении этой двунаправленной части, готовность людей платить внезапно возрастает. Технологические гиганты поняли, что могут заработать намного больше денег, если пойдут по этому пути, и они все равно будут использовать существующую инфраструктуру и существующие глобальные развертывания для чего-то большего. Они видят, что на создании этого интерактивного двустороннего взаимодействия для конечного пользователя можно заработать деньги.

Полную панельную дискуссию о задержке и прямых трансляциях можно посмотреть здесь. Напишите здесь, если у вас есть вопросы по теме.