Потоковое видео что это: Потоковое мультимедиа — Википедия – Технология потокового видео и сферы ее применения — Эксперт — интернет-магазин электроники и бытовой техники

Содержание

Потоковое мультимедиа — Википедия

Потоковое мультимедиа (англ. streaming media) — мультимедиа, которое непрерывно получает пользователь от провайдера потокового вещания. Это понятие применимо как к информации, распространяемой через телекоммуникации, так и к информации, которая изначально распространялась посредством потокового вещания (например, радио, телевидение) или не потоковой (например, книги, видеокассеты, аудио CD).

Первые попытки отображения мультимедийной информации на компьютерах начались в середине XX века. Однако, прогресс в этой сфере был очень малым, вследствие высокой стоимости и ограниченных возможностей компьютеров тех времён.

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

Тем не менее, компьютерные сети оставались ограниченными, а потоковое мультимедиа уступало традиционному (CD-ROM).

В период с 1990 до 2000 пользователи интернета получили:

высокую пропускную способность сетей, в частности, на последней миле
возросло количество абонентов сетей, особенно Интернета
стали использоваться стандартизованные протоколы и форматы, такие как TCP/IP, HTTP и HTML
появилась коммерция в Интернете

Эти достижения в области сетей в совокупности с высокопроизводительными домашними компьютерами и современными операционными системами сделали потоковую мультимедийную информацию доступной широкому кругу простых пользователей. Автономные приёмники интернет-радио предлагали пользователям возможность прослушивания потокового звука без наличия компьютера.

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

Мультимедиа потоки бывают двух видов: по запросу или живыми. Потоки информации, вызываемой по запросу пользователя, хранятся на серверах продолжительный период времени. Живые потоки доступны короткий период времени, например, при передаче видео со спортивных соревнований.

Примерно в 2002 году интерес к единому унифицированному потоковому формату и широкое распространение Adobe Flash поспособствовало разработке формата потокового видео через Flash, который использовался в Flash-проигрывателях, которые размещались на многих популярных видеохостингах, таких как YouTube, сегодня потоковые мультимедиа по умолчанию проигрываются в формате HTML5 видео, которые заменили Flash-проигрыватели.^[1] Растущий интерес пользователей к потоковому видео побудил команду разработчиков YouTube внедрить новый сервис потокового вещания для пользователей.

Американская ассоциация звукозаписывающих компаний (RIAA) в своем отчете о доходах за 2015 год сообщила, что на услуги потокового мультимедиа пришлось 34,3 % от общего дохода музыкальной индустрии за год, увеличившись на 29 процентов по сравнению с предыдущим годом и став крупнейшим источником дохода, получив около 2,4 доллара млрд.

[2]^[3] Доход от потоковой передачи в США вырос в первом полугодии 2016 г. на 57 % и составил 1,6 млрд долл. США, что составило почти половину отраслевых продаж.^[4]

Термин «потоковое мультимедиа» был впервые использован для ленточных накопителей, изготовленных Data Electronics Inc. и предназначенных для медленного наращивания и запуска всей записанной информации; появление таких дорожек привело к снижению затрат на привод, что сделало продукт более конкурентоспособным. «Потоковое мультимедиа» было применено в начале 1990-х годов как лучший способ передачи видео по запросу. Впервые это было сделано Starlight Networks для потокового видео и Real Networks для потокового аудио.^[5]

Потоковое вещание и хранение информации[править | править код]

Реализация сервера потокового вещания по принципу 1 клиент — 1 соединение

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

размер хранилища (в мегабайтах) = продолжительность (в секундах) * битрейт (в кбит/с) / (8 * 1024)

(если считать, что 1 мегабайт = 8 * 1024 кбитов)

Пример из жизни:

Один час видео, закодированного со скоростью 300 кбит/с (типичное видео по состоянию на 2005 год, имеющее размер 320×240 пикселов), будет занимать:

(3600 с * 300 кбит/с) / (8*1024) = порядка 128 Мб места на диске

