Развертывание HTTP живая потоковая передача
Для фактического развертывания HTTP Живая Потоковая передача необходимо создать или страницу HTML для браузеров или клиентское приложение для действия как получатель. Вам также нужно использование веб-сервера и способа или закодировать прямые трансляции транспортными потоками MPEG 2 или создать MP3 или MPEG 4 медиа-файла с H.264 и AAC, кодирующим от Вашего исходного материала.
Можно использовать предоставленные Apple инструменты, чтобы сегментировать потоки или медиа-файлы, и произвести индексные файлы и различные списки воспроизведения (см. Загрузку Инструменты).
Необходимо использовать предоставленный Apple блок проверки допустимости мультимедийного потока до обслуживания потоков, чтобы гарантировать, что они полностью совместимы с HTTP Живая Потоковая передача.
Можно хотеть зашифровать потоки, когда Вы, вероятно, также хотите служить файлам ключа шифрования надежно по HTTPS, так, чтобы только Ваши намеченные клиенты могли дешифровать их.
Создание СТРАНИЦЫ HTML
Самый простой способ распределить HTTP, Живые Потоковые медиа должны создать веб-страницу, включающую HTML5 <video> тег, с помощью .M3U8 файл списка воспроизведения как источник видеосигнала. Пример показан в Перечислении 3-1.
Перечисление 3-1 , Служащее HTTP Живая Потоковая передача в веб-странице
<html> |
<head> |
<title>HTTP Live Streaming Example</title> |
</head> |
<body> |
<video |
src="http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8" |
height="300" width="400" |
> |
</video> |
</body> |
</html> |
Для браузеров, не поддерживающих HTML5 video элемент или браузеры, не поддерживающие HTTP Живая Потоковая передача, можно включать код нейтрализации между <video> и </video> теги. Например, Вы могли отступить к прогрессивному фильму загрузки или потоку RTSP с помощью плагина QuickTime. Посмотрите Аудио Safari HTML5 и Видео Руководство для примеров.
Конфигурирование веб-сервера
HTTP Живая Потоковая передача может быть подан от обычного веб-сервера; никакая специальная конфигурация не необходима кроме соединения типов MIME файлов, подаваемых с их расширениями файла.
Сконфигурируйте следующие типы MIME для HTTP Живая Потоковая передача:
Расширение файла | Тип MIME |
|
|
|
|
Если Ваш веб-сервер ограничивается относительно типов MIME, можно служить файлам, заканчивающимся в .m3u с типом MIME audio/mpegURL для совместимости.
Индексные файлы могут быть долгими и могут часто повторно загружаться, но они - текстовые файлы и могут быть сжаты очень эффективно. Можно уменьшить сервер наверху путем включения на лету .gzip сжатие .M3U8 индексные файлы; HTTP Живой клиент Потоковой передачи автоматически разархивировал сжатые индексные файлы.
Сокращение времени жизни (TTL) оценивает за .M3U8 файлы могут также быть необходимы для достижения надлежащего поведения кэширования для нисходящих веб-кэшей, поскольку эти файлы часто перезаписываются во время прямых репортажей, и последняя версия должна быть загружена для каждого запроса. Сверьтесь со своим провайдером службы доставки контента для определенных рекомендаций. Для VOD индексный файл статичен и загружается только, как только, таким образом кэшируясь не фактор.
Проверка Ваших потоков
mediastreamvalidator инструмент является утилитой командной строки для проверки HTTP Живые потоки Потоковой передачи и серверы (см. Загрузку Инструменты для подробных данных о получении инструмента).
Блок проверки допустимости мультимедийного потока моделирует HTTP Живой сеанс Потоковой передачи и проверяет, что индексный файл и участки среды приспосабливают HTTP Живой спецификации Потоковой передачи. Это выполняет несколько проверок для обеспечения надежной потоковой передачи. Если какие-либо ошибки или проблемы найдены, подробный диагностический отчет выведен на экран.
Необходимо всегда выполнять блок проверки допустимости до обслуживания нового потока или альтернативного потокового набора.
Блок проверки допустимости мультимедийного потока показывает перечисление потоков, которые Вы обеспечиваете, сопровождаемый результатами синхронизации для каждого из тех потоков. (Может потребоваться несколько минут для вычисления фактической синхронизации.) Пример вывода блока проверки допустимости следует.
$ mediastreamvalidator -d iphone http://devimages.apple.com/iphone/samples/bipbop/gear3/prog_index.m3u8 |
mediastreamvalidator: Beta Version 1.1(130423) |
Validating http://devimages.apple.com/iphone/samples/bipbop/gear3/prog_index.m3u8 |
-------------------------------------------------------------------------------- |
http://devimages.apple.com/iphone/samples/bipbop/gear3/prog_index.m3u8 |
-------------------------------------------------------------------------------- |
Playlist Syntax: OK |
Segments: OK |
Average segment duration: 9.91 seconds |
Segment bitrate: Average: 509.56 kbits/sec, Max: 840.74 kbits/sec |
Average segment structural overhead: 97.49 kbits/sec (19.13 %) |
Для получения дополнительной информации читайте Объясненные Результаты Инструмента Блока проверки допустимости Мультимедийного потока.
Обслуживание файлов ключей надежно по HTTPS
Можно защитить носители путем шифрования его. Файл segmenter и поток segmenter и имеют параметры шифрования, и можно сказать им периодически изменять ключ шифрования. То, с кем Вы совместно используете ключи, ваше дело.
Файлы ключей требуют, чтобы вектор инициализации (IV) декодировал зашифрованные носители. IVs может периодически изменяться, как ключи могут. Текущие рекомендации для шифрования носителей при минимизации наверху состоят в том, чтобы изменять ключ каждые 3-4 часа и изменять IV после каждых 50 Мбит данных.
Даже с ограниченным доступом к ключам, однако, для соглядатая возможно получить копии файлов ключей, если они отправляются по HTTP. Одно решение этой проблемы состоит в том, чтобы отправить ключи надежно по HTTPS.
Прежде чем Вы попытаетесь служить файлам ключей по HTTPS, необходимо сделать тест, служащий ключам от внутреннего веб-сервера по HTTP. Это позволяет Вам отлаживать свою установку прежде, чем добавить HTTPS к соединению. Как только у Вас есть известная рабочая система, Вы готовы переключиться на HTTPS.
Существует три условия, которым необходимо удовлетворить для использования HTTPS для обслуживания ключей для HTTP Живая Потоковая передача:
Необходимо установить сертификат SSL, подписанный доверяемыми полномочиями на сервере HTTPS.
Домен аутентификации для файлов ключей должен совпасть с доменом аутентификации для первого файла списка воспроизведения. Самый простой способ выполнить это состоит в том, чтобы служить различному файлу списка воспроизведения от сервера HTTPS — различный файл списка воспроизведения загружается только один раз, таким образом, это не должно вызывать чрезмерную нагрузку. Другие файлы списка воспроизведения могут быть поданы с помощью HTTP.
Необходимо или инициировать собственное диалоговое окно для пользователя для аутентификации, или необходимо сохранить учетные данные на клиентском устройстве — HTTP, Живая Потоковая передача не обеспечивает пользовательские диалоговые окна для аутентификации. Если Вы пишете свое собственное клиентское приложение, можно сохранить учетные данные, или основанный на cookie или обзор HTTP, базируемый, и предоставить учетные данные в
didReceiveAuthenticationChallengeобратный вызов (см. Используя NSURLConnection и Запросы аутентификации и Проверку Цепочки TLS для подробных данных). Учетные данные, которые Вы предоставляете, кэшируются и снова используются медиапроигрывателем.
Если Вашему серверу HTTPS не подписывали сертификат SSL доверяемые полномочия, можно все еще протестировать установку путем создания самоподписанных полномочий сертификата SSL и листового сертификата для сервера. Присоедините сертификат для центра сертификации на адрес электронной почты, отправьте его в устройство, которое Вы хотите использовать в качестве Живого клиента Потоковой передачи и касания на присоединении в Почте, чтобы заставить устройство доверять серверу.
Формат шифрования демонстрационного уровня документируется в Формат поточного шифрования MPEG 2 для HTTP Живая Потоковая передача.