Hrajeme si s FFmpeg/Libav (1/2) (diskuse)

[Peto_MiG]

Možno sa mýlim, ale zdá sa mi, že H.264 je v skutočnosti referenčný KODEK. Názov FORMÁTU je MPEG-4 AVC.

[Max]

Ano, je to tak, stejně jako myslím ogg. Snažil jsem se uvádět obojí, ale nemyslím si, že by bylo nějak tragické bavit se o MPEG-4 AVC jako o h.264.
Zdar Max

[elenril]

Ne, tak to není. Ten formát vyvinulo společně několik organizací a podle toho má taky mnoho jmén a přezdívek. "Oficiálně" se jmenuje "ISO/IEC 14496-10" (když se zeptáte ISO) nebo "ITU-T Recommendation H.264" (když se zeptáte ITU). Ale běžně se tomu říká H.264. Další možné názvy najdete zde

[Max]

Aj, díky za info. Tak jsem žil jen lehce v omylu :-/
Zdar Max

[David Watzke]

Ogg je kontejner.

[Max]

Samozřejmě, že je, samozřejmě jsem napsal blbost, ale už nevím, proč :-/. Ani si už ránní dění moc nevybavuju :-/.
Zdar Max

[Jindřich Makovička]

Mýlíte se. H.264 je pojmenování podle ITU, MPEG-4 AVC pojmenování téhož podle ISO/IEC.

Osobně bych tyhle diskuse, co je formát a co je kodek, zakázal.

[pavlix]

„Já bych všechny ty internety a počítače zakázala.“

[hajny]

Když už se nakouslo téma "kontejner formát kodek", nemohl by někdo poradit nástroj pro práci s kontejnery videa a audia? Např když bych chtěl překontejnerovat mkv do mp4, flac do ogg a tak podobně? A nevíte jak je to s podporou formátů u webových prohlížečů co se týče html5 (audio, video)? všude se většinou udávají kontejnery, ale přímo formáty, které v těch kontejnerech mohou být moc nejsou. Na foru opery jsem právě narazil na to, že opera zvládá i flac, do té doby jsem si myslel, že je html5 omezené na mp3(mpeg) vorbis wav. (source src="song.ogg" type="audio/ogg" /> type ogg má být jako co? vorbis? flac? speex? orientuje se někdo v tom guláši? Díky

[elenril]

Když už se nakouslo téma "kontejner formát kodek", nemohl by někdo poradit nástroj pro práci s kontejnery videa a audia? Např když bych chtěl překontejnerovat mkv do mp4, flac do ogg a tak podobně?

Tohle umí avconv nebo ffmpeg, takže předpokládám, že o tom bude další díl.

[Max]

Ahoj, toto všechno včetně příkladů je uvedeno v příštím díle, který už je napsán a má ho redakce, takže by měl vyjít v nejbližší době.
Zdar Max

[prqek]

Dík za článek, konverze videa mě vždyckz dostane. Na první pohled to vypadá, že to na tom přeci nic nemůže být a pak strávim mnoho času googlením, kompilováním, psaním skriptů apod. než se dostanu k výsledku. Takže jsem jen rád za nějaké ucelená a hlavně aktuální informace

Mám jen jednu poznámku k checkinstallu - místo něj se mi osvěčil spíš následující postup (právě proto, že většinou neskončím u první kompilace): jen zkomopilovat (tedy make) a nalinkovat potřebné binárky do ~/bin (ten mám už z jiných důvodů v PATH na prvním místě). Netřeba pak řešit odstranění staré verze, když chci přidat nějakou featuru, tak ji zapnu (doinstaluju potřebné dev knihovny), zkompiluju a používám, odstranění je pak taktéž triviální. Jediná nevýhoda je, že takto mám "nainstalovaný" ten program jen já, ale vzhledem k tomu, že svůj počítač používám jen já, to je celkem jedno.

[Rivon]

Mě přijde naopak checkinstall výborný nástroj. Po instalaci můžu odstranit celej adresář se zdrojákama a buildem a když chci odinstalit to, co sem kompiloval, tak prostě jen dám apt-get remove *** a je to ;)

[prqek]

Jasně, tenhle přístup se osvědčil mě, není to univerzálně nejlepší postup.

[GeBu]

Moc se na články těším. Díky. Dotázek: Za jak kvalitní považuješ encodér do MPEG2, který je v těchto softech, v porovnání s konkurencí? Já nyní používám HCencoder resp. HCbatchGui (na Windos).

[Max]

Články jsou původně o videích na internetu, ffmpeg/libav je vlastně jen vedlejší věc, primární zaměření článků je jiné. Ani nejsem žádný big boss ohledně videí a ffmpegu.
Zdar Max

[Mandarinka]

Mpeg2 encodér v ffmpegu profituje z různých brute-force algoritmů společných pro mpegovité formáty. Ty ale nejsou nijak zvlášť vytuněné pro konkrétní formát a navíc když to všecko pozapínáte, tak i hodně pomalé (QNS...). Navíc to všechno není bůhvíjak zdokumentováno, takže člověk moc netuší co má jak nastavit, aby to dopadlo dobře.

Co jsem slyšel, tak HC Encoder je obecně lepší. Sám ale mpeg2 nepoužívám. Taky existuje experimentální x262 (modifikace x264 schopná produkovat mpeg2), ale ta má daleko k použitelnosti, takže zmiňuju jen tak do budoucna (dejte tomu 4 roky a pak *MOŽNÁ*).

[GeBu]