Если файл, хранимый на сервере с режимом передачи по запросу, будут просматривать 1000 людей одновременно по протоколу Unicast (1 клиент — 1 соединение), то сервер должен иметь следующую пропускную способность:

300 кбит/с * 1000 = 300.000 кбит/с = 300 Мбит/с сетевого интерфейса

Это эквивалент порядка 135 ГБ информации в час. Разумеется, при использовании протокола Multicast нагрузка на сервер намного ниже, так как для передачи информации всем клиентам используется единственный поток. Следовательно, такой поток будет занимать всего 300 кбит/с сетевого интерфейса сервера. Более подробная информация об этих протоколах даётся ниже.

Если же видео 1080p 60p 3.472222 МБ/с * 8 = 27.777 мбит/сек * 1000 = 27.777 гбит/сек

2160p 120p 27.777 МБ/сек * 8 =222.222 мбит/сек * 1000 = 222.222 гбит/сек

Разработка сетевых протоколов потокового вещания вызывает следующие проблемы:

Датаграмные протоколы, такие как User Datagram Protocol (UDP), отправляют поток медиаинформации как поток отдельных маленьких пакетов. Он прост и эффективен; в то же время, в спецификации протокола нет гарантии доставки данных получателю. Это очень сильно затрудняет поиск и исправление получаемых данных принимающим информацию приложением. При потере данных поток может быть отключен.

Протоколы RTSP, RTP и RTCP специально разрабатывались для передачи мультимедийной информации по сети. Последние два построены на основе UDP.
Надежные протоколы, такие как TCP, гарантируют корректность получаемых данных клиентов потокового вещания. Однако при большом количестве ошибок при соединении/подтверждении получаемой информации передаваемая информация может стать неактуальной. Это также может вызвать значительные задержки при передаче информации на время, затраченное на пересылку поврежденной информации. Одним из решений данной проблемы является буферизация информации на стороне клиента.
Протоколы Unicast отправляют отдельную копию данных каждому клиенту. Unicast подходит для большинства пользователей сети Интернет, но сильно затрудняет масштабирование сервера для бо́льшего количества клиентов.

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

Multicast позволяет передавать один поток информации группе клиентов по сети. Одной из проблем при реализации подобной схемы потокового вещания является корректная настройка маршрутизаторов для передачи широковещательных пакетов из одного сегмента сети в другой. Если организация, предоставляющая потоковое вещание, имеет контроль над сетью между сервером и клиентами (например, в образовательной, правительственной или корпоративной сети), то протоколы маршрутизации, такие как IGMP и PIM, могут быть использованы для доставки мультимедиа нескольким клиентам из различных сегментов LAN.
Протоколы P2P могут использоваться при распространении предварительно записанной мультимедиа между компьютерами. Это снимает нагрузку с сервера, однако сеть передачи данных между сервером и одним из клиентов становится узким местом данного варианта реализации потокового вещания информации.

Типичными примерами потоковой передачи мультимедиа являются видео-записи, онлайн-трансляции и вебинары в интернете.

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

Есть также новые маркетинговые концепции. Например, Берлинский филармонический оркестр продает билеты на прямую трансляцию концерта через так называемый «Цифровой концертный зал».^[7] Подобные «онлайн-концерты» также распространяются во многих разных местах — кинотеатрах — в разных местах земного шара. Аналогичная концепция используется Метрополитен-опера в Нью-Йорке. Многие успешные стартап-компании основывают свой бизнес на потоковом медиа.^[8]

Потоковое медиа, защищенное авторским правом, не может быть^{[уточнить]} скопировано с целью распространения. При этом потоковая передача или просмотр контента в Интернете является законным в Европе, даже если этот материал защищен авторским правом.

[9]

Технология потокового видео и сферы ее применения

Загрузка…

Потоковое вещание — это мультимедийный контент, который пользователи непрерывно получают от провайдера услуг. Термин в том числе применим как к таким источникам передачи информации, как радио и телевидение.

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

