Az UHU-Linux által támogatott fejlesztők bemutatkozása

Gereöffy Árpád előadása: Az MPlayer videólejátszó bemutatása

Én az MPlayer-ről fogok beszélni, amely egy videó lejátszó program, elsősorban LINUX alá, de ma már szinte minden UNIX-like platformon fut, beleértve a BSD-ket, Solarist és a MacOS 10-et is.

A project elsődleges célja az internet fejlődésével egyre elterjedtebbé vált video formátumok, így az MPEG, QuickTime, Windows Media, RealVideo lejátszása, de mára már ezt a célt túlteljesítettük, nem csak hogy kevesebb erőforrást igényel a lejétszéshoz, mint a formátumok eredeti lejátszóprogramjai, de ezen felül jobb a hibatűrése, stabilitása, sőt, akár át is konvertálhatókak vele ezek a file-ok nyílt szabványú formátumokba.

Amikor elkezdtem, még nem volt használható video lejátszó linuxra, nemhogy olyan, ami egyben mindent le tudna játszani. Azóta egyébként készült elég sok program, ami már így hasonló szinten van.

Az MPlayer fejlesztése két éve kezdődött, egyedül álltam neki, viszont pár hónap alatt - köszönhetően annak, hogy nyílt forráskóddal indítottam, és a 0.01 verziótól kezdve ez az interneten elérhető volt, elég hamar sokan bekapcsolódtak a fejlesztésbe. Gyakorlatilag fél év alatt egy világméretű program lett, sőt a mai napra már majdnem 30 fő fejlesztő teljes szabadidejében az Mplayeren dolgozik, és több százan küldözgetnek különböző patcheket, javításokat is.

A diagramon a piros vonalnál látható a letöltések száma, látszik, hogy az elmúlt másfél év alatt ez igencsak magas értéket ért el. A csúcsértékek mindig egy-egy újabb stabil verzióhoz köthetők.

A sárga görbe a kódhoz havonta hozzáadott sorok számát mutatja. Ez, tudom, kicsit relatív mértékegység (microsoftos módszer), mindenesetre nagyjából tükrözi a fejlesztés aktivitását. Ez durván egy éve tetőzött. Azóta inkább nem új dolgokat teszünk bele a kódba, hanem a meglévőket próbáljuk javítani, gyorsítani, de még mindig vannak újabb és újabb funkciók.

A 0.90pre verzió kiadásakor, ami idén április végén, májusban volt, annyira megnőtt a letöltések száma, hogy az egyik legnépszerűbb linuxos portál, a http://freshmeat.net statisztikáján az első helyre ugrott a program. Megelőzött olyan projekteket, mint például a Linux kernel, vagy a nagy konkurens videólejátszó, a xine, de például a GCC és egyéb programok is lejjebb szorultak.

Megint csak vitatható ennek a statisztikának a létjogosultsága, mert általában azok a programok kerülnek ide fel, amik nagy közönséget céloznak meg, vagy amit nagyon sok felhasználó használ, így amelyikben akár több munka van, vagy több fejlesztő vesz részt a fejlesztésben, de ennek ellenére kisebb célközönség használja a programot, azt nyilván nem fogják annyian letölteni, tehát ezek nem is fognak ilyen toplistákra felkerülni.

Elég sok linuxra írt videolejátszó program létezett már két éve is. Amit vastagon jelöltem, az a néhány még a mai napig fejlesztés alatt áll. Amelyeket ki lehet közülük emelni, az az MPlayeren kívűl a xine, illetve az Avifile. Ezek többé-kevésbé lejátsszák a mai médiaformátumokat.

A többi inkább egy-egy formátum lejátszására specializált program. Az ogle például a DVD lejátszást tűzte ki céljául, s abból talán a legjobbnak mondható. Az XMovie inkább a quicktime-os dolgokra koncentrál. Érdemes kiemelni az Open Media Systemet, amelyet gyakorlatilag már több mint egy éve nem fejlesztenek. Ez annak idején, két éve olyan projektnek indult, ami majd összefogja a linuxos lejátszó világot, és egységes szabványt teremt, codec interface-t. Erre azért volt szükség, hogy elkerülhető legyen az, hogy mindenki elkezdi a nulláról ugyanazt megírni. Sajnos kudarcba fulladt a munkájuk, eleinte kicsit túlbonyolították a dolgokat, s utána csak feladat listák maradtak, de nem volt, aki ezt megírta volna. Végül is a projekt elhalt, és kis külön programok fejlődtek tovább.

Nem volt zökkenőmentes az Mplayer útja. A projektet eleinte - amikor elkezdtek többen bekapcsolódni a fejlesztésbe - a SourceForge szerverére raktam fel. Viszont 2001-ben, amikor a VA-Linux-szal problémák voltak, és a cég a csőd szélére került, elkezdték átszervezni magukat, akkor többek között a SourceForge-tól elvonták a pénzt, és ez megérződött rögtön a szolgáltatásaikon is.

