Vlákno názorů k článku Průvodce digitálním vysíláním (1.): Proč digitální televizní vysílání? od Enik - je za současného stavu digitalizace u nás, projevem...

Ne, nebudu se pouštět do další debaty s blbem co nedokáže pochopit že opravné algoritmy fungují, a že tedy z CD/DVD/DVB-T dostanu vždycky ta samá data jako tam někdo uložil/poslal. Naposled jsem zcela nesmyslnou debatou ztrávil večer co večer snad celý týden. Jestli vás to zajímá tak si najděte jak fungují opravné algoritmy a nešiřte tady bludy.

Když někomu dojdou argumenty, tak se uchýlí k osobním výpadům. Když někdo nedokáže pochopit, že v reálném případě může dojít i k několikasekundovému výpadku v příjmu signálu, a dojde tak ke ztráně několika Mbit dat, tak je opravdu těžké s takovým člověkem diskutovat.

Víte jak vypadá ztráta několika Mbit dat? Asi sekundový výpadek obrazu i zvuku...

To jsem tvrdil hned na začátku! Někdo tu ale tvrdí, že k žádným výpadkům nedochází, tak nevím!

Ale já jsem přece netvrdil, že neexistuje nepoužitelný signál! Děláte si ze mě legraci nebo co? Pokud je nepoužitelný, tak je nepoužitelný bez ohledu na to v jakém formátu se vysílá. Pokud je použitelný, tak je signál 100% a zase je jedno jestli je to MPEG2 nebo MPEG4. O opravu chyb se starají jiné algoritmy než MPEG.

Místo signál 100% mělo být data 100%

Já si legraci nedělám! Já jen tvrdím, že pokud zkomprimuji obraz dvěma různými komprimačními algoritmy, bude mít výpadek signálu na každý z nich jiný vliv. Obraz komprimovaný algoritmem s vyšším stupněm komprese bude více trpět nestabilitou signálu v místě příjmu, než obraz komprimovaný algoritmem s nižším stupněm komprese. Je to naprosto logické. Jeden bit u MPEG-4 obsahuje více informace i přenášeném obrazu, než 1bit u MPEG-2. V okamžiku, kdy výpadek přesáhne možnosti opravného algoritmu, zákonitě musí dojít k pixelizaci obrazu. Ta bude za jinak stejných podmínek odlišně velká u MPEG-2, a jinak velká u MPEG-4.

Tak jako tak to nebude ke sledování. Opravdu nechápu o co vám jde...

Taky nevim o co Enikovi jde. Je pravda, ze jeden bit u MPEG-4 nese vic informace. Je ale nesmysl se zabyvat tim, co se stane kdyz selze opravny algoritmus. Do urciteho poctu chyb pri prenosu je dokonaly obraz, jak mile se prekroci, jsou videt v obraze chyby. A pak je uz podle me jedno jestli vidim jeden ctverecek u MPEG2 nebo dva ctverecky u MPEG4, kdyz to prezenu. (Vysledek bude trochu jiny uz kvuli blokove vs. objektove orientovanemu kodovani, mohutnemu prokladani atd.) Odolnost DVB-T proti chybam (impulsum, odrazum, sumu) je dost komplexni a propracovany system, protoze se prolina ucelne zvolena kombinace modulace COFDM s konvolucnim kodovanim, RS (Reed-Solomon) kodovanim a prokladanim. Jen pro zjednodusenou predstavu, RS kodovani prida 8,5% bitu, konvolucni kodovani dalsich 33% bitu (u DVB-T v CR). Podle DVB-T normy je za hranici chybovosti MPEG streamu povazovan qasi dokonaly stream s asi jednou chybickou za hodinu coz je 1e-11. Tomu odpovida chybovost pred RS dekoderem (a po Viterbiho dekoderu konvolucniho kodu) 2e-4. Pokud jsou chybovosti horsi a opravne algoritmy nestaci, je uz temer uplne jedno jestli se vysila MPEG2 nebo MPEG4. Mnohem zasadnejsi vliv aby k viditelnym chybam v obraze nedoslo maji prave parametry kodovani prenosu (MUX Cra konvolucni kodovani 3/4 a ochrany interval 1/8).

