Загрузите инструменты

Существует несколько инструментов, доступных, который может помочь Вам установить HTTP Живой Потоковый сервис. Инструменты включают мультимедийный поток segmenter, медиа-файл segmenter, потоковый блок проверки допустимости, генератор тега id3 и различный генератор списка воспроизведения.

Инструменты часто обновляются, таким образом, необходимо загрузить текущую версию HTTP Живые Инструменты Потоковой передачи от веб-сайта Разработчика Apple. Если Вы - участник Программы Разработчика iOS, можно получить доступ к ним. Один способ перейти к инструментам состоит в том, чтобы войти в систему developer.apple.com, затем использовать функцию поиска.

Типы сеанса

HTTP Живой Протокол потоковой передачи поддерживает два типа сеансов: события (прямые репортажи) и видео по требованию (VOD).

Защита содержания

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

Когда файл ключей перечислен в индексном файле, файл ключей содержит ключ шифра, который должен использоваться для дешифрования последующих медиа-файлов, перечисленных в индексном файле. В настоящее время HTTP Живая Потоковая передача поддерживает шифрование AES 128 с помощью ключей с 16 октетами. Формат файла ключей является упакованным массивом этих 16 октетов в двоичном формате.

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

Первый режим позволяет Вам указывать путь к существующему файлу ключей на диске. В этом режиме segmenter вставляет URL существующего файла ключей в индексном файле. Это шифрует все медиа-файлы с помощью этого ключа.

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

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

Можно служить файлам ключей с помощью или HTTP или HTTPS. Можно также принять решение защитить поставку файлов ключей с помощью собственной основанной на сеансе схемы аутентификации. Для получения дополнительной информации посмотрите Служащие Файлы ключей Надежно По HTTPS.

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

Кэширование и протоколы доставки

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

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

Потоковые альтернативы

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

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

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

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

Можно создать ряд потоковых альтернатив при помощи variantplaylistcreator инструмент и указание -generate-variant-playlist опция для любого mediafilesegmenter инструмент или mediastreamsegmenter инструмент (см. Загрузку Инструменты для подробных данных).

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

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

• Где возможно, закодируйте достаточно вариантов для обеспечения потока высшего качества через широкий диапазон скоростей соединения. Например, закодируйте варианты в 150 Кбит/с, 350 Кбит/с, 550 Кбит/с, 900 Кбит/с, 1 500 Кбит/с.

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

• Видео форматное соотношение на альтернативных потоках должно быть точно тем же, но альтернативы могут иметь различные пиксельные размерности, пока у них есть то же форматное соотношение. Например, две потоковых альтернативы с тем же 4:3 форматное соотношение могли иметь размерности 400 x 300 и 800 x 600.

• RESOLUTION поле в EXT-X-STREAM-INF должен быть включен, чтобы помочь клиенту выбрать надлежащий поток.

• Если Вы - разработчик приложения для iOS, можно запросить устройство пользователя, чтобы определить, является ли начальное соединение сотовой связью или WiFi, и выберите надлежащий основной индексный файл.

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

  150k поток для сотового различного списка воспроизведения рекомендуется.

  240k или 440k поток для списка воспроизведения варианта Wi-Fi рекомендуются.

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

Видео по сотовым сетям

При отправке видео в мобильное устройство, такое как iPhone или iPad Интернет-соединение клиента может переместиться в или от сотовой сети в любое время.

HTTP, который Живая Потоковая передача позволяет клиенту выбирать среди потока, чередуется динамично, когда сетевая пропускная способность изменяется, обеспечивая лучший поток, когда устройство перемещается между сотовой связью и соединениями WiFi, например, или между 3G и Торцовыми соединениями. Это - значительное преимущество перед прогрессивной загрузкой.

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

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

Хороший выбор для пиксельных размерностей, когда предназначение для соединений сотовой сети будет 400 x 224 для 16:9 содержание и 400 x 300 для 4:3 содержание (см. Подготовку Носителей для Поставки основанным на iOS Устройствам).

Требования для приложений

Если Ваше приложение поставляет видео по сотовым сетям, и видео превышает или продолжительность 10 минут или 5 МБ данных в пятиминутный период, Вы обязаны использовать HTTP Живая Потоковая передача. (Прогрессивная загрузка может использоваться для меньших клипов.)

Если Ваше приложение использует HTTP Живая Потоковая передача по сотовым сетям, Вы обязаны обеспечивать по крайней мере один поток в 64 Кбит/с, или более низкая пропускная способность (поток низкой пропускной способности может быть только для аудио или аудио с неподвижным изображением).

Эти требования применяются к приложениям для iOS, представленным для распределения в App Store для использования на продуктах Apple. Неподдерживаемые приложения могут быть отклонены или удалены, на усмотрение Apple.

Избыточные потоки

Если Ваш список воспроизведения содержит альтернативные потоки, они могут не только действовать в качестве пропускной способности или альтернатив устройства, но в качестве нейтрализаций отказа. Начиная с iOS 3.1, если клиент неспособен перезагрузить индексный файл для потока (вследствие 404 ошибок, например), клиент пытается переключиться на альтернативный поток.

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

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

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

#EXTM3U

#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000, RESOLUTION=720x480

http://ALPHA.mycompany.com/lo/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000, RESOLUTION=720x480

http://BETA.mycompany.com/lo/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=500000, RESOLUTION=1920x1080

http://ALPHA.mycompany.com/md/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=500000, RESOLUTION=1920x1080

http://BETA.mycompany.com/md/prog_index.m3u8

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

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

Добавление синхронизированных метаданных

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

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

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

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