Díky za odpověď. Taky jsem slyšel, že HC Encoder je nejlepší freewareový mpeg2 encodér. Ale už neumím posoudit o kolik je lepší tj. jestli se vyplatí ho používat, protože to není komplet soft, kterému bych předhodil video i se zvukem (z DV kamery) a výsledkem bylo mpeg2 (DVD kompatibilní) video. Kvůli jednoduchosti používám HCbatchGUI a rebootuji k vůli němu do Windows (tam je jednodušší instalace).

Proč mpeg2 nepoužíváš? Co používáš?

[Jendа]

Proč mpeg2 nepoužíváš?

Já proto, že existují formáty, které jsou o dost dál.

Co používáš?

H.264.

Ne každý lpí na lesklých placičkách (DVD), ještě k tomu aby je přehrával v hardwarovém přehrávači, který neumí nic lepšího…

[GeBu]

Jaký nastavuješ bitrate?

[Mandarinka]

Jaký nastavuješ bitrate?

Vzhledem k tomu, že je pro mé skromné potřeby irelevantní VBV a podobná omezení, tak tomu dávám tolik, kolik tomu dá x264 (--crf ...), s tím, že někdy jsem nucen činit kompromisy, je-li zdrojové video příliš nenažrané (snažím se udržet pod cca 3000-3500 kbps pro ~dvd rozlišení/24fps). Ale x264 dokáže udržet rozumnou kvalitu i při o hodně nižším toku, to jen já jsem tak velkorysý (obsedantní...).

[GeBu]

Právě, když dneska není tlak na kapacitu, tak proč ne mpeg2?

Někde jsem zahlédl nějaké komentáře o tom, jaký typ chyby zavádí H.264 a vydedukoval jsem si z toho myšlenku, že moderní komprimační mechanismy (H.264 apod.) vyrobí video o malém bitrate s dobrou kvalitou, ale vždy je trochu horší než mpeg2 s velkým bitrate.

[Mandarinka]

Někde jsem zahlédl nějaké komentáře o tom, jaký typ chyby zavádí H.264 a vydedukoval jsem si z toho myšlenku, že moderní komprimační mechanismy (H.264 apod.) vyrobí video o malém bitrate s dobrou kvalitou, ale vždy je trochu horší než mpeg2 s velkým bitrate.

To určitě není pravda. Viděl bych tu minimálně 2 důvody:

1) mpeg2 má některé technické nedostatky, které tomuto brání. Jako první mě napadá absence weighted prediction, takže když máte stmívačky rztmívačky (nebo například osvětlení měnící barvu), tak enkodér nezvládá predikci, má tuny residuálu a výsledkem je kopa artefaktů nebo rovnou bloků. H.264 umožňuje weighted prediction (zkrátka uloží multiplier/offset - IIRC - který se aplikuje na predikovanou hodnotu, a hned je residual mnohem menší). Dále, mpeg2 nemá bit-exaktní DCT/iDCT, takže dekodér může mít drobnou odchylku od výsledku, s kterým pracuje enkodér. V rámci jednoho framu to může být jedno, ale tato chyba se pak kumuluje predikcí v dalších framech (jeden z důvodů, proč mpeg2 obvykle používá krátký interval mezi klíčovými snímky). Něco, čím si nejsem jistý je maximální vzdálenost, o kterou můžou predikovat pohybové vektory, viděl jsem na DVD scény, které byly prostým globálním posuvem nehybného obrazu, ale i prři vysoké bitrate v tom byla kupa bloků. Je však možné, šlo o selhání enkodéru, který neviděl 'dost daleko'.

2) není důležitý jen formát, ale i enkodér. x264 je v současnosti určitě nejpokročilejší enkodér, a tyto schopnosti nejsou dobré jenom k tomu, aby se dosáhlo nejnižší možné velikosti, ale i pro to, aby kvalita na konstantní velikosti rostla, to, že by H.264 nějak snižovala strop dosažitelné kvality myslím nehrozí, spíš i naopak... x264 je určitě pokročilejší než HC Encoder nebo jiné mpeg2 nástroje.

Jestli mi nevěříte, tak zkusím vysvětlit, proč by to tak mělo být: komprese probíhá tak, že se nejprve najde pohyb, aby se daly budoucí snímky predikovat z předchozích. V tomto kroku má h264 výhodu, protože dokáže používat menší plošky (4x4,4x8,8x4,8x8,8x16,16x8), takže dokáže predikovat přesněji. Také má vyvinutější intra predikci, která zase něco přihodí do mlýna. A výhodu tu také budou mát velmi sofistikované enkodéry - jako je x264. V dalším kroku vezmeme rozdíl mezi predikovaným framem a zdrojem - residual. Čím lépe jsme si v předchozím kroku vedli, tím méně dat bude tento rozdíl obsahovat. V třetím kroku pak tento rozdíl transformujeme (DCT/"HCT") a protože těch dat bude hodně, tak některé koeficienty umažeme (quantization), snažíce se přitom, aby efekt toho byl co nejméně znatelný. Zde vlastně dochází ke ztrátové kompresi. Čím pokročilejší byl náš formát, tím méně zde tedy musíme tlačit na pilu. To, kolik, a kterých koeficientů enkodér vypustí je pak ta nejhorší část, kde se toho dá hodně posrat :) Takže v tomto kroku je důležitý pokročilý enkodér. Následující krok (entropy coding, který operuje nad údaji predikujícími frame a těmi koeficienty transformovného residuálu, které nebyly vypuštěny) už je bezeztrátový, takže nás nezajímá (ale v h.264 je tato bezeztrátová komprese také účinnější).

