H.264 enkóder/transzkóder megoldást keresek

Multimédia

Van több videó jelforrásom. Ezeken 1080i50/1080p50 felbontású videó érkezik, ami H.264 kódolású, és AAC hang van hozzá.

Ezt kellene valamilyen úton-módon valós időben transzkódolni más képméretre, bitrate-re, stb. (A cél is H.264/AAC formátumú)

Az FFmpeg megoldja a feladatot, de valami brutál gépigénye van: egy Sandy Bridge Core i5-2400 processzoron az 1080i50 forrásból legfeljebb 720p25-t tudok kódolni valós időben, de már ott is rezeg a léc, épphogy csak megvan a 25fps. Nyilván persze lehet többfoglalatos, 6-8-10 magos rendszerekben gondolkodni, de inkább valami célmegoldás érdekelne. Van egy kis handycam-em, abban egy félkörömnyi chip röhögve lekódolja az 1080p50-et, különösebb hőtermelés nélkül...

Elsődlegesen tehát egy célhardverre vágyom.

A jelbemenet terén nem vagyok válogatós, felőlem lehet HDMI, SDI, vagy akár ethernet felületen IP-vel egy UDP port is. A kimenet ideális esetben szintén valami UDP, vagy RTP/RTSP/RTMP stream...

Ötletek?

  • 9401 megtekintés

( john_silver v | 2013. 03. 18., h – 20:58 )

Most raktam össze egy gépet Core i7 3,6 GHz, van mellette egy NVIDIA 650Ti (középkategóriás kártya 35k körül). Méréseket nem végeztem, de a Pinnacle Studio 15 CUDA nélkül nagyon lassú a Pinnacle Studio 16-hoz képest amelyik már kihasználja a videókártyát.

( Vizibirka | 2013. 03. 18., h – 21:29 )

Hány stream-ed van? És mennyi lóvét szánsz rá?
Liveencoder nem megfelelő?

Egyébként annak a cpu-nak leglább 2 1080p-t tudnia kell valósidőben vinni.
Nagyon sokat számít az x264 enkóder beállítása..

> Hány stream-ed van?

Jellemzően 2-3.

> És mennyi lóvét szánsz rá?

Ha kapok megoldási alternatívákat, akkor megpróbálok közülük választani.

> Egyébként annak a cpu-nak leglább 2 1080p-t tudnia kell valósidőben vinni.

Hmm.

> Nagyon sokat számít az x264 enkóder beállítása..

Van ötleted, hogy állítsam be? A forrás videó 1080i50, H.264, AAC. A cél videó 720p25
Ez így éppen 25 fps-t tud a Core i5-2400 procin. 


AUDIO_BITRATE=160000
AUDIO_CHANNELS=2

VIDEO_BITRATE=4000000
VIDEO_WIDTH=1280
VIDEO_HEIGHT=720

ffmpeg -i "$SOURCE" \
  -acodec aac -ab $AUDIO_BITRATE -ac $AUDIO_CHANNELS \
  -vcodec libx264 -vb $VIDEO_BITRATE -vpre libx264-normal \
  -r 25 -g 50 -pix_fmt yuv420p -strict experimental \
  -vf yadif=0:0,scale=$VIDEO_WIDTH:$VIDEO_HEIGHT:interl=0 \
  -f mp4 "$TARGET"

A preseteket próbáltam változtatni:

libx264-normal -> ~25 fps
libx264-fast -> ~25 fps
libx264-hq -> ~23 fps

Az ideális megoldás vmilyen cél HW lenne, amiben van DSP a decode/encode gyorsítására. Amíg ilyet nem találsz, addig próbáld meg az ffmpeg 'threads' kapcsolóját. Ha jól sejtem, a CPU-d négymagos, így ha a transzkódolás nem csak egy magot terhel, hanem többet, jelentős sebességnövekedést érhetsz el. Egy próbát mindenképpen megér...

Hmmm... ebben az esetben akkor fordítanék magamnak egy saját ffmpeg-et, aminél biztosra venném, hogy az összes, adott CPU-ra elérhező optimalizáció (MMX, SSE stb) be van kapcsolva. (Arra most hirtelen nem emlékszem, az ffmpeg-et lehet-e "runtime CPU detection" opcióval fordítani, azt viszont el tudom képzelni, hogy egy olyan ffmpeg-et használsz, ami "általános" célra lett fordítva, és esetleg bizonyos utasításokat nem használ a CPU-n.)

Az ffmpeg/ffplay-en sokat dob a -ffast-math -funroll-all-loops, meg a -march xxx -mtune xxx megfelelő procihoz állítása. Ugyanez igaz a mplayer/mencoder párosra is. A player résznél tapasztaltam nagyon jó hatását. HD-Divx nézése 1.2 GHz-es ócska procis gépen... Másodpercenként 1-2 kocka ugrott, a hang meg szaggatott. A fenti dolgok újrafordítása után 100% prociterheléssel ugyan, de már nézhetően lejátszotta a filmet. ... meg a megfelelő libekkel is eljátszani ezeket.