Az első és legnagyobb problémánk az volt vele, hogy a CVS szolgáltatásuk kezdett megbízhatatlanná válni. Az anonymous felhasználók CVS letöltéseinél beragadtak időnként lock fájlok, és ez napokig akadályozta azt is, hogy a fejlesztők hozzáférjenek a kódhoz.

A levelező listáikat lassan nem bírták erőforrással, és egyre lassabban jöttek meg a levelek. Egy ilyen fejlesztésnél, online beszélgetésnél elég zavaró volt, hogy az ember válaszolt valamire, azt másfél óra múlva megkapta az illető, az is válaszolt, másfél óra múlva megjött a válasz a kérdésre... Persze lehet mondani, hogy át kellene térni IRC-re és más módszerekre. Tehát a levelező listákkal ez volt a fő problémánk. Végül is ezt próbálták ők úgy orvosolni, hogy a Reply-To mezőt kivették a levelező listákról, hogy a válaszok ne a listákra menjenek, hanem közvetlenül a feladónak, de ezzel igazán nem érték el a céljukat. Továbbá a levelezéseknek archívuma sem volt, tehát nem lehetett visszakeresni, például új fejlesztők nem tudták megnézni, hogy a régebbi diskurzusok miről szóltak. Aztán megszüntették az FTP-t is, ami nekünk elég fontos volt, mert FTP-n tudták a felhasználók az éppen le nem játszható fájlokat feltölteni, s így meg tudtuk nézni, hogy az adott file esetében éppen mi a probléma. Az utóbbi időben elkezdtek egyre több reklámot is feltenni. Addig is voltak banner-ek az oldalon, de addig opensource, ingyenes programokat reklámoztak, és később ezeket fizetett hirdetésekre cserélték le, sőt mostanában már a Microsoft féloldalas hirdetéseit is olvashatjuk.

Ekkor jött a képbe az UHU-Linux. Támogatásuk első lépésében az mplayerhq.hu domain regisztrációval és az MPlayer számra dedikált szervergéppel segítettek minket. Egy hónap alatt átköltözött a projekt erre a szerverre, és a mai napig gyakorlatilag ezen fut. Ezen fut a CVS-től kezdve a web, levelező listák, s minden ilyen szolgáltatás. Ez nem csak azért volt érdekes, hogy megoldódtak a SourceForge problémái, de olyan dolgokat is meg tudtunk oldani a szerveren, amit addig nem lehetett volna. Pl. a CVS-nél a fájl átnevezést, bizonyos műveleteket csak a szerveren shell-ből lehet elvégezni, ezeket a SourceForge nem tette lehetővé. Lehet nagyon sok mindent automatizálni, pl. a napi CVS buildeket, vagy ha valaki módosít a dokumentációban, az rögtön felkerül a webre, sőt küld egy üzenetet a mirror gépeknek, hogy töltsék le, és frissítsék ők is az oldalt.

A későbbiekben folytatódott az UHU támogatása, a fejlesztőknek különböző hardver eszközöket adott az UHU ahhoz, hogy különböző hardvereket tudjunk támogatni. Az UHU előadáson pont erről volt szó, hogy az UHU-Linux is ilyen gondokkal küszködik, nem tudnak mindenféle hardveren tesztelni. Ez a probléma felmerült nálunk is. Szerencsére nekünk nem kell 25 féle hardver típus, igazán egy-két konkrét eszköz fontos, leginkább a videokártyák. Ugyanis a videokártyákhoz a Linux alatt még a driverek elég szegényesek multimédia terén. Az, hogy van kép az Xserver alatt, az még messze nem elég ahhoz, hogy ezen videot is lehessen lejátszani. A videokártyáknak általában képszinkronizálási, pufferezési, scaling, colorspace konverziót és mindenféle olyan belsőbb dolgait is el kell, hogy érjük, amiket az X-es driverek nagyrészt nem tesznek lehetővé. Nekiálltunk, és mi is fejlesztünk a videokártyákhoz drivert, ezekről még lesz szó.

Az UHU-val kapcsolatban elmondom, bár az előző előadásban is elhangzott, hogy régebben ilyen koprodukció volt, tehát ők segítettek hardver eszközökkel, mi pedig cserébe ezeken is teszteltük mind az UHU-Linuxot, mind a saját fejlesztéseinket, s mi is tudtunk nekik segíteni abban, hogy pl. milyen kártyához mely drivereket célszerű használni, mikre kell figyelni a beállításoknál. Illetve még az UHU Linux szponzorálta a GUI fejlesztését is, utánam Ponekker Zoltán fog erről mondani pár szót, illetve megmutatja, hogy mi is az.

