стрийминг hls. Кога да използвате протокола HLS

Предоставяне на услуги IP телевизиячрез интернет и локалните компютърни мрежи става все по-разпространени форми. На територията на страните от ОНД почти няма големи доставчици, които да не излъчват видео мултикасткъм техните локални мрежи, тоест към тези, които предоставят услугата IPTV. Но предоставянето на телевизионни услуги извън неговата локална мрежа е свързано с някои хардуерни разходи и сложността на осигуряването на необходимото качество на излъчване.

HTTP поточно предаване на живосъщо известен като HLS, е комуникационен протокол, внедрен от Apple. Неговата особеност е, че целият поток е разделен на поредица от малки файлове за изтегляне, като всяко изтегляне изтегля един малък фрагмент от транспортния поток. Когато се възпроизвежда поток, клиентът може да избира от няколко различни алтернативни потока, съдържащи един и същ материал, записани с различни скорости на предаване, което му позволява да се адаптира към наличната скорост на предаване. В началото на поточно сесия се зарежда разширен плейлист M3U (m3u8), съдържащ метаданни за различните налични подпотоци. Тъй като заявките използват само стандартни HTTP операции, HTTP Live Streaming е в състояние да заобиколи всяка защитна стена или прокси сървър, който позволява стандартен HTTP трафик, за разлика от UDP протоколи като RTP.

HLS се основава на HTTP. HLS също така дефинира стандартен механизъм за криптиране, използващ AES и начин за разпространение на ключ за сигурност с помощта на HTTPS или HTTP бисквитки, които заедно осигуряват проста система за защита на авторските права.

Принцип на работа на HLS

Сега нека да разберем какви са предимствата и недостатъците на тази технология. Ползите са неоспорими и очевидни. Това е, на първо място, адаптивността на скоростта на предаване на данни към свойствата на линията и приемащото устройство, и второ, вградените механизми за защита на авторските права. Трето, не се изисква рутер с ограничена ширина мултикаст потокпрез WI_FI, което би помогнало да се избегне поглъщането на цялата ширина на канала от мултикаст потоци, в случай на излъчване на IP телевизия чрез мултикаст. Освен това не изисква допълнително устройство с функцията UDP проксиза преобразуване на мултикаст поток в HTTP, което често се изисква за мобилни устройства, въпреки че влияе върху хардуерното натоварване на рутера или друго устройство, което изпълнява UDP прокси функцията в локалната мрежа на абоната. Стандартът HLS стана доста разпространен и се поддържа от почти всички съвременни видео плейъри и приставки за IPTV.

IPTV приемник

Значителен недостатък е, че абонатите имат мултимедийни приставки и приемници за смарт-тв с остарял фърмуер или остарели дизайни, които не поддържат HLS стандартите или не ги поддържат правилно. Също така един от проблемите е невъзможността да се избере правилното качество за стабилно излъчване при условия на промяна на характеристиките на линията във времеви интервали, по-кратки от продължителността на искания видео фрагмент.

Обработвайки, съхранявайки и прехвърляйки видеоклипове за своя онлайн проект, вместо да използва сайтове като YouTube, той неизбежно стига до въпроса кой протокол за трансфер да използва за поточно предаване на видеоклипове към устройствата на потребителите. Изборът е малък, т.к Има редица индустриални стандарти, които поддържат определени устройства. Освен това изборът на протокол до голяма степен зависи от „класа“ на видеото – излъчване на живо или видео по заявка. Изборът на медиен сървър, който ще бъде двигателят на вашата медийна машина, също зависи от избора на протокол: ще инсталирате ли няколко хетерогенни сървъра или ще изградите мрежа за доставка на базата на едно решение? Следователно трябва да претеглите всичко и да вземете решение въз основа на критериите на вашия бизнес.

Като цяло се получава уравнение с много неизвестни. Тук е важна динамиката на процеса – накъде върви индустрията като цяло? Ами ако инвестирам в поддържаща технология и тя ще умре след една година, защото това вече се е случило. Или ще заложа на модерна технология, но никой не я поддържа?

Решихме да оценим как се променя делът на различните протоколи във времето – да разгледаме целия процес в динамика. Данните са взети от миналата година.

Първоначални данни

