Digitální pozemní televize - 5: archivace nahrávek - video (diskuse)

[jam001]

Ještě jsem neviděl nahrávku, kde by nebyl alespoň minimální černý nebo rozmazaný okraj,

Zvlastne, ze je to bezne aj pri DVD. Na druhej strane pri vysielani rakuskeho ORF1 (aj ked som uz davno nepozeral), to byvalo cast bez ciernych pruhov.

Zdá se, že by správné bylo nejdříve nahrávku setříhat a pak až ji enkódovat, abychom nemuseli zbytečně zpracovávat nepotřebné části. Při tomto postupu jsem se ale poměrně často setkal s rozhozením synchronizace audia a videa.

Na toto pouzivam stale dvbcut. Funguje super ak je zdroj mpeg2. Este som nezazil rozhodenie zvuku a obrazu. Aj ked momentalne hladam nahradu, pretoze ho vyrazili z portage a netusim ako dlho mi bude fungovat stary ebuild, pripadne kedy sa vrati.

[Vtipnéř]

Dvbcut jsem taky kdysi zkoušel, ale mám matný pocit, že byl nějaký problém se synchronizací, když jsem potřeboval začít ukládanou nahrávku mimo klíčový snímek. Ale možná, že to bylo mezitím odstraněno.

Jirka

[jam001]

Ja som ho pouzival prave preto, ze som s nim nikdy nemal problem so synchronizaciou a je rychly. Ak sa nemylim, tak pri strihu upravuje video len po najblizsi klucovy snimok a ostatne nechava napokoji (+nema problem s viacerymi zvukovymi stopami).

[Stevko]

S DVB som mal problémy s rozchádzaním zvuku a obrazu. Stačí to raz prehnať cez Project-X (demux na audio a video a potom spojenie napr. cez program mplex) a funguje to už bez problémov. V Project-X sa to dá aj strihať, ale neprišlo mi to ako pohodlné. Možno sa to dá aj jednoduchšie nejak zosynchronizovať. Neviem. A na ďalšiu prácu už môžeme s úspechom použiť aj napr. Avidemux.

[Vtipnéř]

Dík za inspiraci. Project-X už jsem dvakrát použil na vadné nahrávky, které neprošly mencoderem. Občas mívám pocit, že zvuk u zpracované nahrávky je o malinko posunutý. Dočetl jsem se, že to může být tím, že mencoder někdy zahazuje opakované snímky.

Zkusím na něčem pořádně otestovat, jak to dopadne s Project-X, a dám vědět.

Jirka

[Kvakor]

Jednodušší než odečítat ořez z obrázků je použít přikaz change_rectangle a koukat se na výsledek rovnou v reálném čase, více viz můj příspěvek do diskuze o digitalizaci VHS.

[Aminux]

A proč to neoříznout, nepřeškálovat a nepřekódovat přímo v Avidemuxu? Akorát u nahrávek z DVB-t,s má problém se synchronizací zvuku. Vždy musím zvuk posunout. Většinou několik desetin vteřiny do mínusu. Ale jinak pohoda.

[Vtipnéř]

Důvody mám tři. Jednak upravit převodní dávku zvládnu rychleji než naklikat parametry v Avidemuxu. Druhým důvodem je, že pro enkódování nepotřebuji grafické prostředí. Třetím důvodem je, že můžu pomocí at načasovat zpracování třeba přes noc. Ale musím říct, že jednou mencoder nezvládl zpracování kvůli nějaké chybě, kterou jsem nedokázal identifikovat, chybu neopravil ani Project-X, ale Avidemuxem to prošlo.

Mám pocit, že ten časový posun dělá někdy i mencoder. V jednom předchozím příspěvku radí kolega zpracování pomocí Project-X. Mám v plánu to otestovat.

Jirka

[J. M.]

1. Avidemux umí jednak uložit/načíst sadu filtrů (tlačítka Otevřít/Uložit v dialogu správce filtrů), jednak má menu "Custom" pro nastavení celkových "presetů" aplikovaných na aktuální video (sada filtrů, nastavení kodéru atd.), takže žádné opakované naklikávání parametrů v GUI verzi není potřeba.

2. Avidemux nepotřebuje grafické prostředí. Avidemux má oddělené GUI, rozhraní z příkazového řádku (bez závislosti na GUI) a jádro programu.

3. Zpracování Avidemuxem se dá načasovat přes noc, spouštět dávkově, Avidemux je navíc skriptovatelný pomocí ECMAScriptu.

