FFmpeg 0.9

Vyšlo FFmpeg 0.9. Nabízí optimalizace pro ARM, podporu HW dekódování H.264 na Androidu a nativní dekodéry Ut Video a Dirac. Mezi dalšími novinkami je pak podpora vstupu z PulseAudio, experimentální kodér JPEG 2000 nebo podpora libaacplus.

13.12.2011 12:43 | Luboš Doležel (Doli) | Nová verze

Komentáře

[kaja gottzilla]

caute,

v suvislosti s tymto by som sa chcel spytat aky je rozdiel medzi ffmpeg a libav.

nasiel som https://sites.google.com/site/linuxencoding/builds

ktore sa viac oplati pouzivat ? ffmpeg ? libav ? co je kvalitnejsie / perspektivnejsie ?

diik

[Ivanhoej]

podla mna je libav len premenovane ffmpeg, tak neni co riesit.

[Luboš Doležel (Doli)]

Je to fork, ale který převládne, to nevím, jestli je jasné.

[Foo Bar]

Z toho mála, co jsem postřehl to není ani tak o přejmenování, ale o tom, že se rozdělily dvě vcelku dost znepřátelené skupiny.

V průběhu času se zdá, že toto rozdělení nakonec prospělo oboum projektům. Pravděpodobně také proto, že se přestali hádat, a začali zase programovat.

[Espinosa]

No projektům to možná prospělo, alespoň v nějakém směru. Ale uživatelům těžko. Takový developer, třeba MLT, nebo mediálního přehrávače, na kterou kartu teď vsadit? Forky jsou mor.

[l4m4]

To už ty knihovny oddivergovaly natolik, že je zapotřebí vsázet? Nevšiml jsem si...

[pc2005]

Já se ale bojím, že časem jo.

[Grunt]

Víc programuj (testuj, a zajímej se o věci), míň přemýšlej kde koho oškubat jak slepici na cizí úkor a nebudeš muset takové dilemata řešit.

[Espinosa]

Slepice neškubu, ani nikoho dalšího, pokud někdo žije na něčí úkor tak to bude spíš někdo na můj než obráceně.

Řešení problémů s forky, přebytkem distribucí a divergujícím vývojem obecně, mě stojí dost času, který bych jinak právě věnoval programování :)

Přemýšlím rád, ba jsem za to občas i placen, takže se udržuji ve formě.

Do linuxu a OSS jsem dal nějakých 9 let života, takže ano, leží mi tak nějak na srdci.

[Mandarinka]

Hlavně, že to nepostihlo x264. To by byla větší škoda.

[pc2005]

Ono je to stejně vtipný, protože když jsem naposled prohlížel git commity obou projektů, tak byla spousta jmen, co byly u obou repozitářů.

[elenril]

Disclaimer: jsem zaujatá strana, obsah tohoto příspěvku berte podle toho.

Celkem objektivně se dá říct, že libav má víc vývojářů a aktivnější vývoj (počet mailů na libav-devel je zhruba dvojnásobný oproti ffmpeg-devel). Taky celkem objektivně se dá říct, že ffmpeg má víc featur (o jejich funkčnosti/kvalitě se už dá polemizovat).

Subjektivně už přidám, že je to díky tomu, že jejich vůdce merguje nejen libav, ale i všechno ostatní na co došahne. Začalo to kolekcí filtrů z mplayeru (což byla poslední kapka, která spustila revoluci), přes patche které byly předtím odmítnuty na základě technických nedostatků, nedávno to došlo do stavu, kdy merguje nehotové vývojové stromy našich vývojářů. Já osobně si myslím, že tenhle způsob "vývoje" je naprosto otřesný a nemá šanci jim vydržet. Obrovské a stále se zvětšující merge commity (kvůli stále větším rozdílům mezi stromy), které neprocházejí revizí nikoho kromě toho jednoho člověka který je dělá - z toho by měl Linus noční můry. Otrlé povahy necht se podívají například na tohle, kde se mimo jiné bez jakékoli zmínky rozbije ABI kompatibilita.

[Mandarinka]

Hlavně aby už někdo spravil tu konverzi mezi 8-bitovou a 10-bitouvou hloubkou pro potřeby high 10 profile h.264 :3

Nudge nudge... o/

[elenril]

"Spravil"? Ono je to zase rozbité? Bugreport kde?

[Mandarinka]

Ani ne tak "zase". Ptal jsem se kohosi z CCCP asi před 14 dny jen tak pro jistotu, protože jsem si myslel, že od léta už ten algoritmus musí být dávno změněný; řekli mi, že to ustrnulo a k žádné změně nedošlo. Samozřejmě že CCCPáci mohli být toliko blbě informovaný...

Mluvím o http://lists.libav.org/pipermail/libav-devel/2011-August/009950.html respektive http://ffmpeg.org/pipermail/ffmpeg-devel/2011-August/114163.html

Jestli již k nápravě došlo, tak se omlouvám za šum - ono není tak lehké o tom vědět, změn v gitu je spousta a kolikrát laik stejně ani nepozná, o co jde.

BTW ani x264 (při enkódování) to ještě nemá vyřešené - pro správnou funkci je třeba použít opatchovaný build :|

[elenril]

Jestli chceš aby něco bylo opraveno, tak se ukaž u nás na IRC a řekni si o to. Jinak je opravdu těžké si udržet přehled co všechno je potřeba udělat.

[Mandarinka]

Asi bych se an to měl jít zeptat, to je pravda. Já tady to dělám dost nerad, většinou mám pocit, že mě fakt neradi vidí, když to řeknu jemně :)

A taky, oba (foss) directshow dekodéry, tedy ffdshow/libav, už mají vlastní konvertor, což je vlastně důvod, proč jsem o tom ztratil pojem...

[pc2005]

Zrovna libav ani ffmpeg mě moc nepotěšil tím, že začal v poslední době tak rychle zvyšovat číslo verze .

BTW Už to bude asi opravený, ale jedna verze libavu (okolo půl roku zpět a doufám, že to byl libav ) mě generovala nevalidní h264 videa. Šly přehrát, ale při seekování hnusně čtverečkovaly a mplayer z doby ještě dávno před forkem se mě ptal, zda jsem při smyslech . S verzí o prostřední číslo nižší to jelo jako zastara OK.

Jinak nejdůležitější ovšem je, zda je/byl/bude libav kompatibilní s mplayerem (aby to bylo složitější, tak je i u něj fork že? ).

[Mandarinka]

Ano. Pokud koukáte na anime, tak doporučuju MPlayer2 (budou vám fungovat externí openingy/endingy v mkv), pokud ne, asi vám ty rozdíly budou putna.

[Dusan]

No mám pár seriálov s týmito špecialitkami. Píšem si ďalší dôvod do zoznamu prečo minimálne vyskúšať mplayer2.

[elenril]

Které číslo verze? Jako číslo vydání? Ty neděláme zas tak často.

Nebo máš na mysli soname jednotlivých knihoven? Tam se zvyšuje minor verze za každou kompatibilní změnu API nebo za nějakou větší featuru (typu nový kodek). Takže čím rychleji se zvyšuje, tím rychleji jde vývoj; nevidím proč by to mělo jakémukoliv uživateli vadit.

[pc2005]

Aha, je možný, že v tom mám docela brajgl.

Ale schválně jsem si vytáhl komentáře s kámošem, bylo to okolo 20.5.2011 a kámošovi jsem si stěžoval, že forku ffmpegu ve verzi 0.7 beta se ffplay rozmazává dole 16pix široký pás a nejde resizovat h264 videa (problémy při seeku, originál je OK). Verze 0.6.2 to zvládla OK a na x264 to nezáviselo (a ten integrovanej program v x264 vytvořil vždy h264 video v pořádku). Taky si vzpomínám, že se mě ffplay zdál pomalejší/trhanější než prastará verze ffmpegu ještě před forkem.

[pc2005]

Ještě takovej nápad. Teď už je to sice jedno, mám xGHz kompa se SSE, ale před tím půl rokem jsem enkódoval 2 fps . Zajímavá featura by byla enkódování přerušit a třeba druhej den pokračovat ve zbytku.

[elenril]

SIGSTOP/SIGCONT?

Nebo si uložit počet framů a pak použít select filter abys pak začal až od daného framu.

[pc2005]

Myslel jsem aby to přežilo i reboot počítače (divil bych se kdyby ten komp přežil suspend to disk).

To druhý je zajímavý nápad, doufám, že to funguje pro první i druhý průchod a že to přerušení nemá vliv na framy, který závisej na minulejch.

[Mandarinka]

Druhá půlka kódování začne I-framem, samozřejmě, takže všecko odznova - ideálně byste to teda měl rozdělit tak, aby na začátku byl první frame scény. Na druhý průchod to samozřejmě vliv má, ten se musí dělat najednou, z principu. Leda, že byste si rozpočítal příděly bitrate na jednotlivé díly (což není optimální). Tento postup je spíš pro jednoprůchodové kódování (crf u x264).

Aby to přežilo reboot počítače, to by se musel uložit stav toho procesu nebo něco... což se samozřejmě nikomu nechtělo naprogramovat. Ale suspend to disk/ram jsem při běhu x264 používal běžně (jde to to, jeslti se vám pc/notebook probouzí, samozřejmě).

[pc2005]

Jj musel bych správně stopovat první framy scény. To ale není moc user a dokonce ani hacker friendly . Jinak právě druhý průchod byl problém. První míval tak 4 fps, druhej jen 2 a to pak trvalo třeba 8 hodin .

Uložit stav procesu. Na to jsou dokonce softy, ale moc nefungovaly, když jsem je zkoušel naposled (problém otevřenejch souborů, socketů, ...). Ale kdyby to podporoval přímo ffmpeg, tak by v něm stačilo uložit pozice v souborech, aktuální proměnné a tabulky související s enkódováním a snad by to bylo OK (ale fakt, já si hrál u multimedií jen s lamemp3 knihovnou - tam by to nebyl problém).

Proubouzení by asi šlo, ale ten stroj byl fakt mimo (i když tohle by asi zvládl nakonec - po hodně neprospaných nocí ). Další nápad kámoše byla virtualizace, ale to bych enkódoval sice přerušovaně, ale 10x dýl .

[elenril]

Nevim o tom, že by se ted něco takového dělo. Jestli dokážeš něco podobného reprodukovat, tak dej vědět nám a ne kámošovi

[pc2005]

Určitě dám . Teďka už nemusím čekat na jednu kompilaci hodinu (a další hodinu na dostatečně dlouhý h264 video).

[elenril]

Co se týče kompatibility, libav je a bude kompatibilně s mplayer2. U mplayeru si nejsem úplně jistý, ale pravděpodobně taky. Ten je ale stejně prakticky mrtvý.

[Pev]

U mplayeru si nejsem úplně jistý, ale pravděpodobně taky. Ten je ale stejně prakticky mrtvý.

Také jsem si myslel, že mplayer je mrtvý. Dle svn logu (svn://svn.mplayerhq.hu/mplayer/trunk) je vidět za prosinec 75 commitů od 7 lidí, za listopad 84 commitů, každý měsíc tohoto roku 100-200 commitů...

Asi jsou to malé věci, ale "praktický mrtvý" se nezdá být.

[elenril]

Jak to tak vidím, tak jsou to převážně drobné nebo kosmetické změny. Větší (a hlavně uživatelsky viditelné) změny už jsem v mplayeru neviděl hodně dlouho. Narozdíl od mplayeru2, kde je konečně pořádná pauza, mkv ordered chapters a tak dále.

Ale ted vývoj obou projektů moc nesleduju, takže možná mi něco ušlo.

[Pev]

Zdá se, že jsou tam i fixy, a ty se vždycky hodí . Mplayer2 backportuje některé změny z mplayer (asi práve ty fixy).

[pc2005]

Aha, to by šlo. Plánuje se u libavu podpora vlastností, které má zatím nepodporovaný mencoder?

[elenril]

Jakých vlastností? A platí to samé co výše, jestli ti chybí nějaká vlastnost tak je nejlepší se zeptat na IRC nebo uživatelském ML.

[pc2005]

Aha, to já jen aby nestála řeč (zvlášť když je k dispozici přímo vývojář). Mencoder jsem používal hlavně pro vkládání titulků přímo do videa. A taky byl mencoder tuším víc odolnější vůči podivným parametrům podivných formátů.

[elenril]

Co si pamatuju, tak s hardsubbingem měl i mencoder nějaké problémy, většinou bylo spolehlivější řešení použít mplayer so -vo yuv4mpeg a přes fifo to poslat na ffmpeg nebo něco takového.

Naše interní řešení je bohužel ted ve fázi "bylo by hezké to někdy mít", ale není to tak úplně jednoduché zařídit.

[pc2005]

Jasně, držím palce .

[Mandarinka]

Ad vkládání titulků do videa - mplayer2 má (nevím, jestli je to v hlavní větvi) speciální vo pro enkódování (vo-lavc nebo tak). Nejsem si jist, jestli to umí vobsuby. FFmpeg myslím nedávno přidal libass (vykreslovač textových titulků, taky to možná neumí vobsuby) jako filter, ale čert ví, jak dobře to funguje; libass to myslím nemá. Ani jednu z těchto možností jsem nikdy nezkoušel, to jen tak pro pořádek.

[pc2005]

Jasně, mě by osobně nevadilo, kdyby byl mencoder úplně zrušenej (třeba kvůli nekvalitě). Jenom by bylo škoda případných funkcí bez alternativy (protože tyhle dva projekty považuju za killer-app).

[Mandarinka]

Já bych to tak černě neviděl. Jestli je něco ve světě videa killer app, tak je to avisynth :) Pro renderování titulků byste ale potřeboval poněkud alfoidní plugin assrender, protože standardní vsfilter je na potvoru jeden z mála, co IIRC nejdou pod wine.

[pc2005]

Pod wine? To není avisynth pro linux? *ohrnuje nos* Jinak avisynth neznám, takže nemůžu posoudit zda je či není killer app.

[alium]

co vím, tak libav používá gstreamer0.10-ffmpeg, jinde jsem zatím libav použít neviděl...