Felmerül mindig a kérdés, meg is szokták kérdezni, hogy mi a végcél. Megy a fejlesztés, egyre több kódot írunk, s végül is mikor fogunk megállni, vagy mikor mondjuk azt, hogy kész. Erre többféle választ is szoktak adni. Pl. az egyik, ha azt mondjuk, hogy az 1.0 verziónál abbahagyjuk, de közismert, hogy nincs kész program, csak olyan, aminek abbahagyták a fejlesztését. Tehát valószínűleg nem fogjuk abbahagyni, mindig újabb és újabb ötletek fognak jönni. A felhasználóbarát lejátszó - jó kérdés, valamerre erre haladunk, de nem ez az elsődleges célunk. MPlayer Desktop Environment - ez egy kicsit viccesen hangzik, de fejlesztés közben elég sok problémával találtuk szembe magunkat, hogy legyen szó a CVS-ről, a C-fordítókról vagy akármiről.

Többször merült fel, hogy ebből meg abból sajátot kellene írnunk. Jobb lenne, ha írnánk saját C-fordítót, saját X-terminált stb. S jöttek az ötletek, és ezek előbb-utóbb meg is valósulnak, mint ahogy több minden megvalósult már az idők folyamán. S ha ezekből elég sok megvalósul, akár egy ilyen futurisztikus dolog is elképzelhető. Esetleg - Gabucinot idézve - világuralom. Persze ezt nem kell komolyan venni, sőt, nem célunk a többi lejátszóval konkurálni. Nem célunk azoknak a felhasználótáborát elhódítani, már csak azért sem, mert igazán nincs szükségünk több felhasználóra.

A felhasználók inkább csak gondot okoznak, mint előnyt. Az az igazság, hogy az MPlayer fejlesztése nem egy kattintgatós programnak indult eredetileg, bár most már ezen a GUI javított elég sokat. Ha az ember rendesen tudja használni, s bekonfigurálni úgy, hogy az adott hardvert az utolsó bitig ki is tudja használni, ahhoz nem árt a leírás elég sok részét elolvasni, s az alapján a különböző parancssorokat, beállításokat megcsinálni. Általában a legtöbben ezt nem végzik el, letöltik, beírják, hogy "mplayer", nyomnak egy entert, s rögtön jön a levél, hogy nem működik, segítsetek.

Az a baj, hogy a felhasználók 99%-a ilyen, s nagy részük meg is írja ezt a levelet. Nos, a felhasználóknak körülbelül az egy ezreléke az, akik ténylegesen segítenek, akik tényleg bugreportolnak. Akik küldenek olyan fájlokat, amelyet le kellene tudnia játszania a programnak, és például más programok lejátsszák, ez nem. Meg tudjuk nézni, mi okozhatja a hibát, ki tudjuk-e javítani, illetve ezek a felhasználók tudnak írni újabb hardverekről, amelyeket esetleg nem támogatunk. Ezek esetében megnézzük, hogyan lehetne módosítani, míg mások küldenek esetleg patch-eket.

Inkább kooperálunk a többi programmal, minthogy elhódítanánk a felhasználóikat. Más a felhasználói táborunk, más a célunk, más a célja az MPlayernek, más a célja a xine-nak, más a Avifile-nak. Az opensource projektek is azért élnek ma még párhuzamosan, mert különböző célkitűzéseik vannak. Ha ugyanaz lenne a céljuk, akkor nem létezne annyi program. Ehelyett inkább közösen dolgozunk különböző projekteken, olyasmin amire mindenkinek szüksége van, és végül is minden programban megtalálható.

Például az avifile-osokkal közösen fejlesztettük ki a DLL betöltőt. Ennek az a lényege, hogy a Windows alá írt video és audio kodekek használhatók ennek segítségével Linux, BSD, Solaris alatt az x86 platformon. Gyakorlatilag kicsit trükkös megoldás, a Wine és a Wabi windows emulátoroknak egy része van felhasználva. Ennek az a lényege, hogy a DLL-t úgy be tudja tölteni Linux alatt, mint egyéb linuxos dinamikus libeket. Ha egyszer betöltötte, az majdhogynem működik is, mert a codecnek nincs nagyon szüksége a windowsos funkciókra. Tehát nem fog ablakokat kirakni, nem fog különböző windows-specifikus dolgokat csinálni, általában csak valami adathalmazból átkonvertál valamit egy másik adathalmazba. Viszonylag minimális windows függősége van, ezt a pár alapfunkciót emulálja ez a lib.

A VideoLAN-nal közösen dolgoztunk a dvdread, dvdcss kódon, ez a DVD-k olvasásához volt szükséges. Elsősorban ők fejlesztették, de utána mi is küldtünk rá patch-eket. A xine-től vettük át az SVQ1 videó kodeket, ez egy Quicktime formátum, a Sorenson 1 dekódere. Végül is ők fejlesztették valamennyire ki, igaz, hogy egy volt MPlayer fejlesztő segítségével, illetve ők is vettek át tőlünk különböző kódokat. Az FFMpeg projekttel közösen dolgozunk a libavcodecen, ez egy opensource kodek gyűjtemény, ami a mai elterjedt MPEG4, MPEG1/2, MJPEG, H.263 video, illetve mostanában már windows média video, windows média audio formátumokat is tudják dekódolni.

