Velké množství klíčových snímků v českém DVB-T

[Pavel-original]

Tak zdá se že ne. To je z HB?

[Jan Polášek]

Díky Štěpáne za nahrávky! prozkoumal jsem to, a zjistil jsem, že program BR používá GOP 12 snímků, BR alfa a HR jak kdy, většinou 12, ale jsou tam občas i GOPY, co mají 9 nebo 15 snímků. ZDF má vždycky GOP 15 snímků, takže je to mírně víc, než se používá v ČR, ale rozhodně ne 2 vteřiny a víc. řekl bych, že Pavel-original použil na zkoumání nahrávku, která byla už překomprimovaná do Xvidu nebo něčeho podobného, tam je tak dlouhý interval mezi klíčovými snímky normální, ale u MPEG-2 jsem nikdy neviděl GOP delší než právě těch zmiňovaných 15 snímků

[ladik 12]

Tak treba Nova na satelitu, film Duch 7.5.2010, resp. reklamy pred zacatkem filmu:

PVAStrumento 2.1.0.17
running at 05-18-2010 11:25

Pre-Scanning input. May take some time.
Stream info for
Z:\movie\Duch\Nova - Duch - 07_05_10.ts

Found 1 video stream.
Found 1 MPEG audio stream.

VIDEO #1
   Resolution 720 x 576 (full D1)
   Aspect ratio is 16:9
   Frame rate 25.00 fps
   Nominal bitrate 15000000 bps
   First PTS: 17:59:28.507

MPEG AUDIO #1
   MPEG1, Layer 2
   stereo, sampled at 48.0 kHz.
   Bitrate 192 kbps
   Each frame contains 24.0 ms audio (576 bytes)
   First PTS: 17:59:28.023

     
<<DEMUXING>>
      Input: Z:\movie\Duch\Nova - Duch - 07_05_10.ts
      Options
      .. fixing startup delay.
      .. fixing stream synch.
      .. keeping track of audio offset accumulation.
      .. strict checking of audio framing.
      .. falling back to relaxed semantics on TS
      .. ignoring size of GOPs
      .. splitting on change of video format.
      .. splitting on change of audio format.
      .. splitting on number of audio tracks.
      .. clearing CDF
      .. creating new GOP timecodes.
       
      Closing starting GOP.
      Aiming for sync at 17:59:28.507
      Cutting audio.
      Audio stream 1 now starts at 17:59:28.503
      Video stream 1 now starts at 17:59:28.507
      [ Found a GOP with more than 15 pics.
        This is not DVD compliant, but many players accept it.
        See summary for total number at end. ]
      New MPEG video : Z:\Nova - Duch - 07_05_10_00.m2v
      New MPEG audio : Z:\Nova - Duch - 07_05_10_00 - DELAY -3ms.mp2
      Video Format changed at 18:10:07.347
      Splitting output.
      Last fileset:
         198015092 total bytes written
         Video 1: 15969 frames, 00:10:38.760
         Audio 1: 26613 frames, 00:10:38.712
     
      Sync estimate at EOF:
          MPEG Audio #1 : 50 ms before video
     
      Video statistics
      ================
         GOP length (min/avg/max):
                   1 / 28 / 45  [frames]
                   9942 / 323761 / 982802  [Bytes]
         GOP bitrate (min/avg/max):
                   533 / 2302 / 7700 [kbps]

[Steve N]

Přikládám analýzu ukázek DVB-T. Nikde není GOP delší než 18 snímků. Datový tok je ale dost nízký na "německou kvalitu". Pro srovnání přikládám info ze satelitní distribuce ARD, kde jsou přibližně stejně dlouhé GOPy, ale více než dvojnásobný datový tok.

[Jan Polášek]

no já sem si ty transportní toky demuxoval v projectx do mpeg2 a to sem prohlížel ve virtualdubu. demux v projectx podle mně teda GOPy nezkracuje, že by dopočítával klíčové snímky, to těžko. při demuxu akorát vykuchá z TS data a udělá z nich mpeg soubor. navíc demux probíhá tak rychle, že pochybuju, že by se něco přepočítávalo

[ivovi]

Prikladam neco ze svoji zahradky :-):
1) CZ Mux1 GOP 12 (IBBPBBP..)
2) CZ Mux2 GOP 12 a take 9,15,18 (IBBPBBP..)
3) CZ Mux3 GOP 30 (IBBPBBP..) nebo GOP 30 (IPPPPPP)??
4) CZ Mux4 GOP 15 (IPPPPPP..)?? nebo GOP 12az33 (IPPPPPP.. a IBBPBBP..)??
5) 2008/11 CZ Mux1 GOP 34-36 (IBPBPBP..)!! znalci tehda tvrdili, ze GOP az 84!!
6) DE BerlinMux1(WDR/SWR/HSE24/Tele5) GOP 9/12/15 nekdy az27 (IBBPBBP..)

Nejsem odbornik pres kompresi, ale mam za to, ze neni az tak dulezity pocet GOPu,
ale to jak je koder nastaveny a jak tu delku GOPu a posloupnost snimku zvlada.

