FFMPEG erőforrásigénye

Fórumok

Sziasztok!

Egy webes projekten dolgozok, amiben videó feltöltést, illetve lejátszást kell lehetővé tenni egy ún. "Videó" menüben. Még a konvertálás témába csak most kezdtem belemerülni. Videó feltöltést kiviteleztem, tehát elérkeztem oda, hogy fenn van a szerveren a(z olykor elég nagy méretű) videó fájl. Át kéne konvertálni.

Átkonvertálásról, ffmpeg -ről jó cikkek, leírások vannak magyarul is, de a legjobbak úgy érzem angolul vannak. Mindenhol kiemelik a nagy erőforrás igényt. Igazság szerint egyenlőre nem vagyok biztos abban, hogy hogyan kellene kivitelezni a konvertálást. Persze van elképzelés:

- Egyik elképzelés, hogy ugyan azon a szerveren menne végbe a konvertálás amiről a webszerver fut. Ez viszont egy mondhatni komolyabb szervert kíván maga alá, és ott is valamilyen korlátozásokat kellene az FFMpeg -nek csinálni RAM tekintetében, hogy ne zabálja fel az összes erőforrást, ne legyen lassulás a webszerveren. Videó konvertálás ha nem a lehető leggyorsabb az még kevésbé gond, mint az oldal letöltések lassúsága.

- Másik elképzelés, ha két szerverről beszélünk. Egyikről megy a webszerver, a másikról pedig külön megy az FFMpeg, elkonvertálgat és teljes erőforrást felhasználhatja, ez talán nem olyan költséghatékony. Bár a szerverhostingnak nem néztem utána jobban, hogy net nélkül milyen árak vannak (sejtem, hogy a különbség nem sok).

Mit gondoltok? Ti hogy oldanátok meg? Esetleg harmadik opció is szóba jöhet.
Köszönöm válaszaitokat!

Hozzászólások

Én szétválasztanám mindenképpen. Az elején még nem lenne gond néhány júzerrel, de ha beindul az oldal, akkor egy szuperszámítógép fog kelleni. Lásd videómegosztók gépi háttere.
Egyébként az a kérdés hogy teljesen átakarod-e kódolni a videókat, (új ráta/felbontás/konténer/codec) vagy csak módosítani rajtuk (kisebb ráta/felbontás). Sokat számít. Egyébként nem annyira memet zabál az ilyesmi, mint inkább procikat. De azt nagyon. Nekem egyszer sikerült segfaultba kergetni egy amúgy stabil gépet filmkódolással.
Még valami. Ha jól tudom az ffmpeg-et nem fejlesztik (már) annyira. Helyette az avconv van. Erre is keress rá.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Köszönöm a válaszokat!

Én napi 20-40 videóval számolok ha beindul a dolog. Az elején nyilván még ennyi se. De ezek között jó részt nem tömegtelefonokkal készített rossz minőségű videók kerülnének feltöltésre. Sőt ilyenek tiltásra kerülnének inkább, minőséget fontosabbnak tartom.
Átkonvertálás annyit takar, hogy a felbontást mindenképp módosítani kellene a lejátszóhoz igazítva. Egy vízjelet is meg kellene jeleníteni a videókon, és .FLV -be konvertálni. Tehát a konvertálás véleményem szerint igen csak erőforrás igényes lenne.
Sajnos volt már olyan projektem, ami a nem megfelelő kivitelezés és ebből kifolyólag az állandó 100% -os terhelés miatt állt le. Ezt a hibát még egyszer nem akarom elkövetni, már az elején szeretném a későbbiek lehetőségeit látni magam előtt.

Márpedig több hostingot felkeresve, volt több olyan hosting aki ilyen célra VPS -t ajánlott, mégpedig a leggyengébbhez közelebbi csomagokat (160-256Mb RAM, stb.). Éppen ezért kételkedem a témában. Ha egy VPS ezt kiszolgálja, akkor gondoltam csak nem olyan erőforrás igényes a dolog. A legidegesítőbb, hogy ezt mind-mind elvileg hozzáértő emberek ajánlották (nem szeretnék megemlíteni nevén senkit). Az ajánlásokkal ellentétben állt, hogy az FFMPEG -ről szóló cikkek mind mind úgy kezdődtek, hogy "CPU, RAM ...blablabla".
Hozzátenném, hogy a kezdetekben a tervek szerint egy PC alapú szerverről menne a dolog. Egyenlőre egy Intel Xeon E5620 CPU adott. Későbbi bővítésekre való figyelemmel akarom úgy kivitelezni már most a feltöltés-konvertálást, hogy maximum néhány órás munkával át lehessen úgy írni az egész feltöltést, hogy 2 gépről működjön a dolog.