[Vtipnéř]

Dík za informace, člověk se učí pořád.

[Isah]

Děkuju za blog a inspiraci.

[Ctirad Feřtr]

Mě by hodně zajímala jedna věc, se kterou se tu teď peru u svého mythtv. Mám stádo nahrávek, co bych chtěl exportovat do nějakého mkv/avi/mp4 podle potřeby. Na to sice existuje hezký plugin skript mythnuv2mkv, který toho umí opravu hodně, ale bohužel naprosto naprosto ignoruje fakt, že existuje něco jako anamorfní formát obrazu, což je snad veškerý širokoúhlý materiál vysílaný v TV (kromě primy, která pořád zarputile vysílá v letterboxu).

Jinými slovy, mám širokoúhlé nahrávky s poměrem 16:9 bez jakýchkoliv černých pruhů kdekoliv v rozlišení 704(720)x576, což je samozřejmě naprosto normální a každý kloudný přehrávač to roztáhne na správný poměr. Bohužel ten skript, co používá mencoder mi to buď přepočítá na nějakou nudli 7xx na 3xx nebo když mu vnutím 576 řádků, tak mi k tomu dopočítá 1xxx sloupců. Netušíte někdo co s tím? Navíc v hlavičce výsledného souboru je ke všemu ještě nějaký nesmyslný poměr 5:4.

[Vtipnéř]

Poměr 5:4 je poměr rozměrů PAL (720x576) bez přenásobení šířky. Nudle 7xx na 3xx vypadá na americký formát 2,35:1. Na 576 řádků při poměru 16:9 připadá 1024 sloupců. Nešlo by uvést přesná čísla?

Jestli máte jistotu, že to přehrávač správně roztáhne, tak by se nemuselo škálovat a stačilo by vnutit do nahrávky správný poměr, do avi souboru se to dá udělat pomocí -force-avi-aspect 16/9. Kodek lavc má zase parametr aspect. Tak můžete zkusit parametr -aspect při přehrávání mplayerem.

Mimocodem, v jakém formátu máte vstup a v čem chcete výstup? Mkv nebo avi jsou jen kontejnery, můžou obsahovat video v různých formátech.

Zkuste ten citovaný skript poslat. Třeba na něco přijdeme.

Jirka

[Ctirad Feřtr]

Poměr 5:4 je poměr rozměrů PAL (720x576) bez přenásobení šířky. Nudle 7xx na 3xx vypadá na americký formát 2,35:1. Na 576 řádků při poměru 16:9 připadá 1024 sloupců. Nešlo by uvést přesná čísla?

Šlo, ale pro dotaz jsou nepodstatná a neměl jsem je po ruce. Kdyžtak viz parametr "quality" a celý skript tady.

Jestli máte jistotu, že to přehrávač správně roztáhne, tak by se nemuselo škálovat a stačilo by vnutit do nahrávky správný poměr, do avi souboru se to dá udělat pomocí -force-avi-aspect 16/9. Kodek lavc má zase parametr aspect. Tak můžete zkusit parametr -aspect při přehrávání mplayerem.

O to se právě přesně snažím. Přepočítávání jsem z toho vyhodil úplně, ale ten poměr se tam korektně nezapisuje. Zatím jsem to nijak do hloubky nestudoval, ptal jsem se hlavně proto, jestli to už někdo nevyřešil, abych nevymýšlel kolo.

[J. M.]

Ten poměr stran se dá uložit buď na úrovni video bitstreamu, nebo na úrovni kontejneru. To první záleží na formátu a kodéru videa, třeba u kodéru Xvid v MEncoderu jsou v -xvidencopts volby "par" (poměr stran pixelu, ne poměr stran videa) atd., ale ne každý přehrávač to podporuje.

Lepší je ten poměr stran zapsat do kontejneru. Přehrávače podporující MP4 nebo Matrosku by to měly standardně podporovat. Nevím, jak na to u MEncoderu. Já MP4 soubory vytvářím programem MP4Box (i kdybych třeba nejdřív MP4 video vytvořil jiným programem, finální verzi ještě remuxuji MP4Boxem), soubory v Matrosce jedině v MKVToolnix (totéž jako u MP4Boxu).

MP4Box -add soubor.mp4#video -add soubor.mp3#audio -PAR 1=16:9 vystup.mp4

(Opět poměr stran pixelu, ne obrazu.)

mkvmerge --aspect-ratio 0:16/9 -o vystup.mkv vstup.mp4

(Tady je to poměr stran obrazu, ne pixelu.)

