Ano CT4 je v Plzni na kanále 52. A má bitrate dosahující až na 6Mbit/s.
Ale také současně dnes vysílá CDG nějaký podivný signál a minimálně celá Plzeň má festival kostiček na celém multiplexu a já mohu jen konstatovat, že "Porucha není na vašem příjmači".
Zároveň v porovnání s Domažlicemi, je signáz zpožděn o zhuba 5 sekund.
To je právě to, proč fandím Radiokomunikacím, profesionální přístup, i když musím přiznati i vliv , že jsem s ČRa léta spolupracoval. Vše dotvrzuje to, že na mux A se díváme bez problémů, kdežto mux B je nespolehlivý.
Asi jste opravdu dost neobjektivni. Prijimam mux B jiz spoustu let a nevzpominam si, ze by s nim byl nejaky problem. Mozna mam stesti, ze prijimam Strahov, ale co se tyce kvality komprese, v ramci celkoveho bitratu neni CDG oproti CRa co vytknout. Naopak, Prima je dlouhodobe nejkvalitneji pozemne digitalizovanou analogovou stanici.
Vážím si vaších zkušeností,ale moje jsou rozdílné. Vím je to dané i rozdílnými podmínkami přijmu. Mux A z Bukové hory zde funguje doslova na kus drátu a mux B z Prahy se občas neobejde bez t.z. kostiček. Ve svém okolí znám jako propagátor digitalizace, především pozemního vysílání. Těžko se mi vysvětlují příčiny těchto stavů běžnému diváku programu Prima. Jinak s vámi scela souhlasím, že pokud nejsou problémy je kvalita Primy velice dobrá. Nyní ji dostihla Z1.
Neni sporu o tom, ze prazsky mux B ma horsi pokryti nez mux A. Ja jsem ale mluvil o problemech na vysilaci strane, tj. kvalite vytvareni transportniho streamu, a v tomto smyslu jsou podle mych zkusenosti (jsem divakem obou DVB-T muxu cca od roku 2003) oba muxy srovnatelne.
A neni možné, že kvalita je tak špatná, protože je tam tolika programů? Že třeba chtěli ušetřit datový tok, tak odstranili nějakou korekci chyb a pro bezproblémový příjem je třeba bezvadný signál? Mě se to seká jak pr...
Ne, tim to urcite nebude. Celkovy bitrate je vetsi nez v muxu A, navic tam nejsou radia a Ocko ma datovy tok "proklate nizky". Zrejme jde o nejakou prechodnou "nedochytavku" konfigurace koderu. CDG jeden cas vysilala dokonce 6 stanic, takze urcite to jde a kvalita 5 stanic v muxu B by mela byt finalne jeste vyssi nez v muxu A.
No a prave jsem predpokladal, ze kdyz je celkovy bitrate vetsi, tak tim to blbne. Jako že se snaží do jednoho kanálu narvat více, než se tam může vejít.
Něco jako u wifiny když se začlo na 11Mb a teď tam rvou 300Mb a jede to naprd...
...ale jiny dle pouzite konfigurace site. Kazdopadne pri prekroceni max. bitoveho toku (muxu, modulatoru atd.) dochazi prave k efektu vypadku a kostickovani...
Mnohem "medvedejsi" sluzbu ovsem delaji digitalizaci vsechna neplanovana nespusteni. Zaplat Buh za nekolikadenni problemy s konfiguraci koderu, pokud by bylo vysilani spusteno o nekolik mesicu (az let) drive nez v terminu, na ktery bylo ponekolikate odsunuto. To je opravdovy prusvih, nikoli prechodne technicke nuance.
proc bych mel kvuli prechodnym problemum radikalizovat pristup k TV dle vasi rady? Ja chci jen vedet JAKE to jsou PROBLEMY. To se dnes neumime ani priznat ze meli problem a pravdive rici jaky? K cemu se zavadi ISO? Aby se vse tutlalo? Neni ferovejsi rici ano byl takovy a takovy problem? To uz fakt nejsme chlapi? To opravdu budeme mlzit jak pubertaci?
Podle mého názoru byl a bude problém v tom,že vysílač vlastní ČRa,a přechodný MUX B na vysílači provozuje CDG.Zde Vám nepomůže ISO,zde je to konkurence na konkurenci.A nikdo Vám nepřizná kdo udělal chybu,protože se to špatně prokazuje a možná ten silnější si ještě "přiohřál" polévku.Ale takto to prostě chodí.Dva kohouti na jednom dvoře se nemají rádi.
Na vstupu modulatoru (a nejen tam) samozrejme z principu k prekroceni max. bitoveho toku zvolene konfigurace site muze. A prave to zpusobi kostickovani a vypadky. Stejny efekt muze zpusobit spoustu dalsich veci :-)
Asi si nerozumime. Na vstupu "modulatoru", pokud jim minite MPEG-2 koder, je nekomprimovany signal, jehoz bitrate je zcela nezajimavy. Vysledny bitrate jednotlivych streamu je pak vyhodnocovan v systemu statistickeho multiplexu tak, aby celkovy soucet bitratu vsech streamu neprekrocil max. limit dany parametry COFDM.
"Modulatorem" minim modulator.
Pokud na jeho vstup prijde prenosovy tok s vyssi max. bitovou rychlosti nez muze modulator "vlozit" do vytvarenych symbolu, potom dojde k ruznym kolizim a obvykly efekt odpozorovany z praxe jsou nepravidelne vypadky a kostickovani (nutno zduraznit, ze na vsech programech onoho TS).
Dalsi moznosti je multiplexer, ktery ma maly head-room a preteka mu max. bitova rychlost (potom se to muze projevit i jen na nekterych programech), remuxuje program z jineho zdroje a on se ve spickach jaksi "nevejde", protoze jeho koder nedodrzuje diky SW chybam max. bitrate atd. Neverte, ze v retezci je jediny multiplexer navic navazany na statistiku a kodery...
Ale davam Vam za pravdu, ze teoreticky by to melo fungovat presne tak, jak pisete. Prakticky to bohuzel tak zcela puntickarsky nefunguje, zarizeni od ruznych vyrobcu se obvykle chova "ruzne", vsechny obsahuji SW chyby a nedej boze, aby se potkaly v retezci dve ruzne zarizeni navic s ruznou obsluhou.
:-)
Je zrejme, ze COFDM modulator nemuze zpracovat vyssi datovy tok nez jeho parametry umoznuji. Pokud chybou obsluhy ci koderu dojde k preteceni bitratu transportniho toku, predpokladam, ze alespon prumerne zarizeni tohoto typu ohlasi chybovy stav a nesmyslny vystup nevyprodukuje. Nemuze prece "rozhodovat" o tom co z dodanych dat odvysila a co nikoli. Ze by k dodani vetsiho bitratu dojit nemelo by na validitu vysilanych dat nemelo mit vliv. Proste bud COFDM modulator osvysila data tak jak jsou nebo je neodvysila vubec. Pokud to takto nefunguje, povazuji to zvlast na urovni profesionalniho vybaveni za fatalni neschopnost a ostudu vyrobce.
Doufam, ze se tedy uz shodneme, ze na vstupu modulatoru muze byt vyssi max. bitovy tok, nez je max. bitovy tok dany nastavenim site a to v pripade nejake chyby v predchozim retezci? Ta chyba je prave to, o cem jsme se bavili, ze dale muze zpusobit chyby ve vysilani atd atd.
Me tedy logicke prijde, ze pokud vystup presahne maximalni hodnoty, respektive dosahuje spickami prahove hodnoty, tak se automaticky reverzne ponizi kodovani jednotliveho datoveho toku a tim se zajisti, aby spicky dosahovali maximalne povoleneho maxima.
Ano, melo by to tak byt a pri spravnem nastaveni koderu TS tomu tak opravdy je. Dokonce by tam mela byt urcita rezerva, aby k omezeni nedochazelo az ex-post, ale koder zareagoval zvysenim komprese jeste predtim nez k prekroceni limitu dojde. Nejde o idealni iluzi, ale beznou provozni nutnost.
To jako že když na vstup profesionálního modulátoru pro 24/7 provoz TV vysílání dorazí o jeden bit více než mělo, tak se má zablokovat, nahlásit chybu a čekat na zákrok obsluhy? Pro mne je přijatelnější chování kdy nějaký paket(pakety) zahodí a jede dál. Samozřejmě že by měl i signalizovat chybu obsluze. Vysílání tak jede dál, v obraze (případně zvuka a nebo doprovodných službách) jsou výpadky (jejich intenzita je přímo úměrná míře překročení bitrate) a obsluha je informována. Podle mého názoru je tento přístup mnohem lepší než totální "blackout".
Predne by se profesionalni modulator mel pouzivat pouze s profesionalnim a profesionalne zkonfigurovanym koderem, ktery takovy chybovy stav nedopusti. Pokud uz k nemu dojde (treba chybnou konfiguraci koderu), mela by se podle meho nazoru jeho cinnost uplne zablokovat, alespon po dobu, kdy je avizovano preteceni. Jedine tak lze predejit panice tisicu divaku, kteri jen kvuli chybe obsluhujiciho personalu, kterou neni schopen ani za nekolik hodin odstranit, bude lezt po strese a zjistovat pricinu chybneho prijmu. Posilat do eteru data, o nichz je jiz na vysilaci strane znamo, ze nepovedou k spravne rekonstrukci vsech brazovych a zvukovych stop, povazuji za nesmyslne a matouci chovani. Je mnohem lepsi signal uplne vypnout az do doby, kdy na vysilaci strane bude vsechno zkonfigurovano jak ma byt. Ono to vysilani klasicke hlasky "ZAVADA NENI NA VASEM PRIJIMACI", by nebylo uplne od veci a kazdy operator by ji mel mit v zaloze (pochopitelne na vsech stanicich v ramci muxu a nejlepe i ve vsech audio stopach) ;-).