Hlavní navigace

Archivujeme televizní pořady

13. 5. 2011 23:30 (aktualizováno) Ondřej Caletka

Digitalizace televizního vysílání s sebou přináší, kromě rozšíření programové nabídky a (povětšinou) zlepšení kvality příjmu, také výrazné zjednodušení pořizování záznamu. Zatímco v případě analogového vysílání bylo nutno vysílání digitalizovat, digitální vysílání stačí pouze ukládat. O to složitější může být najít si čas na přehrání již nahraného záznamu. Zvlášť  po Vánocích.

V dnešním zápisku jsem se proto rozhodl představit způsob, jakým archivuji nahrávky digitálního televizního vysílání tak, aby nezabraly zbytečně mnoho místa při pokud možno zachování původní kvality. Protože archivuji pro vlastní potřebu, necítím se být svázán pravidly releasů warezových skupin, například že dvacetiminutová epizoda ve standardním rozlišení musí zabírat přesně čtvrtinu CD (175 MB) a podobně. Vypalování archívu na optické disky jsem vzdal už dávno; jsou s nimi jen problémy a ve výsledku zaberou mnohem více místa než jeden 3,5" hard disk…

Krok 1 – záznam

Tento krok záznamu nehodlám podrobně popisovat, neboť ten můj je nejspíše velmi odlišný od způsobu, který používají ostatní. K pořizování záznamu používám projekt DVBgrab, víceuživatelský virtuální videorekordér s webovým rozhraním. Ten na základě XMLTV programu generuje televizní program, ve kterém je možno jedním kliknutím označit pořad k nahrání. Pro záznam z vysílání ČT jsem do svého DVBgrabu integroval filtr vpsrecord, díky kterému jsou pořady České Televize zaznamenány přesně od skutečného začátku do skutečného konce pořadu.

V každém případě, ať zvolíte jakýkoli druh záznamu, výsledkem by měl být MPEG2 Transport Stream, uložený v souboru.

Krok 2 – střih a demultiplexování

Záznam ve formátu MPEG-TS je možné bez větších problémů zpětně přehrát všemi majoritními přehrávači. Jde o soubor složený ze 188 bajtů dlouhých paketů, který každý začíná znakem 0×47, ASCII „G“. Již z toho vyplývá, že jde o formát pro archivaci poměrně nevhodný, neboť je neúsporný a postrádá jakýkoli index. Navíc vlivem poruch při příjmu může soubor obsahovat poškozené, nebo chybějící snímky.

Před dalším zpracováním je potřeba záznam demultiplexovat na obrazovou a zvukovou stopu. K tomu se mi  z celé škály možností osvědčil program s názvem Project-X. Načte téměř jakýkoli MPEG-2 soubor a identifikuje v něm proudy obrazu, zvuku a případně i titulků či teletextu. Umožňuje jednoduchý střih na úrovní skupin obrázků (GOP), což v televizním vysílání představuje přibližně 12 − 15 snímků, tedy půl sekundy. Takovým střihem je obvykle nemožné zcela přesně vystřihnout reklamní přestávku, na druhou stranu jde o střih velice rychlý a na rozdíl od jiných snímkově přesných metod, které jsem vyzkoušel, vždy plně funkční.

Při exportu demultiplexovaného obrazu a zvuku se Project-X postará o to, aby byl obraz a zvuk za každou cenu synchronní. Toho dosahuje tak, že ze zvukové stopy odmazává zvukové rámce korespondující s poškozenými obrázky, nebo naopak ztracené zvukové rámce nahrazuje tichými. Jako příjemný bonus, který se uplatní u televizního vysílání a zvláště ČT, je možnost exportování skrytých podtitulků, vysílaných v teletextu, do klasického textového souboru.

Krok 3 – vlastní transkódování

Možností, co dělat s demultiplexovaným zvukem a obrazem, je spousta. Dříve jsem používal velice jednoduchý skriptík pro konverzi do formátu, kterému se obvykle říká DivX, tedy MPEG-4 ASP video, MPEG 1 Layer 3 audio, to celé zabalené v kontejneru OpenDML AVI. Tento formát však má své limity – například předpokládá, že poměr stran pixelů je 1:1, což u televizního vysílání ve standardním rozlišení není splněno…

Protože od éry AVI souborů s DivX kodekem doba drobně pokročila, rozhodl jsem se proces inovovat. Použil jsem moderní kodek MPEG-4 Part 10 (AVC), neboli H.264 pro obraz a k tomu odpovídající MPEG2 AAC pro zvuk. Pouze na pozici kontejneru jsem si dovolil odchýlit se od standardu a použít nestandardní, ale velmi rozšířený kontejner Matroška.