MPEG4 funguje taky na principu bloků, jen na rozdíl od MPEG2 mají bloky dynamickou velikost. Prokládání je u MPEG4 míň, protože umí dynamicky přepínat mezi prokládaným a progresivním kódováním, a to i v rámci jednoho snímku, část může být kódována progresivně a část prokládaně. (hodí se třeba pro běžící titulky u progresivního filmu nebo pro statický scény)

v prispevku vyse jsou prokladanim patrne mineny slices, nikoli interlacing. ten se na odolnosti vuci chybam moc neprojevuje.

No nevim co myslite tim "slices". Ja jsem mel mel na mysli prokladani datoveho toku - "interleaving" a opravdu jsem nemyslel prokladani obrazovych bodu nebo radku.

Jaký interleaving používá MPEG? O ničem takovým sem nikdy neslyšel.

Ja jsem taky o interleavingu v MPEGu nepsal, slo mi o interleaving pri vnejsim kodovani DVB-T. Tim jsem chtel jen rict, ze chovani DVB-T pri impulsnim ruseni neni tak trivialni jako napr. tato predstava: impuls delky t zpusobi poruchu jednoho bloku, impuls 2*t dvou sousednich bloku (ctvercu).

Ale já nemluvil o interleavingu v DVB, já mluvil o týhle větě: (Vysledek bude trochu jiny uz kvuli blokove vs. objektove orientovanemu kodovani, mohutnemu prokladani atd.)

Ano, moje chyba ze jsem to zmatene napsal, v te vete se kodovani vztahuje k MPEG, prokladani k DVB.

CD/DVD ano, DVB-T ne! Prenos vzduchem bez zpetne linky (tj. moznosti znovyvyzadani si ztracenych nebo pozkozenych dat) prece nemuzete nikdy povazovat za 100% datove propustny. Jde o statistike pokryti, ktere ma urcitou pravdepodobnost spolehlivosti. I kdyby to bylo 99,999%, s vypadky a jejich dusledky vzdycky musite pocitat. Ano, mate pravdu, ze velkou cast chyb dokaze eliminovat prenosovy protokol COFDM, projevy chyb, ktere jim projdou, muzou byt snizeny softwarove (zdvojeny snimek je asi lepsi nez zeleny ctverecek uprostred obrazu), ale i tak, pokud dnes povazujete signal s vypadky, ktere casto subjektivne ani nepostrehnete, za nepouzitelny, pak si troufam tvrdit, ze 80-90% lidi, kteri si dnes spokojene uzivaji DVB-T prijem, maji nepouzitelny signal. Budiz. Podstatne ale je, ze jim to nevadi, ne? ;-)

Lapidarne receno, pokud byste za kazdy ztraceny/poskozeny paket Vaseho super jisteho DVB-T prijmu mel dat stovku, pomerne brzy byste prisel o strechu nad hlavou :o) (casto staci jen rozsvitit nebo zhasnout zarovku a dalsi stovka je v ...) :-))

Jen malou opravu, abych nematl laickou verejnost a neprovokoval k reakcim tu odbornou. COFDM je samozrejme system modulace, nikoli prenosovy protokol (a pak ze rano je moudrejsi vecera ;-)). Nicmene, na jeho vyznamnosti, co se tyce eliminace podstatne casti chyb prenosu, jakoz i celkoveho zaveru prispevku, to vubec nic nemeni. Zatim si stojim.

Proč zpětnou linku? CD taky čte mechanika jen jednou. Jak na CD tak v DVB jsou data navíc, která umožní do určité míry chybovosti 100% opravu.

