Останні кілька років у світі цифрового мовлення відбулися великі зміни. Flash – технологія доставки контенту через інтернет, розроблена Adobe, стрімко скорочує свою присутність. А її місце займають протоколи подібні до HLS.
HTML5 та HLS створені на відкритому коді, їх можна змінювати як завгодно та використовувати безкоштовно. Також вони більш безпечні, надійні та швидкі ніж попередники. У статті постараємося розкрити поняття онлайн мовлення, дамо опис стрімінгових протоколів та рекомендації щодо використання HLS.
Що таке HLS
HLS розшифровується як HTTP Live Streaming – протокол потокової передачі медіа даних через інтернет. HLS нарізує відео контент у форматі MP4 на короткі 10 секундні блоки, чанки. Ці короткі фрагменти доставляються HTTP, що робить протокол сумісним з більшістю пристроїв і фаєрволів.
HLS забезпечує насамперед відмінну якість онлайн трансляцій. Але потрібно враховувати, що затримка при онлайн мовленні складає 15-30 секунд. На серверній частині автор трансляції може призначити кодування потоку в кілька якостей. Потім плеєр динамічно запитує оптимальну якість, виходячи з ширини інтернет каналу в конкретний момент. Відповідно, якість фрагментів може відрізнятися.
Наприклад, мобільний телефон програє відео в HD якості, а хвилиною пізніше глядач потрапляє до зони поганого прийому. Коли плеєр виявляє зниження якості зв'язку, він запитує відео меншої якості. Таким чином знижується буферизація, зависання та інші проблеми.
Історія створення HLS
Спочатку HLS був запущений компанією Apple влітку 2009 року разом з IPhone 3. Попередні моделі IPHone зазнавали проблем з онлайн мовленням, через те, що іноді перемикалися між Wi-Fi мережами і мобільною передачею даних.
Перед виходом HLS, головним стрімінговим медіа протоколом Apple був Quicktime Streaming Server. Хороший сервіс, але оскільки він використовував нестандартні порти передачі даних, його RTSP протокол періодично блокувався файерволами. У поєднанні з повільним інтернетом це призвело до відмови від цього протоколу. Але уроки, отримані при його реалізації, стали в нагоді в розробці HLS. Технічний бік
HLS потік створюється на льоту і зберігається на сервері HTTP. Відеофайли, як згадали вище, поділяються на короткі фрагменти з розширенням. ts – MPEG2 Transport Stream.
HTTP сервер також створює плейлист файл з розширенням. M3U8 (також званий маніфестом), який служить для індексування всіх відео чанків. Цей файл відтворення вказує на додаткові індексні файли для кожного з існуючих якостей мовлення. Навіть якщо ви вирішите вести мовлення, використовуючи одну якість, «маніфест» все одно буде створено.
Плеєр користувача повинен розпізнати погіршення або покращення швидкості передачі даних в Інтернеті. Коли така подія відбувається, плеєр звертається до файлу-маніфесту, щоб визначити на яку якість відео переключитися. Після цього програвач запитує індексний файл для конкретної якості, щоб завантажити фрагмент відео, на якому зупинився глядач. Весь цей процес непомітний для користувача. Протокол HLS також підтримує приховані субтитри,
Огляд стрімінгових протоколів
Кожен із створених раніше протоколів був реалізацією будь-якої інновації в медіа стрімінгу. Були й «війни форматів», як HD-DVD із Blu-Ray та протистояння Betamax із VHS. HLS лідер онлайн мовлення, але так було не завжди і не факт, що збережеться у майбутньому.
RTMP або Real-Time Messaging Protocol, протокол потокової передачі даних у реальному часі. Був створений Macromedia в середині 2000 року для доставки аудіо та відео контенту. Часто його називають просто Flash. Пізніше Macromedia поєдналося з Adobe Inc, який продовжує розвивати RTMP як напіввідкритий протокол.
Протягом минулого десятиліття RTMP був основним способом мовлення через Інтернет. Тільки з появою HLS його частка почала зменшуватися. На сьогоднішній день більшість онлайн-відео платформ працюють з вхідним RTMP потоком. Іншими словами, ви мовите в RTMP, який, потім, онлайн відео платформа кодує HLS і доставляє кінцевим глядачам. Щоправда, багато операторів CDN починають відмовлятися від підтримки RTMP – пруф
Протокол для стримінгу наступного покоління, розроблений Adobe, називається HDS - HTTP Dynamic Streaming. Він сумісний з плагіном для програвання Flash, але частота його використання сильно поступається поширеному HLS.
Для пристроїв та браузерів, які підтримують Flash, HDS буде найкращим вибором. Він дає мінімальну затримку під час мовлення, як і HLS поділяє медіа файли невеликі фрагменти, підтримує шифрування та DRM.
Microsoft Smooth Streaming
Microsoft створив свій протокол онлайн-мовлення, Microsoft Smooth Streaming. MSS також використовує адаптивний бітрейт, щоб доставляти контент у найкращій можливій якості. Мовлення з адаптивним бітрейтом було представлено у 2008 році. За допомогою MSS віщали Літні Олімпійські Ігри 2008 року. Основним користувачем цього типу мовлення є платформа XBox One. При цьому, MSS є один з найменш популярних протоколів сьогодні.
MPEG-DASH
Однією з останніх значимих рішень у сфері стрімінгових протоколів є MPEG-DASH, де DASH означає Dynamic Adaptive Streaming over HTTP, Динамічне Адаптивне Мовлення через HTTP. Перевага MPEG-DASH у тому, що його визнано єдиним міжнародним стандартом мовлення медіа через НТТР. На даний момент він ще не широко поширений і далеко не всі компанії мовлення підтримують його. Але, на загальну думку, за кілька років саме цей стандарт стане найпопулярнішим протоколом мовлення.
MPEG-DASH не залежить від виду кодека, ви можете використовувати будь-який з них для пересилання медіа за допомогою цього протоколу – Н.264, HEVC/H.265, VP10
Коли ж використовувати HLS для онлайн мовлення
Ми рекомендуємо використовувати HLS постійно. Це найсучасніший і найширше підтримуваний протокол медіа стрімінгу. Без нього не обійтися, якщо ви хочете вести мовлення на мобільні пристрої. Нативна підтримка HTML5 плеєра і, звичайно ж, адаптивний бітрейт забезпечують оптимальну якість переглядів.
Як показала практика, найкращим транспортом для відео в порівнянні з 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 з великим кешем =====>
=====> багато клієнтів JWPlayer(hls)
Наш сервер підключається за допомогою ffmpeg до камери та реєструється у додатку nginx hls. nginx створює шматочки та плейлист у певній директорії. Далі віддає ці шматочки на проксі-сервер. Клієнти підключаються до проксі сервера за допомогою JWPlayer.
Налаштування nginx application
Зберемо nginx із nginx-rtmp-module. Ця процедура детально описується у статті.
Допустимо у нас кілька камер, розділимо їх за порядковим номером. Опишу конфігурацію nginx для двох камер. Статичні зображення кешуємо на 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; ; proxy_cache_path / var / www / cache / local levels = 1 : 2 keys_zone = nginx_local_cache : 1 m inactive = 30 m max_size = 512 M ; location / stat ( rtmp_stat all ; rtmp_stat_stylesheet stat . xsl ; ) location / stat . 50 x .html ; location = 50 x . html ( root html ) 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 "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 - 0 6 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. ts1 live 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. :5.280, live - 17544960. ts #EXTINF:5.251, live - 18020160. ts #EXTINF:5.228, live - 18492750. ts #EXTINF:5.242, live - 1893
Вирішення проблеми з камерами, що відвалюються.
Найправильніше рішення, поміняти глючну камеру. Це допомагає у 90% випадків. Якщо немає можливості і потрібно якось жити далі, то допоможе наступне рішення.
Це рішення складається з двох – взаємодоповнюючих:
Запускати окремий процес nginx на кожну камеру та загальний процес віддачі статики. Тобто для двох камер написати окремі конфіги з серверами rtmp і один загальний з http. Тоді глючна камера не впливатиме на загальний процес.
Якщо потік з камери порушується внаслідок її глючності (перегріву, поганої прокладки витухи, недостатнє харчування по PoE тощо), то камера відвалиться, дочірній процес ffmpeg відбраковуватиме пакети і nginx перестане писати шматочки відео. А коли процес ffmpeg завершиться, nginx видалить усі файли з директорії зі шматочками. Цей момент очищення папки ми обчислюємо по cron та рестартуємо необхідний процес nginx.
Для кожної камери створюється в /etc/init.d/ створюється виконуваний скрипт, копія nginx , з іменем 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 для камери camera_2 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.
Пробуйте, копіюйте, дерзайте!
Якщо стаття була вам корисна, прохання клацнути по рекламі. Дякую!
Надання послуг IP-телебаченнячерез мережу Інтернет та локальні комп'ютерні мережі набуває все більш масових форм. На території країн СНД майже не залишилося великих провайдерів, що не транслюють відео через multicastу свої локальні мережі, тобто надають послугу IPTV. Але надання послуги телебачення за межами своєї локальної мережі пов'язане з деякими апаратними витратами та складністю забезпечення необхідної якості мовлення.
HTTP Live Streamingтакож відомий як HLS, є протоколом зв'язку реалізованим компанією Apple Його особливість у тому, що загальний потік розбивається на послідовність малих файлів завантаження, кожна завантаження завантажує один невеликий фрагмент транспортного потоку. Коли потік відтворюється, клієнт може вибрати один з декількох альтернативних потоків, що містять той же матеріал, записаних для різних швидкостей передачі даних, що дозволяє адаптуватися до доступної швидкості передачі даних. На початку сеансу потокової передачі завантажується розширений M3U (m3u8) плейлист, що містить метадані для різних підтоків, які доступні. Так як при запитах використовуються тільки стандартні операції HTTP, HTTP Live Streaming здатний обходити будь-який брандмауер або проксі-сервер, який пропускає стандартний HTTP-трафік, на відміну від протоколів UDP, таких як RTP.
HLS базується на HTTP. HLS також визначає стандартний механізм шифрування з використанням AES та спосіб розподілу ключа безпеки з використанням HTTPS або HTTP-куки, які разом забезпечують просту систему захисту авторських прав.
|
| Принцип роботи HLS |
Тепер з'ясуємо в чому ж переваги та недоліки цієї технології. Переваги безсумнівні та очевидні. Це насамперед адаптивність швидкості передачі даних до властивостей лінії та приймаючого пристрою, по-друге, вбудовані механізми захисту авторських прав. По-третє, не потрібний роутер з обмеженням ширини multicast-потоку WI_FI, що допомагало б уникнути поглинання всієї ширини каналу multicast-потоками, у разі мовлення IP-телебачення за допомогою multicast. Також не потрібний додатковий пристрій з функцією UDP-proxyдля конвертації multicast-потоку в HTTP, що часто потрібно для мобільних пристроїв, хоча позначається на апаратному навантаженні на роутера або інший пристрій, що здійснює функцію UDP-proxy в локальній мережі абонента. Стандарт HLS став досить поширеним і підтримується майже всіма сучасними відеоплеєрами та приставками для IPTV.
|
| IPTV приставка |
Істотним мінусом є наявність у абонентів мультимедійних приставок та smart-tv приставок із застарілими прошивками або застарілих конструкцій, які не підтримують стандарти HLS або підтримують їх некоректно. Також однією з проблем є неможливість правильно вибрати якість для стабільної трансляції в умовах зміни характеристик лінії в інтервалах часу менших, ніж тривалість відеофрагменту, що запитується.
Для організації онлайн трансляцій в реальному режимі часу, відео на запит (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.
- wgethttp://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;
або /tmp/hls;
Висновок
Ця стаття була написана та опублікована спільно з моїм колегою Євгеном Петровим. Ми використовуємо цей модуль (Ngnix-rtmp) у різних проектах. Якщо у когось з'являться питання щодо Ngnix-rtmp, Wowza серверу, пишіть. Якщо вам потрібно щось налаштувати або отримати консультацію щодо медіа-серверів та мультимедійних систем, також можете звертатися до мене та нашої команди через .
Створення ідеальних з технічної точки зору додатків, як правило, є надзвичайно складним та трудомістким завданням. При цьому корисна інформація часто розпорошена по безлічі джерел. Це стосується, зокрема, розробки відеододатків для 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 рекомендується реалізовувати за допомогою 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.