A teď k té otázce, jestli může pokročilejší formát znamenat, že už se sníží maximální dosažitelná kvalita. V principu je to možné u špatného enkodéru, ovšem špatný enkodér staršího formátu taky bude mít špatné výsledky, takže... Když se podíváte na předchozí odstavec, tak vidíte, že v krocích provádějících predikci nemohou pokročilé techniky h.264 uškodit, protože jakákoliv chyba bdue opravena residuálem. Naopak starší techniky v mpeg2 nebudou tak úspěšné a residuálu bude víc. Čili mpeg2 bude muset víc vypouštět koeficienty, což přímo zasahuje kvalitu. Co se týče té kvantizace, tak mi není známo, že by formát h.264 v tomto ohledu zaváděl něco, co by ubližovalo kvalitě, a navíc dobrý enkodér se v tomto kroku může různým nebezúpečím vyhnout. Tzv. adaptive quantization je zdá se skoro nejdůležitější částí jakéhokoliv slušnějšího enkodéru...

Existuje jedna vyjímka z toho, co jsem řekl, a tou je loopfilter - ten je aplikován až po na celkově hotový snímek, takže v principu může umazat nějaké detaily, které v snímku byly (a už ho residual nemůže opravit). Jenže tento filtr je poměrně dobře vyvážen, jeho síla závisí na síle kvantizace (pokud má blok qp 15 a lepší, neprovede se už vůbec), takže moc neškodí, navíc dobrý enkodér si ho dokáže pohlídat tak, že kdyby někde škodil, sníží qp příslušného bloku, aby se loopfilter oslabil nebo vypnul. Moje zkušenost je taková, že to funguje dobře a škody skutečně nevznikají (oni ti týpci z H.264 a MPEGu nejsou úplně na kočku, heh).

TL;DR

1. x264 je nejlepší současný enkodér (a h.264 nej formát). Není reálné, že by způsobil problémy s kvalitou, které by mpeg2 nepostihly v prvé řadě, a navíc mnohem hůře.

2. Lepší komprese znamená, že máme zdrojů k upotřebení, takže naše video bude vypadat lépe.

3. Lepší enkodér opět přináší více zdrojů k upotřebení -> lépe vypadající video. Naopak špatný enkodér může škodit i když použije spoustu bitů (prostě prosto, že něco zmrví).

(4. Ona ta velikost skoro nikdy není neomezená, takže ten přístup "stačí zvednout bitrate" snadno selže. Příklad: max. bitrate u DVD je 9.8kbps při 720x576 nebo 720x480, a přesto to kolikrát dopadá špatně. Důležité ovšem také je, že náročné scény můžou potřebovat mnohonásobně vyšší tok než je průměr.)

[Mandarinka]

Nééé, kam se to zalomení podělo, zrovna když se to nejmíň hodí!

Čitelná verze mého vejšplechtu: pastebin.com

[kralyk z abclinuxu]

U toho dvd měly být jednotky Mbps, předpokládám - 9.8 Mbps. To není nic moc, dnešní HD ripy s bitratem nad 10 Mbps zcela určitě kvalitou DVD předčí (nejen co se týče rozlišení).

Jinak to, že je x264 pokročilý, rád slyšim, myslíš, že je opravdu pokročilejší i než třeba CoreAVC?

[Mandarinka]

Jistě, 9,8 Mbps. Tak jistě, že HD ripy kvalitou předčí, ale právě že mají vyšší rozlišení - to samozřejmě zdvihne nároky na bitrate. Také ale pocházejí z lepších, detailnějších zdrojů (nebo by alespoň měly, ideaálně). Právě že x264/h.264 umožňuje toho dosáhnout, mít hezky vypadající HD v toku, který je blízko dvd.

Co se týče CoreAVC, tak ti nikdy nevyprodukovali enkodér, takže srovnávat nelze... Ale v objektivních studiích (MSU) x264 vítězí nad (kvalitativně) nejbližším konkurentem, jímž je zdá se Mainconcept. Ta technologická převaha je imho dost zřejmá...

[David Watzke]

Upravil jsem formátování tvého komentáře.

[Mandarinka]

Vřelé díky!

[GeBu]

Opravu velice moc děkuji za tak obšírnou odpověď. Hlavně za tu pasáž jak to funguje. Je to pěkně lidsky napsané. Přesvědčilo mne to přestat encódovat do mpeg2. Před 2-3 lety, kdy jsem tu svou úvahu dělal bylo v mém okolí pořád hodně lidí používajících DVD. Dneska už jsme zase někde jinde. Druhým důvodem byla právě ta moje úvaha.

Byl bych Ti také vděčný pokud bys mi poradil jak nejlépe překódovat video z DV kamery (video: dvsd 720x576 a 25 snímků za sekundu s bitrate nějakých 28,8 Mbit/s, audio: stereo pcm 16 bit a vzorkování 48 kHz v kontejneru avi type-2). Kodek je mi jasný (x264), ale jak ho v tomto případě nastavit. Na nějakém tom Mbit/s mi nezáleží, ale HD se z toho stejně nedá udělat. Existuje nějaká hranice pro tak veliký obraz, že se dá říci, že další zvyšování bitrate už nemá smysl?

Docela zajímavé by bylo zkusit bezztrátový profil h.264 :).

[GeBu]

Ještě jsem si znovu prošel odpovědi a našel že už jsi o tom něco psal "--crf" parametr pro řízení bitrate. Je pěkně popsaný na této stránce: http://mewiki.project357.com/wiki/X264_Settings#crf. Zajímavé je, že je to jednoprůchodové.

Je tam také uvedeno, že pro bezztrátové video použít --qp 0 nebo --crf 0 s tím, že prý optimalizace na qp dává video se stejnou kvalitou, ale větší soubor.

[Mandarinka]

prý optimalizace na qp dává video se stejnou kvalitou, ale větší soubor.