[Ctirad Feřtr]

Tohle jsem potřeboval. Díky. Trochu jsem ten skript pošolichal a přidal volbu "noresize" a teď čekám, co z toho vypadne.

[Grunt]

-noaspect nebo parametry -x a -y. V nejhorším případě natvrdo -vf scale.

[J. M.]

Jenom bych měl připomínku k použitému výstupnímu formátu, když to tady nikdo jiný nezmínil. Myslím, že v dnešní době už nemá moc smysl kódovat (ne „enkódovat“) do zastaralého a překonaného formátu MPEG-4 ASP. To snad jedině pokud má někdo starý hardwarový (např. stolní DVD) přehrávač, který kromě obligátního MPEG-2 podporuje MPEG-4 ASP (často chybně inzerovaný jako „DivX a Xvid“). Ale v dnešní době už i kdejaký mobilní telefon podporuje MPEG-4 AVC alias H.264, takže bych rozhodně zvolil tento modernější formát s lepším kompresním účinkem. Lepší kvalita v menším souboru, mainstream dneška, široká podpora. Navíc x264 je asi nejlepší kodér videa současnosti vůbec.

[Grunt]

Jenom s přidávám. Ta uniformita v podobě DVDRip, MPEG-4 ASP, 640×poměr (v tom lepším případě bikubickým filtrem), MPEG-1 Layer 3, CBR o 128kbps, 44100Hz a dva kanály už mě pěkně štve. Aspoň že s bitrate už se přestalo blbnout na 650MB výsledku (a znovu v tom lepším případě dopředu dopočítaným CBRkem) jak se kodeky ASPčka zlepšily a kdo to dá na míň je borec. A právě v tomto dává AVCčko jistou výhodu. Už se nemůžu dočkat až jednou budu tahat díl o velikosti pod 100MB. To by bylo parádní.

[J. M.]

Ona prý ta „Scene“ (nebo jak se ta pirátská komunita jmenuje) má nějaká oficiální pravidla jak mají být ty DVD ripy publikovány, jaký kodér videa se musí použít a tak... Léta měli povinné kódování kodekem Xvid, nevím, jestli teď už snad přidali i x264... Taky mě mrzí ty zbytečně obrovské soubory s podprůměrnou kvalitou obrazu. Ale to není jenom kodekem, nýbrž často neznalostí tvůrců těch videí. Já třeba si stahuju některé sportovní přenosy a na pořádně udělané video narazím tak v jednom případu z dvaceti. Větsina lidí, co ta videa tvoří, vůbec třeba netuší, že existuje prokládání. A tak nejen že nepoužívají deinterlace filtr, ale navíc ten prokládaný obraz zmenší, čímž ho nevratně zdevastují (při pohybu tak vypadá jako roleta). A chtít po nich, aby správně spočítali výsledný poměr stran, no to už je sci-fi. Prakticky všechna ta video jsou zdeformovaná (širokoúhlý obraz ve tvaru čtverce atd.)

Ale taky se těším, až konečně začne dominovat AVC (nebo aspoň to VP8, jestli se zlepší). To ASPčko lidi používají prostě ze zvyku, ze setrvačnosti, protože to bylo léta cool, tak na to je pořád spousta návodů, softwarových nástrojů, každý to umí přehrát a tak.

[kip]

A jaký formát pro zvuk, jaký kontejner?

[Grunt]

HE-AACv2 pro bitrate nižšší než 56kb/s, OGG Vorbis pro bitrate od (48-64kbps) - 128kbps a Musepack pro 128kbps a výše. Všechny tři umí i vícekanálový zvuk, ale nejproracovanější bude nejspíše v této oblasti AAC. Nejpreferovanější kontejner Matrjoška, jelikož zvládne jak všechny vyjmenované video, tak audio formáty a má spousty funkcí. Dále NUT, ten by měl též zvládnout též všechny vyjmenované audio a video formáty. K zahození potom určitě není ani MPEG-4 Part 14 (min. H.264 a AAC zvládne určitě), OGG a nebo třeba QuickTime file format, pokud chceme udělat radost Applistům(min. MPEG-4 AVC a AAC zvládne také určitě).

[Vtipnéř]

Můj mobil neumí ani zobrazovat fotky. H.264 bude patrně za pár let (možná dokonce rok, dva) standard, ale myslím, že zatím to tak není. Já jsem zatím do tohoto formátu nic nepřeváděl. Až s tím budu mít zkušenosti, rád o nich napíšu.

