Sedmero pozastavení na cestě od DVB k MPEG-4

22.1.2007 12:35 | Přečteno: 3928× | Mohlo by se někomu hodit

Pozor, dlouhý zápisek! Koho zajímá, jak s pomocí mencoderu kóduji nahrané filmy z televize, nechť čte dále, ale byl varován

Pozastavení první: důvody

Proč se do konverze pouštět:

• Optimalizace velikosti výsledného videa – jako naschvál mají nahrané celovečerní filmy velikost obvykle v rozmezí 2,3–2,7 GB, což znamená, že se dva filmy na jedno DVD nevejdou a uložení jen jednoho mi přeci jen přijde jako plýtvání místem.
• Vylepšení kvality obrazu – digitální televize v plné nahotě ukazuje propastný rozdíl v kvalitě obrazu starších filmů z televizních archívů a současných pořadů – souslovím starší film přitom rozhodně nemyslím jen černobílý pořad pro pamětníky, směle sem lze zařadit téměř cokoliv z minulého století. Obraz je dost často rozmazaný a zašuměný s velkými černými okraji. Troufám si tvrdit, že aplikací vhodných filtrů lze ve výsledku dosáhnout znatelně lepšího obrazu než v originále.
• Vyřešení některých problémů s formátem MPEG-2 – hlavním důvodem, proč jsem se konverzí začal zabývat, je neschonost mého stolního přehrávače přehrát širokoúhlý MPEG-2 se správným poměrem stran, zatímco MPEG-4 zvládá bez problémů. Zvláštní, že? Do této kategorie též spadá vyřešení problému s duálním vysíláním.
• Touha naučit se něco nového – k tomu snad není třeba nic dodávat.

Pozastavení druhé: pacient a skalpel

Na vstupu konverze se očekává jednolitý videosoubor v MPEG-2, který již prošel odtučňovací kůrou v podobě vymazání reklam v programu dvbcut. Pro konverzi videa jsem si zvolil mencoder a jakožto pomocný nástroj Avidemux.
Jistě, Avidemux lze použít i pro samotnou konverzi, v současné verzi však stále má jistá omezení (například nelze nastavit poměr stran videa) a pro vzdálená spouštění na serveru se taky zrovna nehodí. Program tedy používám zejména pro odladění filtrů, které na záznam hodlám použít, a pro výpočet bitové šířky při požadované velikosti výsledného videa.

Poznámka: Pro výpočet bitrate je nutno znát délku videa, kterou ovšem z uloženého televizního záznamu (zejména pak u formátu MPEG-TS) můžete v přehrávači pouze odhadovat – není neobvyklé, že v tomto světě jedna sekunda ve skutečnosti znamená sekundy hned tři. Pro přesné zjištění délky pořadu je tedy dobré spolehnout se na editor, který si nad videosouborem vytvoří pomocný index.

Avidemux se také hodí pro hledání snímků vhodných ke střihu v případech, kdy se rozhodnu výsledné video rozdělit do dvou či více souborů.

Pozastavení třetí: kabátek

S ohledem na schopnosti stolního přehrávače jsem vsadil na jistotu omšelého kontejneru AVI, do kterého vkládám video ve formátu MPEG-4 a zvuk obvykle originální MPEG-1 layer 2 kódovaný se 192kb šířkou, případně překódovaný layer 3 s 96 či 128kb šířkou. Někdo může oprávněně namítnout, že kódování z MP2 do MP3 sníží kvality zvuku za cenu nepatrných pár ušetřených megabajtů, subjektivně však ve výsledku žádný rozdíl neslyším a ušetřených 50 MB na 700 MB pro video zase tak nepatrné číslo není.
Kódování zajišťuje knihovna libavcodec (neb jak říká nápověda „best quality!“), FourCC ovšem nastavuji na hodnotu DX50. Nikoho také nepochybně nepřekvapí dvouprůchodové kódování obrazu, oproti jedinému průchodu je kvalitativní nárůst jasně viditelný, zatímco více průchodů pro mne znamená akorát ztrátu času, neboť už v tom žádný posun v kvalitě nevidím.
Samotné kódování spouštím pomocí skriptu, který si podle potřeby upravuji a který vypadá přibližně takto (dlouhé řádky jsou rozděleny):