Pozor, tohle platí jenom pro ztrátovou kompresi. S tím, že --qp je šmejd, který se hodí pouze na debugování, takže to určitě nepoužívat (prostě kvantizuje všechny bloky stejnou měrou - vůbec nefunguje adaptive quantization a podobně, což je velmi neoptimální pro vzhled)

--crf 0 a --qp 0 je speciální, protože oboje znamená bezeztrátovou kompresi, čili že se přeskočí transformace, kvantizace i loopfilter (tedy při 8bitovém kódování; pokud kódujete do high 10 profile, tak bude crf 0 ještě ztrátové, ale to je detail)

Jinak bezeztrátová komprese v reálu užitečná není, protože bitrate bude několikanásobně vyšší (než u pomyslného nekomprimovaného videa) - většinou to vyjde hůř než (už komprimovaný) zdroj.

Co se týče nastavení, tak to je dost jednoduché, protože defaultní nastavení jsou slušná (pokud používáte x264 cli), a stačí používat presety: například --preset veryslow (ne ještě nejpomalejší, ale prakticky maximální kvalita ), psychovizuální optimalizace jsou také v defaultu nastavené rozumně, tedy --psyrdo 1.0:0.0 --aq-mode 1 --aq-strength 1.0. Co se týče crf, tak tam je to trošku složitější, protože zdrojová videa se liší typem nebo i případ od případu, a hlavně lidé mají různé nároky. Defaultní nastavení crf je zaměřené na malou velikost (23), tam už je snadné vidět artefakty a ztráty. Za takový střed se často považuje 18, ale zlepšení lze pozorovat minimálně až do crf 15 až 14 (což už často soubor docela nafukuje). Jinak se doporučuje si to vyzkoušet, a to tak, že si vyberete nějaký nízký crf a pak ho zvyšujete, dokud vám výsledek ještě vyhovuje. Eventuálně, když je člověk rozhazovačný, tak obráceně, a rozhodnout se, jak dlouho ještě to zvyšování bitrate má smysl nebo je únosné.

[Mandarinka]

vloudila se mi tam chybka... bitrate nebude větší než u pomysleného nekompriomovaného videa. Měl jsem na mysli to, že náš zdroj už ztrátově komprimovaný je, takže se většinou stane, že pokus o překódování bezeztrátovým kodekem povede k mnohem většímu výstupu.

Když uděláte FLAC z MP3ky nebo vorbisu, tak taky velikost střelí nahoru. Příklad: WAV nekomprimováno: 1456kbps (nebo kolik to vychází u CD stopy); WAV -> FLAC: 850kbps; WAV -> Vorbis: 160kbps; vorbis -> FLAC: 840kbps :)

[GeBu]

Rozumím.

[GeBu]

Zkusil jsem x264 --qp 0 -o out.mkv in.avi a video je větší než originál 1,1 GiB > 2,7 GiB. Na konci byly informace "encoded 13475 frames, 6.11 fps, 43571.93 kb/s". Pokud se nemýlím, tak se u DV kamery udává 28800 kb/s.

[Mandarinka]

Oh, bitrate nesedí? Možná x264 špatně detekovalo fps (a tedy délku)...

[GeBu]

Ne, ne. Ale video zkomprimované bezztrátově "--qp 0" má větší bitrate 43,5 Mbit/s než zdroj 28,8 Mbit/s. Přičemž zdrojem je DV tedy "nekomprimované" video.

[Jendа]

DV není nekomprimované.

[GeBu]

Schválně jsem to napsal do uvozovek.

[GeBu]

Děkuji.

[GeBu]

Dívám se tady na ta nastavení x264 a chápu to dobře, že všechno je to jednoprůchodové kódování? Trochu mne to překvapilo. Myslel jsem si, že vyšší kvality se dosahuje právě pomocí dvouprůchodového kódování.

Zřejmě, abych nemusel u každého videa spouštět 3 věci: encódování videa, zvuku a muxování, tak zkusím Handbrake, vypadá jako GUI pro různé nástroje.

[kralyk z abclinuxu]

Tak bych se připojil k otázce, na některých trackerech jsem viděl HD ripy ve vysoký kvalitě, který byly nakódovaný třeba až 10 průchody... Má to cenu?

[GeBu]

Osobně se snažím chytit logiku věci. Většinou do problematiky nejlépe proniknu, když vyjádřím svůj pohled a někdo ho zkoriguje.

Není to náhodou tak, že víceprůchodové kódování má smysl, když chci nastavit konkrétní velikost videa (ať už ve smyslu velikosti nebo bitrate)? První průchod by byl informační pro to, aby se vědělo, jak se v druhém průchodu kódovat. V případě, že mi na velikosti / bitrate nezáleží, by dva průchody neměly smysl. Je to tak? Moc mi do toho nehrají ty další průchody.

Na tuto svou úvahu jsem přišel, když jsem zkusil Handbrake: když zakliknu kódování na bitrate tak je volba dvouprůchodové kódování aktivní, když zakliknu kódování na "konstantní kvalitu" (což si myslím je to "--crf" z příkazové řádky) tak ta volba aktivní není.

Znovu si pročítám odkaz, který jsem tu poslal a začíná mi to dávat smysl. Jsou tři metody řízení:

• qp - Constant Quantizer: Jak píše Mandarinka "...kvantizuje všechny bloky stejnou měrou - vůbec nefunguje adaptive quantization a podobně, což je velmi neoptimální pro vzhled..." a ještě uvádí "...se hodí pouze na debugování..." Velikost pro stejnou vizuální kvalitu je větší než u "--crf" a také není známá.
• bitrate: Je zacílené na určitou velikost (bitrate) a proto se používá víceprůchodové.
• crf - Constant Ratefactor: Je zacílené na kvalitu. Tedy na kvalitu stejnou jako má nějaké "qp", ale s co nejmenší velikostí, která také není dopředu známá.

