Воспроизведение потокового видео

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

Дата публикации: 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

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

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

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

Программы для потокового видео

Сергей и Марина Бондаренко

Термином «потоковое видео» (streaming video) сегодня обозначают технологии сжатия и буферизации данных, которые позволяют передавать видео в реальном времени через Интернет. Главная особенность потокового видео заключается в том, что при его передаче пользователь не должен ждать полной загрузки файла для того, чтобы его просмотреть. Streaming video пересылается непрерывным потоком в виде последовательности сжатых пакетов и проигрывается по мере того, как передается на компьютер получателя.

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

Способы передачи

Существуют два способа передачи потокового видео — последовательный (progressive streaming) и в реальном времени (Real-time streaming). При передаче последовательным способом качество изображения всегда лучше, поскольку видео воспроизводится с вашего жесткого диска. Для такого способа передачи видео можно использовать стандартный веб-сервер.

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

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

Потоковые серверы дают возможность управлять медиа-передачей, однако, они более сложны в настройке и администрировании, чем обычные HTTP-серверы. Кроме специальных серверов, используются и особые сетевые протоколы, например, RTSP (Real-Time Streaming Protocol). Этот протокол используется Windows Media по умолчанию, но он также поддерживается Real Video.

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

Протокол RTP (Real-time transport protocol) определяет и компенсирует потерянные пакеты, обеспечивает безопасность передачи контента и распознавание информации. Вместе с RTP работает протокол RTCP (Real-Time Control Protocol). Он отвечает за проверку идентичности отправленных и полученных пакетов, идентифицирует отправителя и контролирует загруженность сети. Форматы

Существует несколько основных форматов потокового видео в интернете. Это — Real Media, Windows Media и Quicktime. До недавнего времени наряду с ними широко использовался MPEG, однако, в последнее время он сильно сдал позиции.

Формат MPEG был разработан компанией Moving Picture Experts и до недавнего времени считался стандартом потокового вещания. Существует несколько версий MPEG.

Формат MPEG-1 был создан в далеком 1988-м году и обеспечивал качество VHS при записи видео на CD-ROM. Несмотря на то, что MPEG-1 разрабатывался как формат хранения, а не передачи файлов, он обеспечивает отличное качество потокового видео на высоких битрейтах. Оптимальный битрейт для этого формата — 1.5мб/с для разрешения 352×240 при частоте 30 кадров в секунду. Однако, файлы MPEG-1 обычно слишком велики для передачи по интернету.

Формат MPEG-2 был разработан для вещания цифрового телевидения и со временем также стал использоваться при записи DVD. Его битрейт еще выше, чем у MPEG-1 (между 4 и 9 мб/c), что позволяет добиться изображения высокой четкости. Его использование как потоковой технологии не очень распространено, так его скорость передачи информации очень велика. Для просмотра файла в формате MPEG-2 в режиме онлайн нужно иметь скорость передачи данных около 400 кб/c и выше.

Формат MPEG-4 был специально разработан для передачи данных по интернету и мобильной связи. Его оптимальный битрейт — между 385 и 768 кб/c. MPEG-4 может использоваться для передачи аудио и видео потоков, обеспечивая при этом высокое качество кодирования при большой степени компрессии. Однако, если на небольшой скорости передачи данных он обеспечивает хорошее качество, для широкополосной передачи он не приспособлен.

RealVideo

RealV >

QuickTime

Этот формат, разработанный Apple, широко используется как на компьютерах Mac, так и в среде Windows. QuickTime имеет много общего с форматом Real Media. Степень сжатия файла QuickTime — 1 мб для 3.75 секунд видео, поэтому размер изображения может быть увеличен и уменьшен без потери качества. Это означает, что видеофайл с разрешением 320×240 может быть просмотрен в полноэкранном режиме с таким же качеством. Формат QuickTime лучше всего подходит для последовательной передачи потокового видео, так как в процессе загрузки файла запускается плеер, который воспроизводит полученную информацию.

Windows Media