K tomu výrazu "enkódovat": celou dobu, co jsem měl blok rozepsaný, jsem tam měl "kódovat". Až těsně před zveřejněním jsem se rozhodl použít termín z návodu k mplayeru.

[J. M.]

Návod k MPlayeru překládal člověk, který neumí česky, bohužel tím zblbl hodně lidí, kteří to po něm čtou. Je to klasicky amatérské bezhlavé doslovné přepisování anglického výrazu do češtiny. Slovo enkódovat v češtině neexistuje (v žádném slovníku ÚJČ, ani v pravidlech českého pravopisu, ani v slovníku cizích slov). Předpona „en“ v anglických slovech odpovídá zhruba našemu „za“ nebo „vy“, tedy něco nějak učinit. Např. encapsulate je zapouzdřit (ne enpouzdřit), encipher je zašifrovat (ne enšifrovat), encamp je utábořit (ne entábořit), enrage je rozzlobit (ne enzlobit), no a encode je zakódovat, ne enkódovat.

H.264 je běžný standard už dávno. Prakticky každý moderní stolní přehrávač videa už jej dnes podporuje (nejen proto, že je to standard Blu-ray), jeho podpora je nativně ve Windows 7 i Mac OS X, herních konzolích, video kamerách atd. Vysílá v něm i YouTube, které v H.264 nevysílá jenom pro počítače, ale i televize a mobilní zařízení. Dnes už je prostě H.264 rozšířenější a mainstreamovější než MPEG-4 Part 2, a ten rozdíl bude s každým rokem jenom narůstat.

[Vtipnéř]

Návod k MPlayeru překládal člověk, který neumí česky, bohužel tím zblbl hodně lidí, kteří to po něm čtou. Je to klasicky amatérské bezhlavé doslovné přepisování anglického výrazu do češtiny. Slovo enkódovat v češtině neexistuje (v žádném slovníku ÚJČ, ani v pravidlech českého pravopisu, ani v slovníku cizích slov). Předpona „en“ v anglických slovech odpovídá zhruba našemu „za“ nebo „vy“, tedy něco nějak učinit. Např. encapsulate je zapouzdřit (ne enpouzdřit), encipher je zašifrovat (ne enšifrovat), encamp je utábořit (ne entábořit), enrage je rozzlobit (ne enzlobit), no a encode je zakódovat, ne enkódovat.

Tak jsem to opravil, díky za upozornění.

H.264 je běžný standard už dávno. Prakticky každý moderní stolní přehrávač videa už jej dnes podporuje (nejen proto, že je to standard Blu-ray), jeho podpora je nativně ve Windows 7 i Mac OS X, herních konzolích, video kamerách atd. Vysílá v něm i YouTube, které v H.264 nevysílá jenom pro počítače, ale i televize a mobilní zařízení. Dnes už je prostě H.264 rozšířenější a mainstreamovější než MPEG-4 Part 2, a ten rozdíl bude s každým rokem jenom narůstat.

Vyjádřil jsem se trochu nepřesně. Standard to samozřejmě je, ale myslím, že ještě není moc rozšířený, zejména co se týče stolních přehrávačů. Třeba z mých známých nemá Blue-ray přehrávač nikdo. S tím, že se tento formát bude čím dál víc šířit, naprosto souhlasím. Nicméně, před časem jsem čekal, že klasická DVD nahradí nosiče s formátem MPEG-4, a zatím se tak neděje.

[Grunt]

-vo png

Tož to nevím. Ono to generuje docela rychle ty jednotlivé framy, dost zabírají a pak je ještě mazat? Když už nic, tak doporučuju aspoň -vf screenshot a klávesu S.

nejčastěji tak jsou vysílány přímé přenosy, zprávy a podobně

Já měl za to, že prokládání už je součástí standardu (proto MPEG-2 a ne MPEG-1) DVB-T (a nebo aspoň u nás) a téměř každá televize už jen provádí deinterlacing.

Posledním nutným filtrem je přeškálování. Jak jsem uvedl v předchozí části, jestli chceme mít co nejvíc přenositelnou nahrávku ve formátu MPEG-4, je potřeba alespoň přenásobit šířku nahrávky

To jsem nepochytal. Co je na 720x576 špatného?

Pro průměrnou doporučenou hodnotu CQ=0,25

