Методы наиболее успешной практики для Создания и Развертывания HTTP Живые Потоковые медиа для iPhone и iPad
Этот Technote обсуждает некоторые методы наиболее успешной практики для создания и развертывания HTTP Живые Потоковые медиа для iPhone и iPad.
Введение
Этот Technote описывает рекомендуемые методы для подготовки и развертывания Ваших носителей для использования с HTTP Живая Потоковая передача. HTTP Живая Потоковая передача позволяет Вам отправлять живое или записанное заранее аудио и видео к iPhone, iPad и другим устройствам включая настольные компьютеры, с помощью обычного веб-сервера. Воспроизведение требует iOS 3.0 или позже устройств рабочий iOS; QuickTime X или позже требуется на рабочем столе.
Живой Обзор Потоковой передачи HTTP нужно считать предпосылкой, потому что он представляет HTTP Живая технология Потоковой передачи.
Начало работы
При работе с видео и аудио хорошее общее правило ползунка состоит в том, чтобы получить материал первоисточника высшего качества как возможный. Когда Вы сжимаетесь, очень часто некоторая информация теряется или выброшенный. Поэтому необходимо только сжать материал при кодировании для конечного места назначения, потому что каждый процесс понизит качество. Попытка сжаться от уже в большой степени сжатого исходного материала может дать плохие результаты.
Всегда запускайте с исходного видео высшего качества и аудио, и делайте более низкие фильмы скорости передачи из первоисточника.
Поток операций
Типичный поток операций для подготовки и развертывания Ваших носителей для использования с HTTP Живая Потоковая передача состоит из следующих шагов. Поток операций для живого содержания подобен, но требует, чтобы Вы создали поток операций, который будет заботиться обо всех этих шагах в режиме реального времени.
Вот краткий обзор различных шагов:
Выберите свои варианты
Мы рекомендуем предложить многократные файлы списка воспроизведения для обеспечения различных кодировок того же представления в различных скоростях передачи, а не просто единственного кодирования. Эти кодировки в различных скоростях передачи вызывают вариантами. Тем путем клиент переключится на самый надлежащий вариант на основе измеренного уровня бита сетевой части. Проигрыватель клиента настраивается для минимизации остановки воспроизведения, чтобы дать пользователю лучший опыт, возможный при потоковой передаче. Если Вы просто обеспечите единственное кодирование своего представления, то Ваши пользователи не получат самый лучший опыт. Посмотрите Выбирают Ваши Варианты.
Закодируйте свои варианты носителей
На основе различных вариантов Вы решили развернуть, закодировать каждый из них от Ваших высококачественных исходных носителей. При кодировании вариантов у Вас должен быть по крайней мере один I-кадр в каждом сегменте, чтобы упростить быстрый запуск и искать. Посмотрите Кодируют Ваши Варианты для приобретения знаний об обеспечении различных кодировок того же представления.
Сегментируйте носители
HTTP Живая Потоковая передача отправляет аудио и видео как серия маленьких файлов, обычно продолжительности приблизительно 10 секунд, названной файлами участка среды. Индексный файл или список воспроизведения, дает клиентам URLs файлов участка среды.
Для видео по требованию от носителей с предварительно записанными данными, Apple обеспечивает бесплатный инструмент для создания файлов участка среды и списков воспроизведения от MPEG 4 видеофильмами или фильмами в формате QuickTime со сжатием видео H.264 или аудиофайлами со сжатием MP3 или AAC. Списки воспроизведения и файлы участка среды могут использоваться для видео по требованию или радио потоковой передачи, например.
Для прямых трансляций Apple обеспечивает бесплатный инструмент для создания файлов участка среды и списков воспроизведения от живых транспортных потоков MPEG 2, переносящих видео H.264, аудио AAC или аудио MP3. См. также Сегментируют Ваши Носители.
Создайте различный список воспроизведения
Различный список воспроизведения может поддерживать поставку многократных потоков того же содержания с переменными уровнями качества для различной пропускной способности или устройств. Живые поддержки Потоковой передачи HTTP, переключающиеся между потоками динамично, если изменяется доступная пропускная способность. Клиентское программное обеспечение использует эвристику для определения подходящего времени для переключения между альтернативами. В настоящее время эта эвристика основывается на недавних трендах в измеренной сетевой пропускной способности. Посмотрите Создают Различный Список воспроизведения.
Разверните носители
Для развертывания HTTP Живые Потоковые медиа Вам нужно использование веб-сервера, и необходимо создать или страницу HTML для браузеров или клиентское приложение для действия как получатель. Можно хотеть зашифровать потоки, когда необходимо служить файлам ключа шифрования надежно по HTTPS, так, чтобы только намеченные клиенты могли дешифровать их. Посмотрите Развертывают Ваши Носители.
Проверьте носители
Необходимо использовать предоставленный Apple блок проверки допустимости мультимедийного потока до обслуживания потоков, чтобы гарантировать, что они полностью совместимы с HTTP Живая Потоковая передача. Посмотрите Проверяют Ваши Носители.
Выберите свои варианты
Вместо того, чтобы предложить просто единственное кодирование Вашего представления, необходимо предложить многократные файлы списка воспроизведения для обеспечения различных кодировок того же представления. HTTP Живой клиент Потоковой передачи тогда переключит среди этих поток, чередуется динамично, когда сетевая пропускная способность изменяется, обеспечивая самый лучший поток для текущего состояния сети.
При выборе скоростей передачи для различного списка воспроизведения существует много вещей учесть. Они обсуждены ниже.
Кодируя аппаратные средства, ограничения бюджета
У Вас может быть ограничение на число скоростей передачи, которые могут произвести Ваши определенные аппаратные средства кодирования. Если Ваша система кодирования может только произвести определенное число потоков, необходимо выбрать варианты, работающие на большинство устройств. Для прямых трансляций, поставленных через CDN, необходимо определить, сколько пропускной способности необходимо для подъема всех потоков и работающий одновременно. У Вас могут также быть финансовые ограничения.
Возможность переключиться
Необходимо проверить расстояние между скоростями передачи вариантов, потому что это определит возможность клиента переключиться на различную скорость передачи. См. рекомендации Скорости передачи для получения дополнительной информации.
Функции устройств
Необходимо также изучить столько, сколько Вы можете о клиентских устройствах, которым Вы будете служить, потому что различные устройства могут иметь различные возможности. У некоторых могут быть различные разрешения экранов, некоторые могут поддерживать различные версии уровней профиля H.264. В определенных случаях Вы могли бы хотеть обеспечить различный список воспроизведения для различных моделей устройства; например, различный список воспроизведения к iPad по сравнению с iPhone. Они обсуждены ниже:
Выберите Device на основе Разрешения Устройства
Различные устройства поддерживают различные разрешения. Из-за этого можно хотеть добавить
RESOLUTION
припишите основному списку воспроизведения, чтобы позволить клиенту выбирать список воспроизведения на основе разрешения устройства. Рассмотрите следующий список воспроизведения:#EXT-X-STREAM-INF:BANDWIDTH=1280000,RESOLUTION=640x360
#EXT-X-STREAM-INF:BANDWIDTH=1700000,RESOLUTION=1280x720
#EXT-X-STREAM-INF:BANDWIDTH=3500000,RESOLUTION=1920x1080
При поставке более старому устройству, такому как iPhone 3GS, клиент выберет 640x360 список воспроизведения, так как эти устройства не могут играть содержание на 1 080 пунктов или на 720 пунктов. Однако более новые устройства, такие как новая поддержка iPad, более высокие разрешения и выберут поток на 1 080 пунктов (если это может обработать скорость передачи). Обратите внимание на то, что, если у Вас будет приложение, поставляющее видео меньшему 640x360 окно а не целый экран, то клиент выберет 640x360 поток. Если Вы только показываете видео в маленьком окне, нет никакого преимущества для получения потока на 1 080 пунктов и включения понижающей передачи это. Это потратило бы впустую пропускную способность пользователя. Однако, если приложение тогда перейдет к полноэкранному, то клиент переключится до потока на 1 080 пунктов, если это возможно.
Выберите Device на основе кодека Устройства
Можно также добавить
CODECS
припишите своему списку воспроизведения, чтобы позволить клиенту фильтровать на основе кодека и определенного профиля и уровня кодирования поддерживаемого устройством. Вот список воспроизведения в качестве примера. Первая запись указывает Базовый профиль H.264, вторая запись указывает Основной профиль H.264, и третье указывает, что H.264 Высоко профилируют (Примечание: комментарии в иллюстративных целях только и считались бы недопустимым синтаксисом в фактическом списке воспроизведения):#EXT-X-STREAM-INF:BANDWIDTH=1280000,CODECS="avc1.42001e" // Baseline
#EXT-X-STREAM-INF:BANDWIDTH=1280000,CODECS="avc1.4d001f" // Main
#EXT-X-STREAM-INF:BANDWIDTH=1280000,CODECS="avc1.64001f" // High
При обслуживании такого списка воспроизведения устройству как iPhone 3GS, не поддерживающий Основной или Высокий профиль H.264, клиент выберет Базовый профиль и проигнорирует другие два варианта, тогда как iPhone 4 выбрал бы Основной профиль.
Выберите на основе Модели устройства
Можно также выбрать список воспроизведения на основе модели устройства (например, iPhone по сравнению с iPad) путем фильтрации на поле HTTP Header
User-Agent
идентификационная строка. Это выполняется на серверной стороне, а не клиентской стороне. Вот некоторый примерUser-Agent
строки. Первые две строки представляют переданный Safari клиентов, и вторые две строки представляют приложения:Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) AppleWebKit/ 534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3
Mozilla/5.0 (iPad; CPU OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3
AppleCoreMedia/1.0.0.9B176 (iPhone; U; CPU OS 5_1 like Mac OS X; en_us)
AppleCoreMedia/1.0.0.9B176 (iPad; U; CPU OS 5_1 like Mac OS X; en_us)
Сетевые возможности
Можно также хотеть учесть сетевые возможности при выборе вариантов.
Можно использовать платформу SystemConfiguration, чтобы определить, являетесь ли Вы на сотовой связи или сети WiFi (см. пример кода Достижимости для примера этого). Как только Вы определяете, какая сеть Вы идете, можно хотеть запросить различный URL или добавить это как дополнительную информацию в запросе так, чтобы сервер мог обеспечить различный список воспроизведения. Это особенно важно, потому что это позволяет Вам указывать надлежащую запись для первого элемента в списке воспроизведения на основе сети, что Вы идете (см. рекомендации Скорости передачи узнать больше о важности первой записи в списке воспроизведения).
Рекомендации скорости передачи
Вот некоторые рекомендации для выбора скоростей передачи в Вашем различном списке воспроизведения:
Первая скорость передачи должна быть той, которую может выдержать большинство клиентов
Первая запись в различном списке воспроизведения будет играться при инициировании потока и используется в качестве части теста для определения, какой поток является самым надлежащим. Порядок других потоков не важен. Поэтому первая скорость передачи в списке воспроизведения должна быть той, которую может выдержать большинство клиентов.
Необходимо создать многократные списки воспроизведения, имеющие тот же набор потоков, но каждый с различной первой записью, которая является подходящей для сети назначения. Это гарантирует, что у пользователя есть хороший опыт, когда сначала играется поток.
Мы рекомендуем указать на поток на 150 Кбит/с для сотового Различного Списка воспроизведения.
Мы рекомендуем указать на поток на 440 Кбит/с для Списка воспроизведения Варианта Wi-Fi.
Посмотрите рекомендуемые настройки кодировки для HTTP живые потоковые медиа.
Где возможно, закодируйте достаточно вариантов для обеспечения потока высшего качества через широкий диапазон скоростей соединения
Например, закодируйте варианты в 64 Кбит/с, 110 Кбит/с, 200 Кбит/с, 350 Кбит/с, 550 Кбит/с, 900 Кбит/с и 1 500 Кбит/с.
Соображения Аудио/Видеопотока
Видео форматное соотношение должно быть точно тем же, но может быть различными размерностями.
Мы рекомендуем 416 x 234 для 16:9 содержание и 400 x 300 для 4:3 содержание (см. Рекомендуемые Настройки кодировки для HTTP Живые Потоковые медиа).
Смежные скорости передачи должны быть фактором 1,5 к 2 независимо
Необходимо сохранить смежные скорости передачи в факторе 1,5 к 2 независимо. При помещении их слишком близко вместе Вы потратите впустую пропускную способность. Например, если у Вас будет 150 Кбит/с и поток на 180 Кбит/с, это не будет иметь большую часть значения. С другой стороны, не делайте их слишком далеко друг от друга также. Если они слишком далеко друг от друга, клиент может оказаться в ситуации, где это, возможно, фактически получило лучший поток, но нет одного доступного. То, если клиент идет от 100 Кбит/с до 300 Кбит/с, пример этого. Это является слишком большим из перехода.
Ключевые кадры (кадры IDR)
Необходимо включать по крайней мере один ключевой кадр на сегмент, предпочтительно больше. Если Вы только включаете один, помещаете его в начале сегмента.
Не делайте под скоростью передачи отчета в основном списке воспроизведения
Для предотвращения остановов не занижайте сведения скорость передачи в основном списке воспроизведения. Максимальная скорость передачи должна быть указана на основе пиковой скорости передачи в потоке. Например, если Вы объявили вариант на 200 Кбит/с в своем списке воспроизведения, тогда его максимальная скорость передачи должна составить 200 Кбит/с. Если Ваш поток на 200 Кбит/с фактически достигает максимума в 300 Кбит/с, клиент может остановиться, потому что Вы исказили, сколько пропускной способности фактически необходимо для игры данного потока.
Специальные замечания для сотовой связи
При использовании HTTP Живая Потоковая передача в приложениях для iPhone и iPad, проданных на App Store существуют некоторые специальные замечания для сотовой связи:
Обеспечьте поток на 64 Кбит/с
Если Ваше приложение использует HTTP Живая Потоковая передача по сотовым сетям, Вы обязаны обеспечивать по крайней мере один поток в 64 Кбит/с, или более низкая пропускная способность (поток низкой пропускной способности может быть только для аудио, или аудио с неподвижным изображением).
Мы рекомендуем создать простой аудио элементарный поток, возможно с изображением jpg кадра плаката.
mediastreamsegmenter
иmediafilesegmenter
инструменты (См. Сегмент Ваши Носители) могут произвести поток только для аудио. Посмотрите Создание аудио только поток. Поочередно, создайте аудио и видео транспортный поток с очень низкой частотой кадров. Однако будет очень трудно создать поток и с аудио и с видео, которое является ниже 64 Кбит/с. Вместо этого мы рекомендуем использовать аудио только.Помните, что 64 Кбит/с не являются суммой аудио + полоса частот видеосигнала, это - пропускная способность мультиплексированного потока. 64 Кбит/с являются всем потоком, включая издержки. Если Вы не используете аудио только, возможности - Вы, по пределу на 64 Кбит/с.
Некоторые частые ошибки при создании потока на 64 Кбит/с:
Думая Вы имеете <поток на 64 Кбит/с, потому что сумма Ваших аудио и видео скоростей передачи - <64 Кбит/с, но не включая транспортный поток наверху.
Помещение слишком большого JPG в начале каждого сегмента.
Неточный EXTINF порождение просчета.
Большой сегмент EXTINFs.
Как обсуждено выше, мы рекомендуем использовать ADTS элементарные потоки.
mediastreamsegmenter
иmediafilesegmenter
инструменты могут вытащить аудио из транспортного потока для Вас.Не служите участкам среды из своего приложения
Приложения не могут захватить носители в некотором другом формате по сотовой сети и выполнить локальный веб-сервер, чтобы перевести и служить тому содержанию в качестве Прямой трансляции HTTP. Если Вы сделаете, Ваше приложение будет отклонено.
Закодируйте свои Варианты
Как только Вы выбрали различные варианты, требуется развернуть, закодировать каждый из них от высококачественных исходных носителей.
Для развертывания потока видео по требованию (VOD) необходимо создать MP3 или MPEG 4 медиа-файла с H.264 и AAC, кодирующим от исходного материала. Всегда запускайте с исходных носителей высшего качества и делайте любые более низкие фильмы скорости передачи из первоисточника, потому что последующие перекодировки могут понизить качество.
Прямые трансляции должны быть закодированы как транспортные потоки MPEG 2, переносящие видео H.264, аудио AAC или аудио MP3.
Рекомендуемые настройки кодировки для HTTP живые потоковые медиа
Рисунок 2 содержит рекомендуемые настройки кодировки для использования при создании HTTP Живые Потоковые медиа.
Эти настройки применяются к и живой и записанный заранее (видео по требованию или VOD) кодирование. Предоставленные настройки сгруппированы согласно тому, предназначается ли содержание, чтобы быть переданным потоком по сотовой сети или сети Wi-Fi, является ли содержание для iPhone/iPod Touch или iPad, и является ли содержание 4:3 или 16:9 форматное соотношение.
Следующие форматы аудио и форматы видео поддерживаются:
Видео: Базовый Уровень 3.0 Профиля H.264 (iPhone/iPod Touch), Основной Уровень 3.1 Профиля (iPad 1,2), Высокий Уровень 4.1 Профиля (новый iPad), MPEG 4 Простой Профиль (Касание/iPad iPhone/iPod), Движение JPEG (M-JPEG) (iPod Touch 4-й Генерал, iPhone 4, iPad)
Аудио: HE-AAC или AAC-LC до 48 кГц, аудио OR стерео
MP3 (Уровень 3 Аудио MPEG 1) от 8 кГц до 48 кГц, аудио стерео
Как создать содержание с рекомендуемыми настройками с помощью QuickTime
Чтобы изучить, как экспортировать файлы с этими настройками с помощью QuickTime, посмотрите Техническое примечание TN2218, 'Сжав фильмы в формате QuickTime для сети'
Сегментируйте свои Носители
Живая Потоковая передача HTTP требует, чтобы мультимедийный поток или файл были сегментированы на серию маленьких медиа-файлов приблизительно равной продолжительности. Это обычно выполняется с помощью инструмента, который сегментирует отдельные файлы и создаст список воспроизведения.
Эта архитектура допускает прямую трансляцию, уже сегментированную, чтобы быть быстро преобразованной в поток VOD только путем обновления списка воспроизведения.
Существует два инструмента командной строки, доступные Вам от Apple для сегментации HTTP Живые Потоковые медиа. Инструменты:
Мультимедийный поток Segmenter
Медиа-файл Segmenter
Мультимедийный поток инструмент Segmenter
Можно использовать Мультимедийный поток Segmenter (mediastreamsegmenter
) инструмент для развертывания HTTP Живые Потоковые медиа.
Инструмент установлен на Вашем системном диске в /usr/bin/mediastreamsegmenter
. ( /usr/bin
каталог скрыт от Средства поиска, но является доступным использованием Терминального приложения, расположенного в Utilities
папка.)
Этот инструмент получает транспортный поток MPEG 2 по сетевому соединению UDP или от stdin
и делит его на серию маленьких участков среды равной продолжительности. Это тогда создает индексный файл, содержащий ссылки на отдельные участки среды. Индексный файл и участки среды могут быть развернуты с помощью почти любую инфраструктуру веб-сервера для потоковой передачи к iOS и OS X. mediastreamsegmenter
производит или живые потоки или потоки Видео по требованию (VOD).
mediastreamsegmenter
инструмент принимает различные параметры командной строки (можно получить список параметров командной строки и их значений путем ввода man mediastreamsegmenter
от Терминального приложения, или см. онлайновую страницу справочника).
Вот пример, показывающий, как использовать mediastreamsegmenter
получить и создать незашифрованную прямую трансляцию:
mediastreamsegmenter -s 3 -D -f /Library/WebServer/Documents/stream 239.4.1.5:20103
-s
опция определяет число записей медиа-файла, которые должны быть сохранены в индексном файле. Значение по умолчанию равняется 5. -D
опция (в прямой трансляции) укажет, что медиа-файлы, которые больше не находятся в индексном файле, будут удалены после периода истечения. -f
опция указывает каталог для хранения медиа-файлов и индексных файлов.
В этом примере индексный файл будет содержать 3 элемента. После периода истечения будут удалены медиа-файлы. Медиа-файлы и индексные файлы будут сохранены в /Library/WebServer/Documents/stream
.
Создание аудио только поток
Этот инструмент может произвести поток только для аудио при указании следующего параметра:
-a | -audio-only
Это разделяет аудио элементарный поток (AAC/ADTS или MP3) и пишет его в медиа-файл. Например, Вы могли работать mediastreamsegmenter
на существующем аудио/видеопотоке для получения потока только для аудио.
Если также требуется включать изображение плаката в аудио только поток, просто создать маленький jpg или png (20 к 30k), и использовать -audio-only
установка mediafilesegmenter
, с --metafile
и --meta-type=picture set
(ввод man mediafilesegmenter
от Терминального приложения даст, Вы детализируете для всех опций).
Медиа-файл инструмент Segmenter
Медиа-файл segmenter (mediafilesegmenter
) инструмент командной строки что медиа-файлы сегментов для развертывания с помощью HTTP Живая Потоковая передача. mediafilesegmenter
берет носители от указанного файла, мультиплексирует его в Транспортные потоки MPEG 2 при необходимости и делит его на серию маленьких медиа-файлов приблизительно равной продолжительности.
mediafilesegmenter
также создает индексный файл, содержащий ссылки на отдельные медиа-файлы. Индексный файл и медиа-файлы могут тогда быть развернуты как поток VOD с помощью общей инфраструктуры веб-сервера.
mediafilesegmenter
инструмент принимает много различных параметров командной строки (можно получить список параметров командной строки и их значений путем ввода man mediafilesegmenter
от Терминального приложения).
[-O | -optimize [yes | no]]
Транспортный поток структурные издержки
Транспортные потоки MPEG содержат определенную сумму издержек и дополнения. В зависимости от того, как создается Ваш транспортный поток, у Вас могло бы быть больше наверху, чем в других случаях. Медиа-файл Apple и поток segmenters были оптимизированы для создания очень мало служебного, обычно меньше чем 10% (и в большинстве случаев, меньше чем 5%). Потоки, произведенные некоторыми сторонними кодерами, содержат наверху целых 45%.
Для рассматривания этого в истинном свете если поток составляет 100 Кбит/с, и у Вас есть 45% наверху, только 55 Кбит/с удающихся фактических видеоданных. Если Ваши издержки составляют 5%, то у Вас есть 95 Кбит/с видео. Очевидно, можно произвести намного лучший поток, если у Вас есть 95 Кбит/с видеоданных по сравнению с 55 Кбит/с, таким образом, Вы захотите минимизировать те издержки, если Вы можете. Если Вы работаете со сторонним поставщиком, мы предлагаем, чтобы Вы взяли свое исходное содержание, закодировали его с потоком Apple segmenter и выдержали сравнение для наблюдения, какой наверху Вы получаете.
Используйте по крайней мере один кадр IDR на сегмент (предпочтительно в запуске)
Чтобы иметь быстрый запуск и искать, у Вас должен быть кадр IDR в Вашем сегменте. В видео H.264 IDR относится к Мгновенным кадрам Обновления Декодера, специальному виду I-кадра. Они указывают к декодеру, что никакой кадр, происходящий после кадра IDR, не зависит ни от какого кадра, происходящего перед ним. Мы рекомендуем иметь по крайней мере один кадр IDR в начале сегмента, потому что при поиске или запуске отчасти посредством прямой трансляции клиенту нужен кадр IDR для начала работы. Если Вы помещаете свои кадры IDR отчасти в сегмент, клиент не может запустить, пока он не находит кадр IDR.
Используйте 10 вторых Продолжительностей Target
Значение Вы указываете в EXT-X-TARGETDURATION
тег на максимальное время участка среды будет иметь эффект на запуск. Мы строго рекомендуем 10 вторых целевых продолжительностей. При использовании меньшей целевой продолжительности Вы увеличиваете вероятность останова. Вот то, почему: если у Вас будет живое содержание, поставляемое через CDN, то будут задержки propogation, и для этого содержания для создания всего этого выходом к граничным узлам на CDN, это будет переменным. Кроме того, если клиент выберет данные по сотовой сети то будут более высокие задержки. Оба из этих факторов делают его, намного более вероятно Вы встретитесь с остановом при использовании маленькой целевой продолжительности.
Создайте различный список воспроизведения
Мультимедийная презентация потоковой передачи указана файлом Списка воспроизведения, который является списком ресурсов медиа-файла, каждый из которых относится к сегменту единственного непрерывного потока. Сервер может предложить многократные файлы Списка воспроизведения для обеспечения различных кодировок того же представления когда HTTP Живая Потоковая передача. Если это делает, это должно обеспечить Различный файл Списка воспроизведения, перечисляющий каждый различный поток, чтобы позволить клиентам переключаться между кодировками динамично, если изменяется доступная пропускная способность.
Посмотрите, что HTTP Живет, Передавая потоком Обзор и HTTP Живая Спецификация Протокола потоковой передачи для получения дополнительной информации о Различных Списках воспроизведения.
Различный инструмент создателя списка воспроизведения
Различный создатель списка воспроизведения (variantplaylistcreator
) инструмент командной строки, который создаст различный список воспроизведения в формате m3u8 для потока, переключающегося для сегментов HTTP Live Streaming, создаваемых mediafilesegmenter
. iPhone и элементы Программы Разработчика Mac могут загрузить инструмент как часть HTTP Живой пакет Инструментов Потоковой передачи, как описано в Сегменте Ваши Носители.
variantplaylistcreator
берет пар URLs, и plist файлы генерировали использование -I -generate-variant-info
опция от mediafilesegmenter
и создает различный потоковый список воспроизведения. Можно получить список всех параметров командной строки и их значений путем ввода man variantplaylistcreator
от Терминального приложения.
Используйте относительные пути
Когда возможно, используйте относительные пути в Различных Списках воспроизведения и в частном лице .m3u8
Файлы списка воспроизведения.
Относительные пути являются более переносимыми, чем абсолютные пути. Используя имена полного пути для отдельных записей списка воспроизведения чаще всего использует больше текста, чем использование относительного пути. В случае очень длинного списка воспроизведения VOD или очень длинной продолжительности Живой список воспроизведения, это может создать значительное различие в размере файла в самом файле списка воспроизведения, увеличив время загрузки файлов списка воспроизведения.
Разверните свои носители
Элемент видео HTML5
Мы рекомендуем использовать HTML5 video
элемент для отображения видео в Safari на iOS. Для получения дополнительной информации о video
элемент, посмотрите Руководство по Safari по Аудио HTML5 и Видео и HTMLMediaElement
, HTMLVideoElement
, и HTMLAudioElement
ссылки класса в Safari Ссылка Расширений DOM.
Пример исходного кода в Перечислении 1 демонстрирует, как использовать video
элемент для отображения HTTP Живое Потоковое видео в веб-странице.
Пример элемента видео перечисления 1 HTML5.
<video src="http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8"> |
This browser does not support HTML5 video. |
</video> |
См. также Техническое примечание TN2262, 'Подготовка Вашего веб-контента для iPad', описывающего специфичные для платформы соображения для веб-контента в Safari на устройствах на iOS с определенной информацией для iPad.
Конфигурация веб-сервера
Система распределения для HTTP, Живые Потоковые медиа являются веб-сервером или веб-системой кэширования, поставляющей медиа-файлы и индексные файлы клиенту по HTTP (см., что HTTP Живет, Передавая Обзор потоком для получения дополнительной информации). Никакие пользовательские модули сервера не требуются, чтобы поставлять содержание, и обычно очень маленькая конфигурация необходима на веб-сервере.
Рекомендуемая конфигурация обычно ограничивается указанием ассоциаций типа MIME для .M3U8
файлы и .ts
файлы.
Расширение файла | Тип MIME |
---|---|
.M3U8 | vnd.apple.mpegURL или application/x-mpegURL |
.ts | video/MP2T |
Серверы, ограничивающиеся для совместимости, могут служить файлам, заканчивающимся в .m3u
с типом MIME audio/mpegURL
.
Настройка времени жизни (TTL) оценивает за .M3U8
файлы могут также быть необходимыми для достижения желаемого кэширующегося поведения для нисходящих веб-кэшей, поскольку эти файлы часто перезаписываются, и последняя версия должна быть загружена для каждого запроса. Сверьтесь со своим провайдером службы доставки контента для определенных рекомендаций.
Вручите списки воспроизведения с помощью gzip
Необходимо всегда вручать список воспроизведения с помощью gzip. Списки воспроизведения VOD могут иметь сотни записей. Даже в живом списке воспроизведения, у Вас могут быть сотни записей при поставке большого окна содержания. gzip сокращает размер существенно, и очень просто добавить к Вашему серверу (это обычно - одно изменение строки в Вашей конфигурации сервера).
Отслеживайте свою Производительность
После развертывания Ваших потоков необходимо отследить фактическую производительность в поле для проверки предположений о скоростях передачи, которые Вы выбрали. Используйте клиентский доступ платформы MediaPlayer и журналы ошибок с этой целью. В журнале доступа существует много различных полей. Необходимо обратить внимание на поля, говорящие Вам, какие потоки Вы фактически получаете, какой длины они игра, где потоковое переключение происходит, и получаете ли Вы остановы.
Посмотрите MPMovieAccessLogEvent
, MPMovieAccessLog
и MPMovieErrorLogEvent
классы для получения дополнительной информации.
Проверьте свои носители
Инструмент блока проверки допустимости мультимедийного потока
Блок проверки допустимости мультимедийного потока (mediastreamvalidator
) инструмент командной строки для проверки HTTP Живые потоки Потоковой передачи и серверы. iPhone и элементы Программы Разработчика Mac могут загрузить инструмент как часть HTTP Живой пакет Инструментов Потоковой передачи, как описано в Сегменте Ваши Носители.
Этот инструмент моделирует HTTP Живой сеанс Потоковой передачи и проверяет, что индексный файл и участки среды приспосабливают HTTP Живой спецификации Потоковой передачи. Это выполняет несколько проверок для обеспечения надежной потоковой передачи. Если какие-либо ошибки или проблемы найдены, подробный диагностический отчет выведен на экран.
Вот вывод в качестве примера от mediastreamvalidator
инструмент.
Инструмент блока проверки допустимости перечисления 2 В качестве примера выводится.
Validating https://devimages.apple.com.edgekey.net/resources/http-streaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8 |
Validating child playlist gear1/prog_index.m3u8 |
Validating child playlist gear2/prog_index.m3u8 |
Validating child playlist gear4/prog_index.m3u8 |
Validating child playlist gear0/prog_index.m3u8 |
Validating child playlist gear3/prog_index.m3u8 |
-------------------------------------------------------------------------------- |
https://devimages.apple.com.edgekey.net/resources/http-streaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8 |
-------------------------------------------------------------------------------- |
Playlist Validation: |
OK |
Alternate playlist(s): |
-------------------------------------------------------------------------------- |
gear1/prog_index.m3u8 |
-------------------------------------------------------------------------------- |
Playlist Validation: |
OK |
Segments: |
OK |
Average segment duration: 9.93 seconds |
Average segment bitrate: 231379.21 bps |
Average segment structural overhead: 12107.10 bps (5.23 %) |
-------------------------------------------------------------------------------- |
gear2/prog_index.m3u8 |
-------------------------------------------------------------------------------- |
Playlist Validation: |
OK |
Segments: |
OK |
Average segment duration: 9.93 seconds |
Average segment bitrate: 646360.46 bps |
Average segment structural overhead: 21147.77 bps (3.27 %) |
-------------------------------------------------------------------------------- |
gear3/prog_index.m3u8 |
-------------------------------------------------------------------------------- |
Playlist Validation: |
OK |
Segments: |
OK |
Average segment duration: 9.93 seconds |
Average segment bitrate: 983809.40 bps |
Average segment structural overhead: 29737.85 bps (3.02 %) |
-------------------------------------------------------------------------------- |
gear4/prog_index.m3u8 |
-------------------------------------------------------------------------------- |
Playlist Validation: |
OK |
Segments: |
OK |
Average segment duration: 9.93 seconds |
Average segment bitrate: 1496114.70 bps |
Average segment structural overhead: 40250.70 bps (2.69 %) |
-------------------------------------------------------------------------------- |
gear0/prog_index.m3u8 |
-------------------------------------------------------------------------------- |
Playlist Validation: |
OK |
Segments: |
OK |
Average segment duration: 10.00 seconds |
Average segment bitrate: 41264.41 bps |
Для различных списков воспроизведения важно, чтобы скорости передачи, указанные в списке воспроизведения, были очень близко к фактическим измеренным уровням. В противном случае предупреждение будет выпущено mediastreamvalidator
. Скорости передачи указаны в EXT-X-STREAM INF
тег с помощью BANDWIDTH
атрибут.
Список воспроизведения Варианта перечисления 3 В качестве примера, показывающий атрибут BANDWIDTH.
#EXTM3U |
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000 |
http://example.com/low.m3u8 |
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000 |
http://example.com/mid.m3u8 |
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000 |
http://example.com/hi.m3u8 |
Посмотрите, что HTTP Живет Спецификация Протокола потоковой передачи для получения дополнительной информации о BANDWIDTH
атрибут.
Ссылки
История версии документа
Дата | Примечания |
---|---|
28.02.2014 | Обновленный рекомендуемые настройки кодировки для включения более новых устройств. Другие разные изменения. |
14.08.2012 | Включает новые и обновленные рекомендации для выбора вариантов, кодирования, сегментации и развертывания Ваших носителей. |
03.08.2011 | Передовая статья |
08.07.2011 | Пересмотренные рекомендации настроек кодера включать Apple TV. |
19.04.2010 | Обновленные рекомендуемые настройки кодировки для включения iPad только оценивают. |
19.03.2010 | Новый документ, обсуждающий методы наиболее успешной практики для создания и развертывания HTTP Живые Потоковые медиа для iPhone и iPad |