abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 12:55 | Nová verze

Byla vydána verze 17.12.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi. Aplikace, které nebyly dosud portovány na KDE Frameworks 5, byly z KDE Aplikací odstraněny.

Ladislav Hagara | Komentářů: 1
dnes 03:00 | Komunita

Na Humble Bundle lze získat počítačovou hru Company of Heroes 2 (Wikipedie, YouTube) běžící také v Linuxu zdarma. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 0
dnes 02:00 | Zajímavý software

Christian Kellner představil na svém blogu projekt Bolt řešící bezpečnost rozhraní Thunderbolt 3 na Linuxu. Pomocí příkazu boltctl nebo rozšíření GNOME Shellu lze komunikovat s démonem boltd a například zakázat neznámá zařízení a předejít tak útokům typu Thunderstrike nebo DMA.

Ladislav Hagara | Komentářů: 2
dnes 01:00 | Nová verze

Po půl roce vývoje od vydání verze 11.0 byla vydána verze 11.1 svobodného softwaru pro vytváření datových úložišť na síti FreeNAS (Wikipedie). Nejnovější FreeNAS je postaven na FreeBSD 11.1. Přehled novinek v příspěvku na blogu. Zdůraznit lze zvýšení výkonu OpenZFS, počáteční podporu Dockeru nebo synchronizaci s cloudovými službami Amazon S3 (Simple Storage Services), Backblaze B2 Cloud, Google Cloud a Microsoft Azure

Ladislav Hagara | Komentářů: 0
včera 23:55 | Nová verze

Po dvou měsících vývoje od vydání verze 235 oznámil Lennart Poettering vydání verze 236 správce systému a služeb systemd (GitHub, NEWS).

Ladislav Hagara | Komentářů: 1
včera 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
včera 19:33 | Pozvánky

Pražská Fedora 27 Release Party, oslava nedávného vydání Fedory 27, se uskuteční 19. prosince od 19:00 v prostorách společnosti Etnetera (Jankovcova 1037/49). Na programu budou přednášky o novinkách, diskuse, neřízený networking atd.

Ladislav Hagara | Komentářů: 0
včera 18:11 | Nová verze

Byla vydána verze 2.11.0 QEMU (Wikipedie). Přispělo 165 vývojářů. Provedeno bylo více než 2 000 commitů. Přehled úprav a nových vlastností v seznamu změn.

Ladislav Hagara | Komentářů: 0
včera 17:44 | Komunita

Canonical oznámil dostupnost kryptografických balíčků s certifikací FIPS 140-2 úrovně 1 pro Ubuntu 16.04 LTS pro předplatitele podpory Ubuntu Advantage Advanced. Certifikace FIPS (Federal Information Processing Standards) jsou vyžadovány (nejenom) vládními institucemi USA.

Ladislav Hagara | Komentářů: 3
včera 16:11 | Zajímavý software

Společnost Avast uvolnila zdrojové kódy svého dekompilátoru RetDec (Retargetable Decompiler) založeného na LLVM. Vyzkoušet lze RetDec jako webovou službu nebo plugin pro interaktivní disassembler IDA. Zdrojové kódy RetDec jsou k dispozici na GitHubu pod open source licencí MIT.