No, nevím. Přijde mi to zbytečně moc. Nedávno jsem se rýpal kolik by tak mohlo být sledovatelné minimum pro HD (1920x800) s MPEG-1 videem (kodek lavc) a skončil jsem na nějakých 3.5Mbps. A to šlo o trailer, takže spousta akčních scén v krátkém čase. V případě AVC (a to jsem x264 ani nijak zvlášť moc netunil – v podstatě defaultní parametry) mi nějakých 2.5Mbps přišlo pomalu jako plně transparentní. Určitě je vhodné si svoji hodnotu nějak empiricky najít a nespoléhat na předem rozhodnutá čísla. Úplně nejlepší by bylo samozřejmě nepřekódovávat to a nechat to tak jak to z karty leze.

Při druhém průchodu je dobré uložit do výsledného souboru poměr stran (parametr -force-avi-aspect)

No a úplně nejlepší je nehackovat takový starý krám jako je AVI a ukládat to do něčeho normálního.

Audio je ve formátu MP3, takže většinou stačí ho jen překopírovat.

Audio je ve formátu MP2 (MPEG-1, Layer II přesněji) o 192kbps. Mám pocit, že to dokonce diktuje standard. Ale jinak souhlas. Nejlépe zkopírovat a neprznit ho chudáka ještě víc.

Nicméně až na pár vyjmenovaných maličkostí musím pochválit. Dokonce jsem se dozvěděl pár drobností, které jsem nevěděl.

[VSi]

nejčastěji tak jsou vysílány přímé přenosy, zprávy a podobně

Já měl za to, že prokládání už je součástí standardu (proto MPEG-2 a ne MPEG-1) DVB-T (a nebo aspoň u nás) a téměř každá televize už jen provádí deinterlacing.

Souhlasím. Jen bych doplnil, že občas v televizi běží věci, kde deinterlace není potřeba - obvykle filmy nasnímané na filmový pás, který je z principu bez řádkování a 24 fps se na 50 převede zdvojením framů a lehkým zrychlením.

Posledním nutným filtrem je přeškálování. Jak jsem uvedl v předchozí části, jestli chceme mít co nejvíc přenositelnou nahrávku ve formátu MPEG-4, je potřeba alespoň přenásobit šířku nahrávky

To jsem nepochytal. Co je na 720x576 špatného?

Nejspíš to, že 720/576=1.25 a 4/3=1.33. Samozřejmě můžeme mít nečtvercové pixely (pixel aspect ratio <> 1:1). Mám ale zkušenost, že přehrávače to podporují jen u MPEG kontejneru. U oblíbeného avi (pro většinu lidí navíc avi implikuje obsah v DivX/MPEG4-ASP) to skoro žádný přehrávač nepodporuje (i když kontejner snad ano) - obraz je deformovaný na aspect ratio 1:1.25. Navíc 16:9 obsah se v MPEG-2 v DVB-T/S nebo na DVD taky přenáší v 720×576 a tam už je deformace nesnesitelná a bylo by nutné nastavovat AR ručně (u originálního MPEG2 to přehrávače umí automaticky). Nevím jak MKV, tam už je to možná lepší. Asi platí, že přeškálování je lepší se vyhnout pokud není nutné, protože přináší ztrátu kvality.

[Vtipnéř]

nejčastěji tak jsou vysílány přímé přenosy, zprávy a podobně

Já měl za to, že prokládání už je součástí standardu (proto MPEG-2 a ne MPEG-1) DVB-T (a nebo aspoň u nás) a téměř každá televize už jen provádí deinterlacing.

Souhlasím. Jen bych doplnil, že občas v televizi běží věci, kde deinterlace není potřeba - obvykle filmy nasnímané na filmový pás, který je z principu bez řádkování a 24 fps se na 50 převede zdvojením framů a lehkým zrychlením.

Mám pocit, že co se týče klasických filmů, je takových věcí většina. Ale jak která televize.

[Vtipnéř]

-vo png

Tož to nevím. Ono to generuje docela rychle ty jednotlivé framy, dost zabírají a pak je ještě mazat? Když už nic, tak doporučuju aspoň -vf screenshot a klávesu S.

Tohle jsem kdysi zkoušel a nějak mi to nefungovalo, ale zase to zkusím.

Pro průměrnou doporučenou hodnotu CQ=0,25

No, nevím. Přijde mi to zbytečně moc.

Jak jsem koupil, tak prodávám. Ale jak už jsem napsal, při větších rozměrech se dá jít dolů.

Při druhém průchodu je dobré uložit do výsledného souboru poměr stran (parametr -force-avi-aspect)

No a úplně nejlepší je nehackovat takový starý krám jako je AVI a ukládat to do něčeho normálního.