Windows Media — это относительно молодой формат в области потокового вещания, поддерживаемый Microsoft. Последняя разработка компании — Windows Media Video 9. Этот формат превосходит по производительности своего предшественника WMV8 на 15-30 процентов. Сравнение же с другими форматами потокового вещания тоже говорит только в его пользу. Так, например, видео в формате MPEG-4, транслируемое с битрейтом 6 мб/c, будет выглядеть аналогично сделанному при помощи WMV9 при 2 мб/c. А качество видео в формате WMV9, передаваемого на скорости 150 кб/с, ничуть не хуже, чем аналогичного в формате MPEG-4 на 300 кб/c.

Какой формат выбрать

На сегодняшний день еще можно говорить о том, что значительная часть пользователей выходит в интернет через dial-up, а значит, на очень низких скоростях. Лишь немногие могут себе позволить скорость более 2 мб/c, однако в последние пару лет значительно увеличилось количество пользователей, которые выходят в интернет через выделенную линию со скоростями от 128 кб/с. На таких скоростях уже возможна передача данных с качеством на уровне VHS.

Скорость вашего интернет-соединения имеет значение при выборе формата. Windows Media 7,8, Windows MPEG-4, Real Media, Quicktime лучше всего подходят для диапазона скорости от 36 кб/c до 500 кб/c. Windows media 9, MPEG4 (ISO и DivX) можно выбирать, если ваша скорость от 500 кб/c до 3 мб/c. Для высоких скоростей (от 1 мб/c до 3 мб/c) лучше всего подойдет MPEG-1, а для очень высоких (от 3 мб/c до 15 мб/c) — MPEG2. Хороший кодировщик MPEG-1 даст качество VHS на скорости 1.5 мб/c, качество SVHS — на 2.5 мб/c. MPEG-2 обеспечит качество DVD (4:2:0) на 5 мб/c, видео качество 4:2:2 — на 10 — 15 мб/c. Таким образом, MPEG 1, 2 позволяют достичь очень высокого качества передачи видео, правда, и интернет-доступ для получения этого качества должен быть соответствующий.

Проблемы передачи

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

Перебои в связи

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

Маломощный компьютер

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

Помехи на телефонной линии

Эта проблема актуальна только для пользователей, которые выходят в интернет через dial-up. Всевозможные потрескивания, щелчки и прочие шумы снижают качество передачи. Решением этой проблемы может быть использование более качественного доступа в интернет посредством cable или DSL.

Как сохранить видео на диск

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

Обычно ссылка скрыта в метафайле (RAM, ASX, SMIL). Если кликнуть правой кнопкой мыши по ссылке на видеофайл в окне браузера и выбрать команду «Save target as . «, метафайл будет сохранен на жесткий диск. После этого его можно открыть в любом текстовом редакторе (например, в Блокноте) и скопировать ссылку на файл. Если метафайл защищен паролем или скрыт при помощи JavaScript, Flash и т.д., можно попытаться открыть файл в плеере и просмотреть его свойства.

Например, чтобы увидеть ссылку на видео файл в RealOne Player, нужно выполнить команду View > Clip > Clip Info или View > Clip > Clip Source. В качестве альтернативы этому способу можно использовать программы, позволяющие отследить источник файла, например URLSnooper.

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

HiDownload

Основное преимущество этого менеджера перед аналогичными — возможность записи потоков в форматах Windows Media и RealVideo. HiDownload поддерживает все стандартные протоколы, которые используются для передачи потокового видео. При помощи программы можно также загружать потоковое видео, защищенное паролем.

Net Transport

Бесплатная программа, работающая с большинством потоковых протоколов. Поддерживает протоколы HTTP, HTTPS, FTP, MMS (Microsoft Media Services), и RTSP (Real-Time Streaming Protocol). Как и большинство современных download-менеджеров, Net Transport может разбивать скачиваемый файл на отдельные части, что увеличивает скорость передачи данных. Net Transport позволяет загружать видео в форматах Windows Media и RealVideo, защищенное паролем.

Offline Explorer

Оффлайн-браузер, позволяющий скачивать файлы по протоколам HTTP, FTP, HTTPS, MMS и RTSP. Программу особенно удобно использовать для загрузки больших файлов. Программа доступна в трех версиях, и только две из них (Pro и Enterprise) поддерживают потоковые протоколы.