[Mandarinka]

qp - Constant Quantizer: Jak píše Mandarinka "...kvantizuje všechny bloky stejnou měrou - vůbec nefunguje adaptive quantization a podobně, což je velmi neoptimální pro vzhled..." a ještě uvádí "...se hodí pouze na debugování..." Velikost pro stejnou vizuální kvalitu je větší než u "--crf" a také není známá.

Ono je to skutečně taková středověká metoda, konceptuálně špatná a vůbec, takže říct, že "velikost je větší než u crf" a "neoptimální pro vzhled" je dost diplomaticky řečeno. V podstatě je to mód, v kterém je enkodér zkriplený, praktické použití neexistuje (nepočítám lossless, páč to je irelevantní). Prostě zapomeňte, že to tam je :)

Jinak bitrate může být i jednoprůchodová, ale kvalita nebude tak dobrá (je těžké docílit nějakou konzistentní kvalitu, když víte, jaký máte rozpočet, ale nevíte, co všechno z něj bude třeba zaplatit).

[Mandarinka]

Tak bych se připojil k otázce, na některých trackerech jsem viděl HD ripy ve vysoký kvalitě, který byly nakódovaný třeba až 10 průchody... Má to cenu?

Má to "cenu" v tom smyslu, že zaplatíte na elektřině 10x tolik ;) Jinak ne (u x264).

[Mandarinka]

2 průchody jsou potřeba jenom když je cílem soubor o předem determinované velikosti.

CRF má jiný cíl - cílit na určitou kvalitu, a když video A má menší nároky a video B má nároky dvakrát vyšší, tak to to zohlední. Čili kvalita je do jisté míry předvídatelná (ale pozor, není s CRF faktorem nijak pevně spojená - některé zdroje například potřebují nižší CRF pro dobrý výsledek, než jiné, také se význam CRF faktoru hodně mění v závislosti na nastaveních dekodéru jako je mbtree/no-mbtree, aq-strength, ale i --preset, protože nejrychlejší nastavení vypínají RDO, trellis a tak).

A jinak deset průchodů je nesmysl. Říkalo se, že to potřebuje enkodér CCE (profesionální mpeg2 enkodér), ale to by jenom znamenalo, že má strašně špatnou rate control.

U x264 platí, že 2-pass použijete, pokud chcete konkrétní bitrate (= velikost), jinak crf. Jisté drobné použití mají 3 průchody místo dvou (to se dělá tak, že první průchod děláte s --pass 1, druhý a další s --pass 3), a to sice v případech, že se nepodařilo dostatečně přesně trefit cílovou bitrate; s třetím pokusem je šance, že se ten výsledek o něco přiblíží. Kvalitativní zlepšení videa ale nepřijde (tedy pokud by nedošlo k markantnímu nárůstu bitrate, že).

[GeBu]

Díky za to vysvětlení těch víceprůchodů. Mrkni co píšou na webu mencoderu: "Většina kodeků, které podporují ABR enkódování, podporují pouze dvouprůchodové enkódování, zatímco ostatní jako x264, Xvid a libavcodec podporují víceprůchodové enkódování, které s každým průchodem trochu zlepší kvalitu, ačkoli toto zlepšení již není viditelné, nebo měřitelné po asi čtvrtém průchodu. V této sekci budeme považovat dvouprůchodové a víceprůchodové enkódování za rovnocenné."

Podle mého názoru vůbec ta pasáž z mencoderu je zvláštním způsobem zavádějící / nevhodně napsaná. Člověk získá představu, že CBR určitě ne a že čím více průchodů tím lépe. Kritická je tam tato věta: "V jednoduchých režiměch, jako je CBR, však enkodéry neznají nároky na datový tok budoucích scén a tak nemohou překročit požadovaný střední datový tok na dlouhou dobu. Pokročilejší režimy, jako je víceprůchodové enkódování, umí vzít v potaz statistiky z předchozích režimů, což odstraní výše zmíněný problém."

Nevzniklo to náhodou tak, že ta pasáž je napsaná pro MPEG 4 ASP a H.264 už má jiný přístup?

[little.owl]

Cesky preklad vychazi z anglicke verze a prostym srovnanim lze rici ze je nepresny - jsou to niance, ale vyznam je posunut (a ani anglicky original nebyl podle vsecho psan rodilym mluvcim).

[Mandarinka]

CBR = constant bitrate, to je pro video velmi nevhodná věc.

"V jednoduchých režiměch, jako je CBR, však enkodéry neznají nároky na datový tok budoucích scén" --- tady se asi myslelo 1-pass ABR, protože při CBR kódování je to irelevantní, to prostě používá furt stejnou bitrate, přímo určenou na začátku.

"enkodéry neznají nároky na datový tok budoucích scén a tak nemohou překročit požadovaný střední datový tok na dlouhou dobu" --- tohle je přesné, platí to pro 1-pass ABR (tedy když si řeknete o konkrétní bitrate a je jen jeden průchod). Jinak x264 používá lookahead (zná dopředu určitý počet framů), takže v malém měřítku dokáže některé nectnosti 1-pass ABR zmírnit, samozřejmě ale nemá přehled o celkové průměrné náročnosti zdroje (například nemůže vědět, že uprostřed a na konci filmu je dohromady 20 minut výbuchů, kvůli kterým by to chtělo víc šetřit v statických scénách v první třetině, a že na konci jsou titulky, které toho tolik potřebovat nebudou).

