Visszatérhet az FFmpeg a Debian-ba

Debian

2011-ben kaotikus körülmények közt vált ketté az FFmpeg projekt és jött létre mellette a Libav fork. A Debian akkor úgy döntött, hogy Libav-re vált.

Andreas Cadhalpun arról írt a debian-devel listán, hogy tervei szerint visszatér az FFmpeg a Debian-ba. Hogy miért? Mert a fejlesztő szerint:

  • olyan szolgáltatásai vannak az FFmpeg-nek, amelyeket a Debian felhasználók kérnek
  • néhány alkalmazás nem működik megfelelően, ha azt a Libav-vel fordítják Debian-on, mivel azokat az FFmpeg felhasználásával fejlesztik
  • Vannak olyan problémák a Libav parancssori eszközeiben, amelyeket az FFmpeg eszközeivel nem lehet reprodukálni
  • az FFmpeg nagy és aktív felhasználói és fejlesztői közösséggel rendelkezik

A terv az, hogy nem leváltja az FFmpeg a Libav-t a Debian-ban, hanem egymás mellett lesznek elérhetők.

A részletek elolvashatók a bejelentésben.

( yzsolt | 2014. 07. 29., k – 11:45 )

Munkahelyen kellett PHP-ból ffmpeg-et hívogatni mindenféle videóinfó kinyerésére, csakhogy az éles szerveren Debian volt libav-vel. Kb. másfél óra után feladtam a dolgot, képtelen voltam átírni az addig tökéletesen működő ffprobe-os parancsot avprobe-ra. Valami kapcsolót nem ismert fel (ami amúgy benne volt a libav dokumentációban...). Végülis fordítottam egy ffmpeg-et gyorsan forrásból, helyreraktam a symlinkeket (elég vicces, hogy az ffmpeg, ffprobe, stb. rá vannak kötve a libav exéire, holott baromira nem kompatibilisek egymással), azóta is tökéletesen működik.
Ha jól emlékszem, volt még valami ffmpeg-nek tűnő csomag, de azt sem sikerült felhasználni, meg elég régi volt. Szóval tegyék csak vissza, ha netalán újra Debianhoz kell nyúljak, akkor ennyivel könnyebb legyen az életem :D

( neuron | 2014. 07. 29., k – 20:08 )

phoronix:

"The only reason why libav exists and is used in Debian is some fight between ffmpeg developers that resulted in a fork, and unfortunately, the Debian ffmpeg maintainer was on the libav side of the fight. And now he's unwilling to package ffmpeg, because the ffmpeg devs are his enemy. And it looks like he's also trying to prevent ffmpeg from re-entering Debian when maintained by someone else who is on neither side of the ffmpeg/libav conflict."

----
"Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat."
Instant Coelho

Engem érdekelne a teljes igazság Debian oldalról. Olvastam egy elemzést, hogy az ffmpeg minőségileg sokkal jobb, mert a libav-sok olyannyira öntudatra ébdredtek, hogy nem foglalkoznak az ffmpeg patchekkel, inkább szétverik a dolgokat, és Niedermayer nagy arc, de legalább technikailag jókat csinál az ffmpeg-ben.

--

Debianos oldal ugy all, hogy jelenleg libav van, mert egykor ez jo otletnek tunt. ffmpeg NEW-ban csucsul, es arra var, hogy kitalaljuk, mi legyen. Az alabbi opciok vannak:

  1. Bemegy ahogy van, es conflictol a libav-s dolgokkal.

    Ez egyszeru, amde hasznalhatatlan katyvaszba torkollik. Tehat ez nem jarhato ut. Hogy miert torkollik katyvaszba? Mert a csomagok neve kulonbozik, de a library neve egyezik, ami eleve policy violation. De ha ezen tul is lepunk, van az az eset amikor X lib linkel ffmpeg-hez, Y app linkel X libhez, es mellesleg libavhoz => nem telepitheto, conflictok miatt.

  2. ffmpeg-es libraryk uj, Debian-specifikus soname-t kapnak

    Ez is relative egyszeru, amde szinten katyvasz lesz, mert igy Y app ami X-hez es libav-hoz linkel, X meg ffmpeg-hez, bizony szetesik csunyan. Raadasul 3rd party binarisok amik ffmpeghez linkelnenek, nem mennek, mert mas a soname. Szoval ez sem az igazi.

  3. libavs libek uj, Debian specifikus soname-t kapnak, es ffmpeg lesz a default

    Ugyanaz a problema.

  4. libav-t lecsereljuk ffmpeg-re

    Ez baromi nagy melo, plane igy freeze-hez kozel. Mindent ami libav-s, ujra kell forgatni, potencialisan fixalt bugok nyilnak meg ujra, vagy megujabbak jonnek, es azon kivul hogy N ember allitja, hogy ffmpeg jobb, semmi garancia nincs arra, hogy tenyleg megoldodnak olyan bugok, amik most libav eseteben fennallnak.

Mindezekhez hozza tartozik meg, hogy a security team NEM akar libav-t ES ffmpeg-et is karbantartani egy stable releaseben. Az egyikkel is epp eleg szivas van, ketto az mar eros tulzas lenne. Szoval ok azt szeretnek, hogy ha az illetekesek lebokszolnak a dolgot, es csak egy maradna. Egyebkent is az egy marad az egyetlen ertelmesen jarhato ut, hacsak az upstreamek at nem gondoljak, es meg nem valtoztatjak a library meg symbol neveket, hogy egy appon belul lehessen mindket libet hasznalni.

Szerintem egyebkent ez utobbi lenne a legszebb megoldas, csak igy az ide-oda cherry-pick a ketto kozott meg annyira se mukodne, mint most.

Mindenesetre Debian haza tajan a security team (teljesen jogos) kifogasai akadalyozzak az ffmpeg belepeset, illetve az, hogy a conflictokat nem tudjuk, hogyan lehetne ertelmesen feloldani, a releasehez ilyen kozel. Szerintem ennek a megoldasa jessie+1-re fog csuszni, es jessie-ben libav marad. Utana konnyen lehet, hogy ffmpeg-re atterunk.

--
|8]

Mikor átfutottam a threadet, akkor ott valaki (asszem az ffmpeges eredeti srác írta), hogy a libav-val üszkve 6 havonta volt sec patch, vagy valami ilyesmi. Ez tényleg ekkora gond, vagy van még más is? Tényleg kérdezem, nincs véleményem, csak mondod, hogy szerinted a sec teamtől jogos, de ez alapján a részinfó alapján nem tűnik elviselhetetlennek a dolog...

Nem tudom mekkora melo. De a sec team semmi extra munkanak nem orul, van dolguk eleg. Es kb ugyanazt megpatchelni ket helyen gaz, plane ha azt is belevesszuk, hogy ha az egyikhez kijon egy sec patch, az lehet, hogy a masikat is erinti, es akkor azt is updatelni kene, de lehet, hogy ott meg nincs patch... nem szep helyzet, megertem, hogy el akarjak kerulni, meg akkor is, ha ritkan van szopas vele (mert akkor cserebe az a szopas viszont hatalmas).

--
|8]

Hát nem tudom. Értem én, hogy van dolguk elég, de végülis ők akarnak security teamet játszani, az meg picit hátrább lépve minden patchelés szopás :)

Azért furi, mert a debianra nem jellemző, hogy emiatt kihagyjon dolgokat, kb minden be van csomagolva, ami valakit is érdekel, nem egy rh, ahol rábökünk, hogy ez lesz a webszerver, és csoki... Pl ahogy nézem a testing csomaglistáját (amiből azt a következtetés vonom le, hogy azok a csomagok be akarnak kerülni a stableba, és ezzel senkinek nincs komoly hasfájása), mysql-server, meg mariadb-server is van, és úgylátom még csak nem is conflictolnak... Szal kicsit furi, de persze partvonalról könnyű okosnak lenni.

Nem ez az elso amire sec team azt mondta, hogy ok nem foglalkoznak vele, oldjak meg maskepp, kulonben stable-be nem megy. Most is ezt mondtak egyebkent: ha valaki vallalja, hogy megcsinalja a debianos security maintenanceot, akkor feloluk mehet. (Egyebkent sec teamnek testing + stable-re van rahatasa, unstable-be ettol meg mehetne)

Viszont meg mindig ott van a transition vagy az egyutteles kerdese. Amig az nem dolt el, addig nem sok ertelme van beengedni, mert csak ujra kene csinalni mindent megint.

mysql es mariadb eleg mas, peldaul eleve, az elso naptol kezdve kulonbozo a csomagok neve, nem utkoznek. Ez azert jelentosen egyszerubbe teszi a dolgot :)

--
|8]

Köszi a választ. Azt viszont nem értem, hogy a deb-multimedia repoból feltelepített ffmpeg miért működik szépen, ráadásul együtt a libavval. Mindenféle ütközés nélkül. Ha a deb-multimedias sracnak sikerült megoldani, akkor ugyanazt a megoldást nem lehetne átvenni?

----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

a baj az, hogy conflictolnak a lib nevek. a libav forkkal egy uj projekt jott letre, es ok buszkek ra hogy felrugtak az ABI kompatibilitast az ffmpeg libekkel (errol volt anno egy hosszu vita, hogy legalabb az ABI legyen kompatibilis, hogy az egyikkel linkelt cucc mukodjon a masikkal is).

a masik baj hogy anno a libav-re csereltek az ffmpeget, pedig akkor is koztudott volt hogy az egy halott irany, csak hat a deb packager eppen libav buzi volt. az meg mar a debiant minosoti, hogy ezt hagytak. holnap az openssl packager fog forkolni egy jot es azt is lecserelik egy ugyanolyan filenevu mas cuccra?

A'rpi

Szerintem is hulye otlet volt a fork. Ettol fuggetlenul azert azt is latni kell, hogy Debian, ugy cakkumpakk, nem nagyon lat bele az ffmpeg<->libav dologba, nem is akar, es nem is kell neki. Erre van a maintainer. Aki tortenetesen nem epp a legjobb dontest hozta, ez van, most megy az agyalas, hogyan lehet megoldani, hogy megint jo legyen nekunk.

OpenSSL egy picit mas dolog azert. Egyebkent a glibct pl lecsereltek eglibcre, most meg vissza. Es igen, ezt meg lehet csinalni, a maintainerre van bizva. Termeszetesen van ra mod, hogy ha a maintainer kolosszalis baromsagot csinal, vagy direkt elront valamit, akkor szankcionalni lehessen, es visszallitani a regit (pl. tech-ctte, vegso esetben). Ez egy teljesen jol mukodo modell, velemenyem szerint, megha neha kisebb-nagyobb katyvaszhoz is vezet.

--
|8]

"And now he's unwilling to package ffmpeg, because the ffmpeg devs are his enemy. And it looks like he's also trying to prevent ffmpeg from re-entering Debian when maintained by someone else who is on neither side of the ffmpeg/libav conflict."

Ez ilyen formaban nem igaz. A maintainer valoban libav parti volt, de:

1) Maintainernek nem feladata olyat csomagolni, amit nem akar. El lehet tole venni csomagot, at lehet adatni masnak, de arra kenyszeriteni, hogy libav helyett ffmpeget csomagoljon, nem lehet. Ennel fogva, az, hogy nem akar ffmpeget csomagolni, az egyatalan nem problema. Van mas, aki igen.

2) A Debianba visszakerules akadalyait lasd fentebb. Libav maintainernek ehhez vajmi keves koze van. Nyilvan feltehet kerdeseket, es kifejezheti aggalyait, de a bekerulest nem o hatarozza meg (az az ftp-masterek dontese).

3) Debian reszrol en azt latom, hogy megoldast keresnek, "de"-k tekinteteben megint lasd feljebb.

--
|8]

Azért, ezt így... Egy "politikailag" korrekt magyarázat.
És ebben a politika szót a kellő pejorativitással együtt értsd!

Igen, nagyon szépen védi muksókám az álláspontját. Gratulálok neki. Ha nagy lesz hátba is veregetem érte.

De amennyire eddig látom a történet, a libav az, ami libffmpeg-nek mondja magát, és evvel a becsúszós szereléssel szerez magának userbase-t, mert amúgy ha technikai döntések jönnének politikai alap helyett, akkor a kutya se használná.
Eleve, ebben a formában a libav-nek szerintem nem is lett volna szabad bekerülnie a debianba, mert mint ahogy mondtad policy violation-t sértés van.
Az ok, hogy az ffmpeg _még_ nem volt csomagolva, amikor a libav már bekerült... De a libav aki ffmpeg-nek hívja magát, és nem fordítva...

De ha teszem azt lenne mondjuk egy verybestproduct amit forkolnának lameshit néven, és mivel mindenki el van havazva, meg senki nem figyel, így a helyzetet kihasználva a haverom a debian maintainer közösségben lameshit-et kezdene csomagolni, ami a teljes kinézetig az utolsó pontig még a manuálban is úgy néz ki, mint verybestproduct, közben meg az aljától rohad, (lásd fenti példa, még azt sem teljesíti, ami a saját man-jában volt!), de aztán mire észbe kezdünk kapni, hogy hoppá, a debianban lameshit van, és nem tudjuk csomagolni, még ha akarnánk is a verybestproduct-ot, mert a lameshit is verybestproductnak hazudja magát... És jujujujj policy violation...
Szerinted ez:
1: rendben van így?
2: szerinted verybestproduct csomagolójának a dolga megoldani lameshit által a debinaba lapátolt bughalmot? miközben lameshit, per definíció, NEM a verybestproduct, csak kiváltó valami akarna lenni, valamilyen szintű kompatibilitást biztosítva... De leginkább pár hancúrozó C-kiddi homokozója.
3. ezek így együtt, kevés a debian technical commitének, hogy hozzanak végre egy határozott tökös döntést, és azt mondják, hogy hmm... basszus, a maintainer tévedett, de nem kéne tovább kenegetni a sz@rt, hanem helyette kivágni lameshit-et, és adjunk zöld utat verybestproduct-nak, és ameddig nem talál lameshit gazdája egy policy-ilag elfogadható módszert, addig kerüljön ő blockingra?

+1: nem lenne lassan ideje a debianban egy "universe" repó létrehozásának, ami kb. hasonló mint a main, DE per definíció, csak annyi van tesztelve vele, hogy amúgy korrektül megy, nem ront el semmit, lehetne akár a main része is, CSAK épp nem adunk rá security támogatást?
Sokat lendíthetne egy ilyesmi szerintem a debian releasek gyorsaságán, meg akár lts-képességén is, ha elkezdenének ilyesmit. A security maintainerek, meg a commité meg szépen, akár ki is szavazhatna egy-egy csomagot a universebe. Egy extrém és elrugaszkodott példa, ami lehet, hogy nem lendítené előre a debiant, de az ötletet megvilágítva: SecTeam azt mondja, hogy apache ótvar bughalom, nem figyelnek rá eléggé security szempontból, és még azokat a patcheket is rémálom back és forwardportolgatni, miközben meg lighttpd és nginx meg yippiájé, és innentől apache menne universbe, másik kettő meg mainben maradna.
(Azért mondtam ilyen extrémet, mert a gyakorlatban úgyis megvalósíthatatlan lenne, mivel apache2-utils -ban attól még van egy csomó "extra", amit akkor is használ az ember, ha amúgy apacheot nem is: rotatelogs, htpasswd,...)

( NevemTeve | 2014. 10. 14., k – 19:24 )

Off: Akkor nekem is ilyen gondom lehetett: a házilag fordított ffmpeg/ffprobe megszűnt működni az 'apt-get install kino' után.

Szerk: Most úgy látom, hogy a következő varázsige segített: 


export LDFLAGS='-Wl,-rpath=/usr/local/lib'
./configure ...