Создание идеальных с технической точки зрения приложений, как правило, является чрезвычайно сложной и трудоемкой задачей. При этом полезная информация зачастую рассеяна по множеству источников. Это относится, в том числе, к разработке видеоприложений для iOS. В данной статье собрана наиболее важная и полезная информация, позволяющая качественно использовать весь спектр возможностей HTTP Live Streaming, а также список первоисточников. Данные материалы будут полезны всем читателям, заинтересованным в создании качественных и удобных для пользователей видеосервисов.
Усиление удобства и интерактивности видеосервисов достигается за счет быстрого запуска и перемотки, а также отсутствия буферизаций. Для достижения наилучшего результата предлагается следующий набор действий.
- Старт с низкого качества видео. Для старта видео требуется не менее одного чанка. Соответственно, чем меньше размер одного чанка, тем быстрее запустится видео. Уменьшение битрейта стартового потока и уменьшение длительности чанка приводит к ускорению запуска видео. Мы рекомендуем длительность чанка 4-8 секунд и стартовый битрейт 200-300 Кбит/с. Таким образом, для начала воспроизведения видео пользователю потребуется загрузить максимум 300 кбайт.
- Оптимизация списков воспроизведения. Списки воспроизведения могут занимать существенную часть в общем потоке данных, особенно при небольших размерах чанков и длительном контенте (несколько часов). В большинстве случаев при передаче списков воспроизведения видеоплееру рекомендуется их архивировать.
- Ключевые кадры. Желательно наличие по крайней мере одного IDR-кадра на сегмент — предпочтительно, в самом начале сегмента. Кроме того, при передаче видео в сотовых сетях рекомендуется создавать ключевые кадры не реже одного раза в 3 секунды.
- TS Оверхед. HTTP LS использует MPEG TS в качестве контейнера, поэтому очень важно минимизировать оверхед TS (должен быть меньше 10% даже при низком качестве видео). В данном случае стоит проводить замеры реальных битрейтов по дампам трафика и оптимизировать используемые упаковщики (сегментеры).
- Параметр Target duration в списке воспроизведения. Данный параметр влияет на время запуска, но Apple рекомендует устанавливать его в 10 секунд, потому что при более низких значениях повышается вероятность буферизации, особенно в сотовых сетях с большими задержками. Также не рекомендуется создавать сегменты, длительность которых превышает 20 секунд.
- Динамический битрейт. Встроенный в iOS механизм адаптивного стриминга работает оптимально при точно указанных битрейтах в вариантном плейлисте (с учетом трафика самого плейлиста). При этом для потоков с изменяющимся битрейтом нужно указывать значение ближе к максимальному. В противном случае возможны неверные решения о смене текущего видео потока. Соседние битрейты должны отличаться по скорости в 1,5 — 2 раза.
- Потоки «audio only». Аудиокодек HE-AAC существенно более эффективен и поддерживается большинством устройств. Доставку каналов audio only рекомендуется реализовывать при помощи MPEG Elementary Stream, а не MPEG Transport Stream (существенно меньший оверхед).
В ходе разработки видеоплеера вы можете получить полезную информацию из журнала HTTP Live Streaming (accessLog). Он содержит данные о том, как происходило автоматическое переключение, какие битрейты использовались и т.п. Подробности о доступной в логе информации . Основываясь на этих данных, вы сможете собрать данные видеоаналитики по своим пользователям.
Дополнительные рекомендации
В случае онлайн-трансляций видео буферизации возможны также при задержках в CDN, а также в тех случаях, когда время обновления плейлиста слишком маленькое и сервер не успевает вовремя генерить сегменты. Для оптимизации механизма перемотки рекомендуется использовать нецелые (фактические) значения длительности сегментов: в противном случае может накапливаться ошибка.
Если ваше приложение предполагает использование на разных устройствах, в списке можно указать различное качество видео при разном разрешении экрана. Таким образом вы сможете выдавать разное видео на iPad с дисплеем Retina и на сравнительно старый iPhone.
Протокол HTTP Live Streaming также предусматривает механизмы обеспечения отказоустойчивости (указание резервных источников видео). Эта возможность может быть полезна для повышения надежности ваших сервисов.
Источники знаний
Краткий список материалов по использованию HTTP Live Streaming в видеоприложениях:
HTTP Live Streaming draft
HTTP Live Streaming Frequently Asked Questions
Best Practices for HLS
Напоследок стоит отметить, что для зарегистрированных разработчиков Mac/iOS/Safari доступны бесплатные технические видео сессии с WWDC 2012, где также много полезной информации, в частности — по работе с видео и использованию HTTP Live Streaming.
Обработку, хранение и передачу видео для своего онлайн-проекта, а не использовать сайты вроде YouTube, он неизбежно приходит к вопросу о том, какой протокол передачи использовать для трансляции видео на устройства пользователей. Выбор невелик, т.к. есть ряд отраслевых стандартов, которые поддерживают те или иные устройства. Кроме того, выбор протокола во многом зависит от «класса» видео - живая трансляция или видео-по-запросу. От выбора протокола также зависит и выбор медиа-сервера, который будет двигателем вашей медиа-машины: будете ли ставить несколько разнородных серверов или построите сеть доставки на одном решении? Поэтому нужно взвесить всё и принимать решение исходя из критериев вашего бизнеса.
В общем, получается уравнение со многими неизвестными. Здесь немаловажна динамика процесса - а куда вообще идёт индустрия? Вдруг я вложусь в поддержку технологии, а она загнётся через год, ведь такое уже бывало. Или поставлю на модную технологию, а её никто не поддерживает?
Мы решили оценить, как менялась доля разных протоколов с течением времени - посмотреть в динамике весь процесс. Данные взяли за последний год.
Исходные данные
Для начала - кто мы такие, чтобы судить о долях рынка? Мы - разработчики веб-сервиса отчетности для медиа-серверов . На рынке работаем четвертый год и к нам приходят компании с разными инфраструктурами, разным количеством серверов и разными потребностями. Получается неплохой слепок состояния отрасли.
Мы сделали небольшой отчет, где можно выбирать диапазон дат и получать данные с графиком по количеству просмотров видео через разные протоколы.
В отчете даются данные по серверам:
- Wowza Streaming Engine во всех версиях, начиная с 2.2 и до последних 4.х; бОльшая часть - 3.х.
- Nimble Streamer , работающий с HLS, Smooth, HDS и progressive download - это наша разработка.
- Windows Media Services - их буквально пару десятков, но они есть, и надо их учитывать
Отчет также периодически обновляется у нас в блоге, он доступен по соответствующему тегу .
Поехали
Отчет за июнь/июль 2014 выглядит примерно так. Из 1.4 миллиарда просмотров больше половины - это HLS. На втором месте - RTMP с четвертью просмотров. RTSP - примерно шестая часть. Остальные находятся в районе статистической погрешности.
Что было год назад за тот же период? Ситуация почти зеркальная. RTMP - почти две трети, RTSP и HLS делят второе и третье места. Правда, и база для измерений была меньше почти в 3 раза - «всего» 500 миллионов просмотров . Серверов в нашем сервисе тоже было поменьше, конечно.
Пройдемся между этими двумя точками.
Итак, июнь - август 2014 года, 3 месяца лета. 800 миллионов просмотров , но доли такие же, август изменений не привнёс.
Сентябрь - ноябрь 2013. Начался новый сезон, HLS начал отъедать долю RTMP. Всего 1.1 миллиарда просмотров , у RTMP примерно половина от общего числа, HLS - четверть.
Декабрь 2013 - февраль 2014. 1.4 миллиарда просмотров , из них на HLS приходится уже больше 40%. RTMP и RTMP делят второе и третье место с четвертью доли. Олимпиада в Сочи дала прирост числа просмотров и одновременно заставила провайдеров вспомнить обо всех клиентах со всеми их экзотическими или старыми девайсами, которые понимают только RTSP - отсюда и скачок этого протокола.
Для организации онлайн трансляций в реальном режиме времени, видео по запросу (vod), а также для осуществления записи видео-потоков можно использовать nginx вместе с модулем nginx-rtmp-module.
Медиа серверы
На сегодняшний день существуют несколько популярных медиа серверов, о которых вы можете подробнее почитать в одной из . Медиа серверы необходимы для создания онлайн трансляций в реальном режиме времени.
Существуют как платные, так и бесплатные медиа серверы, включающие в себя разные функции. Сегодня мы поговорим об одном бесплатном и довольно неплохом решении.
Ngnix-rtmp
Базовый функционал медиа сервера, также можно реализовать с помощью бесплатного программного обеспечения — модуля Ngnix-rtmp-module, который на данный момент поддерживает такие потоковые протоколы как RTMP и HLS.
Таким образом, с помощью Ngnix-rtmp (веб сервер Ngnix + модуль Ngnix-rtmp-module), можно организовать вещание по RTMP и HLS на устройства пользователей. Сводную таблицу протоколов и устройств, которые их поддерживают, можно посмотреть в статье . Также в одной из будущих своих статей я планирую сделать сравнительную таблицу функционала модуля Ngnix-rtmp-module и других медиа серверов.
Онлайн трансляция по протоколу HLS
Сегодня мы рассмотрим, как с помощью модуля Nginx-rtmp-module организовать простейшую трансляцию с адаптивным битрейтом по протоколу HLS. В первую очередь нам необходимо скачать исходные коды веб-сервера Nginx с официального сайта. Все команды, представленные ниже исполнялись в Linux.
- wget http://nginx.org/download/nginx-1.4.1.tar.gz
Извлечь файлы из архива.
- tar -zxvf nginx-1.4.1.tar.gz
Скачать zip архив с исходными файлами модуля nginx-rtmp-module и извлечь файлы из архива.
- wget https://github.com/arut/nginx-rtmp-module/archive/master.zip
Теперь нам необходимо скомпилировать nginx с модулем nginx-rtmp-module , для этого при конфигурации nginx нужно указать в опции —add-module расположение исходных файлов nginx-rtmp-module , а также необходимо указать дополнительную опцию with-http_ssl_module .
./configure —add-module=/home/nginx/nginx-rtmp-module-master —with-http_ssl_module
make install
- Если все прошло без ошибок, можно приступать к настройке сервера. По умолчанию сервер устанавливается в директорию /usr/local/nginx . Конфигурационный файл сервера nginx.conf, находится в директории /usr/local/nginx/conf . Рассмотрим подробнее секцию rtmp:server конфигурационного файла. Параметр listen указывает порт на котором сервер будет принимать rtmp запросы.
- Далее мы открываем секцию для настройки приложения testlive. Здесь мы указываем, что у нас live-поток - параметр live on, включаем поддержку протокола hls для этого приложения – параметр hls on.
- С помощью параметра hls_path мы задаем директорию в которой буду располагаться чанки (кусочки) потока. Для того чтобы чанки (кусочки) для каждого видео потока располагались в отдельной директории необходимо подключить директиву hls_nested on .
- Далее с помощью параметра allow publish мы разрешаем публиковать потоки с своего компьютера, а с помощью параметра deny publish all запрещаем всем остальным публиковать видео.
- Теперь рассмотрим секцию http:server . В параметре listen необходимо указать на коком порту сервер будет принимать http запросы. Мы указываем порт 8080. И из примера конфигурационного файла перенести секцию http:server:location /hls . Посмотреть более подробную информацию по всем директивам конфигурационного файла можно по адресу: https://github.com/arut/nginx-rtmp-module/wiki/Directives.
- Настало время запустить сервер. Для этого необходимо перейти в директорию /usr/local/nginx/bin и выполнить команду ./nginx .
Теперь рассмотрим один пример. Мы отправляем на сервер три видео-потока:
- test1 с битрейтом 256 кбит/с,
- test2 с битрейтом 512 кбит/с,
- test3 с битрейтом 1024 кбит/с.
Наша задача, чтобы клиент, использующий протокол HLS (устройства: Mac, iPad, iPhone) мог динамически переключаться между потоками, в зависимости от качества Интернет соединения. Для этого нам необходимо в директории /usr/local/nginx/html создать файл с расширением m3u8 , например playlist.m3u8 , со следующим содержимым:
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=256000,RESOLUTION=640×480
hls/test1/index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=512000,RESOLUTION=640×480
hls/test2/index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1024000,RESOLUTION=640×480
hls/test3/index.m3u8
Просмотр трансляции
Для просмотра видео-потоков необходимо в веб-страницу сайта встроить следующий код.
- ip-адрес вашего nginx сервера.
[название плейлиста] - название файла, созданного в предыдущем пункте (playlist.m3u8).
Ниже, приведен пример простейшего конфигурационного файла nginx.conf.
worker_processes 1;
server {
listen 1935;
application testlive {
live on;
hls on;
hls_path /tmp/hls;
hls_nested on;
allow publish 10.10.146.148;
deny publish all;
server {
listen 8080;
server_name rtmp_test;
charset utf-8;
location / {
root html;
index index.html index.htm;
location /hls {
types {
application/vnd.apple.mpegurl m3u8;
alias /tmp/hls;
Заключение
Эта статья была написана и опубликована совместно c моим коллегой Евгением Петровым. Мы используем данный модуль (Ngnix-rtmp) в разных проектах. Если у кого-то появятся вопросы по Ngnix-rtmp, Wowza серверу, пишите. Если вам нужно что-то настроить или получить консультацию по медиа-серверам и мультимедийным системам, также можете обращаться ко мне и нашей команде через .
Как показала практика, лучшим транспортом для видео по сравнению с RTMP, является HLS. Причины этого:
Очень простое проксирование, с кэшированием через nginx. На первое месте, потому что, камера, как устройство не может обслуживать, как правило, одновременно более 10 подключений. В этом смысле гарантированное проксирование RTMP потоков, возможно только через платные решения, и требует больших мощностей. Не нужно специального серверного программного обеспечения.
Упрощение всей серверной инфраструктуры. В силу идеи видео отдается по кусочкам, через 80 порт по http. За отдачу статики может отвечать сам nginx. Отдача статики (видео кусочки по 50кБ) задача для nginx очень легкая.
Поскольку количество кусочков постоянно, старые удаляются, новые добавляются, жесткий диск никогда не переполнится.
Распространенность больше, чем у RTMP. HLS с кодировкой видео H.264 поддерживается iOS и работает без лишних действий. По данным на 1 июля 2014 с хабры подключений потокового видео с транспортом HLS - 55%, RTMP - 26%, RTSP - 15% и MPEG-DASH менее 1%.
Поддержка большинством мобильных устройств, дестктопов, планшетных компьютеров прямо из браузера.
Гораздо проще, чем вещание в RTSP в принципе. Так как нет таких процедур, как push (публикация потока) или pull (получение потока).
Гораздо более http friendly формат.
Недостатки следующие:
Все таки не все устройства поддреживают этот формат. Android версий меньше 4.2 официально не поддерживает кодек H.264 и транспорт, но на Android вместо браузера для просмотра можно использовать стороннее приложение - например MX Player
Все зависит от камеры. Если камера глючная, например Dlink DCS-3010, то вся система будет работать из рук вон плохо (ffmpeg постоянно отваливается). Например камеры AXIS M1011-W, HIKVISION DS-2CD2412F-IW работают в такой связке хорошо (до месяца без нареканий (дольше просто не тестировал)). Так же большое значение имеет прокладка кабеля. В этом смысле будем рассматривать идеальный вариант.
Что такое транспорт HLS
Видео поток в кодировке h.264 (Кстати: profile baseline понимают Android устройства), делится на кусочки с расширением *.ts , например по 5 секунд, создается плэйлист в live.m3u8 , с последовательным описанием этих кусочков. Предварительно определется длина плэйлиста например 10 кусков. Когда появляется 11 кусочек видео, 1 кусок видео удаляется, плейлист пересоздается. Более подробно можно посмотреть на сайте разработчика .
Для работы системы настроим изображение с камер так, как мы хотим видеть на сайте, формат картинки и качество изображения. На сервере перекодировать не будем. Камера для того и придумана чтобы отдавать такое изображение какое нужно. В камерах обычно есть несколько профилей. Можно настроить один профиль для H.264, для HLS, а второй c MPEG4 для MPEG-DASH. Так же можно настроить различное качество, для широкого и узкого канала интернет. Думайте сами - решайте сами.
Важно! Камера должна на выходе иметь изображение, которое не нужно перекодировать.
Структурная схема для высокой нагрузки
Камера(rtsp) ----->
-----> одно подключение FFmpeg(rtsp->hls) -> Nginx(nginx-rtmp-module) ----->
-----> одно подключение к промежуточному proxy nginx c большим кэшем =====>
=====> много клиентов JWPlayer(hls)
Наш сервер подключается с помощью ffmpeg к камере и регистрируется в приложении nginx hls. nginx создает кусочки и плэйлист в определенной директории. Далее отдает эти кусочки на прокси сервер. Клиенты подключаются к прокси серверу с помощью JWPlayer .
Настройка nginx application
Соберем nginx с nginx-rtmp-module. Эта процедура детально описывается в статье .
Допустим у нас несколько камер, разделим их по порядковому номеру. Опишу конфигурацию nginx для 2 камер. Статические изображения кэшируем на 5 минут в локальном кэше, если картинка не грузится в течении 5 секунд отдаем статическую заставку.
# nano /etc/nginx/nginx.conf
Отредактируем конфигурацию nginx
user www - data ; worker_processes auto ; pid / run / nginx . pid ; error_log / var / log / nginx / nginx_error . log debug ; env PATH ; events { # multi_accept on ; } http { access_log / var / log / nginx / access . log ; error_log / var / log / nginx / error . log ; include mime . types ; default_type application / octet - stream ; sendfile on ; keepalive_timeout 65 ; proxy_cache_path / var / www / cache / local levels = 1 : 2 keys_zone = nginx_local_cache : 1 m inactive = 30 m max_size = 512 M ; proxy_temp_path / var / www / cache / local / tmp ; server { listen 80 ; # rtmp stat location / stat { rtmp_stat all ; rtmp_stat_stylesheet stat . xsl ; } location / stat . xsl { # you can move stat . xsl to a different location root / etc / nginx ; } location / { rtmp_control all ; } error_page 500 502 503 504 / 50 x . html ; location = / 50 x . html { root html ; } include cameras_http_locations . conf ; } } rtmp { access_log / var / log / nginx / rtmp_access . log ; server { listen 1935 ; ping 30 s ; notify_method get ; include cameras_rtmp_applications . conf ; } }
Создадим путь для кэш # mkdir /var/www/cache/local Поправим права для кэш:
# chmod -R 755 /var/www/cache/local # chown -R www-data:www-data /var/www/cache/local`
Создадим http locations для камер:
# nano cameras_http_locations.conf
types { application / vnd . apple . mpegurl m3u8 ; video / mp2t ts ; } # отдаем изображение с камеры 1 - /1/img/ # для всех камер разные, т.к. ip адреса камер разные "http://192.168.0.2/GetImage.cgi?CH=1" # отдаем изображение с камеры 2 - /2/img/ location / 1 / img / { proxy_cache nginx_local_cache ; proxy_cache_key $ request_uri ; expires 1 m ; # кэшируем на 1 минуту add_header Cache - Control public ; # для кэширования на проксе proxy_ignore_headers Cache - Control ; # для удаления заголовков с камеры proxy_pass "http://192.168.0.3/GetImage.cgi?CH=1" ; proxy_set_header Authorization "Basic " ; error_page 502 504 404 @ fallback_img ; } # отдаем плэйлист - /1/hls/live.m3u8 или /3/hls/live.m3u8 # плэйлист кэшируется 10 секунд на проксе location ~* / hls / . * \ . m3u8 $ { rewrite "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break ; # переделываем запрос / 1 / hls / в / hls - 1 / root / tmp / ; expires 10 s ; add_header Cache - Control public ; } # отдаем кусочек видео с камер - /1/hls/live-12345678.ts или /2/hls/live-12345678.ts # кэширование на локальном компьютере не требуется # кусочек кэшируется 3 минуты на проксе location ~* / hls / . * \ . ts $ { rewrite "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break ; root / tmp / ; expires 3 m ; add_header Cache - Control public ; } # именованный location если картинки нет location @ fallback_img { rewrite (. + ) / fallback . jpg break ; root / etc / nginx / ; }
Создадим файл hls конфигурации сервера rtmp с applications для наших камер:
# nano cameras_rtmp_applications.conf
chunk_size 4000 ; application hls_1 { live on ; sync 10 ms ; exec_static ffmpeg - i rtsp : //admin:[email protected]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_1/live 2>>/var/log/nginx/ffmpeg_1.log; hls on ; hls_path / tmp / hls - 1 / ; # путь хранения кусочков на сервере hls_fragment_naming timestamp ; # использовать timestamp для именования кусочков } application hls_2 { live on ; sync 10 ms ; exec_static ffmpeg - i rtsp : //admin:[email protected]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_2/live 2>>/var/log/nginx/ffmpeg_2.log; hls on ; hls_path / tmp / hls - 2 / ; hls_fragment_naming timestamp ; }
Содержимое директории /tmp/hls-1/
$ ls / tmp / hls - 1 / live - 10458360. ts live - 13292010. ts live - 16129440. ts live - 18963270. ts live - 10930050. ts live - 13767390. ts live - 16602660. ts live - 19435050. ts live - 11405250. ts live - 14239260. ts live - 17072820. ts live . m3u8 live - 11878560. ts live - 14710860. ts live - 17544960. ts live - 12348630. ts live - 15182550. ts live - 18020160. ts live - 12821760. ts live - 15658740. ts live - 18492750. ts
Пример файла live.m3u8
#EXTM3U #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:35 #EXT-X-TARGETDURATION:5 #EXTINF:5.224, live - 16602660. ts #EXTINF:5.246, live - 17072820. ts #EXTINF:5.280, live - 17544960. ts #EXTINF:5.251, live - 18020160. ts #EXTINF:5.228, live - 18492750. ts #EXTINF:5.242, live - 18963270. ts
Решение проблемы с отваливающимися камерами
Самое правильное решение, поменять глючную камеру. Это помогает в 90% случаев. Если нет возможности и нужно как то жить дальше, то поможет следующее решение.
Это решение состоит из двух - взаимодополняющих:
Запускать отдельный процесс nginx на каждую камеру и общий процесс по отдаче статики. То есть для двух камер написать отдельные конфиги с rtmp серверами и один общий с http. Тогда глючная камера не будет влиять на общий процесс.
Если поток с камеры нарушается в результате ее глючности (перегрева, плохой прокладки витухи, недостаточное питание по PoE и т.п.), то камера отвалится, дочерний процесс ffmpeg будет отбраковывать пакеты и nginx перестанет писать кусочки видео. А когда процесс ffmpeg завершится, nginx удалит все файлы из директории с кусочками. Этот момент очистки папки мы вычисляем по cron и рестартим необходимый процесс nginx.
В для каждой камеры создается в /etc/init.d/ создается исполняемый скрипт, копия nginx , c именем camera_1 и camera_2
# cp /etc/init.d/nginx /etc/init.d/camera_1 # cp /etc/init.d/nginx /etc/init.d/camera_2 # chmod +x /etc/init.d/camera_1 # chmod +x /etc/init.d/camera_2
Редактируем скрипт запуска nginx.
nano / etc / init . d / nginx
Меняем переменную DAEMON_OPTS . Основной демон nginx будет отдавать всю статику. А так же будет запускать и останавливать демоны отвечающие за камеры./ init . d / camera_1 stop fi if [ - f "/etc/init.d/camera_2" ]; then / etc / init . d / camera_2 stop fi
Добавляем в функцию do_reload:
# reload cameras if [ - f "/etc/init.d/camera_1" ]; then / etc / init . d / camera_1 reload fi if [ - f "/etc/init.d/camera_2" ]; then / etc / init . d / camera_2 reload fi
Редактируем скрипт запуска nginx для камеры 1 camera_1 и для камеры 2 camera_2 по примеру.
# nano /etc/init.d/camera_1
Меняем переменные DAEMON_OPTS и DESC
DESC = "camera_1 for CAMERA-1" DAEMON_OPTS = "-c /etc/nginx/nginx_1.conf"
Редактируем скрипт запуска nginx для камеры 2 camera_2 по примеру.
В /etc/nginx/nginx_0.conf с http locations я пишу волшебные строки:
# DIR-PROCESS-NAME /tmp/hls-1/ camera_1 # DIR-PROCESS-NAME /tmp/hls-2/ camera_2
В них указано через пробел искомое слово DIR-PROCESS-NAME директория и наименование процесса который нужно перезагрузить.
Проверка:
# service nginx start # service camera_1 restart * Restarting camera_1 for CAMERA - 1 configuration nginx # service camera_2 restart * Restarting camera_2 for CAMERA - 2 configuration nginx
Скрипт который перезагружает камеры. Он проходится по папкам с кусочками, ищет, где нет файлов *.m3u8 . Если в папке нет файлов, ищет соответствующий демон по конфигу основного демона, по строчке DIR-PROCESS-NAME . Перезагружает его.
# nano /script/cameras_reloader.sh
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | #!/bin/bash PATH = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin mask = "*.m3u8" dir = "/tmp/hls-*" function find_process(){ process_str = $(cat /etc/nginx/nginx_0.conf | grep "# DIR-PROCESS-NAME" | grep $1 | cut -d" " -f4) echo $process_str } for hls_dir in $dir ; do find_result = $(find $hls_dir -name $mask -type f) if [ -z $find_result ] ; then process = $(find_process $hls_dir ) service $process restart fi done sleep 15s |
Сравнение HLS с MPEG-DASH
MPEG-DASH это аналог HLS созданный компанией Google, в качестве транспорта для MPEG-4. Этот транспорт малораспространен и практически не поддерживается. Его идеалогия такая же, разбить поток на кусочки, только кусочков больше, отдельные куски для видео, отдельные для аудио. В nginx-rtmp-module этот формат настраивается аналогично HLS.
Пробуйте, копируйте, дерзайте!
Если статья была вам полезна просьба щелкнуть по рекламе. Спасибо!