Способы передачи потокового видео

Для просмотра потокового видео на устройстве пользователя должен быть установлен специальный видеоплеер, поддерживающий эту функцию. Кстати, поставляемый в комплекте стандартного набора ПО Windows Media Player относится к таковым. Среди прочих популярных программ стоит отметить Quicktime Player и RealOne Player.

Однако отсутствие программы на ПК не ограничивает пользователя: в интернете есть множество ресурсов, поддерживающих потоковое онлайн вещание. Самыми известными из них являются Twitch и Youtube. В последнее время технологию подхватили популярные социальные сети – например, Facebook и Вконтакте.

Для трансляции потокового мультимедиа обычно используется один из двух способов:

Последовательный – видеофайл воспроизводится с жесткого диска компьютера пользователя или сервера провайдера услуг. Как правило, при передаче таким способом качество изображения и звука выше. К недостаткам стоит отнести то, что невозможно переключить ролик с одного момента на другой, не дождавшись его буферизации. То есть, интересующий фрагмент должен быть загружен, чтобы пользователь смог его просмотреть. Для трансляции подходит обычный веб-сервер.
В реальном времени – требует наличия потокового сервера. Этот метод больше подходит для передачи видеофайлов большой длительности. Пользователь может выбрать место, с которого он хочет начать просмотр. Также этот вид потокового мультимедиа вещания используется для трансляции с веб-камеры или захвата экрана.

Используемые форматы и протоколы

Согласно общепринятым нормам, для трансляции видео сегодня используется несколько стандартов сжатия мультимедиа.
К ним относятся:

MPEG. Первая версия разработана группой специалистов Moving Picture Experts Group в 1988 году. Сегодня актуальны стандарт MPEG-2, используемый для кодирования видео и аудио на DVD, передачи спутникового и кабельного ТВ-сигнала. MPEG-4, кроме вышеперечисленного, регламентирует особенности сжатия 3D-объекктов, видеотелефонии и широкоформатного вещания;
RealVideo. Видеокодек, разработанный компанией RealNetworks в 1997 году. Формат подходит для трансляции сигнала в сетях TCP/IP (Интернет), однако для локальной сети это не лучший вариант;
QuickTime. Технология, созданная компанией Apple в 1991 году. Этот мультимедийный фреймворк задействован во всех устройствах производителя, выполняющих вещание или принимающих потоковое видео.

Передача данных в сфере видеотрансляции регламентируется такими протоколами:

UDP – отправляет поток метаинформации отдельными небольшими пакетами. К недостаткам можно отнести то, что получение пакета пользователем не гарантируется;
RTSP – аналогичный протокол, «заточенный» на передачу аудио и видео;
TCP – гарантирует корректность полученной информации. Требует буферизации данных на стороне клиента;
Unicast – отправка отдельной копии файла каждому пользователю. Неэффективен при большом количестве пользователей, так как требует наличия мощных серверов;
Multicast – передача по сети одной и той же информации группе пользователей. Требует корректной настройки маршрутизации. К недостаткам относится невозможность реализовать функцию «видео оп запросу»;
P2P – используется для передачи между пользователями предварительно записанного мультимедийного файла. Позволяет снизить нагрузку на сервер.

Сферы применения потокового видео

Потоковая передача видео в реальном времени сегодня прочно закрепилась в жизни большинства пользователей интернета.

Технология широко используется для решения многих задач.

Просмотр видео в интернете

Как известно, в Глобальной Паутине найдется все – главное уметь искать. Пользователи могут посмотреть любой фильм, мультфильм или видеоклип в удобное время. Интересный факт: пальму первенства вот уже который год стабильно удерживают фильмы категории «18+»;

Видеосвязь

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

Стоит отметить, что видеосвязь может не только удовлетворить потребность в общении и развлечении (как, например, сервис «Чат Рулетка» со случайным подбором собеседника), но находит и практическое применение во время организации обучающих вебинаров или онлайн-конференций.

