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

27.5.2010 14:36 | Přečteno: 2005× | Multimedia | | poslední úprava: 30.5.2010 22:22

Při zpracování nahrávky se zaměříme nejprve na zpracování videa, což zahrnuje tyto činnosti: ořez, někdy odstranění prokladu, přeškálování a vlastní kódování. První tři patří mezi video filtry a měly by se podle návodu k mplayeru aplikovat v uvedeném pořadí. Pojďme se tedy věnovat jednotlivým fázím zpracování za použití mplayeru a mencoderu.

Ořez

Bez ořezu se u nahrávek z digitální TV neobejdeme. Ještě jsem neviděl nahrávku, kde by nebyl alespoň minimální černý nebo rozmazaný okraj, zpravidla je tento okraj v řádu několika bodů až několika desítek bodů. Jednak je zbytečné zpracovávat ho a pak také by se při zpracování mohly rozmazané okrajové oblasti rozšířit do částí, které jsou v pořádku. Mplayer má volbu -cropdetect pro zjišťování okrajů pro ořez, ale protože okraje u digitálního vysílání bývají často rozmazané, je lepší zjistit rozměry pro ořez ručně. Můžeme to nejlépe udělat tak, že sejmeme z nahrávky obrázek, ve vhodném programu ho zvětšíme a odečteme hranice pro ořez. Musíme ovšem dát pozor, aby se nejednalo o scénu z úvodní části s titulky, protože občas se stane, že tato část je v poměru 4:3 s černými okraji, takže zde je vlastní film v poměru 16:9, ale po titulcích se černé okraje ztratí a pak je vlastní film v poměru 4:3. Taky je potřeba dát pozor na pořady v původním znění s překladovými titulky, protože ty mohou zasahovat do černých okrajů a bylo by nemilé, kdyby jich kousek chyběl.

Ukládání nahrávky do obrázků pomocí mplayeru zajistí např. volba -vo png, takže když chceme sejmout kousek nahrávky uložené ve formátu MPEG-2 po deseti minutách od začátku, zadáme příkaz

mplayer -ss 600 -vo png Nahravka.mpeg

Tím se začnou vytvářet soubory 00000001.png, 00000002.png atd., dokud mplayer nestopnem sitiskem 'q'. Uložené obrázky můžeme prohlížet třeba kolourpaintem, kde lze obrázky jednoduše zvětšit o odečíst rozměry oblasti pro ořez. Při zpracovnání mencoderem se zadává oblast pro ořez parametrem pro filtrování videa

-vf crop=šířka:výška:levýokraj:horníokraj

Zadáváme v pixelech šířku, výšku a hranice oblasti, která zůstane zachována po ořezu, přičemž hranice se počítají od nuly, takže souřadnice začátku této oblasti se rovnají šířce resp. výšce levé či horní odřazané oblasti. Tedy jestliže chceme odříznout 8 bodů zleva a 6 zprava a po čtyřech bodech nahoře i dole (zůstává oblast 706x568), má parametr pro ořez tvar

-vf crop=706:568:8:4

Z důvodů, které jsou přesně objasněny v citovaném návodu, je vhodné, aby odřezané okraje i zbylá oblast měly sudé rozměry, a pokud budeme odstraňovat proklad, musí být výška horního a dolního okraje, a tedy i výška zbylé oblasti, dělitelná čtyřmi.

Proklad

Proklad je metoda vysílání, kdy jednotlivé snímky se nemění celé, ale střídavě po lichých a sudých řádcích. Proklad se často pozná hned při vysílání, nejčastěji tak jsou vysílány přímé přenosy, zprávy a podobně. Ale objevují se i filmy s prokladem, hlavně asi ty starší, které už byly zpracovány pro televizní vysílání dříve. Pokud si nejste jisti, jestli je nahrávka prokládána nebo není, uložte si záběr, kde je nějaký pohyb, hranice pohybujících se objektů jsou na uloženém snímku zřetelně čárkované.

Proklad nemusíme odstraňovat, pokud nahrávku chceme uložit tak, jak je, pouze sestříhanou. V takovém případě stačí odstranit proklad až při samotném přehrávání. Pro převod do MPEG-4 je ovšem odstranění prokladu nezbytné.

Na odstranění prokladu je možné použít více metod. Jejich seznam při použití mplayeru zjistíme např. příkazem mplayer -vf help |grep deint, dál nám napoví man mplayer. Zajímavé srovnání jednotlivých metod najdeme na těchto stránkách. Já na základě rady v jedné diskusi používám jádrový odstraňovač prokladu kerndeint=14:0:0:1:1.