Chystám se na to, až to budu mít na čem přehrávat (myslím kromě počítače).

Audio je ve formátu MP3, takže většinou stačí ho jen překopírovat.

Audio je ve formátu MP2 (MPEG-1, Layer II přesněji) o 192kbps.

Dík za upřesnění, někde jsem to četl. A mplayer mi hlásí "MPEG layer-2, layer-3", tak nevím.

[Grunt]

Jak jsem koupil, tak prodávám

V pohodě. Prostě jen dobře mířená rada.

Ale jak už jsem napsal, při větších rozměrech se dá jít dolů.

Spíš naopak.

Dík za upřesnění, někde jsem to četl. A mplayer mi hlásí "MPEG layer-2, layer-3", tak nevím.

Jde o dekodér (čas od času se vyskytují i ve formě knihovny). Používá to jeden jak pro Layer-II, tak pro Layer-III.

[Vtipnéř]

Ale jak už jsem napsal, při větších rozměrech se dá jít dolů.

Spíš naopak.

Proč naopak? Když se komprimuje stejný obrázek ve dvakrát větším rozlišení, tak nemá čtyřikrát větší velikost, je to míň. Takže počet bitů na pixel je menší pro větší obrázky. U videa by to mělo být obdobné.

Jirka

[Grunt]

No, teoreticky: Se zvyšujícím rozlišením jen narůstá pouze nejvyšší obsažená frekvence a ty stávající zůstávají netknuté (samozřejmě v případě použití ideálního škálovacího filtru), tudíž při zvyšujícím se rozlišení pro zachování stejné velikosti souboru musíme ekvivalentně snižovat kvantizační parametr a to by mělo ústit v to, že ořez a kvantizační sestup bude tak nějak pořád na stejném místě při libovolné velikosti obrázku (samozřejmě ne menší než kde začíná ořez).

Prakticky: Toto pravidlo zase neplatí tak úplně. A to hlavně díky blokové nátuře DCT a max. frekvenci, která se do bloku 8x8 nebo 16x16 vleze. Ano, 2× větší obrázek sice nezabere 2× nebo 4× více místa, ale také to není s tím udržováním kvantizačního koeficientu na stejných hodnotách nijak slavné a prostě musí růst pro zachování transparentnosti (a nebo aspoň stejné úrovně vjemu). A to nás tedy přivádí k otázce co je víc, zda-li menší rozlišení a vyšší kvantizační koeficient a nebo větší rozlišení a menší koeficient (logicky s rostoucím rozlišením by mělo být dáno více prostoru k projevení se energie ve vyšších frekvencích(tedy hranách kupř.) a více prostoru pro rozlití se energiím v nižších frekvencích). Psal jsem tu o tom zápisek (doporučuji začít od posledního odstavce), ale přijde mi že na důkladnou odpověď je tam tomu věnováno hodně málo místa, takže bude-li zájem, nabídnu skript, který snižuje rozlišení a přitom se snaží u obrázku zachovat podobnou velikost (nestoupne přes určitou hranici, ale volí kvantizační koeficient nejbližší nižší) a každý si může porovnat sám.

[Vtipnéř]

Díky za tip na další informace k tématu.

Jirka

[J. M.]

Hlásí „layer 2 layer 3“ ve smyslu „layer 2 nebo layer 3“ (tedy MP2 nebo MP3), protože na to používá společný dekodér.

[Amarok]

-vo png

Tož to nevím. Ono to generuje docela rychle ty jednotlivé framy, dost zabírají a pak je ještě mazat? Když už nic, tak doporučuju aspoň -vf screenshot a klávesu S.

Tohle jsem kdysi zkoušel a nějak mi to nefungovalo, ale zase to zkusím.

To podle me vypada jako pokus o sebevrazdu. Ukladani png za behu, cili pri 30 snimcich za sekundu? Nezkousel jsem, ale pri vyssim rozliseni nevim nevim. Jedine, ze by byla komprese skoro nulova, ale to abych pak radsi ukladal rovnou na externi terabajtovy disk.

[Grunt]

Parametrem z=0-9 se opravdu určuje úroveň komprese a je to téměř bez problému, protože default je opravdu z=0. Je jasné, že s z=9 je to slušný overhead.

[Vtipnéř]

Protože mi -vf screenshot s klávesou 's' nefunguje, dělám to uvedeným způsobem. Uložím pár snímků a stopnu to. Nevidím v tom žádný problém.

Jirka