Sokaknak úgy tűnik, hogy megállt az MPlayer fejlesztése. Kb. másfél évvel ezelőtt készítettem egy interjút Árpi-val, most úgy éreztem, hogy itt az ideje annak, hogy újra megkeressem. Meg akartam kérdezni, hogy mi az oka annak, hogy lelassult (megállt?) az Mplayer fejlesztése, érdeklődtem a készülő G2-es MPlayerről, és a világ eseményeiről. Lássuk:
trey: Lassan másfél év telt el az előző interjú óta, most újra kérdezlek. Amikor 2001. novemberében beszélgettünk azt mondtad, hogy három dolog foglalkoztat titeket: 1. a TV tunerek támogatása, 2. a mencoder elkészítése, 3. a windowsos pluginek (pl. quicktime) támogatása. Ezek közül, mindegyik megvalósult, mégsincs MPlayer 1.0. Miért, és mikor lesz 1.0?
Árpi: Hehe :)
Azóta (úgy 1 éve) amikor a fenti dolgok már rég megvoltak, felállítottam egy újabb TODO listát az 1.0-hoz (ezen elsősorban a DR (direct rendering) és az új codec/filter API szerepelt). Amikor azok is elkészültek, rilizeltük a 0.90-et :)
Hogy miért lett ez is csak 0.90? Mert mindig jöttek az újabb ötletek, hogy mi kéne még, mi az ami ma már nélkülözhetetlen egy 1.0-ás verzióban. Egyébként szerintem sosem lesz 1.0-ás MPlayer riliz. Pl. most is maximum 0.99pre de valószínűbb, hogy 0.95pre verzióval lesz az első snapshot a main (fejlesztői) ágból kiadva.
trey: Pár hónappal ezelőtt Nick Kurshev elhagyta a fejlesztőcsapatot. Mennyire éreztétek meg ezt Ti? Visszavetette ez a fejlesztést?Árpi: Mivel Ő sosem dolgozott az MPlayer magján, csak "külső" munkákat végzett, nem haltunk bele. Gyakorlatilag az Ő nevéhez fűződik a libavcodec és az mp3lib 3dnow-ra való optimalizálása, a VESA és a Vidix output driverek. A felhasználók jobban megérezték a hiányát: azóta a -vo vesa és a vidix elég elhanyagolt, főleg mert a többi fejlesztő nem is használja ezeket, a vidix meg már akkor sem tetszett Nick-en kívül senkinek amikor azt megírta. (nem a céljával van baj, hanem a megvalósítással, az API-val. Alex-szel már régóta tervezzük egy új video driver API tervezését, a vidix kiváltására)
trey: A rossznyelvek szerint az MPlayer fejlesztőcsapat nem sokat csinál, csak kihasználja más projektek eredményeit, pl. az FFmpeg-ét. Azt mondják, hogy a feature-k nagyrészt az Ő érdemeik, Ti maximum beleépítitek a funciókat az MPlayerbe.
Árpi: Hihi :) Ezen mindig jót röhögök...
Ezek a kedves jólelkű emberek csak azt felejtik el megnézni, hogy az ffmpeg és az MPlayer fejlesztői 90%-ban ugyanazok.
Gyakorlatilag az ffmpeg (elsősorban a libavcodec) azért tart ott ahol tart, mert anno egy nagy vita végeredményeképpen úgy döntöttünk, hogy az általunk csinált codeceket, otimalizálásokat visszaportoljuk a libavcodec-be, és ezután az ffmpeg cvs-ben fejlesztjük azt. Ha megnézed, kik commitelnek a libavcodecbe, azt látod, hogy Michael Niedermayer, Alex, én, Mike Melanson (ok, Ő azóta átment a xine-hoz), Nick Kurshev (Ő meg forkolt). Anno azt hittük, így mindenki közösen dolgozhat a codeceken, nem kell ide-oda portolgatni őket a playerek között. Tévedtünk, nagyrészt csak mi fejlesztjük, és a többi player (xine, avifile, stb.) csak használja. Ők, az svq1/svq3 codechez állítólag köze van egy xine developernek is, bár nem bizonyított tény :)
(az más kérdés, hogy az svq1-et is Nick portolta be a xine-ból a libavcodec-be).
Arra még álmunkban sem gondoltunk, hogy egyes emberek azt fogják mondani, hogy mi lopjuk a libavcodecet :)
A libavcodec-től elszakadva, nézzük mink van még: mp3lib, liba52, libmpeg2. Igen, ezeket eredetileg nem mi írtuk, az mpg123, mpeg2dec, ac3dec projectekből származnak. Igaz, azóta 5x-ösére nőtt a forrás, az általunk hozzáadott fixektől, CPU-specifikus optimalizációktól, feature-ktől, amiket sajnos hiába küldtünk el patchek formájában az eredeti projecteknek, nem kerültek be (Michel LESPINASSE, a liba52/libmpeg2 maintainer azért utasítja el pl. az optimalizációt, mert Ő a portolható, C-only átlatható kódot akarja csak látni, azt fejleszteni. Ő amúgy szinte minden patchet elutasít, még alapvető bugfixeket is, mert szerinte
nem jól közelítik a problémát... mindig megígéri, hogy majd fixeli másképp, csak idő hiányában ez általában elfelejtődik. Ezrért van minden projectben patchelt verzió ezekből.)
trey: Elég nagy a csend az MPlayer körül jelenleg. Alex mással foglalkozik, releasek nincsenek. Folyik még egyáltalán az MPlayer (G1) fejlesztése?
Árpi: Fogalmam sincs, semmi közöm hozzá. És most nem is viccelek. Én az rc3-nál bejelentettem (és az rc4-re realizálódott is), hogy nem fejlesztem tovább a G1 (mostani MPlayer main) ágat. A 0.90 release-ig még foglalkoztam a stable ággal (0_90 branch), de azóta azzal sem. Elvileg most Alex a fő maintainer, bár a távozásom után azt szavaztuk meg a listán, hogy 1 leader helyett inkább legyen több maintainer között felosztva a kód. A lényeg, hogy mostanában senki sem csinal semmit, néha úgy havonta 1x Alex becommiteli a patchek 10%-át (a többi elkallódik addigra) de igazából a fejlesztés, mint olyan már nincs.
trey: Az előző mondatban utaltam arra, hogy MPlayer G1, azaz Generáció 1. Ebből következik nekem, hogy kell lennie Generáció 2-nek is. Úgy hallottam, hogy nekiálltál a második generációs MPlayer-nek, amely sokkal letisztultabb, jobban átgondolt szerkezetű lesz. Mondanál erről valamit?
Árpi: Igen, 2 okból hagytam abba a G1-et pár hónapja. Egyik, hogy nagyon sok munkám volt (nem MPlayer related), más projectekkel is akartam foglalkozni (pl. az akkoriban megjelenő midnight commander 4.6-ba portolni a 4.1-hez
készített patch-eimet, ill. más featureket megírni) és amúgyis egy időre elegem lett az MPlayerből, ami amúgy napi 5-10 órát siman lefogalt az időmből.
Másik oka, hogy az MPlayer kódja kezdett nagyon átláthatatlan, de főleg nagyon gány lenni az elmúlt időszakban. Sok patch került be ami mindenféle gányolással,
hack-ekkel, globális változókkal, stb. oldotta meg a most wanted feature-ket, és a kód különböző részei kezdtek egyre jobban dependelni egymáson, így az esély arra, hogy 1-1 részt átdolgozzunk egyre csökkent. A valaha független
rétegekből álló kód kezdett egy nagy vastag, nyálkás masszává válni, ami ragad, akárhol nyúlsz hozzá, és nyúlik vele az egész. Ebből következően ha jött egy újabb gány patch, akkor mindig meg kellett hoznom a döntést: berakjuk cvs-be (mert annak már úgyis mindegy, meg ha a másikat
beraktuk akkor ezt sincs okunk visszautasítani) vagy nem rakjuk be. Utána persze engem anyáztak, hogy miért engedtem berakni... Ha meg azt mondtam nem, akkor meg azért anyázott sok fejlesztő, hogy milyen szigorú vagyok, az userek meg, hogy miért nem rakom be a patchet pedig milyen jó. Közben meg egyre több 'design issue' jött elő, amiket csak a kód mélyebb átalakításával lehetett volna megoldani, ezeket viszont a sok keresztbe hekkelés és gányolás miatt nem nagyon lehet elkezdeni mert összeomlik az egész. Na, ebből lett elegem. Akkor eldöntöttem, hogy némi szünet után elkezdem az egészet előlről,
from scratch, tanulva a G1 hibáiból. Na, ez lett az MPlayer G2 project.
trey: Az MplayerHQ-n találtam egy http://www.mplayerhq.hu/~arpi/g2/ könyvtárat, ahol már megtalálhatóak a MPlayer G2 previe verziói. Ezek milyen állapotot tükröznek? Ezek valamilyen keretmunák, vagy akár kipróbálható verziók?
Árpi: Kiprobálhatók, bár ezek developereknek vannak ott, nincs (G)UI hozzá. Csak ilyen test-*.c fileok, amik 1-1 layert tesztelnek, így pl. látod, hogy jól demux-olja a filet, jól dekódolja a hangot, stb., de ezeket külön-külön, így pl. nem tudsz vele filmet nézni. Bár a legutóbbi néhány preview-ben már van egy test-play.c is, ami lejátszik hangot és képet együtt, ebben az A-V szinkronnal kísérletezek.
trey: Miben lesz más a G2 mint az elődje?
Árpi: Elsősorban a kódban. A felhasználók első közelítésben nem sok újat fognak látni, főleg, hogy egyelőre a G1-ből portolgatjuk át a codeceket stb. A kód viszont átgondolt, független (ill. egymásra épülő, nem keresztbe
gányolt) rétegekből épül fel. Ugyanakkor megcéloztuk pár G1-es design issue fixelését is, de nem mindet. Valószínű lesz majd egy G3 is mire olyanok, hogy dvd menük vagy pl. visszafele lejátszás, vagy több video stream összekeverése filterekkel megvalósulnak.
A másik nagy különbség, hogy a G1-gyel ellentétben itt teljesen külön lett választva a (G)UI és a core. Így bárki írhat könnyeden GUI-kat hozzá, vagy pl. browser plugint, xmms plugint, stb. A G1-ben szorosan integrálva volt a CLI (command-line interface) és az opcionális félig Xlib - félig gtk1 GUI. A G1-hez is készült számtalan frontend, de ezek gyakorlatilag külön programok, amik a parancssoros MPalyert futattjak és az stdin-en keresztül adnak neki parancsokat.
Én szeretném a CLI/GUI kódot (és az azzal járó feature-k implementálását, támogatását) nagyon távol tartani a mag-tól. Így a G2 végülis egy lib külön parancssoros player lesz, talán a libavifile+aviplay felálláshoz lehetne legjobban hasonlítani. (a xine is azt hirdeti magáról hogy külön van a gui és a core, de nem annyira mint szeretnek. ugyan külön kód, de túlságosan meg van támogatva a gui a core-ból)
trey: Mik kellenek ahhoz, hogy valaki le tudja fordítani ezeket a preview kiadásokat?
Árpi: Hmm, lássuk csak. Bash (de végülis brmilyen shell jó), gcc, make. Kb. ennyi. Ha régebbit akarsz fordítani, akkor kell még a G1-ből a ./configure script által generált config.h és .mak fileok is.
trey: Kikből áll az aktív fejlesztői csapat? A G2-t kizárólag Te fejleszted, vagy van más segítséged is?
Árpi: Elsősorban én fejlesztem, de sokan vannak a g2-dev levlistán, és a tervezésben segítenek. Emellett kapom a patch-eket is, melyek egyelőre nagyrészt más OS-ek
támogatását javítjak, de pl. a stream layer új moduljait már nem én írtam. Igazából, amíg az interface-k, API-k nem véglegesek, nem is érdemes fejleszteni alá (plugineket). Egyelőre főként tervezés, viták, esettanulmányok (mi lenne,
ha ez nem int lenne hanem float... jellegűek) mennek. Szeretnénk elkerülni azokat a hibákat amikkel a G1 fejlesztésekor találkoztunk, de közben már a jövőre is gondolni kell, azaz bővíthetőre, függetlenre kell tervezni mindent.
trey: Mikor lehet a G2-ből úgymond publikus tesztverziót látni?
Árpi: akár most is :) a kérdés az, hogy mit akarsz tesztelni :)
végfelhasználóknak szánt verzió még pár hónapig nem lesz, végleges API talán nyár végére. Így ősszel már elkezdhetjük portolni a codeceket, demuxereket, és elkészülhetnek az első GUI-k.
trey: Kicsit más téma. Mint programozó, mint szólsz az IBM vs. SCO ügyhöz? Szerinted az ügy visszavetheti Linux fejlesztését?
Árpi: Az elején éreztem, hogy valami történni fog, ez csak az SCO elkeseredett próbálkozása. Aztán kiderült, hogy az M$ van a háttérben. Jót röhögtem, amikor kiderült hogy a Novell mégse adott el minden jogot, aztán kiderült, hogy ők tévedtek. Ez szerintem egy rohadt nagy ki nevet a végén játék. Nem hiszem, hogy ennek közvetlen hatása lenne a linuxra, de arra pont elég (és az m$ valószínű pontosan ezt célozza vele) hogy megijessze a nagyvállalati linux usereket, és a linuxra való áttérést fontolgató kormányokat. Ez pedig hosszú távon, közvetve károsan hatna a linux fejlődésére.
Azért ne felejtsük el, hogy ugyan van sok kis openproject projectecske, de a komolyabb programok, fejlesztések hatterében nagy pénzes cégek, szponzorok állnak. Legyen szó az openoffice-ról, mozilláról, samba-ról, wine-ról, apache-ról, mysql-ről, de akar az MPlayerről is, az UHU Linux
kezdeti segítsége (szerver, stb.) nélkül nem ment volna ilyen simán minden.
trey: Mostanában divat lett mindenkit beperelni IP-k (intellectual property) miatt. Nem félsz, hogy valaki előbb-utóbb beleköt a projektbe?
Árpi: De. Bár mostmár túl vagyok ezen, inkább azon csodálkozom, hogy nem tették meg idáig. Szerintem már túl messzire mentünk, az pl. hogy a windozos MPlayer porttal lejátszhatók a realmedia, quicktime, stb. fileok, az összes
playerbe épített reklám és backdoor feature nélkül, biztos nem kívánatos. De nem történt semmi a divx visszafejtésekor 2 éve, sem azóta, pedig már túlvagyunk a wma-n, wmv-vm, sorenson codeceken is. Bár meg kell hagyni, hogy nagyot koppanhatna pl. a Sorenson egy perben, mert mint kiderült,
az svq1 a h263, az svq3 a h264 szábvany kicsit módosított változata, hasonlóan ahogy a divx3 (aka. ms-mpeg4) az mpeg4 variansa. Gyakorlatilag lenyúlták a technológiat, picit átalakították, és más néven vagyonokért licenszelik az Apple-nak. Erős a gyanunk, hogy a realvideo codecek is közeli rokonságot mutatnak egyes h.xxx szabványokkal.
(pl. a realaudio d.net codecéről kiderült, hogy sima AC3 fordított bytesorrenddel:))
Szóval vagy félnek tőle, hogy egy ilyen per esetleg fordítva sülne el (ezt amúgy a SCO-linux ügy esetén is gyanítják egyesek, állítólag került linux kód a SCO-ba, nem csak fordítva) vagy csak belátták, hogy képtelenség bizonyítani bármit is. A rizikós kódok amúgyis anonymous-ként
lettek becommitelve a sourceforge-s cvs-be. Másrészt valahol jó is nekik, ha a formátumaik lejátszhatóak mindenféle
oprendszeren, anélkül hogy ők akár egy centet is költenének fejlesztésre. Sőt, a divx.com anno meg támogatta is a linuxos lejátszók fejlesztését, hogy utána elmondhassa, az ő codecével enkodolt file minden OS-en lejásztható.
trey: Kicsit keményebb kérdés: sokan állítják, hogy "(c) arpi" helyett inkább "(c) mplayer team" kéne a programba. Erről mi a véleményed?
Árpi: Teljesen igazuk van. Ez még akkoriból maradt benne, amikor egyedül írtam, és azóta senkinek sem tűnt fel :) illetve ezek szerint igen, csak nekünk nem szóltak. (ilyenkor mindig megkérdőjeleződik bennem a 'sokak' sokasága,
bizonyos értelemben 1 is sok, máskor 100000 is kevés)
trey: A G2-vel kapcsolatban valaki megjegyezte, hogy túl monolitikus, és hogy nem engedsz semmilyen modularizációt benne. Van ennek valami oka?
Árpi: rotfl, még hogy a G2 monolitikus? Nem tudom ki mondta, de tuti sosem látta a G2-t. Ez kb. olyan, mint azt mondani, hogy irak-ban demokrácia van (volt).
trey: Kerestetek már valami komolyabb pénzt a projekttel? Úgy értem, hogy keresett már meg valaki, aki pénzt kínált volna azért, hogy hasznosítsa az MPlayert?
Árpi: Nem jellemző. Anno az Eon Entertainment Inc.. (akik pl. a matrix 2 effektjein is dolgoztak) fizetett nekünk 1500 $-t egy rakás mencoder feature implementálásáért, így az AVID, DV és PNG/JPEG formátumok közötti konverzióra FreeBSD-n a mencodert tudták használni, batch konverziós műveletekhez.
Volt még 1-2 kisebb módosítas, de amúgy nem jellemző, hogy ebből élnénk :) Ellenpélda, hogy a Pixar szeretné használni az MPlayer-t képkockánkénti oda-vissza léptetett lejátszáshoz (animátoroknak), de fizetni nem akarnak
érte semmit. Ha nem lenne nagy meló, még meg is csinálnánk, de a fél playert át kéne tervezni hozzá.
trey: ...vagy eddig csak erkölcsi oldala volt a dolognak? Egyébként jelent valamilyen előnyt az életben nektek, hogy az MPlayert fejlesztitek?
Árpi: Csak a saját nevemben tudok nyilatkozni: nem sokat.
Néhány "jéé, te vagy az aki az MPlayert írta?" esettől eltekintve semmit. Mondjuk amikor Donald Beckertől (linux network driver hacker) kértem segítséget egy driver bug fixeléséhez, válaszlevelében megemlítette, hogy
az MPlayerre való tekintettel azonnal megnézi a bugomat :)
Vegülis 2 napi szívás, és remote debuggolás után sikerült fixálnunk :)
trey: Mennyire becsülik meg szerinted Magyarországon az OS fejlesztőket?
Árpi: Semennyire. Annyira nem, hogy a magyar userek nemhogy lusták RTFM-elni, de még vérig is vannak sértve ha nem politikailag korrekt, diplomatikus protokollbeszédben homályosítjuk fel erről :)
trey: Titeket nem keresett még meg senki, hogy dolgozzatok neki?
Árpi: Nem jellemző. Kaptam 1-2 ajánlatot, de egyik sem volt annyira komoly vagy érdekes, hogy foglalkozzak vele. Lehet, hogy ha munkát keresnek, jól mutatna a CV-ben, de mivel nem keresek...
trey: Többen kritizálják a fejlesztés menetét, azt hogy szorosan fogod a gyeplőt.
Árpi: Igyekeztem mindig szigorú maradni, de kizárólag a kód stabilitása, tisztasága érdekében. Sajnos ez egy idő után már nem ment, mert túl sok fejlesztő volt, és vagy leszavaztak, vagy egyszerűen a vélemenyem megkérdezése nélkül becommiteltek a gány kódokat.
trey: ..ez azért van, mert nem akarod hogy szétforgácsolódjon a fejlesztés, vagy mert csak egyszerűen nem szereted, ha mások által mutatott irányba kell menni?
Árpi: Ez ilyen formában nem igaz. Ha meg tudnak győzni, hogy a másik irány jobb, akkor hagyom magam. Elég sokszor volt ilyen az MPlayer történelmében. Voltak viszont olyan ötleteim, amire az MPlayer épült, ezekből nem engedtem. Ilyen pl. az is, hogy egy szálon fut, a végét ismeritek: Nick forkolt emiatt. A másik, hogy nem engedtem a cosmetics-et (codmetics;)) a cvs-ben.
trey: ...mások szerint pont ez a jó, ezért van még egyben a fejlesztés. Erről mi a véleményed?
Árpi: Sajnos már nincs egyben. Amikor kiszálltam, azt hittem, hogy így végre belidul az igazi, nyitott fejlesztés: minden patchet beraknak, nem szamít, hogy a fél player broken, majd kijavítják a következő patchek, főleg ha közben
mást break-elnek, mert majd kijavítják azt is... lásd xine :). Ennek aztán 2 vége lehet: vagy működik (lásd xine) vagy totális káosz lesz. (Vegülis mindegy mi lesz, csak addig tartson ki, amíg a G2 elkészül :) Sajnos a 3. vége lett: lelassult (megállt?) a fejlesztés, a patchek meg
ugyanúgy nem kerülnek be a cvs-be. Sokan engem hibáztatnak ezért, hát nem tudom, ha egy ekkora project 1 emberen függ, megette a fene.
A'rpi / Astral & ESP-team
--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu
Mit csinál a geek ha vészhelyzet van? Belenyúl a tárcájába, és előveszi a névjegykártyáját.... azaz a névjegykártya méretű bootolható CD-ROM-ját, amelyre előzőleg felvéste a kedvenc Linux disztribúcióját. Az LNX-BBC egy mini disztribúció, amelynek fő célja, hogy elférjen egy BBC-n, azaz egy "bootable business card"-on.
Sokszor használjuk a napi munkánk során azt a szót, hogy PROXY. Lehet, hogy ezt az oldalt is sokan nézik proxy szerveren keresztül. A proxy szervernek sok hasznos funkciója van, amelyből biztos kapásból mindenki fel tud sorolni legalább 3-at. A lokálisan tárolt gyorsítótár (cache) miatt a böngésző letöltési ideje lecsökkenhet, több IP címről is tudunk egy időben internetezni, és valamilyen védelmet is nyújtanak ezek a szerverek. De vajon mit jelentkenek az ARP Proxy, Reverse Proxy, Transparent Proxy szavak? Ezeket a kifejezéseket magyarázza el Dru Lavigne, a kedvenc BSD hacker tanárnőnk. Dru Lavigne hálózati ismereteket oktató tanárnő, instruktor egy magániskolában Kingstonban (ON). Az a hír járja róla, hogy a célja az, hogy minél több operációs rendszert tudjon bootolni egyszerre a tesztgépén. 1997-ben egy bug után nyomoztott az Interneten, a Yahoo keresője a FreeBSD oldalára vetette, azóta megszállott FreeBSD felhasználó. Szabadidejében TCP/IP adminisztációs könyveket és RFC-ket olvas.