A ta dokumentace je skutečně hodně stará (četl jsem to roku 2006), z dob xvidu (tehdy existoval jen constant quantizer, nikoliv CRF mód jako má x264, proto všichni používali 2-pass); nemyslím si, že by byla příliš aktualizovaná - přidaly se sice informace o x264, ale ty obecnější části už nebyly upraveny. Pokud chcete přímo zdroje pro x264, tak je vhodnější ten soupis na Mewiki.

...

Mimochodem, ten rozdíl mezi 2-pass a CRF lze v případě x264 ilustrovat takto (není to zcela přesné, ale v praxi to lze): Enkodér má při rozhodování o tom, jak moc utrácet určitou škálu, to by byl ten "rate factor". Takže když kódujete s ---crf, tak se prostě vybere rate factor, kterým je určena politika při rozhodování, a ta se pak stejně aplikuje na celé video. Výsledkem bude tedy soubor s proměnlivým datovým tokem a velikostí, kterou nebudeme přesně vědět předem.

CQP (constant quantizer) má také stejnou politiku pro celé video a nepředvídatelnou vleikost, ale jde na to primitivně, prostě v každém bloku úpoužije stejný stupeň kvantizace, což je neefektivní.

Proti tomu metody mířící na určitou velikost:

Dva průchody: víme, že existuje určitý rate-factor, který by nám dal požadovanou velikost (při 'konstantní politice'), ale neznáme ho. Když ale zkusmo uděláme kompletní encode a poznamenáme si určité informace, které zaznamenávají náročnost scény a výsledky kódování, můžeme z toho potřebný rate factor spočítat. Pak je vlastně druhý průchod toliko o tom, že použijme --crf se spočítaným ratefactorem (x264 ve skutečnosti vezme z 1. průchodu také rozhodnutí o typu frame - I/P/B). V tomto módu tedy bude mít finální video také konstantní politiku jako CRF. Pokud tedy máme 2-pass encode a crf encode o stejné velikosti, jsou až na drobné detaily rovnocenné.

Jeden průchod: pokud chceme konkrétní velikost ale nemůžeme použít první průchod k analýze, nezbývá než spekulovat. Enkodér tedy musí 'politiku' odhadnout, a během enkódování ji měnit podle toho, jak dobře mu odhad vychází. Když najednou video začne být náročnější, tak musí rate factor snížit, pokud najednou začne být video snazší, tak zase rate factor zmírní, aby cílovou velikost nepodstřelil.

[Jendа]

400 kb/s. Jsou to většinou záznamy přednášek, kde se toho moc nehýbe, světelné podmínky jsou pochybné a kvalita kamery taky nic moc.

[David Watzke]

Zcela souhlasím. Lpět na tom je fakt nesmysl, zvlášť v době, kdy je cena zařízení schopných přehrát cokoliv tak nízká.

[Mandarinka]

Takhle - když chceš vyprodukovat DVD, tak je volba formátu jasná, když nechceš vyprodukovat DVD, tak taky (H.264). Čili potenciální debata by byla o tom, zdali produkovat dvd (důvody jsou), nebo ne.

[Ondrej 'SanTiago' Zajicek]

Jeste bych tu videl jedno hledisko - vypocetni narocnost na prehravani. Preci jen dekodery MPEG-4 AVC (H.264) jsou pri srovnatelnem rozliseni a bitrate o dost narocnejsi nez dekodery MPEG-4 ASP, takze pro prehravani videa na slabsich pocitacich je MPEG-4 ASP vyrazne vhodnejsi.

[elenril]

Přes pět let starý ošklivý craptop s dvoujádrem Core Duo T2050 zvládne v pohodě 720p a s trochou štěstí i některé 1080p kde není moc pohybu.

Počítačů které jsou ještě slabší a zároven je chce někdo používat na přehrávání videa snad zase tolik není.

[pavlix]

Počítačů které jsou ještě slabší a zároven je chce někdo používat na přehrávání videa snad zase tolik není.

Myslíš, že je pomalejší než vcelku běžné starší Atomy? A tvrzení, že na malym notebooku na cestách si nechci pustit vydeo je přinejmenším přitažené za vlasy :).

[David Watzke]

Bavíme se o počítačích a ne o počítadlech

[pavlix]

Špatně čteš. Psalo se o přehrávání videa.

[David Watzke]

Ehm, jsme už slušně OT, ale stejně: podívej se co cituješ / na co reaguješ. (A nechme toho, beztak to byl jen takovej kyd )

[Jendа]

Můj Atom N270 (nejslabší na trhu) dá 720p v H.264.

[pavlix]

I když koukám, že já ani ten Atom nemám :).

[sigma]

Počítačů které jsou ještě slabší a zároven je chce někdo používat na přehrávání videa snad zase tolik není.

Záleží na prostředí, kde se člověk pohybuje. Ale i doma mám jeden počítač - Celeron 2GHz, 256 MB RAM, Win2k - který používá moje matka k naprosté spokojenosti, a nevidí důvod ho měnit. A i to video se na něm přehrává. A takový stroj má někdy problém s H264 v PAL rozlišení.

Ty testy náročnosti AVC/ASP, jak jsem psal výše, jsem dělal částečně i pro jednu školu, kde tou dobou byly stroje typu Celeron 2GHz a SDRAM paměti ještě běžné. Teď už jsou zlikvidované/rozebrané na díly, ale kdyby nebyl posledních pár let zřizovatel tak štědrý, sloužily by pořád.

[Grunt]

Počítačů které jsou ještě slabší a zároven je chce někdo používat na přehrávání videa snad zase tolik není.

Já chci přehrávatelné HD na 100Mhz 486. A Dup!

[kralyk z abclinuxu]