Olvasnivaló: http://knowledge.kaltura.com/best-practices-multi-device-transcoding

Vedd hozzá amit linkeltem korábban a software vs. hw. encoding sebessége, minősége, rugalmassága.
Írták már, de nem lehet elégszer leírni, az flv-t felejtsd el.

És szerintem ismerkedj a rtmp gondolatával (és nézd meg a crtmpserver-t), kíméli a sávszélességet és picit nehezíti a filmek ellopását. Mondjuk nem nagyon.

Fel fog merülni a probléma h264 vonalon, hogy rettenetesen lassan pozícionál a stream-ben, erre a keyint a megoldás, nálam 20-ra van állítva.

Az erőforrásokról annyit, hogy attól függően hogy mit hová állítok 80 és 4 FPS között változik a kódolás sebessége, illetve 300M és 1G között a memóriafoglalás (handbrake ugyan, de a lényegen nem változtat, csilló dologtól függ, hogy). De az igazi kérdés, hogy milyen gyorsan kell az átkódolt video. A tecső pl. azt csinálja, hogy gyorsan kódol egy silány minőségű, alacsony felbontású anyagot, ami már megjeleníthető, ellenőrizhető és feliratozható, miegyéb. És amikor gépidő van (gondolom akkor), akkor legyártja a jó minőségű anyagokat is.

Ehh, rtmp, nem véd az semmit. Kivétel az rtmpe + drm, de az meg más tészta.

Ha már jót akarsz neki, akkor vagy progessive download vagy hls, esetleg MPEG-Dash. Az rtmp már ahol csak lehet kivezetődik.

A specből a progressive dl tűnik a legoptimálisabb választásnak.

A lassű pozícionálást nem annyira befolyásolja a keyint, az sokkal inkább azt befolyásolja, hogy hova tudsz a stream-ben seek-elni.

Az utolsó részre pedig óriási +1!

Ahamm..... Attól eltekintve hogy a teljes idézet így szólna "Ha jól tudom az ffmpeg-et nem fejlesztik (már) annyira." ami feltételezi hogy léteznek/dolgoznak még, abból gondoltam amit gondoltam, hogy sok helyen már az avconv-ra hivatkoznak.
De ma is tanultam valamit. Pedig vasárnap van. Szóval kösz a kiigazítást.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Rövid távon nem dobnám szét, vannak eszközök melyekkel szépen lehet lavírozni, gondolok itt prioritás állítgatásra, kódoláskor maximum használható cpu-k korlátozására, ulimit, control groups..

Természetesen ezek idővel el fognak fogyni és muszáj leszel kiszervezni.

Üdv én is találkoztam hasonló gonddal én abban tükröztem hogy csináltam egy virtuális rendszert amiben benne volt az ffmpeg és írtam egy scriptet kicserélve az ffmpeg binárist ami átküldi a konvertálandó file-t és mikor végzet visszateszi. Ezt kicsit bővítettem mert többszörözni tudtam ezt a vps-t majd sorba raktam egy file-ba az ipker és mindig lépet egyet igy mindig másikra tette a konvertálandó file-t. Eleinte azért volt jó mert skálázhattam menyit akarok az erő forrásból erre elkülöníteni később mert többszörözni lehet! Igaz nekem azért kellett ez mert meglévő vásárolt motort használtunk!

Ubuntu 12.04, Kernel:3.8.3, AMD Phenom 2 x4 955BE , OCZ-VETRTEX3 SSD

Van a youtube-nak alternatívája? Azt gondolnám h nincs az az erőforrás ami elég lenne egy ilyen videós konvergáltatós, kiszolgálós elképzeléshez!Persze ha van valakinek a sarkkörön túli szerverfarmja, combos kábelekkel, az más! De ez az egy-két gépen való vacilálás eléggé illuzórikusnak tűnik...