WM Recorder

WM Recorder записывает потоковое видео в формате Windows Media в процессе просмотра через Windows Media Player. Потоковые данные перехватываются и записываются в файл ASF, который впоследствии может быть воспроизведен любым проигрывателем, поддерживающим этот формат. WM Recorder поддерживает докачку файлов при последовательной передаче. При передаче в реальном времени докачка невозможна. Недостатком WM Recorder можно считать невозможность перехвата файлов, защищенных DRM (Digital Rights Management).

При попытке сохранения видеопотока можно столкнуться с проблемой недостаточной пропускной способности линии. Видео высокого качества требует и большой скорости соединения. Однако, в некоторых случаях возможно сохранить видео высокого качества и при низкоскоростном коннекте. Если используется передача в реальном времени, видео поток не может быть записан на скорости, которая превышает скорость вашего соединения. Если же передача ведется последовательным способом, это возможно. Для этого нужно изменить настройки пропускной способности канала. Некоторые утилиты, например, упомянутые выше HiDownload и WM Recorder позволяют сделать это автоматически.

Смотреть потоковое видео с помощью VLC Media Player

VLC – это популярный проигрыватель для компьютеров под управлением Windows, Mac OS или Linux. В программе есть много скрытых возможностей, на которые начинающие пользователи часто не обращают внимания. Одна из таких функций – просмотр потокового видео через VLC.

Загрузка потока

Следуйте инструкции, чтобы узнать, как смотреть потоковое видео через VLC:

• Откройте плеер и веб-страницу с потоковым контентом;
• Скопируйте ссылку на стрим;
• В приложении зайдите в главное меню и кликните на «Открыть URL-адрес»;

• В открывшемся окне выберите вкладку «Сеть» и в текстовое поле скопируйте ссылку на веб-страничку с потоковым фильмом;
• Закройте окно настроек. Через несколько секунд в окне плеера появится лого трансляции и начнётся её воспроизведение. В процессе просмотра стрима вы можете закрыть браузер и продолжить работу только с плеером.

На рисунке выше представлен пример просмотра прямой трансляции с ресурса Twitch в медиа-плеере VLC на компьютере с ОС Windows 10. Что касается качества воспроизведения потока, оно на порядок выше, нежели при работе с браузерами.

В приложении есть возможность перемотки стрима для просмотра пропущенных моментов.

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

Потоковое видео в Android

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

Представим, что перед вами стоит задача реализовать Android приложение, способное проигрывать множество файлов, заливаемых пользователями на ваш сервер. Написать свой youtube, с блекджеком и кодеками. Для этого вам придётся решить как минимум две задачи: конвертации видео к поддерживаемому на Android формате, воспроизведение видео с удалённого источника. Рассмотрим обе эти задачи более подробней.

Конвертация видео

И так, прежде чем воспроизвести какое-то видео нашем Android устройстве, надо это видео перекодировать в поддерживаемый формат. В документации к Android чётко обозначен список этих самых форматов.

Для того, что бы перекодировать файлы, заливаемые пользователями на ваш сервис, или же записать поток с TV-тюнера, вам потребуется помощь специальной утилиты ffmpeg, являющейся де-факто стандартом в отрасли. Подробную инструкцию по её установке можно найти на сайте одноимённого проекта.

Наиболее распространённым сейчас (на мой взгляд) способом хранения видео является контейнер MP4 с использованием кодека H.264 AVC. Их мы, собственно, и рассмотрим.

Первым делом обратите внимание, что Android поддерживает не все возможности кодека H.264, а только определённый набор — профиль, именуемый Baseline Profile(BP). Так, например, в BP не входят такие полезные фичи H.264 как CABAC или B-Frames.

Для нас это значит, что если мы будем использовать эти фичи при кодировании видео, то Android проигрывать это видео будет не обязан. Хотя и может, если ваш телефон достаточно мощный и вендор позаботился об установке и поддержке дополнительных кодеков. Так, например, видео в Main Profile без проблем проигрывается на Samsung Galaxy SII. На телефонах же обычного класса (например, Samsung Galaxy Ace) мы получим сообщение о невозможности воспроизведения видео и ошибку с кодом неверного кодека в logcat‘е.

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

