Sziasztok!
2014 -et írunk és néhány éves témákat találtam javarészt a témában. Gyorsan fejlődik minden ezért felteszem a kérdést én is. Nem rég volt róla szó nagy vonalakban egy témában hogy hogyan történik egy videó átkonvertálása illetve mivel, milyen erőforrásokkal kellene csinálni. Megoszlott a vélemény, volt aki 2 szervert üzemeltetne, egyik a konvertálásért, másik a webkiszolgálásért lenne a felelős, és volt aki egyben az egészet csinálta volna (persze erős konfiggal). Engem viszont most a komplett téma érdekelne.
Van egy szerver ami egy témával kapcsolatos weboldalt szolgál ki. Most érkeztem el oda hogy a sima képfeltöltés (galériák) után mozgókép feltöltést kéne megvalósítani a felhasználóknak.
- Manapság mibe, hogyan érdemes konvertálni és mivel? A cél jó minőség, de a tárhely is véges bizonyos kereteken belül.
- Milyen stream szervert érdemes használni egy (későbbi esetleges) több Tb -ot meghaladó videószerverhez?
- Eleinte a 100Mbit sávszélesség úgy gondolom elég lesz. Na de később mire számíthatok?
- Egyáltalán mihez érdemes viszonyítani? Mekkora egy átlag videó? Igen tudom, beállítás függő és ezt így nem lehet megmondani. Nem is kell, de valami viszonyítás alap, hogy mekkora diskekre történjen a beruházás majd, hosszútávra. Videónál mire számíthatok? Napi 10-30 videóval számolok
- Témával kapcsolatban tapasztalatok is nagyon érdekelnének!
Nem csináltam még ilyet, talán hasonlót sem. Ezért lenne szükségem a tapasztalatokra. Ha úgy gondoljátok, hogy esélytelen tapasztalat nélkül stabilan felhúzni egy ilyet, azt is elfogadom. Jöhet hideg-meleg. Minden érdekel ami a témába vág.
- 7639 megtekintés
Hozzászólások
Hát, ugyan nekem nincs eszveszett nagy tapasztalatom, de:
- h264 kodek, mondjuk mp4 konténer, és x264 (http://www.compression.ru/video/codec_comparison/h264_2012/)
- én szeretem az rtmp-t (crtmp szerver) mert jól támogatja a lejátszóm, más a http stream-et részesíti előnyben, lásd alább
- az majd később kiderül
- igen (video hossza, felbontása, témája, típusa - karton vagy render vagy amatőr kézikamera -, a kívánt minőség, stb, ettől mindtől függ, különösen az stb-től)
Ha én most fognék hozzá, akkor alighanem a http stream-et választanám, mégpedig azért, mert ahhoz (talán) könnyebben lehet találni olyan CDN-t mint pl. a Cloudflare. Onnanstól kezdve pedig egy csomó probléma már nem a tiéd. Csak esetleg fizetni kell érte.
A videok méretét meg nincs mese, ki kell próbálni, hogy mekkora lesz azokkal a beállításokkal, amiket jónak látsz. Ugyanazt a mondjuk öt percet le tudom tömöríteni 2M-ra is és 500M-ra is.
- A hozzászóláshoz be kell jelentkezni
Nekem akad némi tapasztalatom benne.
+1 a h264 + mp4-re, jelenleg ez a legjobb választás.
Stream formátum: vagy HTTP progressive download vagy HLS esetleg MPEG-DASH, attól függően, hogy kell-e adaptív bitráta vagy sem, illetve kell-e "rendes" access kontroll a fájloknál. Ha igen, akkor HLS/DASH, ha nem, akkor jó a progressive dl.
Hát igen, a videó mérete csak kb a lábfejem nagyságától nem függ, minden mástól igen, tudni kell, hogy milyen felbontás, milyen hossz, te mit engedsz kijátszani, tárolod-e az eredetit vagy sem.
Csak egy zárójeles megjegyzés: az RTMP-t ma már el kell felejteni, annak ellenére, hogy van egy esetleg két olyan előnye amit talán a progressive download tud (félig), de se a HLS/HDS/DASH/SmoothSteaming nem.
- A hozzászóláshoz be kell jelentkezni
Hogy érted azt, hogy "rendes" access kontroll?
- A hozzászóláshoz be kell jelentkezni
pl úgy, hogy van a filmed és szabadon csak bizonyos részeit lehet lejátszani.
Vagy esetleg DRM-et szeretnél csinálni. (Playready és társai.)
- A hozzászóláshoz be kell jelentkezni
Nekem is van kis tapasztalatom a dologban.
Ahogy már fentebb írták h264 + mp4, mert:
- Adott sávszélesség/tömörítettség mellett jobb képminőséget eredményez.
- A B frame -ek Key framek -mennyiségétől kevéssé függ a file méret
- Nincs nagy méretű meta data csomag
Én viszont semmiképpen nem streamelnék http -n, kizárólag rtmp -n. Wowza Media Server -el van tapasztalat, az remekül működik. Nyilván szóba jöhet a RED5 is, de nem tudom milyen lehet. A http strem azért nehéz ügy mert preload -ot csinál ami akkor gond ha a néző nem nézi végig a filmet, így feleslegesen pocsékoltuk a sávszélt és a néző tárterületét.
Konvertálás az egy nehéz kérdés mivel rendkívül sok lehet a bemenő formátum. Különösképp a mindenféle videó kamerák miatt. Érdemes két lépésben konvertálni a jobb kimenő formátum miatt. Az ideális az lenne, ha parancssorból lehetne videó kártyán konvertálni. Ha ez nem megy, akkor marad a processzor erős gép, sok maggal ffmpeg -el súlyosbítva.
Ehhez nem árt még egy upload szerver és egy ami a thumbnail -eket szolgálja ki (ez akár lehetne egy gép)
Viszont szerintem a legtöbbet abból lehet tanulni, ha belevágsz és a problémákra, amikbe bele botlassz külön-külön keresel megoldást.
----
올드보이
http://molnaristvan.eu/
- A hozzászóláshoz be kell jelentkezni
HTTP Progressive download + byte-range requests - megvan?
Az persze igaz, hogy egy minimális preload van, de azért az nagyon messze van a vészestől.
Az rtmp-vel pedig kizárod az összes mobil-t, mert se androidon, se ios-en, se WP-n nem támogatott.
GPU kódolás: jelenleg még mindig csak ott tartunk, hogy az ffmpeg (x264) CPU-n még mindig agyonver "szinte" bármilyen GPU-t. GPU-n live-ot lehet jól kódolni.
"Ehhez nem árt még egy upload szerver és egy ami a thumbnail -eket szolgálja ki (ez akár lehetne egy gép)" erre viszont nagy +1
- A hozzászóláshoz be kell jelentkezni
GPU kódolás: jelenleg még mindig csak ott tartunk, hogy az ffmpeg (x264) CPU-n még mindig agyonver "szinte" bármilyen GPU-t. GPU-n live-ot lehet jól kódolni.
Ezt azert gondold ujra a HD ready es full HD parameterei menten.
Az rtmp-vel pedig kizárod az összes mobil-t, mert se androidon, se ios-en, se WP-n nem támogatott.
Plusz ez az a protokoll, amit valaki anno megprobalt megtervezni, majd kilepett/meghalt/athelyeztek/megunta az Adobe-nal es egy fosadek lett.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Hivatalos Nvidia doksiban olvastam, ha gondolod előkerítem, hogy a full HD esetén vagy 1 streamet valósidő 8x-val tudja, vagy 8 streamet párhuzamosan real-timeban úgy, hogy a beállítások az x264 fast presetjének felelnek meg.
Közben megtaláltam: http://developer.download.nvidia.com/compute/nvenc/v4.0/NVENC_AppNote.p… valósidő 16x tud full HD-nál, "Highest performance" módban ami gyanúm szerint egyenelő az x264 veryfast->ultrafast presetjei valamelyikével.
Szóval óvatosan a GPU-s hype-pal.
- A hozzászóláshoz be kell jelentkezni
+1
Ezt később elolvassuk:)
- A hozzászóláshoz be kell jelentkezni
Nem hajpoltam, vettem reszt gpu-s h.264 codec fejlesztesben is, meg lemértem azt is ami van, beleertve az Intel legujabb h.264 dsp-t is es 48 magos gepeit is. A marketing doksikat mar elvbol es hivatalbol leszarom. :)
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Mint a Freescale iMX53 és a full HD H264 dekódolás. Megcsinálja (max 25 FPS), csak éppen nem tudod megjeleníteni (erről persze már nem szól a doksi), csak hülye trükkökkel bizonyos esetekben.
- A hozzászóláshoz be kell jelentkezni
http atmegy minden tuzfal/proxy-n, rtmp nem valoszinu.
a video fajl merete egyedul a bitratatol fugg: ha azt allitod be hogy 500kbit/sec, akkor 1 percnyi videod ~4M lesz. az mas kerdes hogy ez egy 320x240-es videohoz eleg, de egy 1080p HD videonal edes keves. szoval neked kell megtalalni a megfelelo erteket.
a h264 lighty/apache modulban nincs sok felesleges savszel pocsekolas, mert pont akkorara allitja be a speed limitet, ami az adott videohoz kell (pl mindig 5 sec-nyi adatot kuld elore)
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
A h.264 nem definial ilyen erteket, h bitrata, csak olyat, h qp. Az osszes bitrata allogatas egy oszver megoldas, ennek megfeleloen jobbara csak ajanlast jelent es a codec donti el, h mennyi lesz a valoban hasznalt bitrata. Legalabbis ha azt akarod, h nehany mosott fos folt mellett legyen ertelmezheto informacio is a kepen.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Én viszont semmiképpen nem streamelnék http -n, kizárólag rtmp -n. Wowza Media Server -el van tapasztalat, az remekül működik
Leszamitva azt, h miutan kihajitottuk a fenebe sikerult sajat implementaciokkal a kihozatalt kb. az otszorosere emelni havi berletidij nelkul. Attol nem is beszelve, h CDN-en az rtmp-ert arany drachmaval fogsz fizetni, a http-t kitoljak neked nehany uveggolyoert is es legalabb nem csak a fel internet fogja tudni nezni, mert kizartad a tamogatott formatumokat, mint pl. a HLS-t ios-re es androidra. Vagy a tv-kre. Vagy HTML5 alatt.
Érdemes két lépésben konvertálni a jobb kimenő formátum miatt. Az ideális az lenne, ha parancssorból lehetne videó kártyán konvertálni. Ha ez nem megy, akkor marad a processzor erős gép, sok maggal ffmpeg -el súlyosbítva.
Erdemesnek erdemes, de felesleges. Ugyanis a feltoltott videok minosege, pont azert, h epeszu internet kapcsolat is eleg legyen, a leheto legjobban konvergal a nulla fele. Plusz a Jo Isten vasa nem lenne eleg egy ido utan, hiszen ez a megoldas lefelezi a teljesitmenyt es duplazza a TCO-t.
Es ha jot akarsz, egyre kevesbe hasznalod az ffmpeg-et ilyesmi celra. Indulashoz jo, de utana - foleg ha rtmpzel - jobban jarsz ha zaros idon belul elfelejted.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Ezzel a "Mivel?" helyett a "Mivel ne?" kérdést válaszoltad meg, pedig az előbbi engem is érdekelne... :)
- A hozzászóláshoz be kell jelentkezni
Ez eleg valtozo es jobbara azert nem olcso temakor. En sajatot irtam. Audiora felturboztam egy kicsit a libfaad/libfaac parost, mint referencia codecet, h egy 5 evvel ezelotti xeon-on se nagyon jelentsen koltseget. Videora ugyan a ffmpeg decodere maradt, mert az Intel referencia codec-jei eleg ramaty allapotban vannak, de kep atmeretezesre mar azt hasznalom, mert a libswscale mikor ezt a dontest hoztam nem volt szinhelyes es gyorsabb is volt nala. Encodernek pedig a szokasos x264, direktben, de a Main Concept sem rossz. Vagy a CoreAVC. Valoszinuleg most lesz majd bevezetve emellett az IGD is. Viszont azt tudni kell, h kommercialis celokra hasznalsz h.264-et es/vagy aac-t, akkor fizetsz, mint a katonatiszt. :) Egy x264 licence dollarban merve es nehany ezres tetel az MPEG-LA sarc nelkul. Persze, hasznalhatod helyette a vp8/vp9-et, csak eppenseggel ugy jarsz vele, mint az RTMP-vel. File formatumhoz meg inkabb MP4Box, mint a libavformat mp4 muxere.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Az ffmpeg mp4 demultiplexere sem igazán jó, konkréten az MP4Box-szal készített anyagokkal meggyűlik a baja (elrontja az audio frame-eket). Nem jártam alaposabban utána, de találkoztam a problémával.
- A hozzászóláshoz be kell jelentkezni
Picit pontosabban lehetne, hogy mikor rontja el őket? Dekódolásnál vagy esetleg a A/V szinkron csúszik szét?
- A hozzászóláshoz be kell jelentkezni
Adott egy mp4 fájl, az ffmpeg szépen tudja demultiplexelni az audio/video frame-eket, tudom dekódolni is, minden jó. MP4Box-szal csinálok belőle MPEG-DASH multisegment anyagot, ez egy rakás kis mp4-et állít elő. Ha ezeket az mp4-eket megnyitom, akkor a demultiplexer a video frame-eket továbbra is jól adja vissza, az audionál viszont teljes a káosz, rossz méretek, rossz tartalom stb. Valószínűleg azért van, mert az MP4Box az MPEG-DASH-hez szükséges MP4-et állítja elő (ISOBMF), amit az ffmpeg dmx nem ismer, csak a "klasszikus" mp4-et.
(Az ffmpeg-et mi dmx-re, mx-re és audio dekódolásra használjuk, a videó dekódolást a VPU végzi, A/V szinkron, megjelenítés stb. mind saját fejlesztés, elvégre egy STB-ról van szó)
- A hozzászóláshoz be kell jelentkezni
"Leszamitva azt, h miutan kihajitottuk a fenebe sikerult sajat implementaciokkal a kihozatalt kb. az otszorosere emelni havi berletidij nelkul." - Ehh így könnyű :D
Nem védeni akarom a wowzát, de azért annyira nem szar, bár itt-ott hallom, hogy szidják főleg a 2-es szériát. A 3.6-tól fölfele meg hallok egész meredek dolgokat a teljesítményéről - jó értelemben.
Nálunk teszi a dolgát rendesen.
Megj: ha pusztán arra kell, hogy vod-ot vagy live-ot chunkoljon HLS-re mindenféle viccesség* nélkül akkor arra lehet, hogy nem a legjobb választás a wowza.
*stream access kontroll / DRM / egyebek.
- A hozzászóláshoz be kell jelentkezni
HDS/HLS/DASH esetén már by default korlátozott a preload minden playerben. Valamikor a pszeudóstreaming korában volt az trend, hogy húzóra lekapta a player a fájlt, de már elmúlt.
Az rtmp az 1 ujjamon megszámolható előnyét leszámítva halott protokoll ha a téma a nézők tömegének kiszolgálása. Szerintem.
- A hozzászóláshoz be kell jelentkezni
Ami IPTV streamünk nekünk itt van, az mind MPEG-TS konténerben jön MPEG2 vagy H264 kódolással. Bitrate-ek (MPEG2/H264, SD/HD) a 600 kbps-től a 12 Mbps-ig változnak, sőt olyan is van, hogy egy adott műsorfolyamon belül hirtelen megváltozik, pl. egy sportközvetítés jöhet nagyjából fix sebességgel, aztán beiktatnak egy reklámot, ami meg csak ötödakkora sávszélességet visz el. Vannak csatornák egy hangstreammel, aztán van, ahol van vagy hat (pl. Euronews).
MPEG-DASH pedig megy MP4-gyel és MPEG-TS-sel is, igaz, ha jól tudom az összes funkciójának kihasználásához MP4-et kell használni.
Transzkódoláshoz kezdeti tapasztalatszerzés céljából jó lehet még akár a VLC is, vagy az ffmpeg.
- A hozzászóláshoz be kell jelentkezni
Csak pornó. A többi vesztességes lesz és mindegy, hogy kódolod.
- A hozzászóláshoz be kell jelentkezni
Lehet troll leszek, de nekem eszembe nem jutna sajat streaming megoldasban gondolkodni, hacsak nincs kiscsillo penzed vagy idod es hozzaertesed, esetleg mindharom egyutt. Van uStream/Twitch/YouTube streamelesre, van YouTube videokra, minden konverziot elvegeznek helyetted, es eleg szeles tamogatottsag is van hozzajuk. Raadasul mindegyik szolgaltato eleg szeles forrasanyag-palettat fogad, es ingyen atkonvertaljak neked arra, amire nekik jo.
Sajat megoldast akkor kell elkezdeni uzemeltetni, amikor mar annyi penzed van, hogy megeri.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. - A hozzászóláshoz be kell jelentkezni
Cserébe kb. azt csinálnak a feltöltött anyaggal amit akarnak. Én pl. maradtam a saját megoldásnál. Persze az is közrejátszik, hogy átlag napi egy látogatót kell kiszolgálnom :D
(Jó, icipicit többet, de azért nincs nagy forgalmam.)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni