Flussonic médiaszerver támogatja a videó terjesztést HLS protokollon keresztül.

Sok elérhető lehetőségeket nem szabványos a HLS-hez, de az Ön kényelme érdekében támogatjuk őket.

Támogatott kodekek: H264, H265, MPEG2 video, AAC, MP3, MPEG2 audio, AC-3.

A Flussonic Media Server lehetővé teszi az élő TV, igény szerinti videó, az archívumból származó videók fogadását (felzárkózás és időeltolás) HLS-en keresztül.

Könnyű HLS lejátszás

Ha van egy egyszerű élő közvetítése vagy fájlja (egy videó, egy hang), akkor a HLS-en keresztül lejátszható URL nagyon egyszerű:

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

ahol a flussonic-ip egy példa a Flussonic Media Server cím + portjára.

A Flussonic Media Server a playlist.m3u8 fájlt is elfogadja az URL végén a más szerverekkel való visszafelé kompatibilitás érdekében.

Amikor elkezd dolgozni többnyelvű vagy többbites tartalommal, a dolgok bonyolultabbá válnak.

Többnyelvű HLS

Ha többnyelvű adatfolyamát iPhone-on szeretné lejátszani, ugyanazt a http://192.168.2.3:8080/STREAMNAME/index.m3u8

De ha többnyelvű streamet szeretne nézni VLC vagy set-top box használatával, akkor bele kell adnia a video.m3u8 fájlt.

A lejátszó URL-je: http://flusson-ip/STREAMNAME/video.m3u8

Ennek az az oka, hogy az Apple HLS követelményei szerint minden egyes nyelvhez külön lejátszási listát kell megadni csak audio opcióval. Az MPEG-TS más mechanizmussal rendelkezik: az összes hangsáv a videó mellé kerül, és a lejátszó maga választja ki, hogy mit játsszon le. Ahhoz, hogy egy videót meg lehessen nézni iPhone-on, meg kell felelnie az Apple irányelveinek. De a VLC és a set-top boxok a HLS szabványt megsértve az MPEG-TS régi verzióját várják HLS-re konvertálva. Ezért bele kell foglalnia a video.m3u8 .

„Csak hang” hozzáadása az Apple számára

Az Apple megköveteli, hogy az összes adatfolyamnál legyen videó nélkül, csak hang opció.

Úgy gondolják, hogy ha a felhasználó 3G-n keresztül néz videót, és a bizonytalan vételi zónába kerül, jobb lesz, ha csak hangja van, mint pufferelés.

Ezt a lehetőséget a Flussonic Media Serverben engedélyezheti:

stream ort ( url udp:// 239.0.0.1 : 1234 ; add_audio_only ; )

Ne feledje, hogy emiatt az index.m3u8 cím lejátszhatatlanná válhat VLC-ben vagy set-top boxban. Ilyen esetben használja a video.m3u8 .

Külön bitráta a set-top boxokhoz

Ha több bitsebességű többnyelvű tartalommal rendelkezik, és olyan set-top boxon szeretné lejátszani, amely nem támogatja a többbites HLS lejátszási listákat, kérhet egyedi lejátszási listákat egy videóval és az összes hangsávval a Flussonic Media Servertől, ugyanúgy, mint a mono opció:

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

Ez a lejátszási lista nem több bitsebességű, tartalmazza azoknak a szegmenseknek az URL-jét, amelyekben az első videosáv és az összes elérhető hangsáv található.

Ha többnyelvű, több bitsebességű adatfolyamokat szeretne eljuttatni olyan set-top boxokhoz, amelyek nem értik az Apple többnyelvű szabványát, használja a video.m3u8 fájlt:

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

Ez egy több bitsebességű lejátszási lista, amely listát ad a lejátszási listákról különböző minőségek: video1.m3u8, video2.m3u8 stb.

DVR catchup lejátszás

Ha az adatfolyamot a DVR-ünk már rögzítette a szerveren, a videót lejátszhatja HLS-en keresztül az átvitel kezdő és befejezési időpontjaival (például az EPG-ből).

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

Ez a lejátszási lista lesz az ún. változat, ha egynél több lesz a folyamban hangsáv vagy egynél több bitrátát. A szegmensek listája az UTC 1362504585 (2013. március 5., 17:29:45 GMT) kezdettől és egy órával előtte kezdődik.

A Mono URL az összes mpeg-ts sávot tartalmazó szegmensek listáját adja meg:

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

Egy konkrétabb videoN lejátszási lista N videósávot és összes hangsávot tartalmazó szegmensek listáját tartalmazza:

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

és egy videolejátszási lista változata a videoN lejátszási listák listájával:

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

Lejátszási lista visszatekerése

Van egy speciális lejátszási lista "rewind-N.m3u8" nagy "csúsztatható" ablakkal, amely lehetővé teszi a HLS adatfolyamok hosszú órákra történő visszatekerését és szüneteltetését.

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

7200 - HLS lejátszási lista hossza másodpercben. Ez azt jelenti, hogy ügyfelei 2 órára szüneteltethetik a közvetítést, vagy visszatekerhetnek egy futballmérkőzés elejére anélkül, hogy hozzáférnének a speciális archív linkekhez.

Videók feldolgozása, tárolása és átvitele online projektjéhez, ahelyett, hogy olyan webhelyeket használna, mint a YouTube, elkerülhetetlenül felmerül a kérdés, hogy melyik átviteli protokollt használja a videók streamelésére a felhasználók eszközeire. Kicsi a választék, mert Számos iparági szabvány támogatja bizonyos eszközöket. Ezenkívül a protokoll kiválasztása nagyban függ a videó "osztályától" - élő adás vagy igény szerinti videó. A médiagépe motorjaként működő médiaszerver kiválasztása a protokollválasztástól is függ: több heterogén szervert telepít, vagy egy megoldásra épít egy kézbesítési hálózatot? Ezért mindent mérlegelnie kell, és döntést kell hoznia vállalkozása kritériumai alapján.

Általában egy sok ismeretlent tartalmazó egyenletet kapunk. A folyamat dinamikája itt fontos – merre tart az iparág általában? Mi van, ha befektetek a technológia támogatásába, és az egy éven belül meghal, mert ez már megtörtént. Vagy fogadok egy trendi technológiára, de senki sem támogatja?

Úgy döntöttünk, hogy értékeljük, hogyan változott a különböző protokollok aránya az idő múlásával – hogy az egész folyamatot dinamikusan nézzük meg. Az adatok az elmúlt évből származnak.

Kezdeti adatok

Kezdetnek kik vagyunk mi, hogy megítéljük a piaci részesedéseket? Mi vagyunk a médiaszerverek jelentéskészítő webszolgáltatásának fejlesztői. Negyedik éve dolgozunk a piacon, és különböző infrastruktúrával, különböző számú szerverrel és eltérő igényekkel érkeznek hozzánk a cégek. Kiderül, hogy jól bemutatja az iparág helyzetét.

Készítettünk egy kis jelentést, amelyben kiválaszthat egy dátumtartományt, és grafikonon keresztül adatokat kaphat a videómegtekintések számáról a különböző protokollokon keresztül.

A jelentés adatokat szolgáltat a szerverekről:

• Wowza Streaming Engine minden verzióban 2.2-től a legújabb 4.x-ig; legtöbb - 3.x.
• A Nimble Streamer, amely HLS-sel, Smooth-szal, HDS-sel és progresszív letöltéssel működik, a mi fejlesztésünk.
• Windows Media Services - szó szerint néhány tucat van belőlük, de léteznek, és figyelembe kell vennünk őket

Az írás idején a szolgáltatás mintegy 1000 szervert szolgál ki 60 országból.

A jelentést blogunkon is rendszeresen frissítjük, a megfelelő címke alatt érhető el.

Megy

A 2014. június/júliusi jelentés valahogy így néz ki. Tól től 1,4 milliárd megtekintés több mint fele HLS. A második helyen az RTMP áll a nézettség negyedével. Az RTSP körülbelül egy hatoda. A többi a statisztikai hiba tartományába esik.

Mi történt egy évvel ezelőtt ugyanebben az időszakban? A helyzet szinte tükörkép. RTMP - csaknem kétharmad, az RTSP és a HLS osztozik a második és harmadik helyen. Igaz, a mérési alap majdnem háromszor kevesebb volt - "csak" 500 millió megtekintés. Természetesen kevesebb szerver is volt a szolgáltatásunkban.

Menjünk e két pont között.

Tehát 2014. június-augusztus, 3 hónap a nyár. 800 millió megtekintés, de a részvények ugyanazok, augusztus nem hozott változást.

2013. szeptember - november. Új szezon kezdődött, a HLS elkezdte felemészteni az RTMP részesedését. Teljes 1,1 milliárd megtekintés, az RTMP-nek körülbelül a fele, a HLS-nek a negyede.

2013. december - 2014. február. 1,4 milliárd megtekintés, amelynek a HLS több mint 40%-át teszi ki. Az RTMP és az RTMP holtversenyben a második és a harmadik helyen áll, negyed részesedéssel. A szocsi olimpia megnövelte a nézettség számát, és egyúttal arra kényszerítette a szolgáltatókat, hogy emlékezzenek az összes vásárlóra minden egzotikus vagy régi készülékükkel, amelyek csak az RTSP-t értik – innen ered a megugrás ebben a protokollban.

Amint a gyakorlat azt mutatja, a legjobb videóátvitel az RTMP-hez képest a HLS. Ennek okai:

Nagyon egyszerű proxy, nginx-en keresztüli gyorsítótárazással. Elsősorban azért, mert a kamera, mint eszköz, általában nem szolgálhat ki 10-nél több kapcsolatot egyszerre. Ebben az értelemben az RTMP folyamok garantált proxyzása csak fizetős megoldásokon keresztül lehetséges, és sok energiát igényel. Nincs szükség speciális szerver szoftverre.

A teljes szerver infrastruktúra egyszerűsítése. Az ötletből adódóan a videó darabokban, a 80-as porton keresztül, http-n keresztül kerül megadásra. Az Nginx maga is felelős lehet a statika visszaadásáért. A statika (50 kB-os videódarabok) visszaadása nagyon egyszerű feladat az nginx számára.

Mivel a darabszám állandó, a régieket eltávolítják, újakat adnak hozzá, HDD soha nem fog túlcsordulni.

A prevalencia nagyobb, mint az RTMP-é. A H.264 videókódolású HLS-t az iOS támogatja, és zökkenőmentesen működik. 2014. július 1-től a streaming videokapcsolatok aránya HLS-átvitellel 55%, RTMP - 26%, RTSP - 15%, MPEG-DASH pedig kevesebb, mint 1%.

Többségi támogatás mobil eszközök, asztali számítógépek, táblagépek egyenesen a böngészőből.

Sokkal egyszerűbb, mint elvileg RTSP-ben sugározni. Mivel nincsenek olyan eljárások, mint a push (folyam közzététele) vagy a pull (folyam beszerzése).

Sokkal http-barátabb formátum.

A hátrányok a következők:

Mindazonáltal nem minden eszköz támogatja ezt a formátumot. Android verziók A 4.2-nél kisebb verzió hivatalosan nem támogatja a H.264 kodeket és szállítást, de Androidon böngésző helyett használhatja harmadik féltől származó alkalmazás- például MX Player

Minden a kamerától függ. Ha a kamera hibás, például Dlink DCS-3010, akkor az egész rendszer nagyon rosszul fog működni (az ffmpeg folyamatosan leesik). Például az AXIS M1011-W, HIKVISION DS-2CD2412F-IW fényképezőgépek jól működnek egy ilyen csomagban (akár egy hónapig minden panasz nélkül (csak nem teszteltem tovább)). Ugyanilyen módon nagyon fontos kábelelvezetéssel rendelkezik. Ebben az értelemben az ideális megoldást fogjuk megvizsgálni.

Mi az a HLS szállítás

H.264 kódolású videofolyam (Apropó: a profil alapvonala érthető Android készülékek), darabokra van osztva a *.ts kiterjesztéssel, például egyenként 5 másodpercre, egy lejátszási lista jön létre a live.m3u8 fájlban, ezeknek a daraboknak a szekvenciális leírásával. A lejátszási lista hossza előre meghatározott, például 10 darab. Amikor megjelenik a 11. videó, az 1. videó törlődik, a lejátszási lista újra létrejön. További részletek a fejlesztő honlapján találhatók.

A rendszer működéséhez a kamerák képét úgy állítjuk be, ahogyan azt az oldalon látni szeretnénk, a képformátumot és a képminőséget. Nem fogunk újrakódolni a szerveren. A fényképezőgépet úgy tervezték, hogy a kívánt képet adja. A kameráknak általában több profilja van. Beállíthat egy profilt a H.264-hez HLS-hez, a másikat pedig az MPEG4-hez az MPEG-DASH-hoz. Különböző minőséget is beállíthat egy széles és keskeny internetes csatornához. Gondolkozz magadon – dönts magad.

Fontos! A kamerának olyan kimeneti képpel kell rendelkeznie, amelyet nem kell újrakódolni.

Szerkezeti diagram nagy terheléshez

Kamera(rtsp) ----->

-----> egy kapcsolat FFmpeg(rtsp->hls) -> Nginx(nginx-rtmp-module) ----->

-----> egy csatlakozás egy köztes nginx proxyhoz nagy gyorsítótárral =====>

=====> sok JWPlayer(hls) kliens

Szerverünk az ffmpeg segítségével csatlakozik a kamerához, és regisztrál az nginx hls alkalmazással. Az nginx egy adott könyvtárban hozza létre a darabokat és a lejátszási listát. Ezután elküldi ezeket a darabokat a proxyszervernek. Az ügyfelek a JWPlayer segítségével csatlakoznak a proxyszerverhez.

Az nginx alkalmazás beállítása

Építsük meg az nginx-et az nginx-rtmp-modullal. Ezt az eljárást a cikk részletesen ismerteti.

Tegyük fel, hogy több kameránk van, ezeket elosztjuk sorozatszámmal. Leírom az nginx konfigurációt 2 kamerához. A statikus képeket 5 percig gyorsítótárazzuk a helyi gyorsítótárban, ha a kép nem töltődik be 5 másodpercen belül, statikus indítóképernyőt adunk.

# nano /etc/nginx/nginx.conf

Szerkessze az nginx konfigurációt

felhasználói www-adatok; worker_processes auto ; pid/run/nginx. pid ; error_log / var / log / nginx / nginx_error . log debug ; env PATH ; események ( # 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 inaktív = 30 m max_size = 512 M ; proxy_temp_path / var / www / cache / local / tmp ; szerver ( figyeljen 80 rtmp ; # rtmp ) location / stat ( rtmp_stat all ; rtmp_stat_stylesheet stat . xsl ; ) location / stat . xsl ( # áthelyezheti a stat . xsl fájlt egy másik helyre root / etc / nginx ; ) location / ( rtmp_control all ; ) error_page 500 502 40 50 x .html ;location = / 50 x .html ( gyökér html ; ) include cameras_http_locations .conf ; ) ) rtmp ( access_log / var / log / nginx / rtmp_access . log ; szerver ( figyelj 1935 ; ping 30 s ; notify_method get ; tartalmazza a cameras_rtmp_applications fájlt. conf ; ) )

Hozzon létre egy gyorsítótár-útvonalat # mkdir /var/www/cache/local Gyorsítótár-engedélyek javítása:

# chmod -R 755 /var/www/cache/local # chown -R www-data:www-data /var/www/cache/local`

Hozzon létre http helyeket a kamerák számára:

# nanokamerák_http_locations.conf

típusok ( alkalmazás / vnd . apple . mpegurl m3u8 ; video / mp2t ts ; ) # képet ad az 1. kameráról - /1/img/ # minden kameránál eltérőek, mert a kamerák IP-címei eltérőek "http://192.168.0.2/GetImage.cgi?CH=1"# képet ad a 2. kameráról - /2/img/ location / 1 / img / ( proxy_cache nginx_local_cache ; proxy_cache_key $ request_uri ; lejár 1 percre ; # gyorsítótár 1 percig add_header Cache - Control nyilvános ; # gyorsítótár a proxy-n proxy_ignore_headers Cache - Control ; # a proxy_pass eltávolítása a kamerából "http://192.168.0.3/GetImage.cgi?CH=1"; proxy_set_header Engedélyezés "Alap" ; error_page 502 504 404 @ fallback_img ; ) # adja meg a lejátszási listát - /1/hls/live.m3u8 vagy /3/hls/live.m3u8 # lejátszási lista 10 másodpercig gyorsítótárban van a proxyn hely ~* / hls / . * \ . m3u8 $ ( rewrite "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break s ; add_header Gyorsítótár - Nyilvános vezérlés ; ) # adj egy videót a kamerákról - /1/hls/live-12345678.ts vagy /2/hls/live-12345678.ts # gyorsítótár bekapcsolva helyi számítógép nem szükséges # a darab 3 percig gyorsítótárban van a proxyn hely ~* / hls / . * \ . ts $ ( írd át "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break ; root / tmp / ; lejár 3 perccel ; add_header Cache - Control nyilvános ; ) # megnevezett hely, ha nincs kép hely @ fallback_img ( újraírás ( . + ) / tartalék . jpg break ; root / etc / nginx / ; )

Hozzunk létre egy hls konfigurációs fájlt az rtmp szerverhez a kameráinkhoz való alkalmazásokkal:

# nano cameras_rtmp_applications.conf

chunk_size 4000 ; alkalmazás hls_1 (élő; szinkronizálás 10 ms; exec_static ffmpeg-i rtsp: //admin: [e-mail védett]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_1/live 2>>/var/log/nginx/ffmpeg_1.log; hls on ; hls_útvonal / tmp / hls - 1 / ; # a darabok szerveren való tárolásának elérési útja hls_fragment_nameing timestamp ; # időbélyeg használata a darabok elnevezésére //admin: [e-mail védett]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_2/live 2>>/var/log/nginx/ffmpeg_2.log; hls on ; hls_útvonal / tmp / hls - 2 / ; hls_fragment_nameing timestamp ; )

A /tmp/hls-1/ könyvtár tartalma

ls $ / tmp / hls - 1 / élő - 10458360. ts élő - 13292010. ts élő - 16129440. ts élő - 18963270. ts élő - 10930050. ts élő - 10930050. ts élő - 10930050. ts élő - 11405250. ts élő - 14239260. ts élő - 17072820. ts élő . m3u8 élő - 11878560. ts élő - 14710860. ts élő - 17544960. ts élő - 12348630. ts élő - 15182550. ts élő - 18020160. ts élő - 18020160. ts élő - 18020160. ts élő .

Példa a live.m3u8 fájlra

#EXTM3U #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:35 #EXT-X-TARGETDURATION:5 #EXTINF:5.224, élő - 16602660. ts #EXTINF:5.246, élő - 17072820 #EXTINF. ts :5.280, élő - 17544960. ts #EXTINF:5.251, élő - 18020160. ts #EXTINF:5.228, élő - 18492750. ts #EXTINF:5.242, élő - 1896ts3270.

A leeső kamerák problémájának megoldása

A legtöbb a helyes döntés, cserélje ki a bugos kamerát. Az esetek 90%-ában segít. Ha nincs mód, és valahogy tovább kell élned, akkor a következő megoldás segít.

Ez a megoldás két kiegészítőből áll:

Futtasson külön nginx folyamatot minden kamerához és általános folyamat a statikusság visszatérésekor. Vagyis két kamerához írjon külön konfigurációt az rtmp szerverekkel és egy közöset a http-vel. Ekkor a bugos kamera nem befolyásolja az általános folyamatot.

Ha a kamerából érkező adatfolyam megszakad a hibája miatt (túlmelegedés, rossz vezetékezés, elégtelen áramellátás a PoE-n stb.), akkor a kamera leesik, az ffmpeg gyermekfolyamat elutasítja a csomagokat, és az nginx leállítja a videodarabok írását . És amikor az ffmpeg folyamat leáll, az nginx eltávolítja az összes fájlt a chunks könyvtárból. Kiszámoljuk a mappa tisztításának ezt a pillanatát cron segítségével, és újraindítjuk a szükséges nginx folyamatot.

Minden egyes kamerához egy végrehajtható szkript jön létre az /etc/init.d/ fájlban, az nginx egy példánya, melynek neve camera_1 és 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

Az nginx indítószkriptjének szerkesztése.

nano /etc/init. d/nginx

Módosítsa a DAEMON_OPTS változót. A fő nginx démon az összes statikust kiszolgálja. Ezenkívül elindítja és leállítja a kamerákért felelős démonokat. / init . d /kamera_1 stop fi if [ - f "/etc/init.d/camera_2" ]; majd az /etc/init. d/camera_2 stop fi

Adja hozzá a do_reload függvényhez:

# kamerák újratöltése, ha [ - f "/etc/init.d/camera_1" ]; majd az /etc/init. d / kamera_1 újratöltés fi if [ - f "/etc/init.d/camera_2" ]; majd az /etc/init. d/camera_2 reload fi

Szerkesztjük az nginx indítószkriptet az 1. kamera_1 és a 2. kamera_2 kamerához a példa szerint.

# nano /etc/init.d/camera_1

A DAEMON_OPTS és DESC változók módosítása

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

Szerkesztjük az nginx indítási szkriptet a 2. kamera camera_2 számára a példa szerint.

A http helyekkel rendelkező /etc/nginx/nginx_0.conf fájlba varázssorokat írok:

# DIR-PROCESS-NAME /tmp/hls-1/camera_1 # DIR-PROCESS-NAME /tmp/hls-2/camera_2

Jelzik a DIR-PROCESS-NAME keresőszót szóközzel elválasztva, a könyvtárat és az újraindítandó folyamat nevét.

Vizsgálat:

# service nginx start # service camera_1 restart * Camera_1 for CAMERA - 1 konfiguráció nginx # service camera_2 restart * Camera_2 for CAMERA - 2 konfiguráció nginx

Szkript, amely újratölti a kamerákat. Átmegy a darabmappákon, és megkeresi, hol nincsenek *.m3u8 fájlok. Ha nincsenek fájlok a mappában, akkor megkeresi a megfelelő démont a fő démon konfigurációja szerint, a DIR-PROCESS-NAME sorral. Újratölti.

# 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-*" függvény 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 $maszk -type f) if [ -z $találat_eredmény ] ; then process = $(find_process $hls_dir ) service $process restart fi kész alvó 15s

A HLS és az MPEG-DASH összehasonlítása

Az MPEG-DASH a HLS analógja, amelyet a Google, MPEG-4 szállításaként. Ez a szállítás nem elterjedt és gyakorlatilag nem támogatott. Az ideológiája ugyanaz, törd szét a folyamot, csak több darabra, külön darabokra a videóra, külön darabokra a hangra. Az nginx-rtmp-modulban ez a formátum a HLS-hez hasonlóan van beállítva.

Próbáld ki, másolj, hajrá!

Ha a cikk hasznos volt az Ön számára, kattintson a hirdetésre. Köszönöm!

A műszakilag ideális alkalmazások létrehozása általában rendkívül összetett és időigényes feladat. Ugyanakkor a hasznos információk gyakran több forrásban is szétszóródnak. Ez többek között az iOS-hez készült videoalkalmazások fejlesztésére vonatkozik. Ez a cikk tartalmazza a legfontosabb és leghasznosabb információkat, amelyek lehetővé teszik a HTTP Live Streaming szolgáltatások teljes skálájának minőségi használatát, valamint az elsődleges források listáját. Ezek az anyagok hasznosak lesznek minden olvasó számára, aki érdeklődik a minőségi és felhasználóbarát videoszolgáltatások létrehozásában.

A videoszolgáltatások kényelmének és interaktivitásának erősítése révén valósul meg Gyorsindításés visszatekerés, valamint a pufferelés hiánya. A legjobb eredmény elérése érdekében a következő műveletsort javasoljuk.

• Kezdve az alacsony videó minőséggel. A videó elindításához legalább egy darab szükséges. Ennek megfelelően minél kisebb egy darab mérete, annál gyorsabban indul el a videó. A kezdő adatfolyam bitrátájának csökkentése és a csonk időtartamának csökkentése gyorsabb videóindítást eredményez. Javasoljuk a 4-8 másodperces csonk időtartamot és a 200-300 Kbps kezdő bitsebességet. Így a videó lejátszásának megkezdéséhez a felhasználónak legfeljebb 300 kb-t kell letöltenie.
• Lejátszási lista optimalizálás. A lejátszási listák a teljes adatfolyam jelentős részét foglalhatják el, különösen kis darabméretek és hosszú (több óra) tartalom esetén. A legtöbb esetben a lejátszási listák videolejátszóra való átvitelekor ajánlatos azokat archiválni.
• kulcskeretek. Kívánatos, hogy szegmensenként legalább egy IDR keret legyen, előnyösen a szegmens legelején. Ezenkívül a videó átvitelekor mobilhálózatok javasolt legalább 3 másodpercenként kulcsképet készíteni.
• TS rezsi. A HTTP LS az MPEG TS-t használja tárolóként, ezért nagyon fontos a TS többletterhelésének minimalizálása (alacsony videóminőség esetén is 10%-nál kevesebbnek kell lennie). Ilyenkor érdemes valós bitrátákat mérni forgalmi dumpok segítségével és optimalizálni a használt csomagolókat (szegmentálókat).
• A Cél időtartam paraméter a lejátszási listában. Ez a paraméter hatással van az indítási időre, de az Apple azt javasolja, hogy állítsa 10 másodpercre, mert az alacsonyabb értékek növelik a pufferelés esélyét, különösen a nagy késleltetésű mobilhálózatokon. Nem javasolt 20 másodpercnél hosszabb szegmensek létrehozása sem.
• dinamikus bitráta. Az iOS-be épített adaptív adatfolyam-mechanizmus egy variáns lejátszási listában pontosan meghatározott bitrátákkal működik optimálisan (maga a lejátszási lista forgalmát is figyelembe véve). Ebben az esetben a változó bitsebességű adatfolyamokhoz a maximumhoz közelebbi értéket kell megadnia. Ellenkező esetben helytelen döntések lehetségesek az aktuális videofolyam megváltoztatásával kapcsolatban. A szomszédos bitrátáknak 1,5-2-szeres sebességgel kell különbözniük.
• Streamek "csak hang". A HE-AAC audiokodek lényegesen hatékonyabb, és a legtöbb eszköz támogatja. A csak audió csatornák továbbítását az MPEG Elementary Stream használatával javasolt megvalósítani, nem pedig az MPEG Transport Stream (sokkal kisebb többletköltség) használatával.

A videolejátszó fejlesztése során hasznos információkhoz juthat a HTTP Live Streaming naplóból (accessLog). Adatokat tartalmaz arról, hogyan zajlott az automatikus váltás, milyen bitrátákat használtak stb. A naplóban elérhető információk részletei. Ezen adatok alapján videoelemzési adatokat gyűjthet a felhasználóiról.

További ajánlások
Online adások esetén a CDN késései miatt videopufferelés is lehetséges, valamint olyan esetekben, amikor a lejátszási lista frissítési ideje túl rövid, és a szervernek nincs ideje időben szegmenseket generálni. A visszatekerési mechanizmus optimalizálásához nem egész szám (tényleges) szegmenstartam értékek használata javasolt, különben hiba halmozódhat fel.

Ha az alkalmazást a következő helyen kívánják használni különböző eszközök, a listában különböző képminőséget adhat meg különböző képernyőfelbontásoknál. Így egy Retina kijelzős iPaden és egy viszonylag régi iPhone-on különböző videókat tud majd megjeleníteni.

A HTTP Live Streaming protokoll feladatátvételi mechanizmusokat is biztosít (a redundáns videoforrások jelzése). Ez a funkció hasznos lehet szolgáltatásai megbízhatóságának javítása érdekében.

A tudás forrásai
A HTTP Live Streaming videóalkalmazásokban való használatához szükséges források rövid listája:
HTTP élő közvetítés piszkozat
HTTP élő közvetítés gyakran ismételt kérdések
A HLS legjobb gyakorlatai

Végül érdemes megjegyezni, hogy a regisztrált Mac/iOS/Safari fejlesztők számára ingyenes technikai videókülések a WWDC 2012-vel, ahol szintén sok van hasznos információ, különösen - a videóval való munkavégzésről és a HTTP élő közvetítésről.

Szolgáltatások nyújtása IP TV az interneten és helyileg számítógépes hálózatok egyre inkább elterjedt. A FÁK-országok területén szinte nincs olyan nagy szolgáltató, amely ne sugározna videót multicast helyi hálózatukra, vagyis a szolgáltatást nyújtókra IPTV. De a TV szolgáltatás azon kívül helyi hálózat bizonyos hardverköltségekkel és a szükséges sugárzási minőség biztosításának bonyolultságával jár.

HTTP élő közvetítés más néven HLS, egy megvalósított kommunikációs protokoll az Apple által. Különlegessége, hogy a teljes adatfolyamot kis letöltési fájlok sorozatára osztják, és minden letöltés letölti a szállítási adatfolyam egy kis részletét. Egy adatfolyam lejátszásakor a kliens többféle, ugyanazt az anyagot tartalmazó alternatív adatfolyam közül választhat, amelyek különböző bitsebességgel vannak rögzítve, lehetővé téve, hogy alkalmazkodjon a rendelkezésre álló bitsebességhez. A streamelési munkamenet elején egy kiterjesztett M3U (m3u8) lejátszási lista töltődik be, amely metaadatokat tartalmaz a különböző elérhető alfolyamokhoz. Mivel a kérések csak szabványos HTTP-műveleteket használnak, a HTTP Live Streaming képes megkerülni minden olyan tűzfalat vagy proxykiszolgálót, amely lehetővé teszi a szabványos HTTP-forgalmat, ellentétben az UDP-protokollokkal, például az RTP-vel.

A HLS a HTTP-n alapul. A HLS meghatároz egy szabványos titkosítási mechanizmust is az AES használatával, valamint egy módot a biztonsági kulcsok HTTPS vagy HTTP cookie-k használatával történő terjesztésére, amelyek együtt biztosítják egyszerű rendszer szerzői jogi védelem.

HLS működési elve

Most nézzük meg, melyek ennek a technológiának az előnyei és hátrányai. Az előnyök tagadhatatlanok és nyilvánvalóak. Ez mindenekelőtt az adatátviteli sebességnek a vonal és a vevő eszköz tulajdonságaihoz való adaptálhatósága, másodsorban a beépített szerzői jogi védelmi mechanizmusok. Harmadszor, nincs szükség szélességben korlátozott útválasztóra multicast folyam WI_FI felett, ami segít elkerülni a teljes csatornaszélesség elnyelését a multicast streamek által, abban az esetben, ha az IP-televízió sugárzása multicast használatával történik. Ezenkívül nincs szükség további eszközre a funkcióval UDP proxy multicast stream konvertálása HTTP-re, ami gyakran szükséges a mobileszközökhöz, bár ez befolyásolja a router vagy más olyan eszköz hardverterhelését, amely az előfizető helyi hálózatában UDP proxy funkciót lát el. A HLS szabvány meglehetősen általánossá vált, és szinte minden modern videolejátszó és set-top box támogatja az IPTV-hez.

IPTV set-top box

Jelentős hátrány, hogy az előfizetőknek elavult firmware-rel vagy elavult kialakítású multimédiás set-top boxokkal és smart-tv set-top boxokkal rendelkeznek, amelyek nem vagy nem megfelelően támogatják a HLS szabványokat. Ezenkívül az egyik probléma az, hogy képtelenség kiválasztani a megfelelő minőséget egy stabil adáshoz, változó vonaljellemzők esetén a kért videórészlet időtartamánál rövidebb időintervallumokban.