#/bin/sh
#

INPUT=$1
VIDEO_OPT=" -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1356: \
 vmax_b_frames=2:mbd=2:v4mv:aspect=16/9:dia=2:trell:cbp:mv0: \
 vlelim=-4:vcelim=7:lumi_mask=0.1:dark_mask=0.1:vpass="
MISC_OPT=" -vf crop=702:574:8:2,scale=560:448 -sws 10 -ssf cs=10 \
 -ffourcc DX50 -passlogfile ${INPUT%%.mpg}.log -ss 0 -frames 93874"

mencoder -oac copy -o /dev/null ${VIDEO_OPT}1  $MISC_OPT $INPUT
sleep 1
mencoder -oac mp3lame -lameopts abr:br=96 \
 ${VIDEO_OPT}2  $MISC_OPT $INPUT -o ${INPUT%%.mpg}.avi

Pozastavení čtvrté: velikost výsledku

Při snaze optimalizovat výslednou kvalitu videa v závislosti na bitové šířce, očekávané velikosti souboru a rozlišení obrazu je dobrým vodítkem hodnota udávající, kolik bitů se průměrně spotřebuje na jeden obrazový bod (bits per pixel). Někde jsem četl, že rozumný rozsah hodnot je 0,5–1,0 pro MPEG-2 a 0,2–0,5 pro MPEG-4. Jenomže co dělat, když originální televizní vysílání má tuto hodnotu necelých 0,3 b/px?
Několik experimentů mě přesvědčilo, že hodnota 0,2 pro MPEG-4 je hodně dobrá a 0,15 ještě uspokojivá. Pokud však chci takovýchto hodnot dosáhnout a zároveň snížit velikost videosouboru o více jak polovinu, nezbývá mi, než také zmenšovat rozlišení obrazu. V závislosti na tom, jak který nahraný pořad je pro mne cenný, zmenšuji velikost souboru na polovinu až čtvrtinu původní velikosti a zároveň snižuji výšku obrazu na (obvykle) jednu z hodnot 512, 448 a 384 (viz filtr scale). Schválně píšu výšku, neboť obvykle je třeba ořezat černé okraje u obrazu nalevo a napravo (viz filtr crop), čímž se šířka stává více proměnlivou. Navíc může být zobrazovaná šířka přepočítaná v závislosti na udávaném poměru stran.
Vzhledem k již zmíněné časté nevalné kvalitě vysílaného obrazu zmenšení rozlišení výsledek nijak významně nedegraduje, navíc s sebou přináší tu výhodu, že nemusím řešit odstranění prokládání (deinterlace). Základem úspěchu je však použití dobrého algoritmu pro škálování obrazu – mencoder jich prostřednictvím parametru -sws nabízí hned jedenáct, jejichž kvalita se navzájem liší velmi výrazně. Rozdíly jsou patrné v efektu kostičkování obrazu, ostrosti hran a vyplnění jednobarevných ploch (patrné například u titulků); po otestování všech typů mi nejlepší výsledek dal typ 9 (lanczos) a 10 (přirozený bikubický spline). Rozmazanému obrazu aspoň trošku pomůže lehké doostření pomocí parametru -ssf.

Pozastavení páté: kvalita kódování

Musím se přiznat, že většině parametrů, které v mém skriptu následují za -lavcopts, nijak zvlášť nerozumím – obecně by měly zlepšovat výslednou kvalitu obrazu a jsou opsány z nápovědy a nejrůznějších internetových útržků. Mé povědomí o nich je tedy následující:

• vmax_b_frames – nejsem nepřítelem B-snímků, pokud je obsahuje i původní vysílaný proud, proč by je nemohl mít i zkonvertovaný výsledek?
• mbd, v4mv, mv0 – úprava kódování makrobloku
• dia, trell, cbp – hledání závislostí v obraze
• vlelim, vcelim – potlačování součinitele jasové a barevné složky podle dopručení
• lumi_mask, dark_mask – maskování detailů ve světlých a tmavých částech obrazu
• aspect – pokud rozlišení obrazu neodpovídá poměru stran obrazu (typické pro širokoúhlé televizní vysílání), je nutno správný poměr stran nastavit ručně; v opačném případě je vhodné použití parametru autoaspect

Rychlost kódování se na 3GHz procesoru pohybuje v rozmezí 10–20 snímků za sekundu; možná mám v nastavení nějakou zbytečnou brzdu, které si ovšem nejsem vědom.

Pozastavení šesté: filtry

Ze začátku zápisu se zmiňuji o vylepšení nekvalitního obrazu s pomocí filtrů. Možná poněkud překvapivě není mou hlavní zbraní pro odstranění šumu filtr denoise3d ani jeho vylepšená varianta hqdn3d, ale Gaussovo rozostření unsharp. Filtr aplikuji pouze na jasovou složku obrazu, velikost matice zadávám 3x3 a nakonec doostřuji kladným číslem okolo hodnoty 0,5 – plný zápis filtru tak vypadá následovně: unsharp=l3x3:0.5.
V jednom případě – u filmu Stvoření světa – jsem též docenil kvality filtru MSmooth, který s animovaným záznamem umí hotové zázraky. Konverzi jsem však v tomto případě dělal v Avidemux, neboť u mencoderu jsem jej v seznamu filtrů nenašel.

Pozastavení sedmé: drobnosti

Starší verze mencoderu se občas zasekly při začátku druhého průchodu s chybovou hláškou týkající se generování křivky, upgrade na rc1 toto vyřešil.
Zařízení /dev/null je skvělé úložiště pro výstup prvního průchodu konverze.
Rozdělení videa na více částí zajistí parametry -ss a -frames, které udávají počáteční čas a počet snímků ke konverzi; každá část videa se tak kóduje zvlášť, vhodné hodnoty k těmto parametrům pomůže najít Avidemux.
Stejně ale asi budu muset investovat do koupě dalšího pevného disku ...

       

Komentáře

[David Ježek]

FourCC ovšem nastavuji na hodnotu DX50

proc tam nedat treba xvid? mas nejaky konkretni duvod proc zrovna fourcc DivXu5?

kódovaný se 192kb šířkou v závislosti na bitové šířce

Jaka sirka? nejak to slovo nechapu, to o cem mluvis je totiz tzv "datovy tok" alias "bitrate".

jednu z hodnot 512, 448 a 384 ... že nemusím řešit odstranění prokládání

deinterlaci musis imho resit pokazde, pokud zdroj a) nebyl progressive a za b) resizujes na neco jineho nez "halfPAL"

nejsem nepřítelem B-snímků

nejaky duvod proc byt nepritelem B-snimku? ja osobne jsem treba jejich velkym pritelem, byt maji nevyhody plynouci z jejich definice.

jinak povidani pekne.

[Jiří Poláček]

FourCC ovšem nastavuji na hodnotu DX50

proc tam nedat treba xvid? mas nejaky konkretni duvod proc zrovna fourcc DivXu5?

Nemám. Existuje nějaký důvod, proč tam dávat zrovna XVID?

kódovaný se 192kb šířkou v závislosti na bitové šířce

Jaka sirka? nejak to slovo nechapu, to o cem mluvis je totiz tzv "datovy tok" alias "bitrate".

Pravda, nevhodný překlad. Někde jsem jej zahlédl a nechal jsem se zmást.

jednu z hodnot 512, 448 a 384 ... že nemusím řešit odstranění prokládání

deinterlaci musis imho resit pokazde, pokud zdroj a) nebyl progressive a za b) resizujes na neco jineho nez "halfPAL"

Subjektivně vnímám jen zmenšený obraz a obraz s odstraněným prokládáním následně zmenšený jako dva stejné výsledky, takže se tím nezabývám.