При использовании инструментов Apple можно добавить синхронизированные метаданные путем указания файла метаданных в -F параметр командной строки или к потоку segmenter или к файлу segmenter. Указанный источник метаданных может быть файлом в формате ID3 или файле образа (JPEG или PNG). Метаданные указали, что этот путь автоматически вставляется в каждый участок среды.

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

Для добавления синхронизированных метаданных к прямой трансляции используйте id3taggenerator инструмент, с его выходным набором к потоку segmenter. Инструмент генерирует метаданные ID3 и передает их поток segmenter для включения в исходящий поток.

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

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

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

1. Во-первых, генерируйте выборки метаданных. Можно генерировать метаданные ID3 с помощью id3taggenerator инструмент командной строки, с выходным набором к файлу.

2. Затем, создайте файл макроса метаданных — текстовый файл, в который каждая строка содержит время для вставки метаданных, типа метаданных, и пути и имени файла файла метаданных.

   Например, следующий файл макроса метаданных вставил бы изображение в 1,2 секунды в поток, затем тег ID3 в 10 секунд:

   1.2 picture /meta/images/picture.jpg

   10 id3 /meta/id3/title.id3

3. Наконец, укажите файл макроса метаданных по имени при вызове медиа-файла segmenter, с помощью -M параметр командной строки.

Для дополнительных подробных данных посмотрите man страницы для mediastreamsegmenter, mediafilesegmenter, и id3taggenerator.

Добавление субтитров

HTTP Живая Потоковая передача поддерживает субтитры в потоках. При использовании потока segmenter необходимо добавить субтитры CEA-608 к транспортному потоку MPEG 2 (в основном потоке видеоданных), как указано в ATSC A/72. При использовании файла segmenter необходимо инкапсулировать носители в файле фильма в формате QuickTime и добавить дорожку субтитров ('clcp'). Если Вы пишете приложение, воспроизведение поддержки платформы AVFoundation субтитров.

Живая потоковая передача также поддерживает многократный подзаголовок и дорожки субтитров в Текстовых дорожках интернет-видео (WebVTT) формат. Выборка в Перечислении 2-1 показывает две дорожки субтитров в основном списке воспроизведения.

  Ведущий список воспроизведения перечисления 2-1 с многократными дорожками субтитров

#EXTM3U

#EXT-X-MEDIA:TYPE=CLOSED-CAPTIONS,GROUP-ID="cc",NAME="CC1",LANGUAGE="en",DEFAULT=YES,AUTOSELECT=YES,INSTREAM-ID="CC1"

#EXT-X-MEDIA:TYPE=CLOSED-CAPTIONS,GROUP-ID="cc",NAME="CC2",LANGUAGE="sp",AUTOSELECT=YES,INSTREAM-ID="CC2"

#EXT-X-STREAM-INF:BANDWIDTH=1000000,SUBTITLES="subs",CLOSED-CAPTIONS="cc"

x.m3u8

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

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

Для получения дополнительной информации о реализации WebVTT доступно в 2012 WWDC: Новые функции и возможности в HTTP Живая Потоковая передача и WebVTT: спецификация Формата Текстовых дорожек интернет-видео.

Подготовка Носителей для Поставки основанным на iOS Устройствам

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

Формат файла для файла segmenter может быть фильмом в формате QuickTime, видео MPEG 4 или аудио MP3, с помощью указанного кодирования.

Потоковым форматом для потока segmenter должен быть MPEG элементарные аудио-и видеопотоки, обернутые в транспортный поток MPEG 2 и использование следующего кодирования. Audio Technologies и Video Technologies перечисляют поддерживаемые форматы сжатия.

• Закодируйте видео с помощью сжатия H.264

  • Базовая линия H.264 3.0: Все устройства

  • Базовая линия H.264 3.1: iPhone 3G и позже, и iPod touch 2nd generation и позже.

  • H.264 Основной профиль 3.1: iPad (все версии), Apple TV 2 и позже, и iPhone 4 и позже.

  • H.264 Основной Профиль 4.0: Apple TV 3 и позже, iPad 2 и позже, и iPhone 4S и позже

  • H.264 Высокий Профиль 4.0: Apple TV 3 и позже, iPad 2 и позже, и iPhone 4S и позже.

  • H.264 Высокий Профиль 4.1: iPad 2 и позже и iPhone 4S и позже.

• Частота кадров 10 кадр/с рекомендуется для видеопотоков менее чем 200 Кбит/с. Для видеопотоков менее чем 300 Кбит/с рекомендуется частота кадров 12 - 15 кадр/с. Для всех других потоков рекомендуется частота кадров 29,97.

• Закодируйте аудио любым из следующего:

  • HE-AAC или AAC-LC, стерео

  • MP3 (Уровень 3 Аудио MPEG 1), стерео

• Дополнительно включайте аудиотрек AC 3 для Apple TV (или AirPlay к Apple TV), когда используется с ресивером с объемным звуком или TV, поддерживающим ввод AC 3.

• Минимальная частота дискретизации звука 22,05 кГц и скорость передачи звука 40 Кбит/с рекомендуются во всех случаях, и более высокие частоты дискретизации и скорости передачи строго мотивированы при потоковой передаче по Wi-Fi.

Демонстрационные потоки

Существует серия потоков HTTP, доступных для тестирования на сайте разработчика Apple. Эти примеры показывают надлежащее форматирование HTML для встраивания потоков, .M3U8 файлы для индексации потоков, и .ts файлы участка среды. К потокам можно получить доступ от HTTP Живые Ресурсы Потоковой передачи.