Az OMS projektből - amiről említettem már, hogy megszűnt - vettük át az MPEG2, illetve AC3 kodeket, amelyek DVD lejátszáshoz voltak szükségesek. Ezek mára már eléggé továbbfejlődtek, optimalizáltuk ezeket. Most már libac3 helyett liba52 van, ez már egy újabb változat. A volt mpeg2dec projekt libvo-ján alapul az MPlayer libvo-ja is, illetve túl sok köze nincs már hozzá a nevén kívül, mert eléggé át lett írva, de nyomokban felfedezhető az örökség.

A legfontosabb különbség mégis a programok között, s azt hiszem, az MPlayer egyedülálló tulajdonsága, hogy az egész program egy szálon, egy processzben fut, míg a legtöbb más lejátszó több szálon. Tehát külön szálon megy az audio dekódolás, külön szálon a video dekódolás, külön szálon a video megjelenítés, külön szálon a vezérlés stb. Tehát ők mindent külön vontak, mi viszont egy szálon oldjuk meg az egész feladatot. Sokan vitatják, hogy ez jó vagy sem.

Itt elmondanék néhány érvet. Első lépésben, legyen akármilyen jó az operációs rendszer scheduler-je, tehát az időzítője, az soha nem fogja pontosan tudni, hogy nekünk most hangra, képre vagy mire van szükségünk a folyamatban. Ezt a lejátszó kernelje tudja gyakorlatilag, az pontosan meghatározza, hogy melyik bufferban mennyi hely van, hogy most éppen videót vagy audiot akarunk dekódolni, ha jött egy parancs a felhasználótól és azt végre kell hajtani. Tehát a legjobb, ha a program maga időzíti ezeket a feladatokat, s nem bízzuk ezt az operációs rendszerre. Egy másik probléma az is, hogy a 2.2-es kernel - ami még akkor volt, amikor ezt elkezdtem fejleszteni - de végül is a 2.4-es kernelben sem olyan túl megoldott ez, azaz a szálak, illetve a processzek közötti kapcsolás elég időigényes. Ugye nem arra kell gondolni, hogy néhányszor átkapcsolunk, hanem mondjuk egy 30 FPS-es video lejátszásakor plusz még hang dekódolásnál ez több száz átkapcsolást jelenthet másodpercenként, s tekintve, hogy a Linux időzítője, legalábbis a 2.4-es kernelig 100 Hz-en működik, ez nagyon kevés a video lejátszásra, gyakorlatilag 33, illetve 40 millisecenként kellene váltanunk. Ehhez a 10 millisec pontosság kevés volt.

A 2.5-ös kernelbe bekerült a gyorsabb szálváltás, azt hiszem, átállították 1000 Hz-re az alapfelbontást is, tehát valamennyire közelítenek, de igazából nem látjuk értelmét, hogy emiatt többszálúra átírjuk a programot. Másrészt, amellett, hogy a taskváltást megspóroljuk, van még egy hátulütője, azon kívül, hogy az operációs rendszer hogyan kezeli le. Ezek a kodekek már elég jól ki vannak optimalizálva a CPU CACHE használatára. Nem tudom, ki mennyire van benne elvi szinten az Intel platform programozásában, de itt, főleg az újabb processzorokban már külön lehet CACHE vezérlő parancsokat kiadni, hogy miket töltsön be előre a CACHE-be, ki van arra élezve, hogy mi van az elsődleges, mi a másodlagos a CACHE-ben, és úgy van optimalizálva a kód, hogy a regisztereken túl pl. a CACHE-re is számít, hogy abban éppen mi lesz, s azt gyorsan fogja elérni. Viszont taszkváltás esetén a CACHE törlődik, és a másik taszk fogja újra tölteni az adataival, emiatt ez nekünk nem túl nyerő, mivel ilyenkor sűrűn váltunk taszkot. Mondjuk egy video frame dekódolása közben kétszer-háromszor átváltunk, akkor állandóan törlődik a CACHE, és kezdhet minden adatot újra betölteni. Ez elég időigényes, és ezek a memóriák nem túl gyorsak. További előnye az egyszálú megoldásnak, hogy tisztább, átláthatóbb lett a kód, tehát nem kell több szálban gondolkodni, nem kell több szálat egyszerre összehangolni, ezek között mutexelni illetve lockolni, megmondani, hogy mikor melyik szál a másikat nem szakíthatja meg stb.

