В этой статье обобщим информацию по такому популярному на сегодняшний день термину, как потоковое вещание. Рассмотрим основные компоненты и технологии, которые используются для создания Live streaming. Познакомится с основными серверами и кодерами.
Итак, начнем с короткого определения
Потоковое вещание – это доставка мультимедийных потоков информации (видео, аудио) удаленным пользователям, в реальном режиме времени.
Также можно встретить следующие обозначения это термина:
- Живая трансляция.
- Потоковое видео.
- Линейное вещание.
- Прямая трансляция в Интернет.
- Трансляция в реальном режиме времени.
- Потоковая передача мультимедийного контента.
- Онлайн трансляция.
Примеры потокового вещания
Потоковое вещание может создаваться как компаниями, так и обычными пользователями. В Интернете можно найти довольно много сервисов, которые позволяют любому пользователю создать свою собственную трансляцию за несколько простых шагов. Ниже несколько примеров Live streaming.
- Прямые видеотрансляции футбольных матчей.
- Трансляции выступлений конференций.
- Трансляция пользователем, в сеть Интернет, своего собственного ТВ-канала, например, изображения клетки, с любимым питомцем — попугаем.
Некоторые характеристики потокового вещания
- Протоколы передачи (MPEG-DASH, HLS, MPEG-TS (UDP), RTMP, RTSP/RTP, HTTP и др.).
- Разрешение видео.
- Кодек.
- Задержка воспроизведения.
- Битрей потока.
Битрей потока может быть один для всех пользователей, например 500Кбит/сек, но лучше использовать технологии мультибитрейтного или адаптативного вещания, когда битрейт будет изменяться в зависимости от различных условий или характеристик сети. На сегодняшний день все новые сервера поддерживают технологии переключения битрейтов.
Конечные пользователи, в зависимости от ситуации, могут получать потоковое видео на разные устройства
- Компьютер.
- Мобильное устройство.
- Телевизор с доступом в Интернет.
Источники потокового видео
Рассмотрим на примере трансляции с камеры. Для того чтобы организовать отправку изображения с камеры, необходимо в первую очередь, захватить и кодировать видео сигнал с камеры кодером. Далее кодер отправляет поток на медиа сервер, к которому уже подключаются удаленные пользователи и запрашивают трансляцию для просмотра.
Примеры кодеров.
- Flash Media Live Encoder.
- Telestream WireCast.
- Haivision KulaByte Encoders.
- Microsoft Expression Encoder Pro.
- Flash web приложение.
Примеры Медиа серверов
- Adobe Flash Media Streaming Server.
- Streaming Server.
- Red5 (бесплатный).
- Erlyvideo (бесплатный).
- Microsoft IIS Media Services.
- RealNetworks Helix Universal Server.
Плееры для просмотра потокового вещания
- Flash медиа плеер.
- HTML5 видео плеер.
- VLC плеер.
Популярные видео кодеки
- H.264, H.263, VP6.
Популярные аудио кодеки
- MP3, AAC.
Рассмотрим отличие мультимедийных потоков Видеочата от Потокового видео
По сути, видеочат — это множество одновременных взаимодействий по средствам передачи потокового видео. Но, как правило, Live streaming не предусматривает обратной связи через передачу видео и аудио с удаленными пользователями. В некоторых случаях пользователи все же могут влиять на сюжет видеотрансляции. Например, если это трансляция конференции, пользователь, как правило, может задавать вопросы в текстовом чате или по электронной почте, которые просматриваются и передаются выступающему человеку модераторами онлайн трансляции.
Streaming Data is data that is generated continuously by thousands of data sources, which typically send in the data records simultaneously, and in small sizes (order of Kilobytes). Streaming data includes a wide variety of data such as log files generated by customers using your mobile or web applications, ecommerce purchases, in-game player activity, information from social networks, financial trading floors, or geospatial services, and telemetry from connected devices or instrumentation in data centers.
This data needs to be processed sequentially and incrementally on a record-by-record basis or over sliding time windows, and used for a wide variety of analytics including correlations, aggregations, filtering, and sampling. Information derived from such analysis gives companies visibility into many aspects of their business and customer activity such as –service usage (for metering/billing), server activity, website clicks, and geo-location of devices, people, and physical goods –and enables them to respond promptly to emerging situations. For example, businesses can track changes in public sentiment on their brands and products by continuously analyzing social media streams, and respond in a timely fashion as the necessity arises.
Streaming data processing is beneficial in most scenarios where new, dynamic data is generated on a continual basis. It applies to most of the industry segments and big data use cases. Companies generally begin with simple applications such as collecting system logs and rudimentary processing like rolling min-max computations. Then, these applications evolve to more sophisticated near-real-time processing. Initially, applications may process data streams to produce simple reports, and perform simple actions in response, such as emitting alarms when key measures exceed certain thresholds. Eventually, those applications perform more sophisticated forms of data analysis, like applying machine learning algorithms, and extract deeper insights from the data. Over time, complex, stream and event processing algorithms, like decaying time windows to find the most recent popular movies, are applied, further enriching the insights.
- Sensors in transportation vehicles, industrial equipment, and farm machinery send data to a streaming application. The application monitors performance, detects any potential defects in advance, and places a spare part order automatically preventing equipment down time.
- A financial institution tracks changes in the stock market in real time, computes value-at-risk, and automatically rebalances portfolios based on stock price movements.
- A real-estate website tracks a subset of data from consumers’ mobile devices and makes real-time property recommendations of properties to visit based on their geo-location.
- A solar power company has to maintain power throughput for its customers, or pay penalties. It implemented a streaming data application that monitors of all of panels in the field, and schedules service in real time, thereby minimizing the periods of low throughput from each panel and the associated penalty payouts.
- A media publisher streams billions of clickstream records from its online properties, aggregates and enriches the data with demographic information about users, and optimizes content placement on its site, delivering relevancy and better experience to its audience.
- An online gaming company collects streaming data about player-game interactions, and feeds the data into its gaming platform. It then analyzes the data in real-time, offers incentives and dynamic experiences to engage its players.
Before dealing with streaming data, it is worth comparing and contrasting stream processing
and batch processing
. Batch processing
can be used to compute arbitrary queries over different sets of data. It usually computes results that are derived from all the data it encompasses, and enables deep analysis of big data sets. MapReduce-based systems, like Amazon EMR, are examples of platforms that support batch jobs. In contrast, stream processing
requires ingesting a sequence of data, and incrementally updating metrics, reports, and summary statistics in response to each arriving data record. It is better suited for real-time monitoring and response functions.
| Batch processing | Stream processing |
|
| Data scope | Queries or processing over all or most of the data in the dataset. | Queries or processing over data within a rolling time window, or on just the most recent data record. |
| Data size | Large batches of data. |
Individual records or micro batches consisting of a few records. |
| Performance | Latencies in minutes to hours. | Requires latency in the order of seconds or milliseconds. |
| Analyses | Complex analytics. | Simple response functions, aggregates, and rolling metrics. |
Many organizations are building a hybrid model by combining the two approaches, and maintain a real-time layer and a batch layer. Data is first processed by a streaming data platform such as Amazon Kinesis to extract real-time insights, and then persisted into a store like S3, where it can be transformed and loaded for a variety of batch processing use cases.
Streaming data processing requires two layers: a storage layer and a processing layer. The storage layer needs to support record ordering and strong consistency to enable fast, inexpensive, and replayable reads and writes of large streams of data. The processing layer is responsible for consuming data from the storage layer, running computations on that data, and then notifying the storage layer to delete data that is no longer needed. You also have to plan for scalability, data durability, and fault tolerance in both the storage and processing layers. As a result, many platforms have emerged that provide the infrastructure needed to build streaming data applications including Amazon Kinesis Streams , Amazon Kinesis Firehose , Apache Kafka , Apache Flume, Apache Spark Streaming, and Apache Storm.
Amazon Web Services (AWS) provides a number options to work with streaming data. You can take advantage of the managed streaming data services offered by Amazon Kinesis , or deploy and manage your own streaming data solution in the cloud on Amazon EC2.
Amazon Kinesis is a platform for streaming data on AWS, offering powerful services to make it easy to load and analyze streaming data, and also enables you to build custom streaming data applications for specialized needs. It offers two services: Amazon Kinesis Firehose, and Amazon Kinesis Streams.
In addition, you can run other streaming data platforms such as –Apache Kafka, Apache Flume, Apache Spark Streaming, and Apache Storm –on Amazon EC2 and Amazon EMR.
Для транслирования видео, необходимо выбрать команду меню программы Медиа -> Потоковое вещание. Выбираем файлы, которые необходимо вещать. Смотрите рисунок ниже:
Потом нажимаем кнопку "Поток". В появившемся окне открываем закладку "Destinations" и выбираем HTTP. Смотрите картинку ниже:
На закладке HTTP, вводим IP адрес 127.0.0.1 и порт 8080. Настройки перекодирования необходимо оставить по умолчанию. Или вы можете его поменять, это на ваше усмотрение, но возможно, что с другим кодеком видео не будет транслироваться. Также в настройках перекодировки можно накладывать субтитры на видео.
На закладке "Options" можно найти пример командной строки.
После всех настроек нажимаем кнопку "Поток". Теперь вещание должно пойти, чтобы его проверить, можете открыть этот поток другим VLC или любым другим плеером, открыв адрес http://127.0.0.1:8080.
Стоит отметь, если вы хотите, чтобы трансляция видеофайлов шла непрерывно, то вам необходимо установить непрерывное проигрывание в настройках Playlist-а. Это можно сделать, выбрав пункт меню View->Playlist. В появившемся диалоге установить непрерывную версию.
Как просматривать поток вещания VLC?
Для просмотра потока вещания в VLC необходимо выбрать пункт меню Медиа -> Открыть URL. Выбираем нужный протокол, предположим HTTP, и вводим адрес. Адрес вводится, исходя из следующего формата адрес:порт. То есть, для адреса 127.0.0.1 и порта 8080 адрес будет выглядеть как 127.0.0.1:8080. После нажимаем клавишу "Воспроизвести". Теперь, если всё сделано правильно, можете наслаждаться фильмом.
Стоит помянуть, что адрес может быть и другой, например videohost.ru/my.wmv.
Протестировано на версии VLC 1.0.0
Как сохранить поток вещания с помощью VLC?
С помощью VLC можно не только принимать видео, но и сохранять его, если вы захотите его просмотреть позже. Для этого необходимо открыть меню сохранения, выбираем меню VLC плеера Медиа -> Конвертировать/Сохранить:
После откроется меню открытия файла. В этом окне перейдите на вкладку "Сеть", смотрите картинку выше. После нажатия кнопки "Конвертировать/Сохранить" появится окно:
В этом окне выберите имя файла для сохранения. Установив галочку "Отображать Вывод", вы будите видеть то, что сохраняете. После нажимайте кнопку "Начать"
Протестировано на версии VLC 1.0.0
Как вещать один файл, а затем другой с помощью VLC?
После открытия окна плейлиста, вам необходимо будет проделать процедуру создания потока вещания для нескольких файлов. После этого в плейлисте появится несколько потоков передачи.
Протестировано на версии VLC 1.0.3
Видео трансляция постоянно отключается, невозможно записывать и просматривать?
Иногда при просмотре видеопотока или при его записи, соединение постоянно отрубается и поэтому не получается его нормально посмотреть. Для решения этой проблемы необходимо зациклить текущий проигрываемый url. Смотрите изображение ниже.
Потоковая передача данных - технология, называемая также "потоковое мультимедиа" - представляет собой набор средств и методов для обеспечения непрерывного получения пользователем аудиовизуальных данных от провайдера потокового вещания. Технологии потоковой передачи данных становятся все более важными с развитием сети интернет, поскольку большинство пользователей пока не имеет достаточно высокой скорости доступа для быстрой загрузки больших файлов мультимедиа. Используя эту технологию, программа или браузер клиента может начать воспроизведение мультимедиа данных, не дожидаясь загрузки всего мультимедийного материала. Так как звук и изображение отправляются абонентам в виде потока данных, такая передача называется "потоковой".
Для решения проблемы быстрого доступа к медиа-файлам через Интернет используется сочетание агрессивной компрессии с потоковой передачей данных. Сетевые протоколы пересылают файлы "пакетами" - фрагментами данных, непригодными для непрерывного проигрывания. Для обеспечения работоспособности технологии приложения для приёма-передачи данных реализуют по, при которой сервер собирает поток и, при получении запроса от клиента, отправляет этот поток ему. Клиент же получает данные, обрабатывает их и преобразовывает в звук и изображение. Если клиент получает данные недостаточно быстро, их воспроизведение не будет гладким, то есть будет обрываться или замирать. Возможна и обратная ситуация, когда приложение получает данные быстрее, чем воспроизводит. Для преодоления этой проблемы приложения, осуществляющие потоковую передачу медиа-данных, сохраняют полученные пакеты данных в памяти ("буферизируют"), вследствие чего обеспечивается проигрывание файла с постоянной скоростью. Компрессия данных является компромиссом между качеством передаваемых данных и скоростью самого компьютера, а также скоростью доступа в интернет.
Изначально потоковая передача данных применялась для передачи аудио (интернет-радио и т.п.) Первая аудио-трансляция в интернете была произведена в США в августе 1994 г. Пионером в этой области стала компания RealNetworks (носившая тогда название Progressive Networks) основанная в 1995 г., а их формат постепенно завоевал популярность и превратился в общепринятый стандарт, наравне с такими популярными сегодня форматами, как Flash или MP3. В последних версиях RealAudio предусматриваются динамическая компрессия, которая может переключаться в зависимости от качества соединения, а также обработка аудиоданных в реальном времени на стороне клиента (например, очистка и восстановление полученного звука). Компанией RealNetworks был также разработан формат RealVideo (1997 г.), однако в Российском сегменте интернета он не получил сильного распространения.
У аудиоверсий форматов QuickTime (первый релиз 2 декабря 1991 г.) и Windows Media имеются особенности, связанные с потоковой передачей данных. Так, при кодировании файлов в формат Windows Media Audio (WMA) используется непосредственно операционная система, вследствие чего, при желании, файлы можно закодировать так, что открыть их смогут только определенные пользователи. Технология DRM (Digital Rights Management, или система управления правами на цифровые данные) позволяет поставщикам данных различного содержания шифровать файлы таким образом, чтобы открыть их можно было лишь при наличии специального ключа (вполне естественно, что эту технологию особенно пылко приветствуют представители музыкальной индустрии). Помимо Windows Media DRM существует и другая, немного отличная от нее система шифрования и дистрибуции под названием Liquid Audio, которая поддерживается и программой Windows Media Player, и программой RealPlayer.
С увеличением скорости доступа в интернет у пользователей появилась возможность организовать не только аудио, но и видео-трансляции. Однако первая трансляция была произведена американским телеканалом ABC ещё в 1994 г. Для приёма передач использовался клиент CU-SeeMe, разработанный в 1992 г. Однако клиент CU-SeeMe не стал популярным. По способу организации потока различают протоколы "последовательные" (Progressive Streaming) и "в реальном времени" (Real-time Streaming). Передачу последовательным способом организовать проще, поскольку видео загружается на жёсткий диск пользователя и воспроизводится уже с него. Для его передачи достаточно воспользоваться обычным вэб-сервером. При организации передачи данных в реальном времени необходим специальный потоковый сервер (Unreal Media Server, Adobe Flash Media Server и тп.). Для воспроизведения потокового видео сейчас наиболее популярны протоколы RTSP, Multicast, RTMP, а также P2P и ещё несколько менее популярных реализаций:
- Дейтаграммные протоколы, такие как UDP (User Datagram Protocol), отправляют поток медиаинформации как поток отдельных маленьких пакетов. Протокол прост и эффективен, но в спецификации протокола нет гарантии доставки данных получателю. Это сильно затрудняет поиск и исправление получаемых данных принимающим информацию приложением. При потере данных поток может быть отключен.
- Протоколы RTSP (Real-Time Streaming Protocol), RTP (Real-time transport protocol) и RTCP (Real-Time Control Protocol) специально разрабатывались для передачи мультимедийной информации по сети. В протоколах предусмотрена возможность контролируемой передачи видеопотока. Последние два построены на основе UDP.
- Надежные протоколы, такие как TCP, гарантируют корректность получаемых данных клиентами потокового вещания. Однако передаваемая информация может стать неактуальной при большом количестве ошибок в пакете данных, что также может вызвать значительные задержки на время, затраченное на пересылку поврежденной информации.
- Протоколы Unicast отправляют отдельную копию данных каждому клиенту. Unicast подходит для большинства пользователей сети Интернет, но сильно затрудняет масштабирование сервера для бо́льшего количества клиентов. При широковещательной передаче одна копия данных передается всем клиентам сервера.
- Протоколы Multicast разработаны для снижения нагрузки с серверов при получении потокового мультимедиа большим количеством клиентов. Эти протоколы отсылают одну порцию данных целой группе клиентов. Одним из потенциальных недостатков групповой передачи данных является отсутствие возможности реализовать функцию "видео по запросу", а также невозможность управлять воспроизведением со стороны пользователя. Однако эта проблема может быть решена внедрением в сеть передачи данных кэширующих серверов и буферизирующего принимаемый поток программного обеспечения.
- Протокол RTMP (Real Time Messaging Protocol) разработан компанией Adobe и реализован в Adobe Flash Media Server. На данный момент это наиболее распространённый протокол. Он массово используется во встраиваемых в веб-страницы flash-плеерах.
- Протоколы P2P (Peer-to-peer) могут использоваться при распространении предварительно сохраненного мультимедиа контента между компьютерами. Это снимает нагрузку с сервера, однако сеть передачи данных между сервером и одним из клиентов становится узким местом данного варианта реализации потокового вещания информации.
Воспроизводить потоковое вещание могут практически все, однако наиболее часто используются и программа, позволяющая организовать передачу данных по протоколу P2P. Популярные программы QuickTime и Windows Media также имеют возможность воспроизведения потокового видео, но редко используются для этого. Также распространена универсальная программа с открытым исходным кодом VideoLAN, которая позволяет не только получать, но и создавать свои потоки данных.
Используемые источники:
Введение
Кажется, компании-производители потребительского сетевого оборудования решительно нацелены на продвижение своих 2,4-ГГц продуктов в качестве решений для трансляции потокового видео по домашней сети. А Голливуд сегодня всеми силами пытается не допустить утечку драгоценных бит куда бы то ни было. Впрочем, DRM-защита ещё не добралась до видеофайлов пользователей, поэтому как насчёт того, чтобы закупиться оборудованием и смотреть по сети потоковое видео?
Ранее мы уже обращались к производителям сетевого "железа" с тем, чтобы они перестали рекламировать WLAN-оборудование для диапазона 2,4 ГГц для трансляции потокового видео. Так как диапазон 2,4 ГГц используется также микроволновыми печами, беспроводными телефонами и другим оборудованием, не говоря о Wi-Fi, то существует огромное количество потенциальных источников помех. Если вам мало проблем от бытового оборудования, то несколько соседних беспроводных сетей смогут причинить настоящую головную боль, заняв весь доступный диапазон частот. В результате многие из тех, кто решается на использование беспроводной сети, вряд ли смогут пользоваться её ресурсами даже для web-серфинга, чтения электронной почты, чатов и игр, не говоря уже о таких требовательных к полосе пропускания приложениях, как потоковое видео.
Мы решили настроить передачу данных по беспроводной сети диапазона 2,4 ГГц для потокового видео, то есть как раз так, как любят вбивать в головы потребителей производители оборудования. Наверное, производителям не стоит быть настолько самоуверенными. Но на этом мы не остановились. Давайте посмотрим, почему же перегруженный диапазон так плох для нашего сценария.
Эффекты перегруженного спектра
Если вы являетесь одним из тех счастливчиков, кто живёт в условиях свободного диапазона 2,4 ГГц, то всё, о чём нужно беспокоиться, - это полоса пропускания оборудования в тех местоположениях, где вы собираетесь смотреть видео. К счастью, над решением этой задачи, то есть над увеличением скорости и расстояния, работает большая часть всей индустрии. Последним шагом увеличения скорости и расстояния является разработка стандарта 802.11n, который в очередной раз повышает теоретическую пиковую скорость работы сети 802.11 до 200 Мбит/с для физического уровня (иногда даже ближе к 300 Мбит/с). Такое увеличение скорости предоставит пользователю полосу порядка 100 Мбит/с, чего вполне достаточно для трансляции любого потокового видео.
Однако большинство пользователей всё же сталкиваются с загруженностью диапазона. Очевидно, что многоквартирные дома имеют наибольший потенциал для проявления этой проблемы, и, соответственно, для разочарования пользователя. Но даже в пригородах, где плотность жителей не так высока, риск перекрытия нескольких соседних сетей всё же есть. Даже если сетей нет, то всегда остаётся риск, что диапазон будет периодически перегружаться различным бытовым оборудованием, отчего вам, как пользователю сети, вряд ли будет легче.
Мы пришли к выводу, что в большинстве случаев диапазон 2,4 ГГц, используемый оборудованием 802.11b/g, окажется слишком переполненным, чтобы использовать его для приложений потокового видео. Что же такое перегруженность диапазона и чем она отличается от простой нехватки скорости на желаемом расстоянии?
Вот три основных эффекта перегруженности спектра.
- Уменьшение полосы пропускания
- проще говоря, множество соседних сетей пытаются использовать одни и те же частоты. Это чревато не только снижением скорости работы, но и существенными её колебаниями, поскольку все соседние сети пытаются получить кусок общего канала. - Большие потери пакетов
- высокий уровень "шума", создаваемый соседним каналом и источниками, отличными от Wi-Fi (микроволновые печи, телефоны и другое), может стать причиной снижения скорости, поскольку при потере или повреждении пакета происходит его повторная пересылка. В худшем случае, появляются неисправимые ошибки. - Нестабильное подключение
- пользователи сетей Wi-Fi в местах их большого количества знакомы с проблемой подключения к чужой сети. Это связано с тем, что сигнал соседней точки доступа или маршрутизатора оказывается сильнее сигнала собственной. Это дополняется оставленными по умолчанию настройками встроенной утилиты конфигурирования беспроводной сети в Windows.
Очевидно, что при выходе за минимальную полосу пропускания, или если соединение будет постоянно пропадать, то приложение не будет работать. Но какие потери пакетов допустимы при трансляции видео-потока без ущерба для просмотра?
Эмуляция ошибок
Компания Apposite Technologies позволила нам воспользоваться её решением Linktropy 4500 WAN Emulator (рис. 1 ), чтобы ответить на возникшие вопросы. Устройство является аппаратным эмулятором, который позволяет выполнять настройки скорости входящего и исходящего потока, задержки и потери. Для настройки используется web-интерфейс, для доступа к которому необходимо подключиться к специальному порту Ethernet (или через клиентский компьютер после задания соответствующей опции в настройке). Если вам более по душе интерфейс командной строки, то можно подключиться через последовательный порт и получить консольный доступ.
Рис. 1. Apposite Technologies Linktropy 4500 WAN Emulator.
Для работы 4500 нужно подключить его между любыми двумя сегментами Ethernet LAN. Для подключения на эмуляторе имеются два порта 10/100/1000: LAN A и B. По умолчанию устройство работает как прозрачный интеллектуальный мост с любым протоколом. Однако, при желании, его можно переключить в режим маршрутизатора для работы с IP, но в этом режиме не поддерживается работа с трафиком multicast-приложений.
При подключении на интерфейсе управления задаются желаемые параметры сети (рис. 2 ). Эмуляцию можно включить или отключить при помощи специальной кнопки на интерфейсе (Emulation On/Off ) без изменения других настроек.
Как уже упоминалось ранее, можно настраивать пропускную способность, задержки и потери для всего трафика, проходящего через 4500 в обоих направлениях. Задержка (delay) - единственный параметр, который может не только быть фиксировано заданным (Constant), но и может динамически меняться с равномерным (Uniform) или нормальным (Normal) статистическим распределением. Вообще, неплохо было бы получить подобное динамическое изменение параметров потерь и, возможно, пропускной способности. Тогда мы смогли бы лучше эмулировать беспроводное соединение. Впрочем, посмотреть на эффект от потери кадров можно и в статическом режиме.
Рис. 3. Экран статистики соединения Link Statistics. Нажмите на картинку для увеличения.
Теперь можно подключать 4500 к сети. В нашем случае мы подключили порт LAN A к порту коммутатора LAN, а порт LAN B - к одному из компьютеров. Мы без проблем разобрались с работой 4500. Хотя, надо сказать, весьма долго искали опцию, которая включает доступ к web-интерфейсу администрирования из локальной сети, а не только через выделенный порт.
Размер потока и кодирование
На самом деле, есть два способа воспроизведения удалённых медиа-файлов. Можно просто взять ПК или другое устройство, способное работать с локальными и сетевыми файлами. Тогда достаточно будет найти в сети и запустить на воспроизведение нужный файл. Он будет воспроизводиться через ту сетевую файловую систему, которую использует ваша ОС. В большинстве случаев это будет SMB (Server Message Block) , работающая на верхних уровнях стека TCP/IP.
Другой способ - использовать для воспроизведения медиа-сервер и протокол потокового вещания , который будет доставлять медиа-поток от сервера к плееру. Для передачи потока используются такие протоколы, как RTP и RTCP, работающие поверх UDP.
Отличие в том, что TCP/IP обеспечивает надёжную доставку, а UDP - нет, поскольку TCP имеет встроенные механизмы контроля доставки и целостности данных. Однако TCP нельзя назвать лучшим решением для передачи мультимедиа, поскольку этот протокол добавляет в пакеты данных большое количество служебной информации. Для TCP главное - безошибочно передать данные, а время доставки вторично.
С другой стороны, UDP использует гораздо меньше служебных данных, чем TCP, поэтому он лучше подходит для приложений, работающих с потоковыми данными, где на первый план выходит время доставки информации. Что касается пропусков и искажений пакетов, то решение этой проблемы возлагается на принимающую сторону.
Мы протестировали оба описанных выше способа, используя для этого три тестовых файла:
- DVD VOB, кодек MPEG 2;
- файл DivX с кодеком DX50 в разрешении 640x300 при 24 кадрах в секунду;
- PSP avc1 (MPEG 4), разрешение 368x208 при 30 кадрах в секунду.
Для вещания и воспроизведения потока мы использовали VideoLAN VLC Media player 0.8.5. Выбор пал на плеер VLC, потому что он позволяет работать со всеми перечисленными типами файлов и может как просто открывать медиа-файл, так и воспроизводить поток с другого VLC-плеера, работающего в серверном режиме. Вещание выполнялось в режиме VLC UDP при настройках по умолчанию без перекодировки.
Те, кто экспериментировал с кодеками, знают, что размер потока (битрейт) напрямую влияет на качество воспроизведения, от него также во многом зависит и то, можно ли будет смотреть видео по сети. Размер потока можно узнать в свойствах файла, однако многие кодеки используют динамически меняющийся битрейт, поэтому даже указанному значению иногда не следует верить.
Чтобы узнать реальный битрейт воспроизводимого файла, нужно взять утилиту, показывающую поток данных, проходящий через сетевой адаптер. Мы испробовали несколько решений, после чего остановились на Hoo Technologies Net Meter . Утилита позволяет практически всё, что можно ожидать от измерителя скорости (кроме кнопки очистки графика; для этого приходилось перезапускать утилиту). Hoo Technologies Net Meter совместима с Win 98, ME, NT, 2000 и XP, имеет бесплатный тестовый период 30 дней, цена составляет $20.
На рис. 4 и 5 показаны графики, полученные при воспроизведении первых четырёх минут тестового VOB-файла в обоих режимах.
Рис. 4. График для воспроизведения файла VOB (MPEG 2).
Для VOB значение максимальной и средней скорости при воспроизведении потока оказались примерно на 20% ниже, чем при воспроизведении файла. При этом отношение максимальной скорости потока к средней в обоих случаях составило около 1,6.
Рис. 5. График для воспроизведения VOB (MPEG 2) в потоковом режиме.
На рис. 6 и 7 показаны графики, полученные при воспроизведении тестового DivX файла в обоих режимах.
Рис. 6. График для воспроизведения файла DivX.
В этот раз максимальный битрейт при воспроизведении файла DivX оказался примерно на 20% ниже, чем при воспроизведении потока, при этом средние значения практически не отличались. Отношение максимальной скорости к средней при файловом режиме составило 4,3, в потоковом - 4,8, максимум из всех тестов.
Рис. 7. График для воспроизведения DivX в потоковом режиме.
И, наконец, на рис. 8 и 9 показаны графики для PSP/MPEG4.
Рис. 8. График для воспроизведения файла PSP.
И снова средняя скорость для потока и для файла оказалась практически одинаковой, а максимальная для потока оказалась ниже, чем для файла, примерно на 10%. Отношение максимальной скорости к средней составило 2,8 для файла и 2,2 для потока.
Рис. 9. График для воспроизведения потока PSP.
Поскольку в тестах использовались разные фильмы, результаты нельзя использовать для сравнения кодеков. Зато по графикам наглядно видно, что процесс передачи мультимедиа-файла и потока нельзя описывать одним значением битрейта.
Изначально мы также включили в тестирование файлы Quicktime 7 HD, сжатые при помощи H.264, но были вынуждены отказаться от этой затеи. VLC поддерживает H.264 лишь в экспериментальном режиме (), и у нас возникли проблемы при воспроизведении различных файлов с сайта Apple. А от плеера Quicktime нам пришлось отказаться, поскольку он не смог открыть поток с сервера VLC.
Чувствительность к потерям пакетов при потоковой передачи
Мы продолжили наше тестирование, задавая различные значения потерь пакетов при помощи Linktropy 4500. Для начала мы установили потери в 1% для потокового режима, в результате увидели искажения (квадраты). Затем мы запустили серию тестов, результаты которых показаны в таблицах ниже. Просим прощения за субъективность в описании результатов, однако, лучшего способа охарактеризовать их мы не нашли.
Мы также приводим скриншоты артефактов, полученных при воспроизведении, чтобы вы могли судить об увиденном.
| Таблица 1. Результаты для потока VOB | |
| Потери пакетов | Результат |
| 5% | Невозможно смотреть |
| 1% | Невозможно смотреть |
| 0,5% | Смотреть можно, заметны квадраты |
| 0,25% | |
| 0,1% | |
| 0,05% | |
Рис. 10. Поток VOB при потерях 5%. Нажмите на картинку для увеличения.
| Таблица 2. Результаты для потока DivX | |
| Потери пакетов | Результат |
| 5% | Невозможно смотреть, видео и звук прерываются |
| 1% | Невозможно смотреть, постоянно проскакивают квадраты |
| 0,5% | Смотреть можно, но сложно, квадраты |
| 0,25% | Смотреть можно, часто проскакивают небольшие квадраты |
| 0,1% | Смотреть можно, квадраты проскакивают реже |
| 0,05% | Смотреть можно, квадраты проскакивают очень редко |
Рис. 11. Поток DivX с 1% потерь. Нажмите на картинку для увеличения.
| Таблица 3. Результаты для потока PSP / MPEG4 | |
| Потери пакетов | Результат |
| 5% | Невозможно смотреть, плеер не работает |
| 1% | Невозможно смотреть, но плеер работает |
| 0,5% | Смотреть можно, но сложно |
| 0,25% | Смотреть можно, периодически проскакивают квадраты |
| 0,1% | Смотреть можно, иногда проскакивают квадраты |
| 0,05% | Смотреть можно, искажения появляются редко |
На Рис. 12 показан скриншот при потерях 0,05%. То есть даже при незначительных потерях искажения могут быть весьма существенными!
Рис. 12. Поток PSP/MPEG4 с потерями 0,05%.
Тестирование привело нас к следующим заключениям:
- для появления проблем с потоковым видео достаточно очень малых потерь пакетов;
- при потерях пакетов битрейт и способ кодирования практически не влияют на качество воспроизведения.
Чувствительность к потерям пакетов при воспроизведении файлов
После тестирования потокового режима мы решили повторить тесты при файловом воспроизведении и получили совсем другие результаты. Как и следовало ожидать, из-за способности TCP/IP корректировать ошибки передачи, здесь гораздо сложнее добиться проблем с воспроизведением видео. А если проблемы и возникнут, то в виде пауз или пропусков, но не как искажения картинки.
Чтобы видео отказалось воспроизводиться, нам пришлось прибегнуть к задержкам c равномерным распределением и потерям пакетов. При потерях 1% пакетов и задержках между 10 и 500 мс воспроизведение VOB-файла периодически замирало и, в конце концов, через несколько минут остановилось полностью. При тех же настройках и том же ролике, но уже сжатом в формат DivX (качество Home Theater Quality), паузы стали реже, и мы смогли досмотреть ролик до конца.
Здесь мы пришли к следующим выводам:
- если воспроизводить файлы через TCP/IP, то чувствительность к потерям пакетов оказывается меньше, чем с протоколом UDP;
- битрейт и способ кодирования влияют на восприимчивость к ошибкам передачи.
Заключение
Мы были удивлены: даже незначительные потери пакетов приводят к тому, что потоковое видео становится просто невозможно смотреть! Напротив, если использовать протокол TCP/IP, то создать помехи во время просмотра гораздо сложнее. Во второй части нашей статьи мы посмотрим, как работает потоковое видео в беспроводных сетях. И что нужно сделать, чтобы оно работало хорошо.
