A tökéletes videolejátszás nyomában, Linuxon

Nehéz azon paranoidok élete, akik videót akarnak nézni Linuxon. Magamon diagnosztizáltam a kórt, amihez minden háttértudásom Dr Mágenheim és Dr House adta, azt hiszem, súlyos. Nézem a TV-t a gépemen, egyenletesen úszik a kamera, egyszercsak mit látok!? HÉÉÉ, ONNAN KIMARADT EGY KÉPKOCKA! Ilyenkor elönti az agyam a kétség - úristen, mi lehetett azon a képkockán?! A kormány agykontrollkísérlete? Egy farok Tyler Durdentől? Mandzsúriai jelölt vagyok-e, meleg leszek-e holnapra??

A magyarázat -általában- egyszerűbb: a tökéletesen időzített videólejátszás Linuxon kihívás. Utánajártam.

A videólejátszás hardveres gyorsítása manapság alapigény. Bár a legmodernebb processzorok simán megoldják nyers erőből is, jó sok áramot zabálnak- és hőt termelnek közben, ezért nem lehet közönyös az embörfija. Azt ugye mindenki fújja, hogy 2 életképes, applikációk által közvetlenül használt API van videógyorsításra: a VAAPI az Inteltől és a VDPAU az Nvidiatól (az AMD XvBA-ja nem lett kedvence egyik nagy playernek sem, mivel kezdetben zárt vala).

Igen ám, de a disztrók által szállított alkalmazások ritkán támogatják mindkettőt: a VLC csak a VAAPI-t, az Mplayer csak a VDPAU-t, a Gstreamer és a Xine 1.1 egyiket se. És itt jönnek a különböző branchek, patchek, pluginok:

  • Mplayer VAAPI: csak egy hack, nem alkalmas beolvasztásra, az mplayer fejlesztőket nem is igazán érdekli a VDPAU mellett.
  • Xine 1.2 VAAPI: a Xine körül mára eléggé elfogyott a közösség és a VDPAU-t már beolvasztották mainline, a VAAPI beolvasztással senki nem foglalkozik, érdektelen.
  • Gstreamer VAAPI: jelenleg instabil, de dolgoznak rajta.

Ez utóbbiakat a nagy disztrók tudtommal nem szállítják, derékig el kell merülni a córeszba, hogy feltedd a rendszerre.

A Xine 1.2 (fejlesztői ág) már tartalmazza a VDPAU-t, de nem lehet tudni, hogy mikor jelenik meg. Sajnos a legjobb DVB kliens épp ezt használja: a Kaffeine. A Gstreamer felvette a gstreamer-plugins-bad alá a VDPAU támogatást mainlineba, de a plugint nem szállítja se az Ubuntu se a Fedora, gondok vannak vele. További érdekesség, hogy a Flash 10.2 óta a VDPAU-t kezdte támogatni, de egyelőre csak a 32 bites verzióban.

Szóval a helyzet nem idilli. Szerencsére a VAAPI a VDPAU-t és az XvBA-t is tudja backend-ként használni, azaz amelyk alkalmazás ismeri a VAAPI-t, az kihasználhatja az Nvidia, AMD, Intel grafikus kártyák videógyorsítását is, de sajnos a VAAPI sem élvezi a disztribúciók és az alkalmazások széles körű támogatását, mondhatni csak a VLC-vel megy out-of-box, egyelőre. Mellesleg a VAAPI VDPAU backendet a Fedorahoz csak az rpmfusion szállítja, a vdpau-video-freeworld csomagban.

(Ez bizony remek alkalom elmondani a mondókát a Linux fragmentáltságáról és API helljéről, de jobban örülnék, ha esetleg valaki az fejtené ki, hogy miért megy ennyire nehezen a patchek beolvasztása, miért mindent külső forrásból kell összevadászni.)

Nnna, összehoztunk egy működő hardveres gyorsítást, szóval, jöhet egy újabb saller: a kompozit desktop teljesítménye nem kedvez a tökéletes videó időzítésnek: elég egy glxgears-t elindítani és a Geforce 9500GT-n már látszik is (nálam), hogy ki-kihagy és persze nincs ez másképp a videóknál sem, hardveres gyorsítás ide vagy oda.
Ezt tudják a kompozit WM készítők is, ezért KDE és Compiz alatt van egy olyan feature, hogy "unredirect fullscreen windows". Ez a teljes képernyős ablakoknál megpróbálja kikapcsolni a kompozit megjelenítést, ami annyiból hátrányos, hogy bármilyen popup ablak vagy menü megjelenítéséhez vissza kell kapcsolni a kompozit módot, ami miatt átalában villan egyet a kép, nem kellemes. Ez megoldja a kompozit desktop (azaz offscreen rendering) miatt fellépő időzítési problémát, de csak teljes képernyőn és csak a fent említett környezetekben - ilyen kapcsoló Gnome3 alatt egyelőre nincs.
Ezen a területen megoldás sem várható, hacsak azt nem tekintjük annak, hogy ordenáré gyors videókártyát kell venni. A KDE 4.7 kwin-je még kecsegtet némi reménnyel, de a jobb ablakos videólejátszás esetleg csak a mellékhatása lesz az általános gyorsulásnak.

Az Adobe Flash egyébként OpenGL-t használ a megjelenítéshez, ami gyengébb 3D kártyákon már önmagában ok a szaggatásra, kompozit desktop nélkül is.

Ha már ilyen szépen belefolytam, akkor essen szó az interlaced videókról is. Pl a TV műsorök általában interlaced módban jönnek, mert azt folyamatosabbnak látjuk, mint a progressive videót (a modern megjelenítő eszközöknek több információt szolgáltat az extrapoláláshoz). Számítógépen a doubler deinterlacer algoritmusok tudják leginkább visszaadni a TV minőséget, ezek az eredeti fps duplájával vetítik a képet a monitorra, azaz (nálunk) 50fps lesz a történés. Ezt azért hoztam fel, mert a VLC alapból nem doubler deinterlacer algoritmust használ, azt külön be kell kapcsolni (ajánlom a yadif2x-et), az mplayer pedig csak VDPAU-val használ doublert alapból. A különbség pedig ég és föld, ha TV-t nézel a gépen. A VDPAU és a VAAPI egyébként képes a hardveres deinterlacingre.

A tévedés jogát fenntartom, javarészt emlékezetből írtam, főleg azért, hogy ne kelljen emlékeznem rá, amíg újra elő nem veszem ezt a témát. Ha esetleg valakinek segít eligazodni, egészségére. :)

( asrob v | 2011. 07. 09., szo – 08:18 )

Jó kis írás, gratulálok hozzá. Egy kicsit arról hogy a Fedora miért nem szállít különböző dolgokat....
https://fedoraproject.org/wiki/ForbiddenItems

Itt tökéletesen le van írva miért nincs mp3 "plugin" stb-stb, miért csak külső tárolóból(rpmfusion) érhető el.

-freeworld -ből arra következetetek hogy valami jogi dolog lehet a háttérben. De van egy két érdekes linkem ezzel kapcsolatban még, http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2010-Septembe… és https://fedoraproject.org/wiki/Packaging:Guidelines#Packages_which_are_…
Remélem segítenek ;)

( kirsa74 | 2011. 07. 09., szo – 09:45 )

A UNIX attitud teljes pompajaban :S

( subchee | 2011. 07. 09., szo – 10:38 )

Ritka pillanatok egyike: szakmai tartalom. Grats

( dii | 2011. 07. 09., szo – 12:17 )

A jó kombináció, nálam KDE + Radeon 5600 + archlinux/smplayer kielégítő minőséget ad. Korábban én is boldogtalan beállítás kattintgató voltam, főleg a HD videók miatt.

Ez most nem egy works4me hozzászólás, hanem kiegészíteném még egy dologgal ami engem halálra idegesít, lehet hogy ti csípőből lövitek a megoldást. A Blueray és egyéb HD ripek kapcsán fordul elő a probléma a hanggal. Mi is a gond? Sima sztereó hangcuccot használok, nincs igényem többre. Lejátszóban beállítva hogy sztereó, de a sok csatornás hangból valami rém fura módon lesz két csatorna.

A dialógusok és az effektek hangereje iszonyú különböző. Gondolom a front csatornán beszélgetnének, és hátulról vagy minden irányból jönnének a robbanások, de ez két csatornára mixelve élvezhetetlen. Ha felhangosítom annyira, hogy a beszédet szépen halljam, a szomszédokat sokkot kapnak az akció jeleneteknél.

Ez ügyben van valami jó orvosság? Vagy maguk a ripek rosszul szedték le a hangsávokat?

Az pedig elvileg nem hardvergyorsításos konfig.

A hangra esetleg equalizátor? Mozifilmet csak TV-n nézek ahol az erősítő dekódolja a hangot, de egyébként ott is ez van, hogy az effektek döngetik a falat, miközben a beszéd csak közepes hangerő. Ott a "night mode" bekapcsolásával oldom meg.

nálam ez van az mplayer config-jában: 

channels=6
af=pan=2:.7:0:0:.7:.7:0:0:.7:1:1:.5:.5

persze ízlés szerint át lehet írogatni. engem pl a robbanások nem érdekelnek annyira, úgyhogy arra törekedtem, hogy inkább a beszéd legyen domináns

---------------------------------------------------------------------------------------
Unix is simple. It just takes a genius to understand its simplicity. — Dennis Ritchie

( turul16 v | 2011. 07. 09., szo – 16:20 )

Es mi lett azzal az iranyal, hogy tobbi gyarto(intel) is tamogatja VDPAU -t ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Elhalt, az Intel a VAAPI-ra kattant rá, az AMD is megy a saját feje után. Egyelőre szerintem elég kiegyenlített a küzdelem, nem úgy tűnik, hogy rövidtávon győztest lehetne hirdetni. Esetleg az open-source Nvidia, AMD driverek dönthetnék el a csatát, de azok leginkább még egyiket se támogatják.

( Byron | 2011. 07. 09., szo – 19:49 )

Jéé, egy sorstárs.
Évek óta ezzel szívok (egyébként nem, mert élvezem), a videóra nagyon kényes vagyok, de a tökéletes megoldás még messze van.
Annyi a könnyebbség, hogy a lapomban levő nVidia már 2 éve vdpau-val nyomja a kontentot, de kezdetben a tearing akasztott ki, kiirthatatlan compiz alatt, most a Gnome3 ezt a gondot levette a vállamról, HD pipa.
Marad a TV-vel szívás. A Bob deinterlacer nekem megfelelő, de valamiért az SD tartalom iszonyúan megy mplayer alatt, lehet, hogy csak a parancsom hiányos (VB óta nem nagyon jön be az ablakon normális HD adás, ami miatt oda is tekerném a csatornadekóder oszcillátorát ). Eleve elvetélt ötlet TS-t mplayerrrel nézni (judder-es, szakadozik, néha elfelejti dekódolni a makroblokkokat és csak valami random adatot kipakol a mozgásvektorokkal pozicionálva, ami mondjuk vicces, de nem szép), amíg rá nem találtam a -correct-pts kapcsolóra, nem is használtam.
Jelenleg így megyek neki a Forma1-nek:
mplayer dvb:\\"RTL Klub" -cache 3000 -vo vdpau:deint=2 -correct-pts
Régebben ez kielégítő minőséget adott, de most Arch-ot használok, ki vagyok téve a friss build-ekben levő újabb bugoknak (pár hete újra judder-es lett az eredmény, meg a régi SVN hiba is visszajött, hogy ha pause-t nyomok, nem indul újra el, csak tekerésre), sajátot meg hiába fordítok, SVN-ben van bug, stabilban van bug, amik érintettek engem (reportolhattam volna, tudom, majd talán egyszer), a csomag meg nagyrészt működik.
Hogy miért mplayer? Mivel egyik lejátszó sem tökéletes (mielőtt még valaki megemlítené, Winen sokkal rosszabb a helyzet, talán csak a postprocessing kiforrottabb) és itt a legtöbb a nyúlkálási lehetőség, addig ragaszkodom hozzá, meg egyébként az esetek 95%-ában már kiválóan működik minden.

VDPAU deinterlacer hogyan? Vagy a fenti mód pont ezt csinálja?

Oh igen, a tearing, az is megérne egy posztot önmagában, nem egyszerű téma, sajnos.

Az mplayer TS támogatása nem valami kiforrott, ezt én is tapasztaltam. Korábban volt egy külön posztom a DVB-ről. Én a Kaffeine-t kezdtem el használni (kellett a CAM támogatás), de a Xine 1.2 fordítása a VDPAU-hoz elég gyötrelmes, emiatt most már úgy csinálom, hogy gnutv -vel hangolok és dekódoltatok, aztán vlc-vel nézem/streamelem a /dev/dvb/adapter0/dvr0 -t, egy IRC bottal pedig tudok csatornát váltani. :) Ez annyiból jó, hogy bármilyen lejátszóval működik, nem kell a playerbe DVB támogatás. A posztban még szapultam a vlc-t, de kezdem megkedvelni, az említett hibát javították, nálad nem jöhet szóba?

Az mplayer parancsod a hardveres VDPAU deinterlacert használja egyébként.

Szoktam VLC-vel is próbálkozni, de a lépésenkénti pan-scan (csak aspect cut-off van), a felirat tekergetés, pakolgatás, 21:9 esetén fekete sávba rakás még mindig hiányzik belőle, így mindenre nem jó. TV-nél meg az a baj, ha a tekerésbe belebolondul (elveszik az ajakszinkron), akkor nem áll helyre (correct-pts, khm), kézzel meg nem lehet belenyúlni. A másik meg, hogy ez a gnome3 annyira kiforratlan, hogy sehogy sem akarja nem kikapcsolni a monitort lejátszás közben, ha a tartalom egy qt-s progiból jön.
A továbbstreamelés helyett én inkább dumpolni szoktam a csatornát, így legalább kimehetek sörért, ha akarok.

Remélem, egyről beszélünk, ez itt DVB-T kecskeméti frekvenciákkal (csak az elejét kell átírnod):

RTL Klub:658000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:1070+1071+1072:107
TV2:658000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:1080+1081+1082:108
DunaTV HD:826000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:2000+2001+2002:200
Autonomia:826000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:2010+2011+2012:201
Euronews:658000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:1090+1091+1092:109
m1 HD:658000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:1000+1001+1002:100
m2 HD:658000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:1010+1011+1012:101

Keress rá az aac szóra és tedd fel az összes codec-et, hátha.

Köszi, működik. Ha valakit érdekel a különbség a végén a PID-ek felsorolásában van:
scan kimenete:
[...]:videó:hang:szolgáltatás
mplayer:
[...]:pmt+videó+hang:szolgáltatás
(pmt=videó-1, legalábbis jelenleg dvb-tn)
Viszont csaknem minden tekintetben használhatatlan (SVN-r33161) DVB-T-re:
-Autonómia/Duna HD megy
-m1 HD/m2 HD Ajakszinkron nincs (tekerés se gyógyítja meg)
-TV2/RTL/Euronews összeomlasztja ("MPlayer interrupted by signal 11 in module: decode_audio")

És ezzel vissza is értünk az AAC problémára. Egész pontosan az HE-AAC-t nem tudja lejátszani LATM containerben szinte semmi, ezt viszont szinte kizárólag nagyon modern DVB-T-n és DVB-S2-n használják, ezért nem sietnek a megoldással (nálunk csak a fenti 3 csatornán van kizárólag HE-AAC/LATM, az m1/m2 két hangsávot ad, a dunák meg csak mp3-mat).
VLC/mythTV megy.

Ja és a vaapi radeon5770-en még mindig nem képes bizonyos tartalmakat rendesen dekódolni, ilyen pl a magyar dvb-t hdtv (bezzeg az sd megy).

Ha valaki ezekre tud esetleg megoldást, szóljon. Arch linuxot használok btw

( goodbyte v | 2011. 07. 10., v – 15:02 )

Ennek a postnak az olvasása után gondoltam kipróbálom én is a vdpau kimenetet mplayer alatt. Tesztnek a jól bevált big_buck_bunny_1080p_stereo.ogg-t választottam.
De ahogy elnézem a CPU használatban csak 5-6% különbség van az XV-hez képest? Hogy lehetséges ez?
Mit csinálok rosszul?
'mplayer -vo vdpau big_buck_bunny_1080p_stereo.ogg'-vel indítottam a lejátszást.