Ano, to jste rekl moc hezky. Opravna data umozni do urcite miry chybovosti 100% opravu. Tedy jiste budete souhlasit i s tvrzenim, ze opravna data od urcite miry chybovosti 100% opravu nezajisti, nebo ne? :-))

Tou zpetnou linkou jsem mel na mysli spis srovnatelne bezdratove datove prenosy (treba GPS nebo wi-fi), kde je kvalita signalu take velmi promenna, ale v pripade vypadku (treba vam do signalu zrovna vleti ptak, a co s tim nadelate?) lze server o data pozadat znovu, takze opravdu o nic neprijdete. Kdyz uz ale mluvite o CD, jiste znate situaci, kdy CD mechanika u poskrabanych nebo spatne vypalenych medii smejdi s diskem nekolikrat a ruznymi rychlostmi zkousi problemovy zaznam precejen precist. Nekdy se to povede, nekdy ne. U DVB-T ale nelze ani to, jde o format, ktery s vypadky proste pocita (proto se take uklada nativne jako transport stream *.TS a nikoli jako program stream *.MPG, ktery je urcen pro ulozeni na pevna media a nikoli prenos vzduchem). Pokud signal v eteru dany moment chybi, proste je behem milisekundy fuc a uz nikdy se nevrati ani ho nelze jinak obnovit. Cim drive se s timto faktem smirite, tim lepe ;-).

Opravuji. Samozrejme jde o GSM, ne GPS. Omlouvam se.

No tak ano, on s výpadky počítá, ale tim se myslí to, že chybná data nesmí způsobit zablokování dekodéru. To co může dekodér udělat je to, že si vymyslí něco z okolí/předchozího obrázku, ale taková situace aby to mělo nějaký význam není obvyklá. (americká ATSC na to myslim dost spléhá, ale to je úplně odlišný systém) Pokud je tam chyb tolik, že ani opravné algoritmy si s tím neporadí, pak to stejně bude jen nesmysl z kterého nic rozumného dekódovat nejde. Prostě pokud je signál tak mizerný, že opravné algoritmy nestíhají, tak si toho určitě všimnete. Smiřte se s tím. MPEG4 prostě žádnou nevýhodu co se dosahu týče nepřináší. Jeho jediná nevýhoda je náročnost na HW.
TS se ukládá "nativně" jen pokud ukládáte celý stream, pokud ukládáte jen jeden program tak se stejně musí rozbalit a zase zabalit vybrané kanály, takže je úplně jedno jestli se zabalí jako MPG nebo jako TS.
A pro zajímavost bluray používá taky TS.

Omyl. I videostreamy jsou nativne v TS. Je samozrejme jedno jestli ho nakonec prezabalite do souboroveho formatu MPG, ale uz je to nejaka dodatecna formalni zmena dat, kterou uz teoreticky muzete nejakou informaci (nikoli obrazovou, ale z hlavicek videostreamu) ztratit.

Dalsim omylem je, ze jedinou nevyhodou MPEG-4 AVC (nepletme do toho ty DivX) je narocnost na HW. Naprosto klicovou a vyrazne vetsi nevyhodou MPEG-4 AVC je prece jeho akademicnost, nerozsirenost a komercni nezajimavost. Ano, i auta na vodik jsou naprosto skvela, a verim, ze jich jednou budou plne silnice. Dokud ale nemate jedinou beznou cerpaci stanici na vodik a bezici seriovou vyrobu aut s dostatecne rozvinutou trzni konkurenci, zustanou jen zatracene nakladnou akademickou vizi. A pokud lidem reknete, ze zaroven benzinove stanice zrusite, pak jde o vylozenou utopii, nikoli z technickeho, ale ze spolecensko-politicko-ekonomickeho hlediska. A s MPEG-4 AVC je to dnes uplne stejne. Chapete?

Jaké videostreamy? Stream jen jeden. V něm je 5 video stop, X audio stop, a nějaká ta další data, jako EPG, teletext atd. Pokud si video ukládáte, program funguje tak jak píšu, rozbalí původní transport stream a vytvoří nový podle toho jaký program jste si vybral.

