"Hatalomátvétel" az FFmpeg projektben

Szerszám

Az FFmpeg fejlesztők egy csoportja a napokban bejelentette, hogy a projekt karbantartását egy új csoport veszi kézbe. A céljuk, hogy az FFmpeg fejlesztését felpörgessék, új és izgalmas szolgáltatásokkal, funkciókkal álljanak elő és mindenekelőtt tisztességes, a produktivitást elősegítő infrastruktúrát, környezetet biztosítsanak a fejlesztőknek és a hozzájárulóknak. A fejlesztést az új csapat a Linux kernel fejlesztéséhez hasonlóan képzeli.

  • A master repóhoz csak a karbantartásért felelős csapat tagjai kapnak írási hozzáférést.
  • A hozzájárulásokat az ffmpeg levelezési listára kell küldeni patch formájában.
  • A változtatásokat minimum egy, a területhez értő személynek is át kell néznie és jóvá kell hagynia. Ez a szabály a karbantartásért felelős csapat tagjaira is vonatkozik.
  • A fejlesztőket bátorítják saját, privát repó létrehozására.

A master repó git verziókezelő rendszert használ és az ffmpeg.org-on hostolják.

A váltásról szóló bejelentés meglepetésként érte Michael Niedermayer-t, az ffmpeg egyik régi karbantartóját. Diego Biurrun magyarázatot adott arra, hogy a "forradalom" miért tört ki.

Az tisztán látszik, hogy a kialakult helyzettel nem minden elégedett.

( 4fonya | 2011. 01. 20., cs – 08:28 )

"A master repóhoz csak a karbantartásért felelős csapat tagjai kapnak írási hozzáférést."

No még csak az kéne hogy akárki belekavarjon. Ha eddig nem így volt az elég gáz lehetett.

"Az tisztán látszik, hogy a kialakult helyzettel nem minden elégedett."

Egy forradalomnál ez már csak így van. :-)

( arpi_esp v | 2011. 01. 20., cs – 08:58 )

uristen... asszem ideje lesz forkolni, mielott diego ezt is tonkrevagja.

A'rpi

Ha nem is C++-ra, de egy átírás ráférne, legalábbis a "felhasználói" API-ra mindenképp. Vagy legalább egy korrekt dokumentáció kéne...

Sosem értettem egyébként ezt a C++ SUX hozzáállást C-s projekteknél. Értem én, hogy kivételkezelés meg virtuális fv-ek: broaf, de semmit sem kötelező használni, és pl a konstruktor/destruktor páros elég hasznos tud lenni...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Az emberek fegyelmezetlenek. Fegyelmezetlen fejlesztői gárdával pedig képtelenség C++-ban fejleszteni. Nem tudom, hogy a fejlesztő eszközök (gcc) bénaságán, vagy magán a nyelven múlik, de C++-ban valahogy sokkal több nehezen megfogható hiba keletkezik. A virtuális függvényt én sokkal kisebb problémának érzem, mint a cast-olást, a referencia paramétert vagy az = operátort.

Szerk: a kivételkezeléssel (szerintem) semmi baj nincs, abból nem szoktak misztikus hibák származni.

"Az emberek fegyelmezetlenek."
Ezért kell a szájukba rágni, mit szabad és mit nem. Pl Elnevezési konvenciók, ref paraméter vs mutató, kivétel vs bool visszatérési érték, stb. stb.

"Fegyelmezetlen fejlesztői gárdával pedig képtelenség C++-ban fejleszteni."
Ha le vannak fektetve a szabályok, és nem követik, akkor bármilyen nyelven képtelenség velük fejleszteni. Ha nincsenek lefektetve, akkor mit várunk?

"A virtuális függvényt én sokkal kisebb problémának érzem, mint a cast-olást, a referencia paramétert vagy az = operátort."
Ezek nagyon erős eszközök tudnak lenni, ha ésszel használják őket. Pl ha az = operátor a teljes projectben konzisztens (pl refcounter), akkor esély sincs arra, hogy hibát okozzon.

No de ne indítsunk C vs C++ thread-et...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Ha le vannak fektetve a szabályok, és nem követik, akkor bármilyen nyelven képtelenség velük fejleszteni. Ha nincsenek lefektetve, akkor mit várunk?

Az a furcsa, hogy C-ben mégis lehet fejleszteni. Saját tapasztalatom az, hogy nem keletkezik kevesebb hiba C-ben sem, csak valahogy a C++-os hibák megtalálása sokkal tovább tart. Annyival tovább, hogy azon elbukhat egy project.

Ha nem is C++-ra, de egy átírás ráférne, legalábbis a "felhasználói" API-ra mindenképp. Vagy legalább egy korrekt dokumentáció kéne...
Ez sajnos így van...

"Sosem értettem egyébként ezt a C++ SUX hozzáállást C-s projekteknél. Értem én, hogy kivételkezelés meg virtuális fv-ek: broaf, de semmit sem kötelező használni, és pl a konstruktor/destruktor páros elég hasznos tud lenni..."

Egyetértek veled, okosan használt C++-szal kényelmesebb, gyorsabb fejleszteni, mint C-ben. Nem véletlen, hogy az embedded világban a C++ kódok jelentős része még ma is -fno-rtti -fno-exception -nel van fordítva.

Érdemes megnézni az Android C++ kódját:
- nincs benne (szinte) STL
- nincs benne exception
- nincs benne operator overload (nem greppeltem végig, lehet, hogy valahol van :) )
- van viszont smart pointer + refcounting
- vannak benne olyan segédosztályok, mint Thread meg Mutex ami nagyon hiányzik a standard C++-ból.

Ha rendesen minden heapen foglalt objektumot smart pointerekkel használsz + a resource foglalásokat is úgy csinálod, mint pl. a Mutex::Autolock, akkor RTTI meg exception-ök nélkül is nagyon szép, jól karbantartható és robusztus kódot lehet írni.

Ha valamiért C kódot kell írnom, akkor C++ után nagyon kényelmetlen a goto-s resource / hibakezelésre visszaállni.

Üdv,
Gergely

PS: Az igazsághoz hozzátartozik, hogy lehet látni az Android C++ kódban igen randa goto-s hibakezelést is...nyilván "gyorsan" kellett elkészülni...

Igen, ezt félreérthetően írtam. Úgy értettem, hogy még ezek nélkül a feature-ök nélkül is kényelmesebb, hatékonyabb C++-ban fejleszteni, mint C-ben, és ha így van fordítva a projekt, akkor a "fegyelmezetlen fejlesztők" még véletlenül se tudják ezeket a nem engedélyezett elemeket használni.

És ezután hoztam példaként az Androidot mint bárki számára elérhető "friss" C++ kódbázist, ahol az "ésszel használom a C++"-t stratégia szerintem jól tetten érhető.

Üdv,
Gergely

Mind binding.

Ami nem baj, csak arra reagáltam, hogy "Az "ésszel használom a C++-t" röviden úgy hívják: Java. :)"
Ebből az következne, hogy a Java mindenhol használható ahol a C++. Pedig nem.

Ha meg nem, akkor ez a kijelentés fordítása: "Az "ésszel használom az almát" röviden úgy hívják: körte."

Értem én, hogy smile meg minden, de szvsz nettó hülyeség.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

na elolvastam az egesz thread-et. ahogy nezem, a regi motorosoknak egybehangzoan nem tetszik ez az uj buli, fork lesz ennek a vege vagy abbahagyjak.

akiknek kedvez, es akik miatt csinaltak, azok a "casual developers", tehat a kezdo programozo pistikek akik azt hiszik, hogy az ilyen-olyan 20 eves sose latott dos-os jatek anim formatumanak tamogatasara irt patche annyira fontos, hogy akarmilyen gany is a kodja amit osszelopott valami szimulatorbol azt be kell commitelni. az tuti hogy "sok uj es izgalmas" feature lesz benne, csak kerdes, hogy minek, meg hogy mennyi ido alatt vagjak haza teljesen a kod minoseget?

A'rpi

Az mar most folyamatban van. Epp a het elejen futtam bele abba, h egy h.264 streamet libavcodec-en kivul minden jo minosegben volt kepes dekodolni. Kiveve az ffmpeg ami ugy zajosodott mint a diszno. Az ilyen aprosagokrol nem beszelve, h alig egy-ket honapja fixaltak olyan memleaket a szinten ebben a decoderben, h azt orom volt latni, plusz olyan jol sikerult megoptimalizalni a nal unit parsert, h adott esetben tul olvas a bufferbol. Amivel egeszen addig nincs is semmi gond amig ennek a buffernek a vege nem laphatarra esik. Persze errol sincs szo semmilyen ffmpeg doksiban. :( Agyrem ami ujabban a hazuk tajan tortent.

---
pontscho / fresh!mindworkz

Igazából azt nem értem, hogy pl. Diego hogy lesz hirtelen központi figura az ffmpeg vagy az mplayer fejlesztésében...ő konkrétan milyen feature-öket is rakott bele bármelyik projektbe? Mert amikor még olvastam az MPlayer listákat, akkor ott többet írt "legal" témában mint konkrét patcheket. De lehet, hogy rosszul emlékszem, már régen volt...

Üdv,
Gergely

diego nem coder. talan egy hello worldot ossze tud rakni, de amugy nem irt 1 patchet se. eredetileg documentation maintainer volt az mplayernel, aztan elkezdett kozmetikazni (fileok tetejen GPL szoveget meg datumot updatelni, meg whitespace-t, indentet) igy latszolag jo sok commitje volt de igazabol a kodhoz soha nem nyult.

Michael jol megfogalmazta tegnap egy technikai kerdesre reagalva:
if its a question about ffmpeg, he can ask diego who is the new expert maintainer.
:)))

Az a baj, hogy Michaelen es Fabricen (aki mar evek ota eltunt) kivul senki nem latja at a kodot annyira, hogy maintainerkedni tudjon. Erre mondjuk a neuteam is rajott es egybol felosztottak vagy 8 fele a projektet, de kerdes igy is hogy elboldogulnak-e vele...

A'rpi

( Dacr (nem ellenőrzött) | 2011. 01. 20., cs – 09:36 )

"új és izgalmas szolgáltatásokkal, funkciókkal álljanak elő"

Kváááák.... Először inkább az eddigieket kéne gatyába rázni. Használták ezek már a saját kódjukat??? Imádom az ffmpeg-et, de néha van vele szívás, mikor egy nagyokos "izgalmas" átalakításokat végez benne...

No mindegy, remélem most jobb lesz, minden esetre lehúzok egy forrást tartalékba.

az api changek altalaban vissza kompatibilisen vannak bevezetve, mar ha jol hasznalod az api-t (nem te malloc-olod a structot hanem az erre valo konstruktor fuggvenyt hivod meg).

az meg hogyu eleg bonyolult az api-ja, annak koszonheto, hogy itt a sebesseg volt a fo szempont, az hogy pl. lehessen stripe-nkent kulon, sot akar parhuzamosan feldolgozni egy video framet, akar kozvetlen a video bufferbe dekodolva vay konvertalva. aki sokat foglalkozott a temaval, az orul ennek, aki meg nem erti az hasznaljon gstreamert...

A'rpi

Nem is a bonyolultságával van a bajom, hanem a mérhetetlen bug-mennyiséggel. Újabban egy kollégával eleget szívunk. Mi javarészt stream-szervernek alkalmazzuk, s bizony egy egyszerű továbbításnál is belefutunk hatalmas bakikba.
Mondom, nagyon szeretem, mert piszok jól eltalált alkalmazás, viszont azt gondolom, hogy nem igazán jól szervezett jelenleg a fejlesztés.
A mostani változtatásoknak két hozadéka lehet: vagy jó irányba terelik, vagy az, amit Te mondasz, szétzúzzák a project-et. Ha lenne némi időm, alaposabban is átnyálaznám a forrást, hogy mit lehetne kezdeni vele a jövőben, de erre elég kevés esélyt látok, mert be vagyok havazva.

Az tény, hogy nem egyedi szoftvereket írok vele, viszont végeredményben az ffmpeg-ffserver páros ugyanazokat a libeket használja, amiről Te beszélsz (egyébként add már ki konzolban, hogy ffmpeg, fogsz kapni rá alkalmazást :P ).
A végeredmény pedig ugyanaz: működik, vagy nem... Ha a "gyári" frontend is szarul működik, mert bugzik a "motor" alatta, akkor már elnézést, de kb. ugyanarról beszélünk, azaz hogy nem ártana kigazalni. Nem minden esetben csak fejlesztői oldalról kell vizsgálni a kérdést, hanem a user szemszögéből, hiszen elvileg neki írtok szoftvereket, s nem a saját gyönyörűségetekre.

Nem kételkedtem abban, hogy ismered ;)
Fentebb tényleg codec-ekről beszél mindenki, s az általam indított szál tök más részt érintett, s erre jött Árpi hozzászólása, amiben volt API, s egyebek. Igazából mindenki tökre elbeszéltünk egymás mellett, mert mindketten más szempontból vizsgáltuk a kérdést.
Az már tényleg az én faszságom, hogy erre rá is kontráztam, elég szarul (kissé read-only voltam).

azert azt tegyuk hozza, hogy az ffmpeg mint alkalmazas kb 10 eve szuletett, gagyi video streamelesi cellal, sebesseg minoseg nem igazan volt ott szempont, inkabb a sokfele formatum tamogatasa.

aztan kerult bele egy kezdetleges divx 3.11 dekoder (akkoriban meg windozos DLL-el dekodoltuk linuxon is a divx-et), ami felkeltette az erdeklodesemet, igy elkezdtem a libavcodec libjet hasznalni az mplayerben.

aztan elkezdtek a dekodereket javitgatni, optimalizalni benne, kesobb az enkodereket is (bar foleg az mpeg4-et, a tobbi ma sem kiemelkedo).

ma mar az ffmpeg projekt lenyege a libavcodec (illetve mostanaban mar a libavdemux is kezd hasznalhato lenni), gyakorlatilag csak ez van fejlesztve benne, a kod tobbi resze alig valtozott az elmult 10 evben, es kb senkit sem erdekel mar. mindenki a libavcodecet hasznalja belole...

A'rpi

( dap | 2011. 01. 20., cs – 15:59 )

Itthon nem tudtam lejátszani az ffmpeg-el Matroskába muxolt mpeg4-es video streamet WDTV-n, kidebuggoltam, írtam patch-t, gondoltam megvitatom a devel listán hogy miért úgy működik ahogy, de nem tudok bekerülni. Senki nem fogadja el a feliratkozási kérelmem, pedig már a patch-et is elküldtem emailben, hogy lássák nem spammer vagyok.

Azóta javítottam a matroskába muxolt feliratok elcsúszását is, de már meg se próbálom commitelni upstream.

Nem tudom ki érte a felelős, de nincs jó véleményem a karbantartókról.

Pörgetek a lamerszámlálón. :)

Tényleg sikerült feliratkoznom. Először valamiért nem kaptam meg a megerősítő mailt és mivel a weboldal azt írja, hogy vagy emailt kapok vagy a moderator engedélyére kell várnom, hát vártam:

"Your subscription request has been received, and will soon be acted upon. Depending on the configuration of this mailing list, your subscription request may have to be first confirmed by you via email, or approved by the list moderator. If confirmation is required, you will soon get a confirmation email which contains further instructions."

Mondjuk mostmeg itt a forradalom, gondolom vannak ennél fontosabb témáik is, de majd bepróbálkozok. THX!

( Mcsiv v | 2011. 01. 21., p – 09:40 )

régóta várom hogy rendbeszedjék kicsit a projectet, mert egy két ponton elég kusza lett, viszont azt hiszem, erre többet már nem kell várnom:\

( uid_228 | 2011. 01. 21., p – 11:14 )

Itt is átveszik a zoknis-szandálos forradalmárok az uralmat? :/

Elszomorító a volt tagok kommentjeit olvasni, hogy egy milyen idióta bagázs sajátítja ki magának a projektet.

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

> Itt is átveszik a zoknis-szandálos forradalmárok az uralmat? :/
mar at is vettek a bolcseszek
csak azt felejtettek el, hogy az ffmpeg mint trademark, es a domain is Fabrice Bellard neven van, ot pedig elfelejtettek ebbe beavatni, megkerdezni, es ahogy hallom nem is nagyon happy... lesznek meg meglepetesek, popcornt elokesziteni :)

> Elszomorító a volt tagok kommentjeit olvasni, hogy egy milyen idióta bagázs sajátítja ki magának a projektet.

ugyanazok, akik anno az mplayert is "elkoltoztettek"

A'rpi

Mint lamer/n00b/(bölcsész?) a szakmai részhez nincs sok hozzászólnivalóm, sok-sok ideje annak, amikor követtem az mplayer-el kapcsolatos történéseket. Viszont azon el-elgondolkodom, hogy ha ez javarészt a ti gyereketek (volt?), akkor egy diego & tsai hogy a viharba kaphatott ekkora hatalmat a projecten belül? Az volna a helyénvaló, hogy az idióta bagázs a partvonalon kívül marad és ott hisztizik, vagy forkol, ha érez magában elég erőt a saját 5letek megvalósításához. Most viszont ez úgy tűnik, hogy többé-kevésbé fordítva van. Nem látok bele az mplayer fejlesztésének titkaiba, így a miérteket sem tudom - bizonyosan pár heti levlist olvasás segítene ezen. :)

( al3x v | 2011. 01. 28., p – 00:27 )

A kedvenc reszem a levelezesbol:

>> id commit seppuku if i where that. And actually at this point maybe you should
>> > > consider that too? Id vote in the foundation to fund your burial
> >
> > I think i overshoot my goal here, this joke came out more extreem than intended
to repat what i said on irc, i just tried to be funny

--

Update, ez talan meg jobb:

Dear friends, developers, contributors and vultures,

First i want to give you a warm FUCK YOU ALL! for what you've
written and done the last few days.

--
http://bsdbased.com