Ladislav Hagara | Komentářů: 3
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 993 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník
    Štítky: není přiřazen žádný štítek

    Vložit další komentář
    8.2.2012 08:30 Peto_MiG
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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 avatar 8.2.2012 08:46 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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
    Měl jsem sen ... :(
    wiskas avatar 8.2.2012 09:04 wiskas | skóre: 21 | blog: Raziel
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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
    Libav developer. | The world is just a lot of people trolling each other.
    Max avatar 8.2.2012 09:09 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Aj, díky za info. Tak jsem žil jen lehce v omylu :-/
    Zdar Max
    Měl jsem sen ... :(
    David Watzke avatar 8.2.2012 14:17 David Watzke | skóre: 74 | blog: Blog... | Praha
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Ogg je kontejner.
    “Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
    Max avatar 8.2.2012 15:30 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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
    Měl jsem sen ... :(
    8.2.2012 09:08 Jindřich Makovička | skóre: 13
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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 avatar 8.2.2012 10:06 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    „Já bych všechny ty internety a počítače zakázala.“
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    8.2.2012 09:13 hajny
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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
    wiskas avatar 8.2.2012 10:05 wiskas | skóre: 21 | blog: Raziel
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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.
    Libav developer. | The world is just a lot of people trolling each other.
    Max avatar 8.2.2012 10:22 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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
    Měl jsem sen ... :(
    8.2.2012 09:18 prqek | blog: prqek
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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.
    8.2.2012 13:16 Rivon
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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 ;)
    9.2.2012 09:55 prqek | blog: prqek
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Jasně, tenhle přístup se osvědčil mě, není to univerzálně nejlepší postup.
    8.2.2012 11:01 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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 avatar 8.2.2012 13:05 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Č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
    Měl jsem sen ... :(
    8.2.2012 17:06 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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Á*).
    8.2.2012 18:34 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

    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а avatar 8.2.2012 19:48 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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…
    Why did the multithreaded chicken cross the road? to To other side. get the
    8.2.2012 20:14 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Jaký nastavuješ bitrate?
    8.2.2012 20:44 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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í...).
    8.2.2012 23:05 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

    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.

    9.2.2012 00:22 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

    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.)

    9.2.2012 00:28 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Nééé, kam se to zalomení podělo, zrovna když se to nejmíň hodí!

    Čitelná verze mého vejšplechtu: pastebin.com
    oryctolagus avatar 9.2.2012 00:39 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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?
    There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
    9.2.2012 00:53 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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 avatar 9.2.2012 00:46 David Watzke | skóre: 74 | blog: Blog... | Praha
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Upravil jsem formátování tvého komentáře.
    “Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
    9.2.2012 00:47 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Vřelé díky!
    9.2.2012 14:21 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

    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 :).

    9.2.2012 14:37 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

    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.

    9.2.2012 15:35 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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é.

    9.2.2012 19:10 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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 :)
    9.2.2012 21:55 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Rozumím.
    10.2.2012 20:49 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

    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.

    10.2.2012 21:05 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Oh, bitrate nesedí? Možná x264 špatně detekovalo fps (a tedy délku)...
    10.2.2012 21:41 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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а avatar 10.2.2012 22:39 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    DV není nekomprimované.
    Why did the multithreaded chicken cross the road? to To other side. get the
    11.2.2012 13:36 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Schválně jsem to napsal do uvozovek.
    9.2.2012 21:58 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Děkuji.
    11.2.2012 21:24 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

    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.

    oryctolagus avatar 11.2.2012 21:57 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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?
    There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
    11.2.2012 23:22 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

    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á.
    11.2.2012 23:28 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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).
    11.2.2012 23:31 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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).
    11.2.2012 23:12 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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).
    11.2.2012 23:32 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

    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 avatar 12.2.2012 00:54 little.owl | skóre: 22 | Brighton
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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).
    You're damned if you do, and you're damned if you don't.
    12.2.2012 21:05 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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а avatar 8.2.2012 22:21 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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.
    Why did the multithreaded chicken cross the road? to To other side. get the
    David Watzke avatar 8.2.2012 20:19 David Watzke | skóre: 74 | blog: Blog... | Praha
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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á.
    “Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
    8.2.2012 20:39 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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.

    9.2.2012 10:07 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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.
    wiskas avatar 9.2.2012 10:57 wiskas | skóre: 21 | blog: Raziel
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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í.
    Libav developer. | The world is just a lot of people trolling each other.
    pavlix avatar 9.2.2012 22:15 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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 :).
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    David Watzke avatar 9.2.2012 23:00 David Watzke | skóre: 74 | blog: Blog... | Praha
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Bavíme se o počítačích a ne o počítadlech :-D
    “Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
    pavlix avatar 10.2.2012 11:35 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Špatně čteš. Psalo se o přehrávání videa.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    David Watzke avatar 10.2.2012 13:35 David Watzke | skóre: 74 | blog: Blog... | Praha
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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 :-))
    “Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
    Jendа avatar 10.2.2012 00:05 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Můj Atom N270 (nejslabší na trhu) dá 720p v H.264.
    Why did the multithreaded chicken cross the road? to To other side. get the
    pavlix avatar 10.2.2012 11:36 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    I když koukám, že já ani ten Atom nemám :).
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    10.2.2012 01:13 sigma
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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 avatar 11.2.2012 12:00 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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!
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    oryctolagus avatar 9.2.2012 12:24 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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.
    There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
    9.2.2012 15:31 sigma
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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 %
    9.2.2012 15:35 sigma
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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.
    9.2.2012 19:27 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Zhruba podobny dojem z toho mam ja - 2-3x narocnejsi pri stejnem rozliseni.
    9.2.2012 15:42 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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.
    8.2.2012 12:12 Jindřich Makovička | skóre: 13
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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 avatar 8.2.2012 13:27 pushkin | skóre: 42 | blog: FluxBlog
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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?
    "...viděl jsem Vás žíznit a tak jsem se vrátil." | Díky, Kájo!
    Max avatar 8.2.2012 13:39 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Měl jsem sen ... :(
    pushkin avatar 8.2.2012 15:58 pushkin | skóre: 42 | blog: FluxBlog
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Díky, to jsem nějak nezaznamenal :-)
    "...viděl jsem Vás žíznit a tak jsem se vrátil." | Díky, Kájo!
    oryctolagus avatar 8.2.2012 17:55 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Díky, pěkný, těšim se na další díl.

    Čistě na okraj, budeš povídat i o API libav?
    There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
    Max avatar 8.2.2012 19:07 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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
    Měl jsem sen ... :(
    oryctolagus avatar 8.2.2012 20:11 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    Ok, v pohodě ;-)
    There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
    8.2.2012 19:36 tuxmartin | skóre: 38 | blog: tuxmartin | Jicin
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    <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>
    9.2.2012 13:36 OldFrog {Ondra Nemecek} | skóre: 28 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)

    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?

    -- OldFrog
    10.2.2012 17:26 Mandarinka
    Rozbalit Rozbalit vše Re: Hrajeme si s FFmpeg/Libav (1/2)
    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í...
    11.2.2012 23:36 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Handbrake vs. Avidemux

    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?

    11.2.2012 23:48 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Kombinace

    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 avatar 12.2.2012 19:06 little.owl | skóre: 22 | Brighton
    Rozbalit Rozbalit vše Re: Kombinace
    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 :-D ) a presto ze nebyla casto pouzivana a dobre skladovana mam problemy s jejich ctenim i na novych mechanikach.
    You're damned if you do, and you're damned if you don't.
    wiskas avatar 12.2.2012 20:16 wiskas | skóre: 21 | blog: Raziel
    Rozbalit Rozbalit vše Re: Kombinace
    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.
    Libav developer. | The world is just a lot of people trolling each other.
    12.2.2012 21:09 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Kombinace
    Díky za odpověď.
    oryctolagus avatar 12.2.2012 21:16 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Kombinace
    +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ší...
    There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
    12.2.2012 21:31 Mandarinka
    Rozbalit Rozbalit vše Re: Kombinace
    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.
    12.2.2012 21:40 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: Kombinace

    Díky za pěkné shrnutí.

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

    13.2.2012 01:41 J. M. | skóre: 23 | blog: JMblog
    Rozbalit Rozbalit vše Re: Kombinace
    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.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.