[MPlayer-translations] CVS: homepage/essays/src konf2002-arpi.src.hu, NONE, 1.1

Tue May 31 00:52:07 CEST 2005

CVS change done by Mizda Gábor CVS

Update of /cvsroot/mplayer/homepage/essays/src
In directory mail:/var2/tmp/cvs-serv22107

Added Files:
	konf2002-arpi.src.hu 
Log Message:
synced with 1.1, new file from HTML

--- NEW FILE ---

<!-- content begin -->

<!-- synced with 1.1 -->

<h1>Az UHU-Linux által támogatott fejlesztõk bemutatkozása</h1>

<h2>Gereöffy Árpád elõadása: Az MPlayer videólejátszó bemutatása</h2>

<img class="left-inset" src="../essays/images/logo.png" alt="MPlayer Logo">

É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.

<div class="center">
<img src="../essays/images/konf2002-stats.png" alt="Fejlesztés">
</div>

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.

<table class="left-box" border="0" cellpadding="2">
<tr><th colspan="4"><a href="http://www.freshmeat.net/stats">www.freshmeat.net/stats</a></th></tr>
<tr><td> 1.</td><td><b>MPlayer</b></td><td>50,576</td><td>100%</td></tr>
<tr><td> 2.</td><td>Linux         </td><td>39,514</td><td>78.13%</td></tr>
<tr><td> 3.</td><td>cdrecord      </td><td>26.954</td><td>53.29%</td></tr>
<tr><td> 4.</td><td>xine          </td><td>20.355</td><td>40.25%</td></tr>
<tr><td> 5.</td><td>Gaim          </td><td>18.192</td><td>35.97%</td></tr>
<tr><td> 6.</td><td>gcc           </td><td>17.199</td><td>34.01%</td></tr>
<tr><td> 7.</td><td>MySQL         </td><td>17.028</td><td>33.67%</td></tr>
<tr><td> 8.</td><td>Nmap          </td><td>16.211</td><td>32.05%</td></tr>
<tr><td> 9.</td><td>TightVNC      </td><td>15.546</td><td>30.74%</td></tr>
<tr><td>10.</td><td>Apache        </td><td>15.171</td><td>30.00%</td></tr>
</table>

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.

<div class="right-box">

<h3>Linuxos videó lejátszók 2 éve</h3>

<p><b>Avifile</b>, DVDview, Gstreamer, Kmpg,<br>
LAMP, LiViD/OMS, <b>MPlayer</b>,<br>
mpeg2dec, MpegTV, <b>Ogle</b>, SMpeg,<br>
<b>VideoLan</b>, XMMP, XMPS, <b>XMovie</b>,<br>
Xanim, <b>xine</b>, Xtheater, ZZplayer
</p>

</div>

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.

<div class="left-box">

<h3>SourceForge.net'2001</h3>

<ul>
<li>megbízhatatlan a CVS</li>
<li>lassúlnak a levlisták <sup>*</sup></li>
<li>nincs Reply-To:</li>
<li>nincs levlista archívum <sup>*</sup></li>
<li>megszünik az FTP</li>
<li>egyre több reklám, banner</li>
</ul>

<p><small>(<sup>*</sup> <i>2002-ben megoldva</i>)</small></p>

</div>

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.

<div class="right-box">

<h3>Az UHU Linux támogatása</h3>

<ul>
<li>Domain név regisztráció</li>
<li>Dedikált szerver gép (P3-733, 512Mb, RAID)</li>
<li>DVD drive-ok</li>
<li>VGA kártyák</li>
<li>GUI fejlesztés támogatása</li>
</ul>

</div>

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.

<div class="left-box">

<h3>Mi a végcél???</h3>

<ul>
<li>"Világuralom? :)" - <i>Gabucino</i></li>
<li>v1.0?</li>
<li>egy felhasználóbarát lejátszó?</li>
<li>mplayer desktop environment?</li>
<li>...</li>
</ul>

</div>

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.

<div class="right-box">

<h3 class="center">R&nbsp;&nbsp;T&nbsp;&nbsp;F&nbsp;&nbsp;M&nbsp;&nbsp;!</h3>

<h3>Read The Fine Manual</h3>

<h3>Olvasd el a leírást</h3>

</div>

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.

<div class="left-box">

<h3>Kooperáció</h3>

<ul>
<li><b>Avifile</b>: .DLL loader  / win32 emu</li>
<li><b>VideoLAN</b>: DVD/DeCSS</li>
<li><b>xine</b>: SVQ1 codec</li>
<li><b>FFmpeg</b>: libavcodec</li>
<li><b>OMS</b>: libmpeg2, libac3</li>
<li><b>Mpeg2dec</b>: libvo</li>
<li>...</li>
</ul>

</div>

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.

<div class="left-box">

<h3>A lejátszó idõzít, nem az OS ütemezõje!</h3>

<ul>
<li style="display:block"><b>+</b> a lejátszó tudja, mikor mire van szüksége</li>
<li style="display:block"><b>+</b> nincs lock-olás, mutex-ek</li>
<li style="display:block"><b>+</b> nincs lassú thread- vagy task-switching</li>
<li style="display:block"><b>+</b> tisztább, átláthatóbb a kód -&gt; kevesebb bug</li>
<li style="display:block"><b>+</b> egyszerübb a debug</li>
<li style="display:block"><b>-</b> nincs SMP kihasználás</li>
</ul>

</div>

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.

<div class="left-box">

<h3>Támogatott formátumok</h3>

<ul>
<li>MPEG1 (VCD), 2 (SVCD/DVD/DVB), 4 (.MP4)</li>
<li>AVI, DivX (support of Windows DLLs!)</li>
<li>ASF, Windows Media Audio/Video 7/8</li>
<li>RealAudio/Video G2, 8.0, 9.0, RealOne</li>
<li>Quicktime (Cinepak, Sorenson1)</li>
<li>VIVO 1.0, 2.0</li>
<li>DV PAL/NTSC (Sony Digital Video)</li>
<li>FLI, RoQ, SMJPEG, NuV, Y4M, FILM, PVA ...</li>
</ul>

</div>

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.

<div class="right-box">

<h3>Támogatott video output eszközök</h3>

<ul>
<li><b>X11</b>: Shm, Xvideo, GLX/OpenGL, DGA 1/2</li>
<li><b>Linux</b>: framebuffer, svgalib, VESA, mga_vid</li>
<li><b>Wrappers</b>: SDL, GGI, DirectFB, VidiX, AAlib</li>
<li><b>HW decoders</b>: dxr2, H+/dxr3, dvb, zoran</li>
<li><b>Images</b>: gif89, png, jpeg, pgm, yuv4mpeg</li>
</ul>

</div>

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.

<div class="left-box">

<h3>Közvetlenül támogatott VGA kártyák</h3>

<ul>
<li><b>mga_vid</b>: Matrox G200, G400, G450, G550</li>
<li><b>vidix</b>: ATI mach64, Rage 128, Radeon</li>
<li><b>tdfxfb</b>: 3Dfx Voodoo 3/Banshee</li>
</ul>

</div>

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.

<div class="right-box">

<table border="0" cellpadding="2">
<tr>
<td colspan="4"><b>MPlayer "stabil" verziók</b></td>
</tr>
<tr><td>v0.01:</td><td>2000.</td><td>Nov</td><td>01.</td></tr>
<tr><td>v0.10:</td><td>2001.</td><td>Jan</td><td>01.</td></tr>
<tr><td>v0.17:</td><td>2001.</td><td>Apr</td><td>27.</td></tr>
<tr><td>v0.50:</td><td>2001.</td><td>Oct</td><td>08.</td></tr>
<tr><td>v0.60:</td><td>2002.</td><td>Jan</td><td>03.</td></tr>
<tr><td>v0.90:</td><td>2002.</td><td>???</td></tr>
<tr><td>v1.0:</td><td>????</td></tr>
</table>

</div>

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.

<div class="left-box">

<h3>Távlati tervek - v1.0 után</h3>

<ul>
<li>Videó szerkesztõ</li>
<li>Streaming server</li>
<li>Web-böngészõ plugin</li>
<li>Kódmodularizáció</li>
</ul>

</div>

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.

<h3>Kérdések - válaszok</h3>

<p><b>K</b>: 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?</p>

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.

<!-- content end -->