Nakonec jsem napsal skript, používající ffmpeg, normalize a faac pro konverzi zvukové stopy do formátu AAC s normalizací měřítka a mplayer s x264 pro překódování videa. Moje použití vypadá takto:

  1. V Project-X mám nastaveno, aby při exportování vytvořil adresář s demultiplexovanými stopami.
  2. Do tohoto adresáře nakopíruji zmíněný skript.
  3. Skript upravím podle parametrů aktuálního pořadu (především poměr stran a prokládání).
  4. Skript spustím, jako první parametr uvedu společný název souborů se stopami, jako druhý parametr cestu a jméno cílového souboru bez přípony.

Skript nejprve překonvertuje zvukovou stopu, poté spustí konverzi videa. Při mých testech se ukázalo, že není nutné používat dvouprůchodové kódování, zvlášť pokud netrváme na dodržení přesné velikosti výsledného souboru. Na samý závěr je obraz a zvuk multiplexován do výsledného kontejneru a to i s případnými skrytými titulky, které Matroška umí nastavit skutečně jako skryté (tedy že se objeví až po explicitním zapnutí).

Pokud zdrojový obraz obsahuje artefakty prokládání řádků, je pro jejich odstranění použit filtr yadif z mplayera, který dlouhodobě hodnotím jako nejlepší deinterlace filtr na poli open source. Je nutné poznamenat, že takovéto použití deinterlace filtru se nehodí pro sportovní přenosy s rychlými pohyby. V takovém případě by bylo vhodné použít variantu filtru yadif, která zdvojnásobuje snímkovou rychlost. Vyzkoušel jsem, že takové zvýšení způsobí při stejném faktoru kvality nárůst velikosti výsledného souboru o dvě třetiny, což mi připadá neúměrně mnoho. Protože sportovní přenosy nezaznamenávám, výzkum jsem na tomto místě přerušil a spokojil se s 25 snímky za sekundu.

Poznámka o poměru stran

Na tomto místě si dovolím malou poznámku o poměru stran obrazu, neboť se v tom často chybuje. Informace o poměru stran 4:3 nebo 16:9 totiž platí pro analogovou televizi. Jelikož ta digitální vznikla digitalizací analogové, bylo potřeba zaručit, že v digitálním obraze bude určitě všechno, co je v analogu. Proto digitalizací vznikne obraz poněkud širší. V případě PALu se poměr stran 4:3 nebo 16:9 vztahuje k horizontálnímu rozměru cca. 702,9 pixelu, nikoli k celé šířce obrazu 720. Protože počet pixelů nemůže být neceločíselný, zaokrouhluje se tato hodnota na 704 pixelů. Ideální digitalizovaný obraz tedy je zleva i zprava o osm pixelů širší, tyto pixely by měly být černé. V reálném případě je obraz obvykle posunut k některé straně, nebo klidně vyplňuje celou šířku 720 pixelů. Pak je jeho reálný poměr stran širší než 4:3 a 16:9.

Mnoho programů pracujících s videem, včetně např. mplayera, nebo VLC, tento fakt ignoruje a obraz 720×576 škáluje na 768×576 v případě 4:3 a 1024×576 v případě 16:9. Dochází tím k drobnému poškození proporcí obrazu, takové poškození je však jen těžko měřitelné a ještě hůře pozorovatelné člověkem.

Vzhledem k tomu, že můj skript nemění velikost obrazu, je rozhodnutí o výsledném poměru stran pouze nastavením metainformace o poměru stran pixelů. Nejběžnější varianty jsou vypsány přímo ve skriptu v tabulce, a každý nechť se rozhodne mezi tím, co je snadné (SAR1) a tím, co je správné (SAR2). Případně můžeme doplnit ještě hodnoty, které by odpovídaly úplně správnému poměru stran – takovému, který bere jako základ šířku 702,9 pixelů (SAR3)

##  DAR -  SAR1 -  SAR2 -   SAR3
## 16:9 - 64:45 - 16:11 - 118:81
##  4:3 - 16:15 - 12:11 -  59:54

Pro podrobnější studium doporučuji například článek zde, nebo na Wikipedii.

Závěr

Popsal jsem jeden z možných postupů, jak jednoduše archivovat televizní pořady. Díky použití standardizovaných kodeků by výsledný záznam měl být bez větších problémů přehratelný i na nejrůznějších hardwarových MPEG-4 přehrávačích. Použitím skriptovacích jazyků je možné postup zautomatizovat do té míry, že je jeho použití jednodušší, než shánění nelegálně zveřejněných TV-ripů na warezových fórech.

Přeji všem čtenářům, kteří dočetli až sem, vše nejlepší v roce 2011!

Sdílet