Egy picit még a kernel újrafordítása (proci beállítása, +ne méretre optimizáljon, ezen kívül semmit nem piszkálva) is dob rajta, de ez valszeg csak a player részre hat.

Mielőtt hardvervásárlásba kezdenék, egy ilyet mindenképp kipróbálnék.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Egyébként, ha már preset-ek és libx264 beállítások: a különböző libx264 paraméterek állítgatásával - a minőség róvására - el tudok érni +1-3 fps gyorsulást, de a világot nem ez váltja meg. Egyedül a subpixel motion estimation metódus megváltoztatása okoz jelentős gyorsulást, de az durván redukálja a képminőséget is. (a subme 7 helyett subme 1-et használva mintegy másfélszeresére gyorsul az enkóder)

... de még ez sem elég az 1080p-hez. Fel nem foghatom, mire mondják azt, hogy ilyen kategóriájú procin akár több 1080p streamnek is kellene menni valós időben...

Ezzel a vassal nem fogsz ket 1080p50-et valosidoben ujra tomoriteni, de meg egyet sem. Ha ragaszkodsz ehhez a vashoz, akkor vagy celhardver (pl. az uj Intel Ivy w32/osx alatt, vagy valamilyen usb-s ext dongle es imadkozas, h az usb ne fossa ossze magat), vagy 12+ magos gep. A gpu-s encoderek jelenleg a vicc kategoriaban leledzenek.

En a nagyobb szerverekre szavaznek, flexibilisebbek. Btw, csak azert latod jonak az ffmpeg skalazasat (ami amugy sem szamit, az x264 a lenyeg), mert csak 4 processzorod van es azt maximalisan ki tudja ez a feladat igy hajtani. :)

Raadasul az x264 16 szal felett nem javasolt a kepminoseg rovasara megy a plusz teljesitmeny. A legjobb konstrukcio amit ebben az esetben eddig talaltunk az a sok magos gep volt amiben van eleg kraft, az osszes specialis hardveres ize (usb dongle, gpu, whatever) egy nagy rakas szar volt a gyakorlatban mar rovid tavon is.

---
pontscho / fresh!mindworkz

Hm. Erdekes dolog ez. A televiziotarsasagok valahogyan megoldjak a realtime FullHD AVC kodolast, bar ott persze teljesen mas a jel (lasd az itt linkelt kartyakat is, YCbCr bemenetek, nem pedig szoftverbol, memoriabol kapjak a jelet).

Ilyennel lehetne esetleg meg kiserletezni, bar ezek a kartyak nem olcsok, meg nem biztos, hogy megeri egy kartyaval kikuldeni a kepet, amit az encoder megesz es a szoftver v4l2 interfeszen megkap.

Hirtelen nem tudok mast mondani a posztolo felvetesere.

Tudni kell azt a h.264-rol, h egy masszivan szekvencialis algoritmus, amit (a pl. a vp8-cal ellentetben es ez erosen latszik pl. az igenyelt tranzisztorszamon) mar az elejetol fogva arra terveztek, h koromnyi sziliciumra integraljak es ezert nem trivialis parhuzamositani.

A gpu-s implementacioknak altalaban harom resze letezik:

1. csak pre/post processzre hasznalja a gpu-t, tehat nem igazi codec.
2. celhardvert integraltak a gpu melle, ez a modszer nehezen hasznalhato tobb stream egy idoben torteno feldolgozasara,
3. valamilyen megoldassal elve a CUDA/OpenCL egysegeket hasznalja fel az adatfeldolgozasra.

A masodik modszer kihalofelben desktop vonalon, mert nehez karban tartani, az nVidia is inkabb abba az iranyba probal elmenni, h a CUDA egysegeket hasznalja fel erre, hazai startupokkal is dolgoznak kozosen ilyen projecten.

A problema ott adodik, h a pci(-e) busz atviteli kepessege a gyakorlatban nagy felbontasu video eseten mar sovany tud lenni es parositva a szamitasi kapacitasok algoritmikus es CUDA/OpenCL compiler problemakbol fakadoan nem hasznalhatoak ki teljesen es igy semennyivel sem gyorsabb vagy energiahatekonyabb igy egy h.264 encode. Ennek termeszetesen hatasa van a kepminosegre is, igy vagy a stream merete lesz nagyobb ugyanolyan minoseg mellett, vagy forditva. Nem mondom, h nincs fejlodes ez ugyben, mert van, sot latvanyos, de egyelore nem az igazi.

---
pontscho / fresh!mindworkz

Ahogy tapasztaltam ár/teljesítmény arányban a h264 kódolásban az intel saccra 3x jobb (háromszor gyorsabb ugyanazért az árért) mint a CUDA(*).

Tulképp képfeldolgozásban se jött be annyira, gyorsabb a fotók matatása, ám - és ez nem a CUDA hibája - egy csomó képjavító/effektező plugin nem használja a CUDA-t, így a különbség nem mellbevágó.