Като начало, кои сме ние, за да съдим пазарните дялове? Ние сме разработчиците на уеб услуга за отчитане за медийни сървъри. Работим на пазара вече четвърта година и при нас идват компании с различна инфраструктура, различен брой сървъри и различни нужди. Оказва се добър състав на състоянието на индустрията.

Направихме малък отчет, в който можете да изберете период от време и да получите данни с графика за броя гледания на видео чрез различни протоколи.

Отчетът предоставя данни за сървърите:

• Wowza Streaming Engine във всички версии от 2.2 до най-новата 4.x; най-много - 3.x.
• Nimble Streamer, който работи с HLS, Smooth, HDS и прогресивно изтегляне, е нашата разработка.
• 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 - оттук и скокът в този протокол.

Както показа практиката, най-добрият транспорт за видео в сравнение с RTMP е HLS. Причини за това:

Много просто прокси сървър, с кеширане през nginx. На първо място, защото камерата като устройство не може да обслужва по правило повече от 10 връзки едновременно. В този смисъл гарантираното проксиране на RTMP потоци е възможно само чрез платени решения и изисква много енергия. Не е необходим специален сървърен софтуер.

Опростяване на цялата сървърна инфраструктура. По силата на идеята видеото се дава на парчета, през порт 80 през http. Самият Nginx може да бъде отговорен за връщането на статика. Връщането на статика (видео парчета от 50 kB) е много лесна задача за nginx.

Тъй като броят на парчетата е постоянен, старите се премахват, добавят се нови, твърдият диск никога няма да препълни.

Разпространението е по-голямо от това на RTMP. HLS с H.264 видео кодиране се поддържа от iOS и работи безпроблемно. Към 1 юли 2014 г. връзките за поточно видео с HLS транспорт са 55%, RTMP - 26%, RTSP - 15% и MPEG-DASH по-малко от 1%.

Поддръжка за повечето мобилни устройства, настолни компютри, таблети директно от браузъра.

Много по-лесно от излъчването в RTSP по принцип. Тъй като няма такива процедури като push (публикуване на поток) или pull (получаване на поток).

Много по-удобен за http формат.

Недостатъците са следните:

Все пак не всички устройства поддържат този формат. Версиите на Android под 4.2 официално не поддържат кодека H.264 и транспорта, но на Android вместо браузър можете да използвате приложение на трета страна за гледане - например MX Player

Всичко зависи от камерата. Ако камерата е бъгове, например Dlink DCS-3010, тогава цялата система ще работи много зле (ffmpeg постоянно пада). Например камерите AXIS M1011-W, HIKVISION DS-2CD2412F-IW работят добре в такъв пакет (до месец без никакви оплаквания (просто не го тествах повече)). Прокарването на кабела също е важно. В този смисъл ще разгледаме идеалния вариант.

Какво е HLS транспорт

Видео потокът, кодиран в h.264 (Между другото: базовата линия на профила се разбира от устройствата с Android), е разделена на части с разширение *.ts, например по 5 секунди всяка, плейлист се създава в live.m3u8, с последователно описание на тези парчета. Дължината на плейлиста е предварително определена, например 10 парчета. Когато се появи 11-то видео, 1-то видео се изтрива, плейлистът се създава отново. Повече подробности можете да намерите на уебсайта на разработчика.

За да работи системата, ще настроим изображението от камерите така, както искаме да го виждаме на сайта, формата на изображението и качеството на изображението. Няма да прекодираме на сървъра. Камерата е проектирана да даде изображението, от което се нуждаете. Камерите обикновено имат няколко профила. Можете да конфигурирате един профил за H.264, за HLS, а втория с MPEG4 за MPEG-DASH. Можете също да настроите различно качество за широк и тесен интернет канал. Мислете сами - решавайте сами.

Важно!Камерата трябва да има изходно изображение, което не е необходимо да се кодира повторно.

Структурна схема за високо натоварване

Камера(rtsp) ----->

-----> една връзка FFmpeg(rtsp->hls) -> Nginx(nginx-rtmp-module) ----->

-----> една връзка към междинен nginx прокси с голям кеш =====>

=====> много клиенти на JWPlayer(hls).