Tu ostudu CT mam jen v MPG, ale je to autenticky zaznam bez rekomprese.
Je tam videt povestny efekt "dychani" (diskuzi mozno najit v historii DZ pres google).

Mimochodem, vsiml jsem si ze na O2Info STB Digipal2 "kokta-kostickuje". Ocko
pritom bez problemu a O2Info na jinych STB taky bez problemu. TV Sony zase
O2Info strasne dlouho nacita, nez zacne prehravat. Mozna to taky souvisi s
delkou GOPu nebo posloupnosti snimku, ze by vadil GOP30 IPPPP?

[Pavel-original]

řekl bych, že Pavel-original použil na zkoumání nahrávku, která byla už překomprimovaná do Xvidu nebo něčeho podobného,

Nejsem idiot. Ale je pravda že je to už delší doba, možná to změnili, jako u ČT, jak někdo píše.

ivovi: Ano, blikalo to, máte pravdu. Ale to musel to muselo být použitým enkodérem. Normálně nic nedýchá ať to nastavíte vzdálenost snímků jakkoli, není k tomu důvod.

[Jan Polášek]

no podle vzdálenosti klíčových snímků mně to tak připadalo, v divX se běžně používá interval třeba 150 snímků mezi klíčovými, i víc, záleží na nastavení. u mpeg2 jsem se s tím osobně nesetkal, ale když vás to píše tolik, tak budu věřit :-)
Štěpáne, DivX i XviD umí bez problémů rozlišení 720 x 576, umí dokonce i full HD, aspoň teda Xvid, DivX už dlouho nepoužívám. program Dr. Divx neznám, ale asi to nebude nic moc. pro kompresi a další upravy videa doporučuju VirtualDubMod, je to skvělý program, má spoustu možností, ovládání není složité a je zdarma, opensource. umí pracovat se všemi kodeky v systému

[Ondřej Caletka]

Já si myslím, že kolem 15 snímků na GOP je optimální. A neříkám to jen proto, že většinu nahrávek z TV stříhám pro jednoduchost po I-snímkách (a stačí mi to), ale i proto, že půl sekundy na přepnutí programu vidím jako optimální čekací dobu.

[Pavel-original]

pro kompresi a další upravy videa doporučuju VirtualDubMod, je to skvělý program, má spoustu možností, ovládání není složité a je zdarma, opensource. umí pracovat se všemi kodeky v systému

Pokud nepotřebujete upravovat obraz tak možná. Ale jakmile potřebujete jakékoli úpravy, je zoufale nekvalitní, protože vše provádí jedině v 8 bit RGB. (pokud se za posledních pár let něco nezměnilo) Jen převodem do RGB a zpět přijdete tak o půlku barevných odstínů. A ne všechny kodeky fungují, třeba x264 v něm nejde.

[Jan Polášek]

no a vkolika bitech barevné hloubky se vysílá v DVB? podle mně teda v 8 bitech na barevný kanál, takže je to uplně jedno, nikdy jsem zhoršení barev nepozoroval. a x264 ve Virtualdubu funguje

[Ondřej Caletka]

no a vkolika bitech barevné hloubky se vysílá v DVB? podle mně teda v 8 bitech na barevný kanál

V zásadě ano, ale jde o barevné kanály YUV, a navíc je vzorkovací kmitočet složek U a V snížen na čtvrtinu (4:2:0).

Převod do RGB a zase zpět může obraz poškodit, zejména kvantizačním šumem.

[Pavel-original]

no a vkolika bitech barevné hloubky se vysílá v DVB? podle mně teda v 8 bitech na barevný kanál, takže je to uplně jedno, nikdy jsem zhoršení barev nepozoroval. a x264 ve Virtualdubu funguje

V osmi, ale YCbCr. To má sice o něco nižší počet odstínů, (protože některé kombinace nejsou použitelné) ale jsou jinak rozmístěné než u RGB. Na počítači rozdíl možná neuvidíte, protože to zase převede na 8bitů RGB. I když snad všechny novější karty používají dithering z více bitů. Dobře je to vidět na jednolitých plochách. (anglicky se tomu říká "banding") Spousta lidí to považuje za kompresní artefakt, ale problém je v počtu barev. Komprese to jen zhorší tím, že odstraní šum, který to celkem dobře zamaskuje.

[Jan Polášek]

V zásadě ano, ale jde o barevné kanály YUV, a navíc je vzorkovací kmitočet složek U a V snížen na čtvrtinu (4:2:0).

pravda, to jsem si vůbec neuvědomil...

[Pavel-original]

ivovi: Ano, blikalo to, máte pravdu. Ale to musel to muselo být použitým enkodérem. Normálně nic nedýchá ať to nastavíte vzdálenost snímků jakkoli, není k tomu důvod.

Tak oprava. Dýchá to proto, že použitá komprese je příliš nepřesně definovaná, proto i když jak enkodér i dekodér splňují normu, můžou barvy "ujíždět", protože každý zaokrouhluje jinak. XVID sice používá stejnou iDCT jako MPEG2, ale problém se řeší tím, že se vždy používá stejný algoritmus. Problém doopravdy řeší až MPEG4 AVC, který má dekódování definované na bit přesně.