*) Persze ezt mindig ki kell tesztelni az adott sw környezettel és a kívánt anyaggal, h264 esetén van pár beállítási lehetőség :D

> Ha fullHD transcoding kell neked, akkor érdemes célhardver után nézni.

Pont ezt teszem épp, ha a topiknyitóból nem lett volna egyértelmű :)

> http://www.ntt-electronics.com/en/products/video/products/lsi_and_modul…

Ez egy chip. Nekem valami kész megoldás kell, amibe csak be kell dugni a kábeleket...

"Pont ezt teszem épp, ha a topiknyitóból nem lett volna egyértelmű :)"
Felhasználói programok, Multimédia + szövegbeli FFmpeg alapján én azt gondoltam, először szoftvert keresel.

Amúgy google://h.264 encoder card
Első találat: http://www.matrox.com/video/en/products/compresshd/

Szerk:
Olyan, ami Linuxot is támogat: http://www.bluecherrydvr.com/2012/01/bluecherry-releases-8-port-h-264-l…

( deje | 2013. 03. 19., k – 08:24 )

Intel Core i3 Sandy Bridge-től felfelé van h264 célhardver a CPU-ban (http://en.wikipedia.org/wiki/Intel_Quick_Sync_Video). Sajnos csak Windóz alatt érhető el, cserébe brutál gyors, gyakorlatilag nincs olyan GPU a piacon jelenleg, ami gyorsabb lenne. Ivy Bridge-ben még gyorsabb.
Intel Media SDK-val lehet kihasználni ezt a CPU-ba épített ASIC-ot, nem tudom pontosan, milyen szoftverek tudják használni, én Badaboom-al szoktam konvertálni, az tudja.

Hmm, ez nekem új volt, kösz az infót. Mondjuk a nagy száguldás mellett kiváncsi lennék a képminőségre is :)

A jelenlegi felállás az, hogy egy videó pultból jön a jel, amit egy nem-opensource kereskedelmi szoftver fogad. Ez a szoftver backendnek FFmpeg-et használ. Az FFmpeg binárist ki tudom alatta cserélni, viszont más nem nagyon játszik.

... vagy, az FFmpeg-et átteszem -acodec copy -vcodec copy-ra, és jöhet a külső célhardver...

lehet, hogy rosszul gondolom, de ő a szoftveréből (annak a kimenetéből) akar újabb streameket előállítani, azaz H.264-ben áll már rendelkezésére az input és nem mondjuk SDI-ban (azaz nem videóbemenetről akar H.264-et), azaz neki olyan célhardver kell ami a H.264->H.264-re ad támogatást, tudtommal ilyen a fentebb már javasolt matrox CompressHD, vagy például az Elgato Turbo.264 HD (bár ez utóbbi csak Mac OS X alatt megy, sokkal olcsóbb, de állítólag (és ez valószínűleg így van) képminőségben gyengébb), (az előbbinek meg van magyar forgalmazója, pld. a Leonardo SNS, én megpróbálnék tőlük egyet tesztre "elhozni", ha van "raktáron"),

bocsánat, most látom, hogy ezt írta az elején: "A jelbemenet terén nem vagyok válogatós, felőlem lehet HDMI, SDI,...", azaz félreértettem,

( uid_18313 | 2013. 03. 19., k – 11:51 )

ha sok pénzed van és klaszterben is gondolkodsz, akkor esetleg a Telestream Episode Engine-re is vethetsz egy pillantást (bár gondolom ez a te esetedben ágyúval verébre, bár ki tudja)

Jobb ötletem viszont ebben a kategóriában nincs. Vannak broadcast encoderek (Cisco, Nevion, stb.), de azok 15-20k euro körül vannak, az meg elég húzós, bár ez relatív...

----------------------------------------------------------------------------------------------------
Hármas........alá............kettes.........................egyest írtam be.

már korábban "szemezgettem" vele, de úgy-e hivatalosan nincs belőle próbaverzió, a nem pro-ban meg nincs H.264 enkódolás,

neked van vele valamilyen gyakorlati tapasztalatod?

hagyományos filmes utómunkával, vágással foglalkozom, rengeteg programot kipróbáltam már, de még mindig nem találtam meg azt, amelyikkel elégedett lennék,

persze tudom, sosem elég a kódolás gyorsasága, mert megszokja az ember és emiatt egy idő után lassúnak tűnik, de sokszor azt érzem, hogy rengeteg "felesleges" kört futok, például az általam általában használt vágóprogramból a H.264-es mov lassabban jön ki, mintha előtte QuickTime reference mov-ot exportálnék, majd abból QuickTime Pro-ban végezném a H.264-es enkódolást ugyanazokkal a beállításokkal (mint a vágóprogramban),

a "finomhangolásról" meg ne is beszéljünk, az ffmpeg-ben "elveszik" az ember, a ráírt GUI-k meg nem sok pluszt adnak, sőt néha bosszantó, hogy 1-1 program megpróbálja "elfedni/eltakarni" azt, hogy valójában csak egy felület az ffmpeg felett,