Škálování

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, i kdyby nebylo potřeba udělat žádný ořez. Výsledné rozměry po přeškálování musí být dělitelné 16 a musí být přibližně ve stejném poměru jako je ořezaná nahrávka po přenásobení příslušným koeficientem. Poměr nemusí být úplně stejný, protože malé deformace přibližně do 3 procent při běžném sledování nezaregistrujeme. Takže když na šířce nahrávky odřízneme zhruba 20 bodů a na výšce jen 4, což není nijak řídký případ, můžeme s klidným srdcem nechat původní poměr 4:3 nebo 16:9.

O něco složitější je výpočet poměru, když odřezáváme větší okraje. Nejlépe si to ukážeme na příkladu. Mějme širokoúhlý film, který je ale vysílaný v poměru 4:3 s černými okraji nahoře a dole. Tyto okraje mají výšku 72 bodů, samotný film má tedy 432 bodů. Kromě toho je vlevo okraj 2 body a vpravo 4 body, zůstává tedy šířka 714 bodů. Tento rozměr musíme přenásobit koeficientem 16/15, kterým se násobí šířka vysílaná (720 bodů) na šířku zobrazovanou (768 bodů): 714x16/15=761,6. Poměr filmu je tedy 761,6:432=1.763. Takže můžeme bez obav použít klasický širokoúhlý formát 16:9=1.778.

Americké filmy, ale nejen ty, bývají někdy v poměru 2,35:1, v tom případě se bez černých okrajů ve vysílání nelze obejít. Tento poměr bychom dostali v předchozím příkladu, pokud by zobrazovaná šířka byla 1024 bodů. Pak je násobící koeficient 64/45 a podobným výpočtem by nám vyšel poměr 1015.467:432=2.351. Pro ukládání takových filmů je lepší použít poměr 7:3=2,333, který nabízí víc možností rozměrů, ale původní poměr se dá samozřejmě použít taky. V případě, že je film natočený původně v tomto poměru, nebo případně i klasický širokoúhlý film, částečně ořezán ze stran, narazíme na nestandardní poměry. Pak buď musíme nahrávku ořezat ještě více, nebo použít nejbližší poměr při zachování dělitelnosti rozměrů 16. Některé z nich uvádí i s doporučenými rozměry tabulka uvedená níže.

Vlastní parametr pro škálování je

-vf scale=šířka:výška

Jednotlivé video filtry se oddělují čárkou. Celkem tedy může sekvence video filtrů při zpracování vypadat takto:

-vf crop=706:568:8:4,kerndeint=14:0:0:1:1,scale=512:384

Kódování

Při vlastním zpracování do MPEG-4 musíme nejdřív výbrat kodek. K tomu slouží parametr -ovc a seznam dostupných kodeků zjistíme pomocí příkazu mencoder -ovc help. Výpis může záviset i na tom, jestli používáme distribuční verzi mencoderu, nebo jsem si jej kompilovali sami. Pro naše účely nejlépe poslouží buď kodek lavc nebo xvid. Kdysi jsem četl srovnání různých kodeků, kde autor uváděl, že oba dva mohou dát stejně kvalitní výstup, ale lavc potřebuje hlubší znalosti o tom, jak nastavit jednotlivé parametry, kdežto xvid dává kvalitní výsledky i při defaultním nastavení. Parametry pro tyto kodeky se nastavují pomocí -lavcopts, resp. -xvidencopts. přičemž identifikace parametrů se pro jednotlivé kodeky liší. Podrobnosti najdeme třeba v manuálových stránkách.

Nejdůležitějším parametrem je video bitrate, který nejvíc ovlivňuje kvalitu zpracované nahrávky. Vetšinou je udáván v kilobitech za sekundu (kilobit je 1 000 bitů, nikoliv 1 024) a ovlivňuje faktor kvality komprese označovaný jako CQ. Hodnota CQ odpovídá počtu bitů na jeden pixel a pro MPEG-4 se doporučuje, aby byl mezi 0,2 a 0,3, ale při větších výsledných rozměrech můžeme CQ volit i menší až zhruba k 0,15. Je jasné, že čím větší hodnota CQ, tím kvalitnější je zpracovaná nahrávka, ovšem na úkor větší velikosti. Taky záleží na tom, o jaký typ filmu se jedná, jestli je děj poklidný nebo plný rychlých akčních scén. Nejhůř dopadají při zpracování scény v šeru, v mlze nebo pod vodou. U filmů, kde je podobných scén hodně, je lepší nastavit video bitrate spíš větší.

Označíme-li VBR video bitrate, Š a V šířku a výšku výsledné nahrávky a počítáme-li se standardními 25 snímky za sekundu, dostáváme pro CQ vztah CQ=(VBR*1000/25)/(Š*V) (první závorka dává počet bitů na jeden snímek, druhá počet pixelů v jednom snímku). Pro průměrnou doporučenou hodnotu CQ=0,25 odtud dostáváme jednoduchý vztah pro přibližný video bitrate VBR=Š*V/160.