Tehát ezeket a problémákat gyakorlatilag mind megúsztuk, s mivel ennyire egyszerűsödött a kód, gyakorlatilag a hiba is kevesebb benne, és a stabilitása jelentősen javult, legalábbis hasonló problémákkal mi nem találkozunk. Egyszerűbb lett így a hibakeresés is: egy szálon fut a program, van egy adott feladat lista, amit végre kell hajtson, ha valahol megáll, meg lehet nézni, hogy miért ott állt meg. Amikor több szál fut egyszerre, akkor lehet, hogy az egyik szál okozta a másik hibáját, ezeket mi megússzuk.

Van persze egy nagy hátránya is ennek a dolognak, az, hogy a multiprocesszoros gépeket nem lehet kihasználni. Viszont ha jobban belegondolunk, az nem nagy probléma, mert végülis az MPlayert nem szervereken szokták futtatni. Itt egy videolejátszóról van szó, desktop gépekre nem annyira jellemző, hogy több processzor lenne bennük, márpedig ha több processzor is van bennük, általában egy processzor is több mint elég, a videodekódoláshoz, tehát nincs igazán kihasználva még az az egy processzor sem, nemhogy szükség lenne még egyre. Azt esetleg lehet addig más programok futtatására használni, vagy több MPlayert lehet futtatni egyszerre.

Jelenleg a Linux alatt lévő lejátszók közül az MPlayer támogatja a legtöbb videoformátumot, röviden átfutva rajta: - a szabványos MPEG 1, azaz Video CD, MPEG 2-es, ami a DVD, DVB, és használható az MPEG4 is. Az MPEG4 alatt az összes általunk ismert MPEG4 kodeket, beleértve a DivX variációkat, Microsoft "MPEG4" verzióit mind támogatjuk, legalábbis, amik eddig vannak rendelkezésünkre fájlok, ezeket mind tökéletesen lejátssza.

A windows alatt elterjedt AVI fájlformátum végülis inkább csak ilyen nagyon tág definíció, mert az csak a fájlformátumot adja meg, azon belül szinte bármilyen kodek használható, de miután a windowsos DLL-eket is támogatjuk, így gyakorlatilag szinte minden fájl lejátszható. Nagyon kevés olyan DLL van, amivel esetleg problémák vannak, mert pl. 16 bites windowsra írták és nem működik a mi emulátorunkkal.

Az utóbbi időben elterjedt a windows média audio/video, korábbi nevén az ASF formátum. Ebből is a 7, 8-ast gond nélkül le tudja játszani. A 7-es videohoz, illetve a 7, 8-as audiohoz most már van natív kód is, nincs szükség a DLL-ekre. A 8-on még dolgoznak, de az is előbb-utóbb meg lesz oldva. Az utóbbi időben megjelent a 9-es változat, azt hiszem, még csak béta változatban windowsra, ez még nagy kihívás számunkra, miután változtatott a Microsoft a kodek formátumon, tehát nem kompatibilis a korábbi DLLekkel, tehát egy újabb interface-t kell majd írnunk hozzá.

RealAudio, RealVideo: elméletileg az összes verziót támogatjuk, a régebbi verziókhoz van natív dekóder, az újabb verziókat a lejátszóhoz adott végülis bináris pluginek felhasználásával tudjuk lejátszani. Megjegyzendő, hogy ezek nem csak x86 platformon működnek, a lejátszót nagyon sok platformra kiadták, minden platformra az adott platformú pluginjeit lehet betenni alá.

A Quicktime formátum a Macintoshtól ered, szintén lejátszható. Itt probléma van a kodekekkel, miután elég extrém és általában zárt szabványú kodekeket használnak. Itt néhány régebbi formátum vissza van már annyira fejtve, hogy ezek lejátszhatók, de pl. a Sorenson 3, illetve a QDM audioval még gondok vannak. A napokban dolgozunk egyébként azon, hogy a windowsos Quicktime lejátszó pluginjeit fel tudjuk használni, így ezek is lejátszhatók lennének legalább az x86 platformon.

Vivo 1, 2 - talán valaki még emlékszik rá, néhány évvel ezelőtt volt windowson elterjedt formátum. Az utóbbi években kihalt a közéletből, főleg az ASF-nek köszönhetően.

A Sony digital video, a DV formátumhoz most van kb. négyféle dekóder, ebből két nyílt forráskódú és két DLL, lehet válogatni, különböző sebességűek, illetve tudásúak.

Illetve van elég sok régi fájlformátum: különböző játékprogramok fájlformátumai, illetve ritkábban használt média szerkesztő programok saját formátumai, azokat is általában le tudja játszani, ezeket általában nem mi írtuk, hanem az ilyeneket igénylő felhasználók készítették a patch-et és küldték el nekünk.