Preci jen dekodery MPEG-4 AVC (H.264) jsou pri srovnatelnem rozliseni a bitrate o dost narocnejsi nez dekodery MPEG-4 ASP

No tak tady bych to okořenil nějakým tím [citation needed]... Imho náročnost videví v AVC je přecijen dána jejich obvyklým vyšším rozlišením a bitrate.

Nebo máš nějaké srovnání náročnosti při stejném rozlišení a bitrate? Případně ještě objektivnější by bylo stejné rozlišení, ale o něco nižší bitrate u AVC, protože imho dokáže s menším bitrate vyšší kvalitu oproti ASP.

[sigma]

Dnes už může být situace jiná, i software učinil určitý pokrok, ale cca v polovině roku 2008 jsem si dělal srovnání pro přehrávání videa na Windows (dekodéry z tehdejšího K-Lite Codec Pack). Kvůli archivaci DVD, S-VHS/VHS, a záznamů z DV kamer.

Testoval jsem AVC/H264 (kódováno x264) - 1500 kb/s, a ASP (kódováno Xvid4) - 2000 kb/s. Obojí rozlišení 768×576, subjektivně skoro stejná kvalita, možná trochu lepší u H264.

Zjištěná zátěž: Typ CPU / AVC / ASP:

• Celeron 1600 MHz / 100 %, nekoukatelné / 40 %
• Pentium M 1500 MHz / 75 % / 30 %
• Pentium 4 2800 MHz / 55 % / 25 %

[sigma]

Ještě upřesnění - kódován byl stejný zdroj v HUFFYUV, pomocí tehdy aktuálního Avidemux (2.4.3). Nastavení kodérů výchozí, 2 pass, average bitrate na uvedené hodnoty.

[Ondrej 'SanTiago' Zajicek]

Zhruba podobny dojem z toho mam ja - 2-3x narocnejsi pri stejnem rozliseni.

[Mandarinka]

Ta náročnost je skutečně znatelně vyšší (při stejném rozllišení, stejné bitrate). A to zejména pokud je použit CABAC (ale kdo by ho nechtěl používat, heh), jehož spotřeba cpu roste lineárně s bitrate a je hodně komplexní. Oproti tomu entropy decode u mpeg2/4asp je mnohem rychlejší. Rovněž, mpeg2 nemá qpel a mepg4asp ho sice má, ale lidi ho nepoužívají. Navíc je tu loopfilter u h.264. Jisté zrychlení u h.264 je: iDCT je zjednodušené, aby se dalo počítat pouze sčítáním a shiftem - IIRC; byl zrušen GMC (ale tohle stejně u mpeg4asp nikdo nepoužíval). To ale není tak významné a tu zvýšenou náročnost nedokáže dohnat.

[Jindřich Makovička]

Mimochodem, kdyby to někomu pomohlo, nedávno jsem si dal trochu práce se skriptem pro automagické převádění videa pro mobily via libav, provádějícího všechny ty základní blbosti jako je cropdetect, ořezání, zmenšování a úprava aspectu na 1:1.

[pushkin]

Dotaz trochu z jiného soudku - jak je to aktuálně s multithreadingem? Co jsem zaznamenal kdysi vznikl fork ffmpeg-mt, jak je to dnes? Už umí i základní ffmpeg / libav multithreading?

[Max]

Vícevláknový FFmpeg-mt přijat do FFmpegu
Zdar Max

[pushkin]

Díky, to jsem nějak nezaznamenal

[kralyk z abclinuxu]

Díky, pěkný, těšim se na další díl.

Čistě na okraj, budeš povídat i o API libav?

[Max]

Bohužel, ffmpeg/libav je vlastně jen vedlejší produkt dvoudílného článku, který je spíše zaměřen na cíl, tzn. html5 + tag video + podpora v prohlížečích + praktické ukázky apod.
A takové znalosti, bych mohl něco napsat o ffmpeg/libav nemám. A/V mně moc nezajímá, jen jsem před nějakou dobou dělal pár malých návrhů na jeden projekt, tak jsem o tom chtěl jen napsat, aby mé průzkumy nevyšly úplně v niveč :).
Zdar Max

[kralyk z abclinuxu]

Ok, v pohodě

[tuxmartin]

<flame>

Ještě je potřeba přihodit klíče, ať máme do budoucna aspoň nějakou úroveň zabezpečení ze zmíněného repositáře :

wget http://www.debian-multimedia.org/pool/main/d/debian-multimedia-keyring/debian-multimedia-keyring_2010.12.26_all.deb

Ta uroven bude opravdu nizka

</flame>

[OldFrog {Ondra Nemecek}]

zdravím vespolek, když už je tu debata o videu a audiu, tak toho využiju a zepatám se:

Máte tušesní, co může způsobova tuhle chybu při přehrávání většiny naprosté videí i audio (např. mp3)

Nemohu zjistit typ proudu.

Dělají mi to tyto přehrávače:

• Exaile
• Totem
• Whaaw!
• Pragha

Bez problému jsou naopak

• VLC Player
• XMMS
• Audacious
• Mplayer (GNOME Mplayer)

Mám Fedoru 16. Co s tím?

[Mandarinka]

No, neznám, a tak jenom střelím od boku...

MPlayer a VLC jsou buďto staticky nebo dynamicky linknuté s ffmpegem (xmms a audacious, netuším). Takže pokud jsou dynamicky, tak to znamená, že distribuční ffmpeg je správně zkompilovaný i s podporou treife ('nonfree') formátů. Pokud jsou staticky linknuté, tak je možné, že takto plnotučná je jen jejich vnitřní instance, a ne už distribuční ffmpeg.