nejsem nepřítelem B-snímků

nejaky duvod proc byt nepritelem B-snimku? ja osobne jsem treba jejich velkym pritelem, byt maji nevyhody plynouci z jejich definice.

Nevím, zdá se, že jsou tací mezi námi ...

[zde]

Přemejšlím že bych taky naskočil do vlaku, ale nemůžu se rozhodnout, která varianta je lepší:

a) K televizi obyčejný levný STB (Třeba digipal 2) + PCI karta do PC.
+ cena
+ snadné zpracování dat na PC
- nutnost mít zapnuté PC (spotřeba)
- horší komfort obsluhy (chybí věci jako nahrávání jedním tlačítkem, timeshifting, atd)

b) Koupit STB s HDD a dvěma tunery.
+ snadná obsluha
+ nízká spotřeba
- cena (cca 8k+ za Sencor SHR 9116T)
- nutnost data do PC nosit přes DVD-RW

c) ???

[Jiří Poláček]

Karta PCI má pro mne tu výhodu, že mohu programovat nahrávání vzdáleně po Inetu (wakeonlan, ssh, vlc, shutdown).

[Josef Kufner]

man at

[Lu-Tze]

jednoznačně b) ale takový, který má buď USB (něco jako tenhle ale ne Mascom ) nebo s ethernetem (viděl jsem takový, byl postavený na linuxu, teď ho nemůžu najít)

já bych určitě nekoupil jiný než s podporou pro přenos z i do stb...

[zde]

USB obvykle moc nefunguje. Tomu s Linuxem se tuším říká Dreambox, ale je to dost drahé a hlavně nepříliš user friendly. U Sencora je přenos dat díky vestavěné DVD vypalovačce bezproblémový, ovšem nejsem si jistý jestli nahrávání z DVB neprobíhá přes analogovou cestu. Nikde jsem se to nedočetl, ale protože je to velmi levné, a protože tam jdou nastavovat různé úrovně "komprese", tak by mě to bohužel nepřekvapilo..

[zde]

Nikoho také nepochybně nepřekvapí dvouprůchodové kódování obrazu, oproti jedinému průchodu je kvalitativní nárůst jasně viditelný, zatímco více průchodů pro mne znamená akorát ztrátu času, neboť už v tom žádný posun v kvalitě nevidím.

Proč by dvouprůchodové kódování mělo přinést vyšší kvalitu? Pokud jsem omezen velikostí výsledku tak samozřejmě musím volit buď konstantní průměrný bitrate (což souhlasím je neefektivní), nebo dva průchody (což zase dlouho trvá). Ale pokud mne víc než velikost výsledku zajímá jeho kvalita, proč nepoužít jednoprůchodové kódování s předem odhadnutým vqscale? Oč to bude horší než 2-pass?

[Jiří Poláček]

Nevím, nikdy jsem to nepoužil.

[Spike]

Přesnější by asi bylo uvést, že více průchodů zajistí optimální distribuci bitrate, který je k dispozici. Jinak řečeno nejvyšší možná kvalita pro kýženou výslednou velikost.

[zde]

Co je to kýžená výsledná velikost?

[Spike]

Požadovaná konečná velikost podle aktuální potřeby, řekl bych. Nebo tady někomu dělá problémy čeština?

[zde]

> Požadovaná konečná velikost podle aktuální potřeby, řekl bych.

Co myslíte "aktuální potřebou"? To jako film z DVD zkomprimujete nejprve (dvěma průchody, samozřejmě) na 700MB, pak zjistíte že je to nekoukatelné, tak to dalšími dvěma průchody uděláte znovu na 1400MB? Proč používat 4 průchody místo jednoho?

Mě je jedno jestli bude video mít 500MB nebo 900MB, pokud to bude koukatelné a pokud budu vědět že bitíky jsou alokovány optimálně (vyšší bitrate pro světlé a akční scény, menší pro tmavé apod).

> Nebo tady někomu dělá problémy čeština?

Bude to jinde.