Просмотр трансляции с веб-камер

Не покидая собственной квартиры, любой пользователь может посмотреть на известные достопримечательности, прочие интересные места или на нашу планету с борта МКС. Однако развлечением использование веб-камер не ограничивается: в последнее время все большую актуальность обретает наблюдение за избирательными участками во время выборов, что помогает обнаружить нарушения.

Широко применяется видеонаблюдение службами безопасности, однако в этом случае трансляция ведется не через интернет, а по локальной сети.

Стриминг

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

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

Как и любая технология, эта не стоит на месте и стремительно развивается. Возможно, через несколько лет потоковая передача видео откроет перед пользователями возможности, которые казались фантастикой еще вчера.

Что такое потоковая передача мультимедиа?

Автор Исхаков Максим На чтение 5 мин. Просмотров 736 Опубликовано 09.01.2019

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

В чем разница между потоковой передачей и загрузкой?

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

Можно подумать об этом, как о разнице между озером и рекой: оба содержат воду, и река может содержать столько же воды, сколько озеро. Разница в том, что в реке вода не находится в одном и том же месте в одно и то же время. Загруженный видеофайл больше похож на озеро, поскольку он занимает много места на жестком диске (и для перемещения озера требуется много времени). Потоковое видео больше похоже на реку, в том, что данные видео непрерывно, быстро течет в браузер пользователя.

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

Отправка видео через интернет, в отличие от отправки текста и неподвижных изображений, требует более быстрого метода передачи данных, чем TCP/IP, который отдает приоритет надежности над скоростью.

Как протокол UDP улучшает потоковую передачу?

UDP — это транспортный протокол, который используется для перемещения пакетов данных по сетям. UDP используется с интернет-протоколом (IP), и вместе они называются UDP/IP. В отличие от TCP, UDP не отправляет сообщения назад и вперед, чтобы открыть соединение перед передачей данных, и он не гарантирует, что все пакеты данных прибывают и находятся в порядке. В результате передача данных не занимает столько времени, сколько через TCP, и, хотя некоторые пакеты теряются по пути, существует так много пакетов данных, участвующих в поддержании потока, что пользователь не должен замечать потерянные.

Большая часть интернета использует TCP или протокол управления передачей. Этот транспортный протокол предусматривает тщательное взаимное подтверждение для открытия соединения. Как только соединение открыто, и два коммутирующих устройства передают пакеты назад и вперед, TCP гарантирует, что передача надежна, что все пакеты поступают в порядке.

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

Если TCP похож на службу доставки пакетов, которая требует, чтобы получатель подписал его, то UDP похож на службу доставки, которая оставляет пакеты на переднем крыльце, не стуча в дверь, чтобы получить подпись. Служба доставки TCP теряет меньше пакетов, но служба доставки UDP работает быстрее, так как пакеты могут быть выгружены, даже если их никто не подписывает.

Потоковая передача и буферизация

Потоковые медиаплееры загружаются на несколько секунд раньше времени, чтобы видео или аудио могли продолжить воспроизведение, если соединение ненадолго прервано. Это называется буферизацией. Буферизация обеспечивает плавное и непрерывное воспроизведение видео. Однако при медленных соединениях или большой задержке в сети буферизация видео может занять много времени.

Какие факторы замедляют стриминг?

На стороне сети:

Задержки в сети: различные факторы задержки воздействия, в том числе контент, который пользователи пытаются получить.
Перегрузка сети: если через сеть передается слишком много данных, это может снизить производительность потоковой передачи.

На стороне пользователя:

Проблемы wi-fi: перезапуск маршрутизатора LAN или переключение на провод вместо Wi-Fi может помочь улучшить производительность потоковой передачи.
Медленные клиентские устройства: для воспроизведения видео требуется большая вычислительная мощность. Если устройство, на котором просматривается потоковое видео, имеет много других работающих процессов, или просто медленно в целом, потоковое производительность может быть затронута.
Недостаточно пропускной способности: для потокового видео домашним сетям требуется около 4 Мбит/с пропускной способности. Для видео высокой четкости им, вероятно, потребуется больше.