$ vdpauinfo
display: :0.0 screen: 0
API version: 1
Information string: NVIDIA VDPAU Driver Shared Library 275.09.07 Wed Jun 8 14:37:53 PDT 2011

Video surface:

name width height types
-------------------------------------------
420 4096 4096 NV12 YV12
422 4096 4096 UYVY YUYV

Decoder capabilities:

name level macbs width height
-------------------------------------------
MPEG1 0 8192 2048 2048
MPEG2_SIMPLE 3 8192 2048 2048
MPEG2_MAIN 3 8192 2048 2048
H264_MAIN 41 8192 2048 2048
H264_HIGH 41 8192 2048 2048
VC1_SIMPLE 1 8190 2048 2048
VC1_MAIN 2 8190 2048 2048
VC1_ADVANCED 4 8190 2048 2048

Output surface:

name width height nat types
----------------------------------------------------
B8G8R8A8 8192 8192 y Y8U8V8A8 V8U8Y8A8
R10G10B10A2 8192 8192 y Y8U8V8A8 V8U8Y8A8

Bitmap surface:

name width height
------------------------------
B8G8R8A8 8192 8192
R8G8B8A8 8192 8192
R10G10B10A2 8192 8192
B10G10R10A2 8192 8192
A8 8192 8192

Video mixer:

feature name sup
------------------------------------
DEINTERLACE_TEMPORAL y
DEINTERLACE_TEMPORAL_SPATIAL y
INVERSE_TELECINE y
NOISE_REDUCTION y
SHARPNESS y
LUMA_KEY y
HIGH QUALITY SCALING - L1 -
HIGH QUALITY SCALING - L2 -
HIGH QUALITY SCALING - L3 -
HIGH QUALITY SCALING - L4 -
HIGH QUALITY SCALING - L5 -
HIGH QUALITY SCALING - L6 -
HIGH QUALITY SCALING - L7 -
HIGH QUALITY SCALING - L8 -
HIGH QUALITY SCALING - L9 -

parameter name sup min max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH y 1 4096
VIDEO_SURFACE_HEIGHT y 1 4096
CHROMA_TYPE y
LAYERS y 0 4

attribute name sup min max
-----------------------------------------------------
BACKGROUND_COLOR y
CSC_MATRIX y
NOISE_REDUCTION_LEVEL y 0.00 1.00
SHARPNESS_LEVEL y -1.00 1.00
LUMA_KEY_MIN_LUMA y
LUMA_KEY_MAX_LUMA y

------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"

( goodbyte v | 2011. 07. 10., v – 18:18 )

Ezek szerint sima DivX, Xvid tartalmakat nem tudnak ezek az API-k hardware-esen gyorsítani?

------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"

( vtechun | 2011. 07. 17., v – 07:41 )

Atom procis gepen, archlinuxon van nekem htpc. Xbmc a szoftver, tvheadend a dvb-t backend.
Xbmc-t probaltad mar? 1,5 eve ezt hasznalok, teljes megelegedessel, a hang HDMI-n megy ki az erositobe. Minden tokeletes - legalabbis nekem jonak tunik :)

A nagyon alacsony fogyasztás (kb 10W), a méret (kb 10x10x4cm) és a hackelhető firmware meggyőzött, igazából mindent tud ami nekem kell (UPNP, 24Hz, OpenVPN, linuxshell), sőt, pl a fullscreen movie sheetek kezelését imádom benne, az XBMC akkoriban ilyesmit még nem tudott (azóta nem tudom mi a helyzet). Az XBMC nekem rendes PC-n futott, a zaj, a fogyasztás, a méret horribilis volt ehhez képest.

Xbmc generalja, lehet tobbek kozott themoviedb, imdb vagy akar port.hu scrapert beloni, szoval akar magyarul is leszedi az infot. Sot, ami megjobb, hogy vannak feliratscraperek is, es ebben is van magyar, a feliratok.info, nagyon jo, ezert tervezem egy appletv2-es vasarlasat, a mostani htpc meg lehetne nas. Errol irtam is a szemelyes blogomban.