Archivujeme televizní pořady
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 0x47, 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:
- V Project-X mám nastaveno, aby při exportování vytvořil adresář s demultiplexovanými stopami.
- Do tohoto adresáře nakopíruji zmíněný skript.
- Skript upravím podle parametrů aktuálního pořadu (především poměr stran a prokládání).
- 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!
Vše z Blog Root.cz
Hezké, jen by mě zajímalo, proč zvuk znovu komprimuješ - to je AAC o tolik kvalitnější než ten MPEG-1 layer 2 (nebo co to vlastně je v našich DVB-T multiplexech), že se vyplatí dělat nad tím další ztrátovou kompresi?
Ano, kodek AAC by měl být účinnější než MP3, které by zase mělo být účinnější než MP2, přinejmenším na nízkých bitových tocích.
Je pravda, že úspora, které se tím dosáhne, je kolem 100kbps, tedy nic zásadního. Na druhou stranu, z mých drobných poslechových testů vyplynulo, že rekomprese nevede ke (pro mě) slyšitelnému zhoršení kvality. Kromě toho ocením normalizaci, protože televizní stanice mají ve zvyku vysílat zvukový doprovod s patnáctibitovým měřítkem, a komerční ještě obvykle vysílají filmy o další 2dB potišeji, asi aby vynikly reklamy.
Dík za zajímavý zápisek. Sice s ním spíše nesouhlasím, ale je to minimálně dobré téma k diskusi.
Záznam: K tomu asi není moc co dodat. DVBgrab jsem neznal a může to být zajímavé. Určitě vyzkouším.
Střih: Project-X je docela klasika. Par let jsem ten program nepoužil, ale zde mi docela silně vadila neschopnost ořezat s přesností na snímky. Navíc nevidím důvod se babrat s nějakým děleném na obrazovou a zvukovou stopu. Včera jsem nahrával z TV po několika letech a zpracování TS mne teprve čeká, ale v minulosti se mi silně osvědčil DVBcut. Tento program má bohužel poslední verzi z dubna 2007, ale funkčně vyhovoval. Video mezi klíčovými snímky také kopíroval beze změn a tam kde došlo k střihu mezi nimi, tak to přepočítal. Přijde mi to jako menší zlo, než tam mít něco navíc, nebo naopak nemít.
Převod do MPEG AVC a AAC: Na to mužů říct jen jediné. Proboha proč? Nahrál jsem si včerejší 12h blok Retrománie z ČT24 a těch 12h má nějakých 17.2GB, pokud se dobře pamatuji. Maximálně to ořežu, ale nevidím důvod s tím cokoliv jiného dělat. Schválně jsem namátkově koul do Alzy na disky s nejlepším poměrem cena/kapacita a když to to uložím na 1.5TB Samsung, tak to bude stát 18.25 Kč a na 2TB 18.5 Kč To je míň, než kolik stojí lahvová Plzěn. Když to budu encodovat do něčeho jiného, tak se možná dostanu na třetinu, čtvrtinu velikosti, ale zabiji si tím na den počítač a takhle si můžu být jisty, že to mám v maximálně kvalitě, co jsem z toho mohl vytřískat. Tohle mělo IMHO smysl v dobách analogu, kdy se video do nějakého komprimovaného formátu uložit stejně musel a cena za 1GB byla vyšší. Navíc dnes už je jen minimum věcí, které se vyplatí nahrávat z TV. Na netu jsou HD ripy dřív, než daný materiál se k nám dostane do TV a u toho zbytku to IMHO nemá smysl řešit.
[3] V podstatě souhlasím. Střih v DVB-cut jsem zkoušel, bohužel jsem několikrát narazil. Například pokud jsem střihnul jeden snímek před I snímkem, DVB-cut zřejmě vyrobil GOP o jednom snímku a s takovým MPEG-streamem mi některé programy − už nepamatuji si které − přestaly správně fungovat. Teď se k tomu přidalo to, že jako Qt3 aplikace mi to už nejde zkompilovat
Transkódovat nebo ne, to je otázka k zamyšlení. Já sám pro sebe dospěl k přesvědčení, že dostat to na pětinovou velikost a přitom vyřešit problém s tichým zvukem a zubatým obrazem (obvykle používám mplayer a zapomenu ručně zapnout de-interlacing), přitom bez pozorovatelné ztráty kvality, mi za to stojí.
Cenově to ale vyjde nejspíš nastejno, když započítáme cenu elektřiny za kódování
> od skutečného začátku do skutečného konce pořadu
co to znamená? já jsem si všiml, že stolní rekordéry často nepoznají začátek a konec přesně (asi kvůli nepřesnostem v EPG, protože třeba nestihnou v televizi o minutu vysílací program a pak jsou časy rozhozený) - a to i v případě, že nechám rekordér nastavit čas "automaticky" (počítám že dvb-t má v sobě nějaký systém seřizování hodin). vždycky jsem myslel, že to bude fungovat tak, že televize bude vysílat spolu se streamem taky kod programu a rekorder ho pozna, ale mam dojem ze cely EPG proste stoji a pada s tim ze je predem znamy cas vysilani (dokonce i informace o prave vysilanem poradu je casto chybna, tedy se domnivam ze i to je reseno na zaklade casovych udaju). Opravdu nechapu, jestli by bylo tak tezke priradit kazdemu poradu nejake cislo a vysilat ho spolu s obrazem (serialy by mohly mit prefix, aby bylo mozny nahrat serial kompletne). tusim ze v zahranici to umely i analogovy videorekordery.
[5 ]Technicky by to asi problém nebyl, ale nezapomínej, že TV žije z reklamy. TV stanice potřebují, aby si u pořadu seděl (od nouze nahrával) 10 minut předem, aby si nezmeškal počátek.
convx264.sh: řádek 61: normalize: příkaz nenalezen
Normalize je odkud/součástí jakého balíku?
nm, našel jsem to a upravil ten skript (nainstaloval normalize-audio a nahradil normalize normalize-audio)
[5] Tím jsem myslel, že se záznam spustí v návaznosti na kód VPS/PDC, který ČT (a jenom ČT) vysílá jako součást VBI streamu (teletextu).
DVB specifikace s přesným nahráváním počítá tak trochu. V EIT tabulkách, kde se přenáší EPG data, je u každého pořadu i jedna kolonka, označená jako „Running Status,“ podle které by mělo být možné řídit domácí rekordéry. Bohužel, žádný komerční domácí rekordér, o kterém vím, hodnotu tohoto pole nebere v potaz a nahrává pouze podle anoncovaného času.
Zlé jazyky tvrdí, že je to proto, že výrobci spotřební elektroniky jsou zadobře s filmovými studii, které jsou zase zadobře s televizními společnostmi. To vede k začarovanému kruhu, TV společnosti i při nejlepší vůli argumentují tím, že nemá cenu něco takového vysílat, když to spotřebiče nepodporují a výrobci spotřebičů to neimplementují, protože to TV společnosti nevysílají.
[7] Na gentoo se ten balík jmenuje media-sound/normalize
Zajímavé, hlavně to VPS opět.
Děkuji.
Mi se ale stávalo, že, než bych si chtěl něco nahrát, jsem se dostal do situace, kdy mi někdo řekl "viděl jsi to a to? včera to bylo na ČT2 večer...". A já to neviděl, že. Takže jsem sehnal 3 Yakumo DVB-T sticky, na volný disk, co se mi tu válel, ukládám cyklicky všechny 3 muxy (dvbstream) a případně si zpětně vykopíruji, co potřebuji. K dispozici mám od 24-48 hodin vysílání DVB-T zpětně. Je to sice kolem 30 GiB za hodinu (20-24 Mibps na mux), ale to už dnes není problém.
Problém je teď, že spíše sloužím jako poskytovatel "hele, ty určitě máš to, jak včera odpoledne bylo..." ostatním. :-/
No, jinak ještě používám utilitku ts2vob, která také opravuje vypadnuté snímku. (Příklad použití: dvbstream -c 0 -o -f 730000000 -v 257 -a 273 -t 289 | vpsrecord -p 289 -t 23:45 | ts2vob -v 6000000 > /tmp/stastnych_deset.mpeg)
"viděl jsi to a to? včera to bylo na ČT2 večer..."
Takuto sluzbu ponuka slovensky orange. Vola sa to "TV archiv". Nahravaju sa tam vsetky zaujimave stanice 7 dni dozadu.
Nahrava sa to na ich servre.
http://www.orange.sk/web/fibertv/fibertv_archiv.html
[6.] No to je mi celkem jedno, kdyz oznaci reklamu jako porad ktery si chci nahrat, ale vadi mi kdyz se mi nahraje konec jinyho poradu, reklama, ale pak uz se treba nenahraje konec filmu (frustrace z toho ze nevim, jestli prezil di caprio v titaniku je predpokladam pochopitelna), nebo naopak se nahraje zacatek dalsiho poradu, ale nenahraje se zacatek myho filmu (a ja pak vubec nevim, jak se neo dostal za zrcadlo).
kdyby se mi nahrala reklama, tak mi to nevadi. Jednak protoze si ji stejne pretocim, nebo dokonce vystrihnu pomoci interniho editoru v prehravaci, ale kdyz se zacne nahravat 5 minut po zacatku filmu, tak se pochopitelne nenahraje ani reklama pred filmem, takze z marketingovyho hlediska to televizni stanici stejne nepomuze.
[11]. Díky za příspěvek, ts2vob jsem neznal. Jsem rád, že někdo další používá můj vpsrecorder
Vyrábět si vlastní archiv TV, to mě taky napadlo, mám v plánu pro ten účel naprogramovat sadu utilitek, co budou v reálném čase stříhat vysílání na krátké TS soubory, které se budou posléze mazat a v případě, že budu chtít nějakou část vysílání zachránit, jednoduše si catnu soubory s časy, které mě zajímají.
Díky za článek, hlavně to stříhání reklam nějak vychytat.
Super clanok,
zaujimalo by ma Vase subjektivne hodnotenie AAC vs AC3 vs ogg vorbis. Predpokladam ze vacsina stanic stale vysiela stereo a stacil by aj vorbis.
[16]. Já se do takových hodnocení nerad pouštím. Jedna věc je porovnat, jaké kodek nabízí metody, druhá věc je, jak dobře jsou na tom dostupné implementace kodeků, a třetí, zcela zásadní věc, jak to celé zní při poslechu.
Nejsem vybaven tak kvalitní technikou, abych mohl třetí kritérium dostatečně posoudit, na posouzení předchozích dvou nejsem dostatečně erudovaný. Takže když zavádím nový kodek, mám v zásadě jediné kritérium - nesmím slyšet kompresní artefakty. A stejně posuzuji i kompresi obrazu. Trochu problém je v tom, že už vstupní obraz z DVB-T vysílání obsahuje občas značné množství artefaktů, které transkódováním nezmizí, je ale důležité aby se neobjevovaly další.
Pro zvuk AAC jsem se rozhodl především v zájmu co největší kompatibility - na rozdíl od Vorbisu jde o industry standard, takže je pravděpodobné, že si s ním poradí i nejrůznější HW přehrávače. Pro plnou konformitu není problém dílčí stopy zabalit místo Matrošky do MP4.
Chci poděkovat autorovi za výborný článek i skript (právě ho testuji). Pídil jsem po možnosti stříhat mpeg-stream aniž bych přišel o skryté titulky. Např. dvbcut, který jsem používal, buď teletext ze streamu vypouští, nebo alespoň informaci o něm. Nasměrování na projectx mi moc pomohlo, protože mám neslyšící ženu a jakékoli informace o zpracování ST "hltám". Zdá se, že je to jediný soft, který dokáže vytáhnout titulky z teletextu. Díky.
Já si filmy ukládám na DVD je to velmi jednoduché.
[19]. Děkuji za velmi podnětný komentář
[20] Trochu si rýpnu: Komu nestačí běžné (za předpokladu kvalitního vstupu DBV-T) m2t nahrávky prostřednictvím frontendů mplayeru či xine třeba na DVD a proč?
Doplním: Je úspora archivačního prostou jediným důvodem pracovat na něčem, co obírá čas na tůrčí činnost?
Kdybyste se někdo setkal s tím, že výstupní soubor má správný obraz, ale přeskakující zvuk, tak je to s velkou pravděpodobností způsobeno tím, že vstupní zvuková stopa obsahuje jak mono, tak stereo data.
Typický příklad je záznam pořadu, kde běží televizní reklama ve stereo a samotný film pak v mono a vy to v ProjectX ustřihnete ještě v té reklamě.
Při demuxování je potřeba před spuštěním toho konverzniho skriptu koukat na log ProjectX, jestli tento řádek se src_audio je tam jenom jednou:
-> adjusting audio at video-timeline
-> src_audio: MPEG-1, Layer2, 48000Hz, mono, 192kbps, CRC @ 00:00:00.000
Pokud je tam ten řádek vícekrát, tak při následné konverzi zvukové stopy z mp2 na wav bude výsledný wav zkreslený a audio stopa nepoužitelná.