Následující tabulka ukazuje některé možné použité rozměry zpracované nahrávky při daných poměrech stran spolu s hodnotou VBR podle uvedeného vzorečku (zaokrouhleno dolů).

poměr	rozměry	VBR	rozměry	VBR	rozměry	VBR
4:3=1,333	640x480	1900	512x384	1200	384x288	650
16:9=1,778	1024x576	3650	768x432	2050	512x288	900
7:3=2,333	896x384	2150	672x288	1200	560x240	800
19:8=2,375	912x384	2150	608x256	950
47:20=2,35	752x320	1500
2:1=2	1024x512	3250	768x384	1800	512x256	800
5:3=1,667	720x432	1900	640x384	1500	480x288	850
3:2=1,5	720x480	2150	576x384	1350	432x288	750
15:8=1,875	960x512	3050	720x384	1700	480x256	750

Pokud máte na převod dost času, je doporučeno provádět zpracování dvěma průchody, kdy při prvním průchodu se ukládají informace o nahrávce do pomocného souboru divx2pass.log a při druhém průchodu se podle uložených údajů optimalizuje komprese videa, aby bylo dosaženo požadovaného bitrate. Jednoduchá dávka pro převod nahrávky pak může vypadat třeba takto:

#!/bin/bash
# dvouprůchodové kódování TV nahrávky (MPEG-2) v poměru 4:3
fname=$1
videobr=700
mencoder \
 -oac copy \
 -ovc xvid -xvidencopts bitrate=$videobr:pass=1 \
 -vf crop=700:568:8:4,kerndeint=14:0:0:1:1,scale=384:288 \
 -o /dev/null $fname.mpeg
mencoder \
 -oac copy \
 -ovc xvid -xvidencopts bitrate=$videobr:pass=2 \
 -vf crop=700:568:8:4,kerndeint=14:0:0:1:1,scale=384:288 \
 -force-avi-aspect 4/3 -o $fname.avi $fname.mpeg
rm divx2pass.log

U kodeku lavc je parametr označující průchod nazván vpass a parametr pro video bitrate vbitrate. Příklady nastavení parametrů pro různou výslednou kvalitu pro oba kodeky najdeme tady a tady. Při kódování je možné i odstranit proklad, ale v návodu i v manuálových stránkách (hledejte parametr interlacing pro kodek xvid) jsou informace o tom poměrně stručné, proto jsem to ani nezkoušel.

Při prvním průchodu vlastní zpracovanou nahrávku k ničemu nepotřebujeme, takže ji můžeme zahazovat. Při druhém průchodu je dobré uložit do výsledného souboru poměr stran (parametr -force-avi-aspect), protože jsem se několikrát setkal s tím, že se uložil poměr nesprávný, patrně z části před vlastní nahrávkou z reklam nebo upoutávek. Audio je ve formátu MP3, takže většinou stačí ho jen překopírovat. Podrobněji bych se chtěl o audiu zmínit v dalším díle.

Stříhání

Nakonec vyhodíme reklamy, upoutávky a podobný balast. Zdá se, že by správné bylo nejdříve nahrávku setříhat a pak až ji kó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.

Ke stříhání používám avidemux. Jeho ovládání je velmi jednoduché a intuitivní a dá se dobře ovládat jen z klávesnice bez myši. Jediný problém, který jsem musel řešit, byl nefunkční zvuk při spuštění. Je potřeba otevřít "Předvolby" v menu "Upravit" a nastavit "AudioDevice" na kartě "Audio". Zkuste vybrat z nabídky a otestovat. U starší verze bylo potřeba napsat "default" v položce "Alsa zařízení".

Při otevření video souboru nám nabídne možnost jeho přeindexování, tu odsouhlaste, zabere to jen pár vteřin. Nastavení formátu pro video i audio nechte implicitní "Kopie". Pro nahrávku bez reklam uvnitř stačí označit začátek a konec a pak uložit. Pokud jsou reklamy během nahrávky, označte začátek a konec reklamního bloku a ten vymažte. Někdy je to trochu piplačka, když chcete, aby záběry před reklamou a po reklamě na sebe plynule navazovaly. Při tom se často stane, že odstraníte klíčový snímek, od něhož se vždycky odvíjí kousek nahrávky. V takovém případě budete při ukládání dotázáni, jestli chcete použít tzv. "Smart copy". Odsohlaste a nechte defaultní parametr.

Namísto vystřihávání reklam můžete taky postupovat tak, že si uložíte jednotlivé části bez reklam, což se dá většinou udělat tak, aby začínaly klíčovým snímkem. Pro spojení jednotlivých částí pak lze použít mencoder:

mencoder -oac copy -ovc copy -o Film.avi F1.avi F2.avi F3.avi

To by mohlo být k videu zruba všechno, příště napíšu něco o zpracování audia.

       

Komentáře

[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