Akademičnost, nerozšířenost a komerční nezajímavost? Tak jaktože na satelitu se na něj hromadně přechází? Na evropských satelitech je možná už víc než polovina HDTV kanálů v MPEG4. (co se týče SDTV nevim)

Transportní stream se skládá z tzv. elementárních streamů. Elementární streamy (pravděpodobně tím myslíte stopy) obsahují už příslušná data (audio, video, SI sekce, teletext, ...). Takže například video elementární stream obsahuje MPEG data. Transportní stream vznikne tak, že se zmultiplexují všechny elementární streamy do jednoho výsledného datového toku.
MPEG4 - ano pro HDTV. Pokud jde o SDTV, na žádný takový kanál nenarazíte. A proč? Protože MPEG4 SD umí paradoxně přijímat pouze HDTV přijímače.

Nechci se prit, ale pokud se nemylim, mezi elementarnimi streamy a transportnim streamem celeho multiplexu existuje jeste jedna slupka, a to kanalovy transportni stream, ktery obsahuje data spolecna pro jeden TV (nebo rozhlasovy, nebo datovy) kanal. V tomto transportnim streamu je jedna obrazova stopa, jedna nebo vic zvukovych stop (u nas zatim jen jedna), a kanalove prislusne informace (teletext, titulky, EPG, ...). Prave tento stream se obvykle (presne tak jak je, bez jakekoli formalni upravy hlavicek) uklada pri nahravani na pevny disk. Jakakoli dalsi konverze, napr. na archivacni format program stream (MPG), je samozrejme mozny, ale musi uz probehnout nejakym softwarovym nastrojem (programem), takze se to uvnitr pristroje vetsinou nedeje (je to uplne zbytecne). Mnohem jednodussi je ulozit kanalovy TS tak jak je a uplne stejne ho dekodovat i pri prehravani. Dekoderu je pak v zasade uplne jedno jestli jdou data primo z tuneru nebo z disku. Jsou stejna.

Ne, tak to není, o žádném kanálovém transportním streamu v DVB standardech nevím. Například stejný audio elementární stream a nebo Teletextový elementární stream může být přiřazen k více programům, takže by v případě existence "kanálového TS" byl vysílán opakovaně. Takhle se pouze vysílá tabulka, ve které jsou jednotlivé elementární streamy přiřazené jednotlivým programům a pořadům. Transportní stream si prostě představte jako způsob, jak dostat všechny elementární streamy "současně" (časový multiplex) přenosovým kanálem.

Pokud jde o nahrávání na pevný disk - je možné že vaše PC aplikace a nebo PVR prostě k vybranému programu nastaví příslušné filtry a výsledná data vybraných elementárních streamů uloží na disk. Pak ale transportní stream remultiplexuje a bylo by potřeba upravit spoustu věcí, aby výsledný transportní stream byl opravdu korektní transportní stream. Anebo jde o jakýsi vnitřní formát té aplikace pro ukládání vysílání bez nutnosti rekomprese a ne o korektní TS. Můžete upřesnit o jakém zařízení/SW mluvíte?

Nemluvim o zadnem sw reseni, ale o vsech PVR modelech, z jejichz disku jsem mel moznost analyzovat primarni zaznamy. Vsechny mely stejny tvar, a to TS, v nemz jsou veskere elementarni streamy patrici k dane stanici usporadane jako MPEG-2 transportni stream. Jsem presvedcen, ze pokud by bylo jednodussi ukladat demultiplexovane elementarni streamy, vyrobci PVR by se s nejakym remultiplexem jisto jiste neparali ;-). Mrknete se radeji do odborne literatury. Ucinim taktez, ale myslim, ze tohle si pamatuji i z hlavy docela dobre.

A mam pravdu, viz schema, vy mudrlanti :-)