Az MPlayernek van még egy nagy erőssége a többi lejátszóhoz hasonlítva: a kimeneti formátumok, az output eszközök támogatása. A legtöbb lejátszó X11-et igényel, s azon belül is egy-két funkciót tud kihasználni. Mi az X11-ből kihasználjuk gyakorlatilag az összes lehetőséget, tehát mind a sima XImage-s XSHM módot, mind az Xvideo-t, ami a 4.X-el került bele. Ha az OpenGL-hez van megfelelő hardver gyorsítás, akkor azt is lehet használni video lejátszásra, illetve DGA1, DGA2 verziót is teljes képernyős lejátszásnál. Ezenkívül, ha nincs X11 a gépen, vagy nem szeretnénk használni - beágyazott rendszereknél ez gyakori probléma -, akkor használható a Linux framebufferje, az SVGAlib, tudja a program használni a kártya VESA BIOS-át is, gyakorlatilag semmilyen linuxos driverre nincs szükség: még ha nincs a kártyához linuxos driver, akkor is működhet a dolog, egyszerűen DOS emulációs módon keresztül a VGA kártya BIOS-án keresztül bekapcsolja a grafikus módot, lekérdezi a paramétereit, és közvetlenül a kártya memóriájába ír. Így végül is minden kártya vezérelhető vele.

Mi is fejlesztettünk hozzá drivereket, ezekről mindjárt szó lesz. Például ilyen az mga_vid, ami a Matrox videokártyához írt speciális driver. Vannak még ilyen köztes libraryk, amit wrappereknek hívunk, más interface-k és a program közötti áthidalást végzik. Ilyen az SDL, a GGI, DirectFB, illetve az általunk fejlesztett Vidix. De ilyen a szöveges módokra kitalált AAlib is. Hardveres dekóder kártyákat is támogat a program, illetve képkockánként ki lehet képfájlokba is menteni a videot, ha valaki ilyesmit szeretne művelni.

Említettem a video drivereket. Az mga_vid a Matrox G200 és afölötti kártyáit támogatja. Itt az a nagy problémánk (ezért is kezdtünk neki saját magunk video drivereket írni), hogy bár az utóbb pár év alatt elég sokat fejlődött a video driverek minősége, illetve támogatottsága, de még mindig messze vannak attól, hogy teljes mértékben ki tudják használni a kártyák videolejátszási képességét. A Matrox videokártyák hardveresen négy video buffer között tudnak maguktól kapcsolni amikor az elektronsugár visszafelé fut (tehát a vertikális retrace idő alatt), így a képen tehát nem látszanak csíkozások, villogások. Illetve a videokártya RAM-jába is lehet tenni ezeket a buffereket, tehát ő automatikusan onnan fogja kiolvasni.

Ezeket az X-es driverekkel nem lehet megoldani, mert az X is a rendszermemóriába teszi a képet, onnan másolja át egy külön processz a videokártya memóriába, s ott is maximum két buffert tud. Tehát vannak ilyen problémák, amiket ki lehet küszöbölgetni, de ezek mind a teljesítmény és a képminőség rovására mennek. A VIDIX driver egy unified rendszer, amely egységesíti az általunk fejlesztett video driver interface-eket. Úgy keletkezett, hogy az ATI kártyákhoz készült driverekhez hozzáfejlesztettünk, de a többi maradt a saját egyéni interface-ével.

A Linux kernelben van egy TDFXFB nevű driver, amely lehetővé teszi a 3Dfx régebbi kártyáinak a teljes mértékű kihasználását. Ebben is nagy segítséget jelentett nekünk az UHU, miután nélkülük nem tudtunk volna ennyiféle kártyán tesztelni, illetve fejleszteni, ezeket is ők biztosították számunkra. Illetve sokan kértek az nVidia kártyák támogatását. Nem tudom, ki volt a Free SW fórumon az ebédszünetben, felmerült pont ez a téma, hogy a hardvergyártók nem adnak ki semmi dokumentációt a chipekre. Az nVidiával is az a fő problémánk, hogy a gyártó megtagadja mindenféle informácó kiadását, míg a Matrox, a ATI vagy a 3DFX kiadott minden szükséges anyagot, legalább a fejlesztőknek. Az nVidiánál csak arra tudunk támaszkodni, hogy a Linux alatt kiadott bináris drivereket visszafejtegetjük, nézegetjük, vajon hogy működhet ez, kitalálni régebbi kódokból - de ez így elég nehézkesen halad. Már jó pár hónapja dolgozunk rajta, de még valószínűleg legalább ennyi lesz, amíg valami működőképes kódot készítünk, s lesz még egyszer ennyi, amíg valóban optimális kód lesz. Mindenesetre tervbe van véve. Remélem, hogy a jövőben a videokártya-gyártók megpróbálnak vagy ők maguk fejleszteni ilyesmit, pl. Vidix alá drivereket, vagy legalább kiadják a szükséges dokumentációt, hogy legalább így támogassák a fejlesztést. Sajnos egyelőre nem nagyon érdekli őket a Linux alatti video lejátszás, mert ha Linux-szal foglalkozik is egy-egy gyártó, az inkább csak a szerver platformban érdeklődik.