Как сделать потоковую передачу быстрее?

Потоковая передача подвержена тем же задержкам и снижению производительности, что и другие виды веб-контента. Поскольку потоковое содержимое хранится в другом месте, расположение хостинга имеет большое значение, как и в случае с любым типом содержимого, доступного через интернет. Если пользователь в Нью-Йорке пытается выполнить потоковую передачу с сервера Netflix в Лос Гатос, видеоконтент должен будет пересечь 3000 миль, чтобы достичь пользователя, и видео придется потратить много времени на буферизацию или может даже не воспроизводиться вообще. По этой причине Netflix и другие поставщики потоковой передачи широко используют распределенные сети доставки контента (CDN), хранящие контент в местах по всему миру, которые намного ближе к пользователям.

CDN оказывают огромное положительное влияние на производительность потоковой передачи. Cloudflare Stream Delivery использует сеть CDN Cloudflare для хранения видеоконтента во всех точках присутствия Cloudflare по всему миру. В результате сокращается задержка для времени запуска видео и уменьшается буферизация.

Потоковое видео: что это такое?

Содержание

В чем разница между потоковой передачей и загрузкой?

Как работает потоковая передача мультимедиа?

Как протокол UDP улучшает потоковую передачу?

Потоковая передача и буферизация

Какие факторы замедляют стриминг?

На стороне сети:

Задержки в сети: различные факторы задержки воздействия, в том числе контент, который пользователи пытаются получить.
Перегрузка сети: если через сеть передается слишком много данных, это может снизить производительность потоковой передачи.

На стороне пользователя:

Проблемы wi-fi: перезапуск маршрутизатора LAN или переключение на провод вместо Wi-Fi может помочь улучшить производительность потоковой передачи.
Медленные клиентские устройства: для воспроизведения видео требуется большая вычислительная мощность. Если устройство, на котором просматривается потоковое видео, имеет много других работающих процессов, или просто медленно в целом, потоковое производительность может быть затронута.
Недостаточно пропускной способности: для потокового видео домашним сетям требуется около 4 Мбит/с пропускной способности. Для видео высокой четкости им, вероятно, потребуется больше.

Как сделать потоковую передачу быстрее?

Дата публикации: 2018-02-01

От автора: поскольку все больше и больше клиентов используют сети с высокой пропускной способностью, потоковое видео стало нормой в Интернете. Социальные медиа, веб-сайты и потоковые сервисы, такие как YouTube и Netflix, передаются прямо на ваш телефон. Исследование показало, что видео повышает взаимодействие с клиентами, поэтому мы должны ожидать, что количество видео в Интернете и на мобильных устройствах будет продолжать расти быстрыми темпами. Но что нужно для хорошего воспроизведения видео? И (возможно, что более важно), как вы можете реализовать хорошее воспроизведение видео, которое также очень высокоэффективно? В этой статье я сосредоточусь на нескольких способах оптимизации потоковой передачи HTTP Live Streaming (HLS) для улучшения доставки. Эти передовые методы также применяются к форматам MPEG-DASH и другим потоковым форматам и ни в коем случае не являются исчерпывающим списком, а просто представляют собой способы повышения производительности потоковой передачи видео.

Исследование: что делает хороший поток?

Ответ: зависит от разных факторов. Клиенты демонстрируют различное поведение для разных типов потоков. Это интуитивно имеет смысл — если вы сидите и смотрите телешоу или фильм (более 15 минут), вы будете более терпеливыми, чем, если это будет видео с котом, едущем на Roomba.

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

Задержка запуска: время от нажатия воспроизведения до тех пор, как начнётся поток.

Столбцы. В буфере устройства видео не остается, и воспроизведение останавливается.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

Качество видео: сколько пикселей на экране в любой момент времени.