z toho schematu by se mohlo zdat, ze mate, nicmene v ts multiplexu je proste hromada elementarnich PIDu, ktere k sobe spojuji PMT tabulky. Ve sdileni PIDu mezi vice programy vam nic nebrani, podminkou je pouze aby pakety v PIDech mely konzistentni PCR/PTS/DTS casy a prehravac je tak byl schopny vzajemne synchronizovat.

Ono to schéma je vůbec nějaký divný. Pro vysílání se používá standard ITU-R709, ne ITU-R601. (alespoň pokud mi to ukazuje správně)

Kdyby uložili jen elementární streamy tak máte na disku zvlášť obraz a zvlášť zvuk vy chytrolíne.

Pak to je způsob, jakým PVR ukládá nahrané pořady. Ale ve vysílání žádná taková obálka pro jeden program není. Vazba je přes PMT - kde jsou jen ke každému programu vypsané PIDy elementárních streamů ze kterých se program skládá.

K tomu schématu - samozřejmě je možné aby se multiplexovalo takto ve dvou krocích, bohužel to provozovateli MUXu neumožní některá data sdílet mezi jednotlivými programy a pokud je obsah totožný, budou muset být v transportním streamu 2x. Můžete prozradit zdro, odkud uvedené schéma pochází a k čemu patří?

Martin Legin: Digitalni televize (nakladatelstvi BEN). A muzete naopak prozradit, odkud berete sva moudra Vy?

Jisteze je to zpusob, kterum PVR (resp. vsechny PVR) ukladaji zaznam, protoze je to pro ne nejjednodussi, jak pri zaznamu (demuxuje kanalovy TS a jen ho ulozi), tak pri prehravani (nacte kanalovy TS z disku a dekoduje). Ono to de facto ve dvou krocich neni, je to jeden proces, ale pouziti vice protokolu je v datovych sitich naprosto bezna, dokonce je jich casto i mnohem vic.

Muzete prozradit ktera data byste povazoval za potrebne sdilet? Obraz, zvuk, titulky predem vylucuji, vse ostatni je datove naprosto zanedbatelne (lepsi pidipaket zkopirovat nez komplikovat zpracovani).

V TS je tabulka, která říká které PID patří k sobě. To je i na oficiálním vebu DVB.

To prece nikdo nepopira, existence unikatniho ID kazdeho elementarniho streamu existenci vrstvy kanaloveho TS nijak nevylucuje. Doporucuji mene teoretizovat a vice cist.

Btw. nevite ktery ud vymyslel design stranek na pevnou sirku? :-( Nejak se to rozmaha, a pritom je to uplne debilni ...

A muzete naopak prozradit, odkud berete sva moudra Vy?
DVB normy, internet, analýza vysílaných TS.

demuxuje kanalovy TS a jen ho ulozi
Kanálový TS ve vysílaném TS prostě nenajdete, je to určitý termín použitý v nákresu z dané knihy.

Muzete prozradit ktera data byste povazoval za potrebne sdilet? Třeba teletext si dokážu představit velmi dobře. A ten si z celkového bitratu ukrojí taky řádně. Ve skutečnosti je možné sdílet audio - představte si, když se vysílá určitá událost (např. sport) z více kamer současně a se stejným zvukovým doprovodem...

Teletext ze ukroji radne z datoveho toku? Delate si legraci? ;-)

Nedělá, taky mě to překvapilo, ale datový tok teletextu je srovnatelný se zvukovou stopou.