ffmpeg -i in.3gp -f mp4
-vcodec libx264 -vprofile baseline -b:v 1500K
-acodec libfaac -b:a 128k -ar 44100 -ac 2
-y out.mp4

Рассмотрим подробнее каждый из параметров:

• -i src входной (перекодируемый) файл;
• -f mp4 используемый видеоконтейнер;
• -vcodec libx264 используемый видеокодек;
• -vprofile baseline используемый профиль;
• -b:v 1500K bitrate;
• -acodec libfaac используемый аудиокодек;
• -b:a 128k аудио bitrate;
• -ar 44100 частота звука;
• -ac 2 количество аудиопотоков;
• -y флаг перезаписи выходного файла;

Так же стоит отметить, что можно обойтись и без указания профиля, а явно включить/отключить нужные опции кодека H.264 через параметр -x264opts, так что бы они удовлетворяли условиям BP. Но это же занятие для любителей.

Раздача видео

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

Как же быть? Платформа Android предлагает нам нативную поддержку следующих технологий/протоколов:

• HTTP/HTTPS progressive streaming;
• HTTP/HTTPS live streaming;
• RTSP (RTP, SDP);

Рассмотрим их по порядку.

Progressive streaming

Наиболее простой способ раздачи видео с помощью обычного web-сервера, сводящийся по сути к скачиванию заранее подготовленного файла по HTTP(S) протоколу. Вся соль в данном случае заключается в том, что воспроизведение файла начинается не по окончанию загрузки, а как только будет скачано достаточно данных (наполнен некоторый буфер).

Тут стоит уточнить, что при использовании контейнера MP4, необходимо сформировать файл так, что бы метаданные о видео потоке (moov atoms) располагались в начале файла (после атома ftyp), перед видеоданными (mdat atoms). Сделать это можно с помощью обработки файла утилитой qt-faststart:

Основной проблемой progressive streaming‘а является невозможность перемотки видео к нескачанному моменту, наличие достаточного количества свободного места на устройстве и необходимость поддержки большого числа «толстых» клиентов, скачивающих видео, на web-сервере.

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

Pseudo streaming

Данная технология является логическим расширением progressive streaming‘a и позволяет решить одну из его главных проблем — перемотки к ещё не скачанному фрагменту. Применима для контейнеров MP4/FLV с кодеком H.264/AAC.

Единственным отличием от progressive streaming‘a в данным случае является, тот факт, что вам потребуется специальный web-сервер, который с учётом временной метки в GET-запросе будет отдавать нужный вам фрагмент видео файла. Примером такого web-сервера естественно может служить православный NGINX с его ngx_http_mp4_module.

Мне не удалось найти какой-либо официальной информации относительно поддержки данного стандарта в Android. Однако, эмперическим путём было установлено, что она присутствует как минимум на устройствах HTC Desire и Samsung Galaxy SII. Однако, хочу обратить внимание, что да же в случае отсутствия нативной поддержки на вашем устройстве всегда можно воспользоваться сторонними плеерами типа MX Player, которые самостоятельно реализуют логику скачки и воспроизведения фрагментов видео с нужной временной меткой, что позволяет организовать перемотку.

Live streaming

Довольно нестандартный протокол передачи данных от компании Apple. Суть его сводится к тому, что раздаваемый файл «пилится» на множество небольших частей, объединяемых спецтальным файлом-playlist’ом формата M3U8. Передача данных происходит по протоколу HTTP(S).

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

Однако, появляются и проблемы. Для «распила» файла и создания playlist’а потребуется ресурсы процессора, время и место на сервере. Для вещания файла в сеть, как и в предыдущих примерах, потребуется HTTP сервер (без каких-либо дополнительных модулей).

«Распилить» видео файл можно использовать VLC:

vlc -I dummy /path/to/pornofilm.mpg vlc://quit —sout ‘#transcode

Воспроизвести такой файл можно по URL localhost/pornofilm.m3u8.