Эти показатели сильно зависят от того, насколько быстро видео можно транспортировать по сети. В исследовательской работе Akamai обнаружено, что после 2 секунд задержки запуска клиенты начинают отказываться со скоростью 5,8% за дополнительную секунду. Они также считают, что более длинные (и более многочисленные) торможения приводят к отказу. Наконец, видео высокого качества более приятно смотреть, поэтому важно избегать пиксельного и низкого качества видео.

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

Скриншоты в этой статье взяты из AT & T Video Optimizer, бесплатного инструмента, который собирает сетевые захваты на вашем мобильном устройстве. Он оценивает сетевой трафик против ~ 40 лучших способов повышения производительности сети вашего приложения. Помимо видео, он также просматривает изображения, текстовые файлы, соединения и другие функции производительности сети.

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

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

Первое, что вы могли заметить, — это столбец идентификатора, который немного не соответствует порядку. Существуют значения 1-7, но список начинается с 3. Каждый идентификатор отображает полосу пропускания, разрешение и аудио и видео кодеки, используемые для создания потока.

Запуск видео

Первым битрейтом, указанным в манифесте, является качество видео, которое первоначально запросит пользователь. Если этот список был последовательным, видеопоток начался бы с очень низкого качества 1 (128 × 320 @ 193 KBPS). С положительной стороны, 193 KBPS будет загружаться очень быстро в большинстве сетей.

Если бы порядок был отменен, начальное качество видео было бы чрезвычайно высоким (676 × 1024 3.6 MBPS). И хотя большое качество видео важно, это может привести к очень большой задержке запуска в сети с пропускной способностью менее 3,6 МБ.

Лучшая практика № 1: Чтобы сбалансировать начальное качество видео и задержку запуска, поместите поток средней полосы пропускания / качества в качестве первого выбора, чтобы сбалансировать быструю загрузку / запуск видео и начальное качество видео.

Проигрывание видео

После того, как плеер начнет загружать видео сегменты (2-8 сек фрагментов видео для воспроизведения), проигрыватель будет измерять скорость загрузки. Если он подсчитает, что сеть может обеспечить видео более высокого качества достаточно быстро, он попытается загрузить более качественную версию видео. И наоборот, если сеть работает медленнее, она снизится до более низкого качества видео, чтобы обеспечить постоянный поток. Каждый раз при изменении качества видео загружается манифест для нового потока, и видео может начать загрузку новой версии.

Video Optimizer может отслеживать количество сегментов в буфере локального устройства и отчитывается количество буферизованного видео в секундах и МБ во время сбора данных:

Если любое из этих чисел достигает 0, на устройстве больше нет видеозаписи, и видео будет остановлено.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

Используя функцию «Затухание сети» в «Оптимизаторе видео», я изменил пропускную способность сети с 5 Мбайт до 1 Мбит / с в среднем потоке, и мы видим, что видеопроигрыватель начинает запрашивать более качественные видео сегменты, снижая с 1,5 МБПС и в конечном итоге устанавливая 500 КБ.

(Кроме того, можно подумать: если пропускная способность сети составляет 1 Мбайт, то почему 800 KBPS-видео плохо транслируется? Оказывается, есть два потока: один для видео и аудио — поток размером 128 Кбайт. Плеер определил, что 928 килобайт (+ накладные, + аналитика) были слишком приближены к 1024 KBPS и понизил видео. В этом случае можно было бы сделать аргумент за то, что более низкое качество звуковой дорожки, чтобы гарантировать, что более высокое разрешение видео воспроизводится. Кроме того, Лучшая практика: Качество звука (отдельный поток или встроенный в видеопоток) влияет на общую скорость передачи видео).

Очевидно, что несколько битрейтов помогут обеспечить хорошее видео. Примеры, показанные выше, имеют кодировки с изменениями битрейта, которые увеличиваются в довольно регулярные интервалы. Это означает, что небольшие изменения пропускной способности сети будут лишь незначительно влиять на качество видео на экране. Сравните это с рекомендуемым списком битрейтов, который я обнаружил в Интернете:

Представьте, что вы просматриваете видео, закодированное на мобильном устройстве с пропускной способностью 1,4 Мбайт. Единственный возможный вариант — ID 1, а это означает, что любой из пользователей 3G будет видеть только видео с самым низким качеством видео. Кроме того, разница в качестве видео между потоками 1 и 2, вероятно, значительна. Если видео перемещается между битрейтами 1 и 2 несколько раз, изменение качества видео, скорее всего, будет очевидным для конечного пользователя. Этот набор кодировок не очень подходит для потоковой передачи данных на мобильных устройствах.

Лучшая практика № 2: Доступны несколько битрейтов с регулярными интервалами между качествами. Это помогает обеспечить плавное прогрессирование качества видео и предотвратить значительные изменения качества видео.

Видеоплееры отличаются своей агрессивностью, чтобы улучшить качество видео. Некоторые видеопроигрыватели, почувствовав более высокую пропускную способность, начнут процесс замены сегмента — где видео сегменты, уже загруженные с более низким качеством, загружаются снова с более высоким качеством. Это приводит к тому, что один и тот же сегмент загружается более одного раза, но поскольку он улучшает отображаемое видео, я считаю его компромиссным, который обычно оценивается. Например, в таблице ниже сегменты 111-112 изначально загружаются с качеством 0. Плеер регистрирует всплеск пропускной способности и оценивает, что эти 2 сегмента можно заменить и повторно загружать по качеству 2. Однако плеер также довольно агрессивный, загружая 112 третий время в качестве 4. В целом для 4-секундного сегмента 112. потребляется ~ 2 МБ данных. Это может считаться слишком агрессивным — поскольку он тратит большой объем данных.

Мы также видели примеры «замены обратного сегмента», когда плеер загружает более качественную версию после того, как уже имеет более качественную версию на устройстве. В этом случае сегменты 134-134 загружаются с качеством 4 (1,6 MBPS), а затем загружаются с качеством 1 (447 KBPS):

По крайней мере, если качество 4 воспроизводится конечному пользователю, ~ 370 КБ будет потрачено впустую (сумма качественных 1 сегментов). Если воспроизводится качество 1, ~ 1,3 МБ данных теряется, и пользователю предоставляется ухудшенное воспроизведение видео.

Лучшая практика № 3: если ваш видеопроигрыватель агрессивно продвигается к высокоскоростному видео, убедитесь, что замена сегмента только улучшает качество видео. Мониторинг использования данных замены сегмента для ваших пользователей (в Video Optimizer это сообщается как избыточность).

Для видео с несколькими высокими потоками битрейта агрессивный алгоритм битрейта может привести к увеличению количества остановок. Если локальный буфер составляет 30 МБ, но поток работает с 8 Мбайт / с, то локальная локация может быть только 2-3 секунды. Внезапное изменение пропускной способности, вероятно, приведет к остановке, прежде чем сеть и сервер смогут отреагировать.

Лучшая практика # 4: при потоковой передаче видео с высоким битрейтом убедитесь, что буфер устройства может поддерживать много секунд видео для учета внезапных изменений пропускной способности. Альтернатива: ограничить максимальные битрейты для устройств с ограниченной памятью.

Вывод:

Потоковое видео становится все более распространенным в Интернете и в мобильных приложениях. Однако потоковая передача видео сложна десятками потенциальных переменных, которые могут повлиять на качество воспроизведения для ваших клиентов. В этом посте мы выделили лишь некоторые из функций потоковой передачи HLS, которые могут повлиять на время запуска видео, предотвратить блокировки и обеспечить передачу потокового видео высочайшего качества заказчику, одновременно сводя к минимуму потраченные впустую данные.

Автор: Doug Sillars

Источник: https://calendar.perfplanet.com/

Редакция: Команда webformyself.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее