Libav 0.7

Vyšel Libav 0.7. Mezi nejzajímavější novinky patří vícevláknové dekódování VP8, H.264 a dalších video formátů a dekódování 10-bitového H.264. Jako obvykle přibyla řada nových dekodérů, např. zmíněné VP8, AMR-WB, HE-AACv2 a další. AC3 kodér byl obohacen o vylepšení z projektu Aften a nově umí kódovat do E-AC3. Bylo začleněno i několik nových (de)muxerů a mnoho dalšího.

21.6.2011 14:26 | elenril | Nová verze

Komentáře

[David Heidelberg]

Konečně

[Grunt]

Konečně co?

[xm]

Hlavně vícevláknové dekódování - už bylo opravdu na čase.

[Grunt]

Do tak do teď se defaultně používalo ffmpeg-mt. A jinak:

                 threads=<1-8> (pouze MPEG-1/2)
                      počet vláken použitých pro dekódování (výchozí: 1)

[elenril]

Někdo tady má špatnou verzi mplayeru =p

[Grunt]

To už je zas další? Já měl za to že jsou jen dva, ne?

[elenril]

Mplayer2 u mě říká

threads=<0-16>
Number of threads to use for decoding. Whether threading is actually supported depends on codec. 0 means autodetect number of cores on the machine and use that, up to the maximum of 16. (default: 0)

[Grunt]

Jo, však jo. Vždyť říkám, že do teď se stejně používal jako default ffmpeg-mt (i když mám počítač s jedním jádrem). Ten man je samo pro mplayer první verze a ten také uměl více-vláknové dekódování (a existoval pro MPEG-4 mplayer-mt), takže tak nějak nechápu wo co go (nehledě na fakt, že moc nechápu k čemu takový mplayer-mt využít).

[xm]

(nehledě na fakt, že moc nechápu k čemu takový mplayer-mt využít)

WTF? Pokud chce člověk na vícejádru přehrávat plynule 1080p H.264 ripy (což je možná se budeš divit velmi častá činnost) a chce k tomu přehrávání používat mplayer, byl až donedávna mplayer-mt jedinou možností. Bez něj by mi např. moje linuxové HTPC bylo na hovno.

[Grunt]

Kodek který potřebuje dvě jádra (pokud to teda není nějaká 486, u toho by se to snad dalo připustit) aby mohl být přehráván v reálném čase si ani nezaslouží být přehráván!

[elenril]

Troll detected.

[Grunt]

Ale prdlajs. Kde?

[Luboš Doležel (Doli)]

Hned nad mým příspěvkem. Mám snad dodat nějaké H.264 s vysokým bitrate, aby ti to jedno jádro neutáhlo?

[Grunt]

A rovnou si dej i facku. Bitrate ≠ kvalita ≠ potřeba vysokého výkonu (podobně to platí i pro rozlišení…čistě teoreticky vyšší rozlišení automaticky nemusí znamenat větší nároky na výpočetní výkon při dekódování, v praxi to holt trošku vázne). Libovolný formát nebo kodek je jen kompromis mezi účinností a náročností (čistě teoreticky je možné i v současné době zkonstruovat formát ještě mnohem účinnější, ale také mnohem náročnější). Dám příklad: Např. MPEG-1 Part 3 byly navrhovány tak že každá další vrstva je zpětně kompatibilní s předchozí a o málo komplexnější než ta předchozí, ale také potřebuje k dosažení transparentnosti nižší bitrate. Takže MPEG-1 Layer I je jen velice jednoduchý 32.pásmový filtr a celkově struktura bitstreamu není moc náročná (délka okna 384 vzorků, fixní SCF i alokační tabulka pro celý frekvenční rozsah, pouze CBR rozlišení 750 Hz,uniformní kvantizace vzorků,512 bodů pro FFT,…) ale pro transparentnost se udává snad nějakých 384kbps, Layer II je už o něco komplexnější (granule a grupování vzorků, adaptivní jak SCF, tak alokační tabulka a ta ještě podle důležitosti rozdělená na tři oblasti podél celého pásma, SCFSI, délka okna 1152 vzorků, 1024-bodová FFT,…) ale furt je bez DCT (takže furt 750Hz rozlišení a furt CBR a stále uniformní kvantizace), takže koeficienty jsou v podstatě stále PCM vzorky ale transparentnost je udávána u nějakých 192kbps a nakonec MPEG-1 Layer III která vzorky promele ještě MDCT (32-pásem, ale 575 spektrálních lajn, rozlišení 41.66Hz), přidává Huffmanovo kódování, neuniformní kvantizaci skrze kontrolní smyčku, úplně jinou alokaci takže i s VBR, možnost změny okna (ale to je z jiných důvodů) a udávaná transparentnost je při nějakých 128kbps (o psychoakustyckých modelech radši mlčím úplně). To samozřejmě neplatí jen pro Part 3 ale i pro Video část libovolného MPEG standardu. I když se to moc neví, tak ona v podstatě neexistuje jedna H.264 (/MPEG-4 Part 10 abych byl přesnější), ale má spousty voleb a profilů které sice ovlivňují efektivitu kódování, ale také komplexnost. A navíc H.264 není jediný standard (že je MPEG-1/2/4-ASP nebo i třeba SP starší ještě automaticky neznamená, že je o tolik horší nebo třeba vhodný jen na nízká rozlišení). Takže třeba v mém případě stačí vypnout to debilní deblokování při kódování a i můj stařičký 2.6Ghz Celer nemá s téměř libovolným videem do rozlišení 1920x1080 (na větší prostě mám obrazovku a ani zdroj) nejmenší problém. Osobně jsem si samozřejmě zkusil MPEG-4 ASP (u toho se snažím ještě poroubovat GMC a skip_lambdu tak aby to bylo ještě mnohem méně náročnější) a MPEG-1/2 i pro vysoká rozlišení a to je ještě lepší. Takže to že to neutáhne jedno jádro ještě nemusí nutně znamenat, že máš pomalý počítač, ale to že riper nebo třeba někdo z Mplayer týmu je prostě a jednoduše lama.

Čistě pro zajímavost: S uniformní kvantizací aplikovanou na obraz také blbnu. Zatím se mi s MPEG-1 podařilo dostat na nějakých 600Mhz pro dekódování (800Mhz i s režií) o rozlišení 1920x1080 a věřím že s optimalizovaným formátem i přehrávačem by to šlo ještě o mnoho níž. A jak se zdá, Monťák se na prostou blbou frekvenčně-časovou reprezentaci pomocí prosté Fourierky vykváknul též.

[Aminux]

Takže to že to neutáhne jedno jádro ještě nemusí nutně znamenat, že máš pomalý počítač, ale to že riper nebo třeba někdo z Mplayer týmu je prostě a jednoduše lama.

To je asi pravda. Nicméně já jako uživatel s tím nic nesvedu. A skutečně existují videa, které jedno jádro mého procíku neutáhne. Takže uvítám, když je možnost vícevláknového přehrávání anebo HW dekódování. Záleží na spoustě věcí. Jak byl nastaven kodek při převodu, jestli je to 25 fps nebo 50-60 fps. Dostal byste se na 600 MHz při 60 fps?

[Grunt]

Nicméně já jako uživatel s tím nic nesvedu

Tohle nesnáším. Jakože ti co to píšou, navrhují nebo ripují jsou co? Nějací polobohové? A hubu (resp. teda klávesnici) na vřískání má snad každý (jeden by až řekl, že si stačí vzít příklad z Ubunťáků, teda samozřejmě kdyby chtěl rýpat ), když už teda ta klávesnice neslouží k psaní kódů, standardů nebo příkazů, které začínají $ x264. Důležité je aby se vědělo, že existuje problém.

A skutečně existují videa, které jedno jádro mého procíku neutáhne

Tak to samozřejmě i na můj (dokonce bych spíš řekl majorita a nejen nějaká videa). Já jsem jen tak fikaný, že to nedávám za vinu ani mně, ani mému procíku, ale všem ostatním.

Takže uvítám, když je možnost vícevláknového přehrávání anebo HW dekódování.

To je moc jednoduché. Samozřejmě že to uvítám i já (resp. jsem vítal snad dva roky zpět nebo tak), ale neznamená automaticky že neexistují i jiné (i když nehotové možnosti).

Dostal byste se na 600 MHz při 60 fps?

K tomu se nebudu vyjadřovat, jelikož bych se zase vzteknul nad tou obnovovací frekvencí.

[Grunt]

Takže ať to shrnu: Mám ti zas pro změnu já dodat nějaké video s vysokým bitrate a o vysokém rozlišení (myslím, že 1920x1080 je standard) ve formátu MPEG-4 (klidně i AVC) aby ti to libovolné moderní (no minimálně víc než to moje což snad ale k 32-bitovému Celeru o 2.66Ghz nebude problém) jedno-jádro bez problémů utáhlo?

[Miloslav Ponkrác]

Kecáte hovadiny pane. Nejlépe je to napsat takto naplno.

Možná se budete divit, ale takový ARM ve vícejádrovém provedení v úsporném režimu docela více jader ocení.

Nehledě na to, že i můj 4jádrový AMD na 3,2 GHz poměrně ocení vícejádrový přehrávač. Ono milý pane, pokud 4jádra drží v klidu na low výkonu, pak spotřeba cpu = 19,5 W. Když byť jedno jádro jede naplno, pak spotřeba = 119 W. S Cool'n'Quiet se automaticky podtaktovává cpu, když není třeba plný takt.

Takže rozdíl mezi vícejádrovým a jednojádrovým přehrávačem se dá snadno vyjádřit i finančně v prospěch multithreaded.

Také znovu připomínám, nejste pupek světa a Vás model cpu není jediný na světě. Ne všechny video přehrávače mají x86 procesor a pokud ano, ne všechny mají výkonný x86 procesor.

Jinak co jste jako argumenty použil, je zhruba inteligenční odborný šum používaný asi tak v úrovni pro ekologické zdůvodnění, proč musí být zakázány žárovky.

[pavlix]

Kecáte hovadiny pane. Nejlépe je to napsat takto naplno.

Mám úplně stejný názor ohledně vás.

[Grunt]

No Ponkráce mi byl teda ještě čert dlužen.

Kecáte hovadiny pane.

Jo, jo. Protože to já umím nejlíp.

Možná se budete divit, ale takový ARM ve vícejádrovém provedení v úsporném režimu docela více jader ocení.

No když už nic, tak ARMy (aspoň OMAPy určo) mají DSPčka, které zpravidla jedou díky speciálním registrům a instrukcím ještě na nižší frekvence, mají jedno jádro a hlavně to na nich těžko přehraje Mplayer.

Nehledě na to, že i můj 4jádrový AMD na 3,2 GHz poměrně ocení vícejádrový přehrávač. Ono milý pane, pokud 4jádra drží v klidu na low výkonu, pak spotřeba cpu = 19,5 W. Když byť jedno jádro jede naplno, pak spotřeba = 119 W. S Cool'n'Quiet se automaticky podtaktovává cpu, když není třeba plný takt.

Tento odstavec zní tak že bych se z něj největší radostí smíchy potrhal. Komplexnost dekódování má vliv na dvě věci: Na výrobní cenu (řekněme DSP) čipu a o něco méně pak na jeho nároky na energie (když je potřeba udržovat na živu víc registrů, tak to holt víc žere a víc topí, atd.). A i když první bod argumentace byl ze začátku stěžejní, tak díky tomu že DSPčka dělá kdejaký Vietnamec, tak stále více pomíjí a naopak do popředí se dere bod druhý – tedy náročnost na energie. Jediný Ponkrác na celém širém světě je snad schopný to domotat tak, že z neschopnosti výrobce svého procesoru dovede udělat výhodu. Věřím, že manipulace je Vaším denním chlebem, no bohužel na mě to neplatí. Já si ty Vaše kecy bohužel ověřuju.

Takže rozdíl mezi vícejádrovým a jednojádrovým přehrávačem se dá snadno vyjádřit i finančně v prospěch multithreaded.

LOL. Žádný technik by se do takové kraviny jako finančního vyčíslování tak komplexní věci nechtěl pouštět (krom Manažera, ale to není technik takže to nemůže chápat), takže blahopřeju. To jste si znova naběhl.

Ne všechny video přehrávače mají x86 procesor a pokud ano, ne všechny mají výkonný x86 procesor.

Znova parádní náběh. Třeba takový ne-x86 procesor TMS320C62x (C64x) od TI na tyto věci dělaný dokonce komplexnější věci než je H.264 Baseline (tzn. snad všechny dnešní BDRipy) ve svém firmwaru odmítá přehrávat protože víc než na jádra klade důraz právě na tu komplexnost. Samozřejmě nemám nic proti provozování více jader s nízkým taktem. Ale ruku na srdce, kdo to v praxi viděl? (a až uvidím budu upřimně rád)

Také znovu připomínám, nejste pupek světa

Říká Ponkrác? To snad zapíšu do memoárů.

Jinak co jste jako argumenty použil, je zhruba inteligenční odborný šum používaný asi tak v úrovni pro ekologické zdůvodnění, proč musí být zakázány žárovky.

Nápodobně. Přesně takto to vidím já. Jen jsem ještě nepřišel na to jestli schválně nebo Vás to jen prostě tak ukrutně baví.

[Jiří Němec]

Jo ARM mají různá DSP, ale pak vyjde třeba takový WebM kodek, nebo člověk narazí na nějaký MS formát nepodporovaný v hw a to své staré telefony máme zahodit? Stále existují přehrávače používající sw cestu i pro mobilní telefony.

[Grunt]

ale pak vyjde třeba takový WebM kodek

S VP8 je to velmi složité. Technicky jde o formát, který vychází právě ze standardů MPEG-4 AVC a jen ho kopíruje, ale je s jeho bitstreamem nekompatibilní. Teda až právě na ty profily. Sice má VP8 nějaké možnosti nastavení, ale jednak nejsou příliš modulární a jednak je stejně oficiálně doporučováno nic neměnit a nechat to tak jak je, protože výsledek bude k ničemu (výchozí je profil slow, fast prostě není nijak optimalizován a je tam jenom protože tam je). K libVpx se nevyjadřuji vůbec, protože to je bazmek pomalý, který je holt nahackovaný na libVP8, který zase pro změnu nepsali hackeři a podle toho to také vypadá. Celý formát prostě vznikl z toho důvodu aby mohl zajistit existenci firmy On2 Technologies (takových kopírovačů standardů co prodávají špatně okopírovaný naleštěný prd bylo v historii mnohem víc) a normálně bych řekl, že je to právě jeden z formátů, který to přehrávání nezaslouží (V tomhle jsem prostě radši pro standardy, protože z technického hlediska jsou mnohem promakanější). Bohužel všichni víme jaká je patentově-licencová situace a tak je těžké říct jestli si zaslouží nebo nezaslouží být přehráván. Prostě z licenčního hlediska není na výběr. Určitě si zaslouží být více optimalizován.

Pro zajímavost: S přehráváním VP8 na mobilech bych si nedělal moc nadějí. LibVPX sotva dává i při malých rozlišeních můj počítač, ne můj mobil. FFVP8 možná. Sice se dívám, že jeho podpora v Andoridu 2.3.3 přibila, ale to nemá žádné racionální opodstatnění, ale je tam jen protože Google. Současné DSP to dají těžko (teda aspoň to moje určitě). Vím o tom, že Google měl s výrobci DSP nasmlouvanou podporu VP8 právě v nějakých DSPčkách, ale sám jsem moc zvědavý jak se s tím vývojáři vypořádají. Ale ať to shrnu: Technicky dementní návrh rozhodně není omluva pro nároky, které je možné uspokojit až s více jádry.

nebo člověk narazí na nějaký MS formát nepodporovaný v hw

DivX 3.11 Aplha vzniknul tak, že se hackla Microsoftí implementace MPEG-4 ASP kodeku. Microsoft se nasral, implementaci MPEG-4 ASP kodeku zahodil a udělal si vlastní formát podle MPEG-4/H.26X, proprietární a zpětně nekompatibilní. Vznik WMV nemá žádné racionální opodstatnění, ale stejně jako v předchozím případě vznikl jen z toho důvodu aby i Microsoft měl vlastní formát a aby se markeťáci furt nenudili. Odpověď jednoduchá: To radši MPEG-4/H.26X a tento formát si nezaslouží…

Stále existují přehrávače používající sw cestu i pro mobilní telefony.

Nechci do toho kecat, ale nainstaloval jsem si do své LGiny Mplayer, který právě dekóduje SW a s videi se kterými HW přehrávání nemá problém to nebylo fakt nijak slavné. Teda pokud cílem opravdu neměla být slideshow. Pokud to bude tak komplexní formát, že bude potřebovat víc jader a nezvládne ho DSP, tak SW přehrávání to určitě nevytrhne.

[Grunt]

A čistě pro zajímavost: YouTube i když je zatrhnuté HQ vysílá pro mobilní přehrávač v Androidu právě Baseline H.264 i když to není nutné. Předpokládám, že je to právě z toho důvodu že většina zařízení na kterých je provozován Android to následně cpe do nějakého toho DSP kde právě ty od TI nižší řady odmítají něco komplexnějšího přehrát.

[David Heidelberg]

Koukám, že už si získal nějakou tu uživatelskou základnu.

Mě ohromně potěšilo, že když jsem přišel na IRC s bugem, tak ho fakt vývojář ten den vyřešil. Mám rád vstřícný přístup Fakt věřím, že mplayer2 má dobrou šanci se prosadit

[xm]

Ffmpeg-mt jsem samozřejmě spokojeně používal (už několik let). Ale nesmírně mě s*alo, že ten kód nebyl v oficiálním repozitáři ffmpegu. Měli ho do ffmpegu přijmout už dávno pradávno, né to tak strašně stupidně oddalovat. Nakonec je k přijmutí dohnal až fork (nejdřív do původního ffmpegu a nyní konečně už i do libav, to to ale trvalo).

[Grunt]

Ffmpeg-mt jsem samozřejmě spokojeně používal (už několik let).

Však proto nechápu to konečně. A v GITu to trčí také už nějakou dobu. A kdo nepoužívá verzi z repositáře je buď debil nebo 0K!AS.

[David Heidelberg]

já ti dám

nebo OK!AS

... samozřejmě že jsem používal 0.7 už před vydáním (pre), ale jsem rád, že to konečně oficiálně vydali

[Grunt]

No právě protože jsem tě nechtěl zařazovat do množiny debilové, tak jsem tě napsal mimo, ale jak se tak dívám, tak se mi to moc nepovedlo.

... samozřejmě že jsem používal 0.7 už před vydáním (pre), ale jsem rád, že to konečně oficiálně vydali

Spíš jsem chtěl říct, že jediná správná verze u libav je tato. Teda jestli vůbec, protože i tam snad existují nějaké branche a i mimo je spousta užitečných patchů.

[Dusan]

dekóder pre HE-AACv2 hmm

[Espinosa]

Mozna stalo za to dodat ve zpravicce, ze libav je forknuty Ffmpeg, pro ty co nestihaji sledovat. A ze na Ffmpegu stoji vetsina (vsechny) soucasne prehravace, encodery a editory videa.

Jinak je to dalsi z rady forku, ze kterych nemam vubec radost. Rozhadana komunita, hlani kontributor zvazuje uplny odchod. Ach jo. Vice info zde: https://lwn.net/Articles/423702/

OpenOffice, KOffice a ted Ffmpeg. 2010/2011 se zrejme zapise do historie desktopoveho linuxu jako "doba forkova" nebo proste "fork madness".

Mimochodem, ktere projekty presli na libav misto Ffmpeg?

[Grunt]

Co to vůbec bylo za problémy co je donutilo udělat fork? Co se pamatuju, když jsem dobruslil na IRC, tak se hádali, že někdo někomu zamnul RW přístup do repositáře, teď se perou o logo a to kdo poleze do hlavních repositářů distribucí. Ale kdo to vůbec začal a kdo je ten hodný a kdo ten zlý? Ale když už nic, tak na ten fork mají svaté právo (pokud dostali RO, tak určitě).

[elenril]

Zaujaté shrnutí ze strany Libav.

[Grunt]

Ten führer o kterém je řeč je kdo? Míša Niedermayer?

[elenril]

No jasně, kdo jiný.

[Grunt]

To je takové lečo, jo? Sakra. Jediný nerd v mém okolí a musí to být zrovna takový lečoid. No, neříkám, že by se takovému diktátorovi/manažerovi mělo ustupovat, to ani omylem a ani o krok. Zas na druhou stranu jestli se procpe libav do repositářů významných distribucí, tak v tom bude pěkný guláš. Dle mého názoru by se mělo opravdu oddělit jen jádro, tedy libav{codec,format,…} (no vlastně projekt libav bez ffmpegu, ffserveru a ffplay), u toho rozdělit rozumně pravomoce (nějaký kulatý stůl nebo něco takového) aby se předešlo takovému Big-Kernel Österreich locku a zbytek nech si dělá kdo chce a jak chce (jestli se to bude jmenovat ffmpeg nebo třeba dědalebeda už je jedno, hlavně že to bude nalinkované na libav kde bude v kodecích a demuxerech pořádek a čistota). Ono na tom totiž krom ffmpegu a mplayeru visí docela podstatná část projektů a teď si musejí vybírat. O uživateli nemluvě vůbec.

Co jsem se tak díval, tak má ten repositář nasměrovaný i v Downloadech. Co? Jaká je s ním řeč? Hraje Zagorku?

[pc2005]

Nejvtipnější bylo, že když jsem se před měsícem koukal do gitu na ffmpeg a libav, tak spousta commitů byla shodná. Pár lidí prostě přispívá do obojího :-/.

[Grunt]

Však jo. A jak se dívám, tak wiskas ještě rozdrbal API. No ty krávo, to zas bude bordel (ještě větší než je teď a že teda je)

[elenril]

To je tím, že oni mergují prakticky všechno od nás (a my mergujeme něco od nich).

[pc2005]

A to se "vyplatí" .

[Espinosa]

Tak to vypada podobne jako u OpenOffice a LibreOffice :)

Jak rozpad mnohaleteho manzelstvi, strasne se pohadat, rozdelit domacnost, uzit si chvili svobody a pak zjistit ze bez sebe nedokazou tak docela zit, ze toho maji moc spolecneho.

[Grunt]

BTW: Že to bylo kvůli tomu rozhraní mezi mplayerem a ffmpegem.

[elenril]

To byla spíš poslední kapka.

[Grunt]

Sem si to myslel. To bylo fakt pořádné vemeno. BTW: Furt to převrací pomocí mempcy z bufferu alokovaného ffmpegem do double-bufferu k flipu?

[elenril]

Nemám ponětí, tohle není moje oblast. Use the source, Luke

[pc2005]

Hehe zrovna když začínám používat libav 0.6 . Zkoušel už někdo na 0.7 vytvořit h264/aac v mkv video? Mě to tvořilo na 0.7 beta nějaký nevalidní soubory. Mplayer (2 roky starej) si stěžoval na chyby ve streamu a při seekování se objevovaly nehezké artefakty. S poslední 0.6 to funguje.

[Grunt]

A jak to vypadá? Concealuje to makrobloky? Na YouTube už asi totiž i stihli přejít

[pc2005]

Mplayer píše tohle (na každý seek víckrát):

[h264 @ 0x886e540]number of reference frames exceeds max (probably corrupt input), discarding one

A ty artefakty jsou zbytky obrazu po předchozím snímku před seekem. Ty jsou pak hnedka nahrazeny novými daty. Na x264 knihovně to nezávisí, protože stejný video enkódovaný 0.6.2 a 0.7b2 v prvním případě funguje OK a ve druhým má ony problémy.

(musel jsem si to znova vyzkoušet , enkódováno pomocí příkazu:

ffmpeg -i $1 -an -vcodec libx264 -vpre fastfirstpass -b 500k -bt 500k -s 480x320 -threads 2 2test1.mkv

ale moc to na parametrech nezávisí)