Nagyon kérdéses a userek mennyisége a hw meg a videok max mérete original nagysága ideje és kimenet minősége. Esetleg cél hw meg hardeveres kodolás kérdése bár a vga alapu x264 tömörítést ffmpeg alatt nem próbáltam. egy kisebb oldal simán kiszolgálható ha nem tömeges a dolog mint pl youtube és társai. Inkább az a kérdés mennyi a tőke. További kérdés a tár terület vagy hogy többszörözve lesz e a tartalom hogy legyen elég sávszél és ne lassuljon be a stream. Szoval sok kérdés van és még több lehetőség amit én mondtam az egy átmeneti és bővíthető megoldás fejlesztés alatt akár egy gépen is lehet a convertáló egység és a honlap későbbiekben meg hátulról össze lehet drótozni a gépeket akár közvetlen net nélkül is! Elég sok megoldás jut eszembe mert volt már dolgom hasonló dologgal!
Ubuntu 12.04, Kernel:3.8.3, AMD Phenom 2 x4 955BE , OCZ-VETRTEX3 SSD

Nem lenne tömeges a dolog, szó sincs ilyesmiről. Egy alap géppel gondoltam elindulni, ami egy kisebb user mennyiséget még képes kiszolgálni úgy gondolom. És ahhoz mérten majd bővítünk. De amíg nem tudom, hogy mi az igény, addig feleslegesnek tartom, hogy komolyabb valami legyen vásárolva a projekt alá. Nem akarok alá célozni semmit, a túl nagy terhelés, lassúság miatt. De túlságosan fölé sem, a pénz miatt.

Tudom sokan kinevetnek de én ezt tenném:
8 magos buldozer 16 gb gyors memória. (2 éve mennek hasonló konfigok hw hiba nélkül)
Wincs opcionális sw raid 1.
Debian linux nálam
Virtualbox +virtualbox php
Alaprendszer az oldal kiszolgálásra.
A virtualbox-ba én debiant dobok ez lesz az ffmpeg. (skálázható menyit áldozol be a vasból!)
A két rész smb vel összedrótozom.
Én mp4 be szoktam konvertálni.
Apache2 pedig stream kezelést végzi.
Amíg a konvertálás tart és a mysql ben már bent vannak a dolgok egy pármásodperces videóval ki rom hogy konvertálás alatt vagy inaktívba teszem a videót. Ha kell segítség szólj szívesen segítek.

Nagy vonalakban gy megoldható az oldal lassulása nélkül. És amd configgal olcsóbb is a dolog és semmit nem vesztesz és a virtualizálás is kényelmes!

Ubuntu 12.04, Kernel:3.8.3, AMD Phenom 2 x4 955BE , OCZ-VETRTEX3 SSD

Nekem az a tapasztalatom, h ha a desktop gépen elindtom a torrrentes film konvertálását [, hogy a tv -n tudjam játszani] akkor arra a pár órára amg konvertál kb használhatatlanná válik a gépem. Legalábbis erőforrás igényes dolgot nem lehet rajta csinálni. Persze tény h meglehetősen alapszinten közeltek a kérdéshez és biztos lehetne optimalizálni az opciókon. Innen nézve eleve kizárt az egygépes megoldás. A konvertálás tipikusan queue feladatnak tűnik, amit majd valamikor valamelyik háttérgép elvégez ha lesz hozzá kanala.
Aztán meg a kiszolgálás is kérdéses, mivel nyilván a peak-et is birnia kell. És nem is tudom, h kell itt számolni, ugye yt -is előtölti a videót. Vagyis az is megkapja az egészet aki a felénél kikapcsolja lejátszást. Másodpercenkenti userszámtól függően, elég hamar elfogyhat a sávszélesség.

en nem raknak kulon gepre, hacsak nincs irrealiasn sok video feltoltes.
visoznt nem azonnal inditanam amikor feltoltottejk, hanem beraknam valami queue-ba, es aszinkron dolgoznam fel a queue-ban levo videokat valami scripttel, max 2-3 filet egyszerre, alacsony cpu prioritassal.