Az MPlayer verziószámozása elég érdekes probléma. A 0.01 verzió két nap híján két éve lett kiadva, azóta érdekes verziószámok jelentek meg. Ezeknek hosszú története van, hogy melyik verzió miért ennyi. Mégis lényeges az, hogy a 0.90-es verziót április óta húzzuk, halasztjuk. Áprilisban jelent meg az első Pre beta verziója, azóta kiadtunk már 9 pret, illetve kiadtuk volna tegnap a 10-est, de az el lett megint tolva, s végül is 0.90 stabil verzió nem tudom mikor lesz ténylegesen, valószínűleg néhány hónapon, illetve héten belül.

Az a probléma, hogy nem akarunk, illetve nem is tudunk fix határidőket szabni, nem mondhatom, hogy január 8-án kiadjuk a 0.90-et, addigra mindenki mindent csináljon meg, s minden legyen stabil. Sajnos ez nem így működik, egyrészt mert a fejlesztők ezt hobbiból csinálják, és ez egy teljesen nonprofit projekt. Tehát nem mondhatjuk valakinek azt, hogy márpedig ezt te holnapra fogod megírni, és kész legyen, mert emellett más dolguk is van az embereknek, tanulnak, dolgoznak. Tehát erre nem lehet számítani. Másrészt a fejlesztés jelentős része, valószínűleg több mint a fele abból jön, amiket nem is mi fejlesztünk, hanem közvetlenül a felhasználók küldözgetnek nekünk patch-eket, javításokat, amikre végül is nem lehet nagyon előre építeni. Viszont általában egy-egy ilyen javítás elindít egy egész lavinát, s egész sok kódot átalakítunk, amit az a módosítás indított meg, az világított rá, hogy azt szükséges átírni. Tehát egy-egy ilyen patch érkezése előfordul, hogy hónapokra eltolja egy-egy új verzió kiadását, s már április óta így tologatjuk magunk előtt, s még mindig nem látjuk, hogy mikor fog megjelenni, de valószínű, hogy még az idei évben kiadjuk. Az 1.0 megint jó kérdés. Kb. egy éve írtam egy listát, hogy mi az, amit az 1.0-ba bele akarunk tenni, mi az, ami az 1.0 verzió kiadásához szükséges. Azok már rég megvalósultak, de a lista fokozatosan nőtt, mert amikor kitöröltünk egy sort, kettőt hozzáírtunk, tehát így soha nem fog elfogyni, így valószínű, hogy ez majd valamikor jövőre fog elkészülni. Igazából az MPlayernél azt a filozófiát követjük, hogy túl szigorúra sem lehet venni a kiadás dátumait, de túl szabadra sem, úgyhogy próbálunk tág határidőket szabni, csak nem nagyon sikerül betartani egyelőre.

Még néhány szót a távlati tervekről, hogy mi lesz az 1.0 után, ha elkészül. Terveinkben szerepel például egy videoszerkesztő program, a szükséges kód magyrésze már rendelkezésre áll, (pl. kodekek, MEncoder, demuxerek) tehát amire szükség van ahhoz, hogy egy fájlt olvassunk, írjunk, dekódoljunk. Gyakorlatilag egy felületet kell hozzá létrehozni, illetve úgy kell átalakítani valamennyire a kódot, hogy párhuzamosan több videofájlt is fel lehessen vele dolgozni. Most úgy van megírva, hogy egyszerre egy fájlt tud olvasni. Ezt viszonylag kis munkával át lehet alakítani, továbbá ilyen "streaming" szervert, hogy lehessen pl. videokonferencia feladatokra, video szolgáltatásra használni, szintén ehhez is majdnem minden megvan, a hálózati részt kell hozzá implementálni.

Web böngésző plugin, ezt nagyon sok felhasználó kéri. Létezik több tőlünk független projekt, ami ezt próbálja elérni, de valószínűleg ezt igazából teljes értékűen csak úgy lehet, ha ezt magába az MPlayer kódba írjuk bele, külső vezérlő kódokkal ezt nehéz lesz megoldani. Kód modularizáció - ez végül is az utóbbi időben kezdődött el, s folyamatosan dolgozunk rajta, hogy kicsit modulárisabbá tegyük az elég monolitikus programot. Különböző libekre van szétszeparálva a program, s ezek most már kezdenek lassan egymástól függetlenné válni. Ha akarja egy program, az MPlayer egy-egy részét fel tudja használni. Arra is szükség van, hogy a többi lejátszóval közösen tudjunk egy-egy részt használni, tehát végül is átemelhetőek bizonyos modulok más programokba. Ezek a távlati terveink.

Kérdések - válaszok