Нашият сървър се свързва с ffmpeg към камерата и се регистрира с приложението nginx hls. nginx създава парчетата и плейлиста в определена директория. След това изпраща тези части на прокси сървъра. Клиентите се свързват с прокси сървъра с помощта на JWPlayer.

Настройка на приложението nginx

Нека изградим nginx с nginx-rtmp-module. Тази процедура е описана подробно в статията.

Да кажем, че имаме няколко камери, ще ги разделим по сериен номер. Ще опиша конфигурацията на nginx за 2 камери. Кешираме статични изображения за 5 минути в локалния кеш, ако изображението не се зареди в рамките на 5 секунди, даваме статичен начален екран.

# nano /etc/nginx/nginx.conf

Редактирайте конфигурацията на nginx

потребителски www-данни; worker_processes auto ; pid/run/nginx. pid ; error_log / var / log / nginx / nginx_error . дневник за отстраняване на грешки; env ПЪТ ; събития ( # multi_accept on ; ) http ( access_log / var / log / nginx / access . log ; error_log / var / log / nginx / error . log ; включва mime . типове ; default_type application / octet - stream ; sendfile on ; keepalive_timeout 65 proxy_cache_path / var / www / cache / локални нива = 1 : 2 keys_zone = nginx_local_cache : 1 m неактивен = 30 m max_size = 512 M ; proxy_temp_path / var / www / cache / local / tmp ; stat; # слушане 8 location / stat ( rtmp_stat all ; rtmp_stat_stylesheet stat . xsl ; ) location / stat . xsl ( # можете да преместите stat . xsl на друго местоположение root / etc / nginx ; ) location / ( rtmp_control all ; ) error_page 500 / 5050 5 50 x .html ;location = / 50 x .html ( root html ; ) включва cameras_http_locations .conf ; ) ) rtmp ( access_log / var / log / nginx / rtmp_access . log ; сървър ( слушане 1935 ; ping 30 s ; notify_method get ; включва 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 местоположения за камери:

# nano cameras_http_locations.conf

типове ( приложение / vnd . apple . mpegurl m3u8 ; видео / 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 ; изтича 1 m ; # кеш за 1 минута add_header Cache - Control public ; # за кеширане на проксито proxy_ignore_headers Cache - Контрол на заглавките на камерата_ от "http://192.168.0.3/GetImage.cgi?CH=1"; proxy_set_header Упълномощаване "Основно" ; error_page 502 504 404 @ fallback_img ; ) # дайте плейлиста - /1/hls/live.m3u8 или /3/hls/live.m3u8 # плейлист се кешира за 10 секунди на проксиместоположение ~* / hls / . * \ . m3u8 $ ( пренапишете "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 прекъсване ; # заявка за пренаписване / 1 / hls / to / hls - 1 / root / tmp / ; изтича 10 s ; add_header Cache - Публичен контрол ;) # дайте парче видео от камери - /1/hls/live-12345678.ts или /2/hls/live-12345678.ts # не се изисква кеширане на локалната машина # парчето се кешира за 3 минути на прокси сървъраместоположение ~* / hls / . * \ . ts $ ( пренапишете "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 прекъсване ; root / tmp / ; изтича 3 m ; add_header Кеш - Контрол публичен ; ) # наименувано местоположение, ако няма изображениеместоположение @ fallback_img ( пренаписване (. + ) / резервно . jpg прекъсване ; root / etc / nginx / ;)

Нека създадем hls конфигурационен файл за rtmp сървъра с приложения за нашите камери:

# nano cameras_rtmp_applications.conf

chunk_size 4000 ; приложение hls_1 (на живо; синхронизиране 10 ms; exec_static ffmpeg-i rtsp: //администратор: [защитен с имейл]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_1/live 2>>/var/log/nginx/ffmpeg_1.log; hls включен; hls_path / tmp / hls - 1 / ; # път за съхранение на парчета на сървъра hls_fragment_naming timestamp; # използвайте времеви печат за именуване на парчета ) приложение hls_2 ( на живо ; синхронизиране 10 ms ; exec_static ffmpeg - i rtsp : //администратор: [защитен с имейл].0.3:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_2/live 2>>/var/log/nginx/ffmpeg_2.log; hls включен; hls_path / tmp / hls - 2 / ; hls_fragment_naming timestamp ; )

Съдържание на директорията /tmp/hls-1/

$ ls / tmp / hls - 1 / на живо - 10458360. ts на живо - 13292010. ts на живо - 16129440. ts на живо - 18963270. ts на живо - 10930050. ts на живо - 137672010 на живо - 13767 тс. - 11405250. ts на живо - 14239260. ts на живо - 17072820. ts на живо . m3u8 на живо - 11878560. ts на живо - 14710860. ts на живо - 17544960. ts на живо - 12348630. ts на живо - 15182550. ts на живо - 18020160. ts на живо - 12544960. ts на живо - 15182550.

Примерен файл 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 - 1707ts #EXTINF. :5.280, на живо - 17544960. ts #EXTINF:5.251, на живо - 18020160. ts #EXTINF:5.228, на живо - 18492750. ts #EXTINF:5.242, на живо - 18963270

Решаване на проблема с падащи камери

Най-правилното решение е да смените бъги камерата. Помага в 90% от времето. Ако няма начин и трябва по някакъв начин да живеете, тогава следното решение ще помогне.

Това решение се състои от две - допълващи се:

Стартирайте отделен процес на nginx за всяка камера и общ процес за връщане на статика. Тоест за две камери напишете отделни конфигурации с rtmp сървъри и една обща с http. Тогава камерата с бъги няма да повлияе на цялостния процес.

Ако потокът от камерата е прекъснат в резултат на бъгове (прегряване, лошо окабеляване, недостатъчно захранване през PoE и т.н.), тогава камерата ще падне, ffmpeg дъщерният процес ще отхвърли пакети и nginx ще спре да пише видео парчета . И когато процесът ffmpeg приключи, nginx ще премахне всички файлове от директорията chunks. Изчисляваме този момент на почистване на папката чрез 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 стоп fi, ако [ - f "/etc/init.d/camera_2" ]; след това /etc/init. d/camera_2 стоп fi

Добавете към функцията do_reload:

# презаредете камерите, ако [ - f "/etc/init.d/camera_1" ]; след това /etc/init. d / camera_1 презареди fi if [ - f "/etc/init.d/camera_2" ]; след това /etc/init. d/camera_2 презареди fi

Редактираме скрипта за стартиране на nginx за камера 1 camera_1 и за камера 2 camera_2 според примера.

# nano /etc/init.d/camera_1

Промяна на променливите DAEMON_OPTS и DESC

DESC = "camera_1 за CAMERA-1" DAEMON_OPTS = "-c /etc/nginx/nginx_1.conf"

Редактираме скрипта за стартиране на nginx за камера 2 camera_2 според примера.

В /etc/nginx/nginx_0.conf с http местоположения пиша магически редове:

# 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 * Рестартиране на camera_1 за CAMERA - 1 конфигурация nginx # service camera_2 restart * Рестартиране на camera_2 за CAMERA - 2 конфигурация nginx

Скрипт, който презарежда камерите. Преминава през папките с парчета, търсейки къде няма *.m3u8 файлове. Ако в папката няма файлове, той търси съответния демон според конфигурацията на главния демон чрез реда DIR-PROCESS-NAME . Презарежда го.

# nano /script/cameras_reloader.sh

Сравняване на HLS с MPEG-DASH

MPEG-DASH е аналог на HLS, създаден от Google като транспорт за MPEG-4. Този транспорт не е широко разпространен и практически не се поддържа. Идеологията му е същата, разбийте потока на парчета, само още парчета, отделни парчета за видео, отделни парчета за аудио. В nginx-rtmp-module този формат е конфигуриран подобно на HLS.

Опитайте, копирайте, направете го!

Ако статията ви е била полезна, моля кликнете върху рекламата. Благодаря!

Flussonic Media Server поддържа видео разпространение чрез протокола HLS.

Много от наличните функции са нестандартни за HLS, но ние ги поддържаме за ваше удобство.

Поддържани кодеци: H264, H265, MPEG2 видео, AAC, MP3, MPEG2 аудио, AC-3.

Flussonic Media Server ви позволява да получавате телевизия на живо, видео при поискване, видео от архива (catchup и timeshift) чрез HLS.

Лесно HLS възпроизвеждане

Ако имате обикновен поток на живо или файл (едно видео, един звук), тогава URL адресът за възпроизвеждане чрез HLS е много прост:

http://flussonic-ip/STREAMNAME/index.m3u8

където flussonic-ip е пример за адрес + порт на вашия Flussonic Media Server.

Flussonic Media Server също приема playlist.m3u8 в края на URL адреса за обратна съвместимост с други сървъри.

Когато започнете да работите с многоезично или мултибитрейтно съдържание, нещата стават по-сложни.

Многоезичен HLS

Ако искате да пуснете своя многоезичен поток на iPhone, трябва да използвате същия http://192.168.2.3:8080/STREAMNAME/index.m3u8

Но ако искате да гледате многоезичен поток с помощта на VLC или приемник, трябва да включите video.m3u8.

URL за плейъра: http://flussonic-ip/STREAMNAME/video.m3u8

Това се дължи на факта, че според изискванията на Apple HLS трябва да се посочи отделен плейлист с опция само за аудио за всеки отделен език. MPEG-TS има различен механизъм: всички аудио записи се поставят до видеото, а плейърът сам избира какво ще се възпроизвежда. За да може видео да се гледа на iPhone, то трябва да отговаря на указанията на Apple. Но VLC и приставките, в нарушение на стандарта HLS, очакват старата версия на MPEG-TS, преобразувана в HLS. Следователно, трябва да включите video.m3u8 .

Добавяне на "Само аудио" за Apple

Apple изисква всичките ви потоци да имат опция без видео, само аудио.

Те вярват, че ако потребителят гледа видео през 3G и веднъж в зоната на несигурно приемане, той ще има по-добър звук само от буфериране.

Можете да активирате тази опция във Flussonic Media Server:

поток ort ( url udp:// 239.0.0.1 : 1234 ; add_audio_only ;)

Имайте предвид, че това може да направи вашия адрес index.m3u8 невъзможен за възпроизвеждане във VLC или приемник. В такъв случай използвайте video.m3u8.

Отделни битрейтове за приемници

http://flussonic-ip/STREAMNAME/video1. m3u8

Този плейлист не е мулти-битрейт, той съдържа URL адреса към сегментите, в които е първият видео запис и всички налични аудио записи.

Ако искате да доставяте многоезични, многобитови потоци на приемници, които не разбират многоезичния стандарт на Apple, използвайте video.m3u8:

http://flussonic-ip/STREAMNAME/video. m3u8

Това е плейлист с много битрейт, който връща списък с плейлисти с различни качества: video1.m3u8, video2.m3u8 и т.н.

Възпроизвеждане на DVR

Когато вашият поток вече е записан на сървъра от нашия DVR, можете да възпроизвеждате видеото чрез HLS, като използвате началното и крайното време на предаването (например от EPG).

http://flussonic-ip/STREAMNAME/archive-1508403742-3600. m3u8

Този плейлист ще бъде т.нар. вариант, ако в потока ще има повече от един аудио запис или повече от един битрейт. Той ще изброява сегменти, започващи от UTC 1362504585 (5 март 2013 г., 17:29:45 GMT) и един час напред.

Mono URL ще даде списък със сегменти, съдържащи всички песни в mpeg-ts:

http://flussonic-ip/STREAMNAME/mono-1362504585-3600. m3u8

По-специфичен плейлист videoN ще даде списък от сегменти с N видео запис и всички аудио записи:

http://flussonic-ip/STREAMNAME/video1-1362504585-3600. m3u8

и вариант на видео плейлист със списък от videoN плейлисти:

http://flussonic-ip/STREAMNAME/video-1362504585-3600. m3u8

Превъртане на плейлист

Има специален плейлист "rewind-N.m3u8"с голям "плъзгащ" прозорец, който ви позволява да превъртате назад и да поставяте на пауза HLS потоци за дълги часове.

http://flussonic-ip/STREAMNAME/rewind-7200. m3u8

7200 - Дължина на плейлиста HLS в секунди. Това означава, че вашите клиенти могат да поставят на пауза излъчването за 2 часа или да превъртат назад към началото на футболен мач, без да имат достъп до специални архивни връзки.