A'rpi

Néhány megjegyzés: Az flv-t messze el kell felejteni, helyette mp4 konténer.

További jó tanács a konvertáláshoz: egyszerre egy maximum két szálon futtasd a konvertálást, a feltöltött videókat rendezd sorba.

Én megfelelő paraméterezéssel az ffmpeggel ki tudok terhelni koppig egy 2 CPUs bámilyen szervert, tudni kéne, hogy milyenek a feltöltött videók, illetve milyen a "kimenő" videók felbontása, bitrátája. Számít-e az átkonvertált videók mérete?

Milyen gyorsan kell a feltöltött videókat publikálni?

Ez csak néhány gondolatébresztő kérdés volt, a válaszoktól függ, hogy külön gép vagy lehet ugyan azon.

16 magos xeonom vigan konvertal 10 videot egyszerre. De tudni kene mit kell konvertalni mibe.
------------------------
Jézus reset téged

Na, persze QCif-et, a notimban lévő centrinom is tud konvertálni, akár 10 szálon is.

A 16 magos Xeon meg egy darab rendes HD konvertálása esetén is úgy áll bele a földbe*, ahogy az a nagykönyvben elő van írva.

*: beáll a földbe == ha a kódolás sebessége real-time alá megy (kisebb mint 25-30fps forrása válogatja)

Szóval a 16 mag meg xeon nem jelent önmagában semmit.

Rontáslevétellel is foglalkozol, hogy így látatlanban kitaláltad? Dehogy találtad ki :D:D:D

vélelmezem hogy nem avatar méretű és per vagy minőségű fájlokat akar tömöríteni, meg mozgatni a weben. akkor pedig...

azért kérdeztem, mit mibe.


------------------------
Jézus reset téged

Nem, rontáslevétellel nem foglalkozok, az boszorkányság, én csak varázsolni szoktam :D

Miből mibe illetve milyen preset-tel konvertálsz azon a vason? (Forrás felbontás, codec, illetve kimenő felbontás, codec, és preset érdekel elsősorban.) Még nem elhanyagolható kérdés mi a CPU típusa?

Azért kérdem, mert éppen szerver vásárlás előtt vagyunk, és szintén transzkódolni fog, és jó lenne valami valós adatot kapni a cpu kiválasztáshoz, mert a mostani XEON-ok már nem mérvadóak.

-r 25 -pass 1 -vcodec libx264 -flags +loop+mv4 -partitions +parti4x4+parti8x8+partp4x4+partp8x8+partb8x8 -subq 1 -trellis 0 -refs 1 -bf 16 -b_strategy 1 -coder 1 -me_range 16 -g 10 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -bt 100 -rc_eq \"blurCplx^(1-qComp)\" -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -acodec libfaac -b:a 96k -ac 2 -ar 44100

forrás felbontás változo, de jellemzően "jó minőség", 590×362 b:v 1024 0:30-10:00 videoméretek. Intel(R) Xeon(R) CPU E5620 @ 2.40GHz 2 db, HT. ugy van 16.
ami viszont megfektet, az a thumbnail kiszedés. ffmpeg-php module tolja, de hosszabb videoknál sok-sok másodperc 8 thumb kinyerése.


------------------------
Jézus reset téged

Ezt próbáltuk: https://zencoder.com/ Jó volt, csak átálltunk saját szerverre, mert sok videó lett hirtelen. Mi külön szerveren konvertálunk, h264-be. Streaming seekelés problémát a megoldja szerveren ez: http://h264.code-shop.com/trac#H264StreamingModule, lejátszó pedig ez: http://www.projekktor.com/ (ha teheti, natív lejátszót használ, de seekeléskor küld a szervernek egy ajax kérést. Így a szerver ugrál a fájl kiszolgálásakor az mp4 fájlban. A keyint_min nálunk 25-re van beállítva, így nincs gond. Így tudunk olyan 20 fps-mal konvertálni olyan 300 MB-os memória használattal videónként.
Háttérben konvertálunk PgAgent-tel, így nálunk a konvertálás csak egy INSERT az adatbázisba. Ha kész van, kap értesítést a felhasználó.