K: Ez a modularizációs ötlet nem jelenti azt, hogy az elszeparált modulhatárok közötti adatcsere, átmenet, lassíthatja a lejátszást?

V: A kérdés jogos, feltehetően lassítani fogja, ezért megy ez ilyen lassan, mert nagyon át kell gondolni minden egyes módosító lépést, hogy úgy tudjuk átalakítani, hogy ne okozzon semmilyen lassítást, illetve semmilyen hátrányt a kódban. A modularizáció mindenképpen az, hogy egységesítjük a különböző viselkedési formákat, ráerőltetni egy közös felületet, az biztos, hogy bizonyos funkciókat ki fogunk belőle venni, illetve meg fogja bonyolítani azt, hogy a formátum specifikus opciókat átadunk egy-egy dekódernek, amiket egy másik dekóder nem tud értelmezni. Emiatt megy ez lassan. Most egy új konfig kódot készítünk, még nincs benne a CVS-ben, mert elég béta állapotú, végül is ez próbálja majd azt valamennyire egyszerűsíteni. Tehát egy-egy ilyen modul amikor indul, be tudja regisztrálni egy központi konfig kódba azt, hogy ő milyen funkciókat tud ellátni milyen protokollal. Végülis nem lesz annyira ráerőltetve ilyen szabványos interface, hanem valamennyire meghagyjuk a szabadságát, de azért megpróbáljuk úgy, hogy azt egy külső program is le tudja kérdezni, megismerni mik a sajátosságai.

A média fájlokból két alapvető fajta van, vannak az interleaved formátumok, amikor folyamatosan van összekeverve a hang- és a videojel, és vannak olyan fájlformátumok, amikor szét vannak ezek választva, tehát külön van a kép, külön a hang a fájlban. Ezeket alapvetően másként kell kezelni, ezért a lejátszónak tudnia kell, hogy ez milyen jellegű. És nagyon sok ilyen apró példa van még. Amiért az MPlayer elérte ezt a sebességet és stabilitást, az az, hogy ezekre külön figyelünk. A többi lejátszó megpróbálta a kezdetektől fogva ráerőltetni egy közös felületre ezeket.

Ez az erőltetés elég találó szó, végül is ugyanez a probléma az X-es meg mindenféle egyéb driverekkel, amikor videokártyákra próbálnak interface-t erőltetni. Nagyon jó példát mondasz, például ez az, amiért a Matrox driver át lett írva Vidix interface alá, de végülis még mindig a kernel drivert használjuk, mert még mindig több minden funkciót el tud látni, mint amit a Vidix egységesített felületén el lehet érni. Így aztán kitalálunk egy felületet, de utána kiderül, hogy jön egy újabb kártya, aminek megint másfajta jellemzői vannak, ezeket megint nem lehet ráerőltetni, s valószínű, hogy az X-nél pont ez a probléma. Az a másik gond, hogy az XVideo-t amikor kitalálták pont erre célra, hogy video overlayt elérjenek, grabbelésre, digitalizálásra találták ki, és utána tették bele a következő kiadásnál, hogy lejátszást is lehessen, de ez már kicsit "belegányolás" lett inkább, mert alapvető funkciók például hiányoznak ebből, mondjuk képek szinkronizálása, ami tv-kimenet esetén elég problémás, mert annak pont 25 Hz-en kell megjelenni, különben a képernyőn futni fog - ez a monitoron nem látszik. Erre ők valószínűleg nem is gondoltak akkor, de később már nem tudják beletenni, mert akkor megint át kellene írni az egészet.

Q: Hallottál már ilyen irányzatról, hogy minél kevesebb interface felhasználásával való programírás? Hogy érted? Pont annak az ellenkezője, amire mennétek, hogy modularizálni kellene a dolgot, hogy inkább jó a monolitikus, és gyakorlatilag amit elérnétek a modularizációval, azt úgy megvalósítani, hogy forrás szinten használja fel az a program az adott modult, aminek szüksége van rá. Mert ha nem írtok annyi interface-t, akkor a lényegi kód kisebb, kevesebb probléma származik abból, ha azt felhasználják egy az egyben. Mintha jól körbecsomagolod.

A: A jól körbecsomagolást próbáljuk mi is elkerülni, de annyira nem kell pl. a GTK-hoz hasonlítani, ahol tényleg túl van bonyolítva, ahol sok réteg van ráépítve. Mi igyekszünk egy réteget tartani, s azok is ilyen opcionális függvények. A kodekek modulárisan lettek átdolgozva idén tavasszal, ez a réteg úgy néz ki, hogy van egy általános struktúra, amiben a kodek beállíthatja, hogy ő abból a funkcionalitásból melyik funkciókat implementálja. S akkor meg kell nézni a lejátszónak, hogy ezekből a funkciókból, amelyiket ő implementál, melyik a legoptimálisabb. Tehát nem kell olyat implementálni, ami neki nem optimális.