Totem, Exaile, atd... tady tuším, že budou tyto přehrávače používat systémové kodeky nebo backendy, takže je třeba zjistit, co používají k přehrávání a pak zjistit, jestli ta věc nebyla zkompilována stylem FOSStard-friendly (jenom VP8, vorbis, theora), případně nemá jiné problémy.

Tím backendem může být víc věcí - gstreamer například, v tom případě by asi chyběly pluginy. Tuším, že gstreamer měl 'good', 'bad' a 'ugly' pluginy, máte nainstalováno ugly? (možná to chce také poohlédnout se po nějakém špinavém, non-free repositáři). Wikipedia taky říká, že existuje zvláštní plugin ffmpeg...

Ale může být důvod i ten, že sice backend zkriplený není, ale prostě si něco nerozumí...

[GeBu]

Abych nemusel z příkazové řádky ovládat tři programy (kódování videa, audia a muxování) tak hledám nějaké GUI k těmto CLI nástrojům. Porovnával jsem Handbrake a Avidemux a zdá se mi, že Handbrake se více drží toho, že používá terminologii kodeků, které používá.

Co používáte vy?

[GeBu]

A ještě mám jednu otázku. Co považujete za nejperspektivnější z hlediska možnosti přehrávání do budoucna pro komprimaci domácího videa:

• Kontejner: MKV, MP4,... Mě se zdá, že největší budoucnost na hardwareových přehrávačích má MKV. Dalším kandidátem je WebM, ale toho vidím spíš na web.
• Formát videa: H.264, VP8,... Tady bych viděl spíš H.264 a VPM (WebM) zase pro web.
• Formát audia: MP3, OGG Vorbis, AC3, AAC,... Nevím. Rád bych tam viděl OGG Vorbis, ale zdá se mi, že na hardwareových přehrávačích tak rozšířený není. Jak je to s vlastnosti (vícekanálů apod.) a kvalitou AC3 a ACC v porovnání s MP3 nemám představu.

Tedy kombinace MKV: H.264 a MP3?

Jaký bitrate pro MP3? 192 kbit/s?

[little.owl]

Hlavne je treba mit to v otevrenem/standardizovanem formatu, kdy je k dispozici svobodny dekoder [napsany pokud mozno v C]. Pak byste nemel mit problemy veci jednoduse prevest - drive ci pozdeji to nastane.

Zajimovou otazkou je schopnost opravy, pokud je zaznam poskozen (ponicene CD/DVD). Mam asi jedenact let stara CD (Verbatim Datalife ) a presto ze nebyla casto pouzivana a dobre skladovana mam problemy s jejich ctenim i na novych mechanikach.

[elenril]

Kontejner -- ano, matroska je asi nejmenší zlo. Má sice řadu problémů, ale to všechny existující alternativy taky. Webm je jen osekaná matroska.

Video kodek -- není o čem mluvit, na x264 v současnosti nic nemá.

Audio -- MP3 je dávno překonaný kodek z pravěku. Jediný důvod pro mp3 je kompatibilita se starým hw. To samé AC3. AAC už je lepší, ale všechny opensource implementace jsou dost hrozné. Co jsem slyšel, tak neroaacenc je celkem dobrý. Pokud nepotřebuješ kompatibility se vším možným, tak vorbis (encoder libvorbis) je dobrá volba.

[GeBu]

Díky za odpověď.

[kralyk z abclinuxu]

+1, AAC je i lepší z hlediska patentů/licencí... A podpora bude určitě minimálně u všech přehrávačů podporujících h264. libfaac snad není tak hrozná, ne? Ačkoli to Nero bude asi lepší...

[Mandarinka]

Co se týče AAC, tak hrozné jsou opensource enkodéry, ale u dekodérů je to pak už jedno. Takže když už jednou máte tu stopu hotovou, třeba i s proprietárním sw, tak už to nevadí. A přece jen, AAC je standard v průmyslu, kdežto vorbis si sice určitou pozici získal, ale coby standard je to pořád spíš "rádoby". Kvalita asi bude podobná u obou (pozor na enkodéry - u AAC použít nero nebo quicktime, který je prý teď lepší, u vorbisu použít libvorbis od Xiphu).

Pro AC3 by teoreticky mohla hovořit schopnost určitých audio receiverů ho odebírat přes spdif. Přes spdif totiž nedostanete dekódovaný/nekomprimovaný surround, vejde se ta, pouze stereo. To podle mě ale není bůhvíjak důležité.

Ovšem, pokud už máte ac3 stopu (třeba z DVD, kde bývá 192-448kbps), tak ji nemusíte překódovávat a můžete ji muxnout tak jak je, protože by se tím stejně moc místa neušetřilo. Já to tak u DVD ripů dělám, nemám ale představu o tom, jak podstatnou škodu bych nadělal, kdybych např. 384kbps stereo AC3 překomprimoval na 160kbps AAC/Vorbis. Osobně komprimuju jenom když je na zdroji LPCM nebo jiné bezeztrátové video.

[GeBu]

Díky za pěkné shrnutí.

Vstupem je video se zvukem z DV kamery tudíž zvuk PCM.

[J. M.]

On hlavně MP3 není kodek, takže nemá smysl porovnávat softwarový nástroj (x264) s formátem komprese (MP3). Jak už bylo řečeno, zásadní je kvalita implementace, tedy kodek (respektive kodér, což je jediný správný český překlad anglického slova encoder), nikoli jen použitý formát. Já pokud ještě někdy výjimečně kvůli kompatibilitě nepoužiju Vorbis, tak jedině MP3, protože LAME je zatraceně dobrý opensource kodér, AAC je z hlediska uživatele opensource softwaru podle mě úplně k ničemu.