Uf, tak to je tedy škandál! ;-) Povazuji to za technickou chybu administratora (tzv. admin error), kterou lze hrave napravit odebranim premii nebo vymenou za svepravnejsi osobu :-)). Text se zanedbatelnym formatovanim v datovem objemu zvukove stopy?! To me zabije. Uuuuuuuuuuuuuuu... :-(((

tak to je sila, statickemu textu ma odpovidat rychlost tak 1200bit/sekundu (bit, ne Byte). jinak to je furt dokola to same, zbytecne. Po prepnuti programu je celkem jedno, za jak dlouho se nactou stranky 348 - nez se tam clovek proklika pres stranky 100, 300, atd., tak je cely obsah TXT v pameti STBoxu.... a ten ktery nema pamet na vsechny stranky, ten at se vubec na trh nedostane...

A nevysílá se tam náhodou jako obrázky a ne text?

asi nee, protoze nektere STBoxy a mnoho SW ke kartam do PC ma zmrsenou cestinu v TXT

Ne, je to text. Ale je ho tam kupodivu docela hodně. A vzhledem k tomu, že se vysílají i podstránky, tak potřebujete klidně i 10 cyklů k tomu, abyste měl všechna data (v podstatě potřebujete tolik cyklů, kolik se maximálně vyskytuje podstránek).

No, a kolik si myslite, ze zabere kompletne cely obsah teletextu (vcetne vsech podstranek)? 10 kB? I kdyby to bylo 20 kB (jde o cisty ANSI text o maximalnim rozsahu 30x24 radku na jednu stranku), neni pozadavek na nacteni celeho obsahu teletextu behem necele sekundy (zvuk se produkuje s bitratem nejmene 192 kb/s) trochu prehnany? Takova rychlost aktualizace teletextu je podobny luxus jako vzorkovat zvuk na 96 kHz a vysilat ho s bitratem 1024 kb/s :-).

Tak to vážně nevím, pokud máte někdo info, tak dejte vědět. Ale když vezmu 30*24*0,75*800*1,5=648000, tak je to něco pod 1MB. Vycházím z toho, že každá stránka bude plná ze 75%, bude využito všech 800 stran a každá druhá strana má jednu podstránku (a nebo každá desátá jich má pět). Neberu v úvahu další data. To by při bitrate 192kb/s dělalo cyklus cca 26sec. Takže je vidět že jsem asi trochu s velikostí dat přestřelil, ale asi zase ne moc. Takže si představte, že na kompletní stránku, která má 10 podstránek, byste čekali 260sec - téměř 5minut - je to poměrně dlouho.

Po prepnuti programu je celkem jedno, za jak dlouho se nactou stranky 348 - nez se tam clovek proklika pres stranky 100, 300, atd., tak je cely obsah TXT v pameti STBoxu
Tak to jste zřejmě v menšině - já se třeba chci dostat rychle po přepnutí programu k datům v teletextu - a pokud chci 348, tak jí prostě zadám přímo ;-).

no a kdo vi, ze to je na 348? ale netvrdim, ze nazor je spatny. Je pravdou, ze ja TXT vyuzivam jen v nejvyssi nouzi.

Me osobne by se napriklad libilo, kdyby CT24 mela teletext z CT2. Napriklad pri cekani na zpravy na CT24 se nemuzu podivat na zpravy v TXT. Netusim jestli je to technicky mozne vyresit v multiplexu. Slo by to asi vyresit i inteligentnim STB.

Pokud vím tak nic takového neexistuje, v TS jsou jen údaje které stopy patří k sobě. Ale o tom že by tam byla nějaká obálka navíc jsem nikdy neslyšel.

No vždyť o tom mluvím. Je jedno jestli to mu říkáte elementární stream nebo stopy. Tedy pokud chci TS jen s jedním programemm, musí to program remultiplexovat.

Myslím že není až tak úplně jedno jestli tomu říkám stopa a nebo jinak. Stopa může být třeba další zvuk. Raději bych používal zažitou terminologii.

Stejně tak jako elemental stream může být další zvuková stopa...

To není pravda, mpeg4 nerozpoznává žádný objekty, taky dělí obraz na čtverečky,(a obdélníčky) ale můžou mít různou velikost. U MPEG4 (nevím jak MPEG2) se navíc pakety dělí na DC (hlavní barva čtverečků (ne makrobloků, MPEG2 makroblok je skupina 6 bloků, 4 na jas, 2 na barvy)) AC(detaily) a pohybové vektory. Pohybové vektory a DC koeficienty mají největší vliv na kvalitu, ale taky zabírají nejmíň paketů, takže šance že se ztratí zrovna paket co bude hodně vidět je u MPEG4 naopak mnohem menší.
Nevím co je tak těžkého pochopit na tom, že korekce fungují, bez ohledu na médium.
Tak jako tak, pokud k nějakým chybám dochází bude obraz strašný. Pravděpodonost, že by k drobným výpadkům docházelo čas od času je hrozně malá. To potom už dochází k takovým situacím jako že ve všední dny vám TV nejde a v noci/o víkendech jde atd.(asi nižší rušení, takhle nějak se mi chová signál z hohen bogen)

Naopak, pravdepodobnost, ze k drobnym vypadkum dochazi prakticky stale, je v mistech dobreho prijmu znacna. To, ze o nich nevite, je jen tim, ze jsou male a poste subjektivne (v obraze ci zvuku) tezko postrehnutelne, ale meritelne. Co se tyce prvni casti prispevku, obavam se, ze trochu motate dohromady spotrebni kompresi MPEG-4 (v desitkach pocitacovych klonu V1, V2, V3, DivX, XVid, ...), se standardizovanou kompresi MPEG-4 layer 10, aneb AVC aneb H.264 aneb ISO/IEC 14496-10. Zaklad je, jako u vsech MPEG kompresi, stejny, ale rozdil je presto znacny.

Ale vždyť stačí otevřít v nějakém programu co umí zobrazit chyby a chyby tam opravdu nejsou. Pokud je příjem dobrý tak opravné algoritmy musí stíhat.
Nevím kde si co pletu, tenhle systém je sice i u MPEG4 ASP (to je to čemu říkáte "komerční MPEG4" (mymochodem co je V1,V2,V3?) ale i AVC podporuje error resilience a nemyslim si že princip bude nějak výrazně odlišný, a pokud ano, tak těžko bude horší než to co jsem popsal.

mimochodem, jak se mi povedlo napsat mYmochodem?!? :D

"Naopak, pravdepodobnost, ze k drobnym vypadkum dochazi prakticky stale, je v mistech dobreho prijmu znacna."

To neni pravda, v miste dobreho prijmu je opraveny datovy tok (MPEG tok) bez chyb.

Ano, muze to byt pravda. Staci jen jeste dodefinovat pojem dobry prijem ;-). Muj vyklad je ten, ze k vypadkum sice dochazi, ale spise nahodile, napr. vlivem ruseni od elektrickych spotrebicu ci jinemu nahodnemu jevu (holub usalasivsi se na antene, vyjimecne spatne klimaticke podminky pro prijem). Rekneme radove cca v desitkach denne, z nichz nektere jsou jeste jen stezi videt/slyset nebo nejsou nijak rusive. To je myslim alespon aktualni stav vetsiny subjektivne spokojenych divaku, uzivatelu DVB-T vysilani, vybavenych pokojovou antenou.

Ne, k tomu většinou opravdu nedochází. Asi tak pravděpodobný, jako že se vám na analogu budou objevovat vodorovné proužky bez signálu...

K cemu nedochazi? K nepatrnym provoznim vypadkum? To myslite vazne? Pokud takovy signal mate, gratuluji, ale pak neni jen dobry, ale vynikajici :-).

No ja ho napriklad mam (STA v Brne), diky za gratulaci, i kdyz to nebylo na me. Samozrejme je vse o definici dobreho prijmu. Za dobry prijem rozhodne nepovazuji pokojovou antenu (vypadky pri pohybu osob, ruseni el. spotrebici) a rozhodne ani prijem antenou na strese pokud prijem dokaze narusit holub nebo spatne pocasi (pak je to prijem na hrane a ne dobry prijem).

Jiste, vzdyt dobry je taky trojka ;-). Nicmene, stejne si na zaklade informaci od zakazniku troufam odhadovat, ze vetsina uzivatelu jej dnes takovy ma. Bohuzel. Life is real.