Поддержка HTTP Live Streaming на нативном уровне в Android присутствует начиная с версии 3.0. С помощью сторонних плееров (DicePlayer, MX Player), судя по wiki, можно добиться поддержки с версии 2.2.

Real Time Streaming Protocol (RTSP)

Протокол прикладного уровня с поддержкой состояния, разработанный специально для передачи видео. Формат команд очень напоминает HTTP. Сами же команды напоминают кнопки на обычном кассетном магнитофоне: PLAY, PAUSE, RECORD и т.д.

В отличие от HTTP Live Streaming RTSP не требует разбиения фалов на мелкие части и составления playlist’ов. Нужные части файла будут генерироваться и отдаваться клиенту налету. В качестве RTSP сервера можно использовать VLC.

Стоит заметить, что сам протокол RTSP не определяет способ передачи данных, а делегирует это другим протоколам. Например, RTP. Для вещания файла по протоколу RTP нужно будет запустить VLC со следующими параметрами:

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

Поэтому вернёмся к протоколу RTSP и воспроизведению видео по требованию (Vidoe On Demand). Для того, что бы использовать VLC в качестве RTSP сервера для проигрывания VOD необходимо прежде всего запустить VLC, указав атрибуты RTSP сервера и Telnet интерфейса:

vlc -vvv -I telnet —telnet-password 123 —rtsp-host 127.0.0.1 —rtsp-port 5554

После этого как сервер запущен, необходимо произвести его настройку. Делать это удобнее всего с помощью telnet‘a, так как такой подход даёт возможность настройки налету:

setup porno input /path/to/pornofilm.mpg

Для воспроизведения видео (в том числе и на платформе Android) необходимо запросить его по URL rtsp://localhost:5554/pornofilm.

Из недостатков можно отметить тот факт, что HTTP открыт зачастую на всех firewall’ах и проксях… с RTSP в случае политики Deny,Allow всё иначе.

Кроме того, при использовании RTSP-сервера для добавления/удаления файлов на сервере придётся обновлять его конфигурацию (список vod’ов). Да, для этого есть telnet, но это всё равно сложнее, чем просто заливать или удалять файлы из каталогов web-сервера.

Воспроизведение с помощью данной технологии поддерживается платформой Android нативно. Например, с помощью всё того же стандартного класса MediaPlayer.

Multicast

Многие считают, что multicast не работает в Android. Это не совсем так.

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

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

Однако, как показывает практика, проигрывать multicast видео на Android всё можно. В моём случае с этой задачей удачно справился недавно вышедший VLC Beta для Android.

Кроме того с помощью VLC-сервера всегда можно свести воспроизведение multicast‘a к HLS:

vlc -I dummy udp://@192.168.20.1:1234 vlc://quit —sout ‘#transcode

new multicast-porno vod enabled

setup multicast-porno input udp://@192.168.20.1:1234

Попытать удачу с проигрыванием multicast’a на вашем устройстве вы можете, передав плееру URL вида udp://@192.168.20.1:1234.

Что выбрать

Если с форматом видео всё ясно (H.264 BP / MP4), то со спобом дистрибуции вопрос открыт. У каждого их них есть свои достоинства и недостатки.

Первым делом из рассмотрения я бы убрал обычный progressive streaming. Да он работает всегда и везде, но отсутствие перемотки и загрузка всего файла целиком — это уже слишком.

Следующим кандидатом на вылет является live streaming. Главным его недостатком является нативная поддержка в Android начиная с версии 3.0. А игнорирование более 80% пользователей c версией 2.x — не вариант. Хотя тут можно посмотреть на сторонний плеер, или заняться собственной реализацией (свободных наработок для поддержки HLS я, увы, не нашёл).

И последним я бы вычеркнул RTSP. Да, это протокол, разработанный специально для видео. Да, его использование идейно верно. Но есть два момента. Во первых — необходимо постоянно обновлять конфигурацию сервера. Во вторых, HTTP открыт всегда и везде, чего нельзя сказать о RTSP/RTP.

Лично я бы остановился на pseudo streaming. Он позволяет осуществлять перемотку и при этом не скачивать весь файл полностью. От нас требуется только немного донастроить web-сервер.