Vzhledem k velmi dobrým výsledkům připravovaného kodeku H.265, který má nahradit současný H.264, bude po celkovém přechodu na DVB-T2 předpokládám používán již pouze ten. Současné výsledky ukazují zhruba poloviční datový tok potřebný pro stejnou kvalitu. Jak jsem si chtěl pořídit již trochu lepší televizi s DVB-T2 tunerem, tak se po tomto zjištění zřejmě zatím spokojím s levnější, jen s DVB-T. U dnešních televizorů je 100% jistota, že H.265 podporovat nebudou. Problém by neměl být naopak u PC tunerů. Otázkou jsou pokročilé přijímače založené na Enigmě 2. Podle zpráv by se první přijímače s podporou H.265 měly začít objevovat nejdříve v příštím roce.
Do DVB-T2 se teď nikdo z provozovatelů televizních stanic nehrne, protože jsou to další velké výdaje navíc a lidé nejsou ochotni přijímače zase hned měnit. Časem však bude tlak na kvalitu sílit. To už bude H.265 zcela hotový a budou dostupné i přijímače. Myslím, že provozovatelé t. s. budou tlačit H.265, protože místo jedné stanice budou moci vysílat ve zhruba stejné kvalitě dvě, případně vysílat v HD za ~ cenu SD.
Pletete si hrusky s jabklama.
Samotny tunerovy cipset samozrejme zvlada T/T2 v dnesni verzi a bude zvladat i za 5 let verzi, protoze posledni kvetnova revize je konecna, ostatni drobne updaty se budou vkodovavat do RILL bloku MSC streamu.
Z cipu leze 7 vodicu Transport Streamu 96MBps do hlavniho CPU iDTV/STB.
Takze vse (audio/video MPEG4/7/21) je otazkou pouze aktualizace fw v televizoru/STB a niceho jineho. Radiovemu kanalu MUXu je sumak co je obsahem stejne jako je to jedno UTP kabelu a vasi sitovce v PC.
Teprv hlavni CPU (nikoliv sitovej NIC CPU) PC (mozna s grafickou kartou GPU) dekoduje aktualni MPEG atd... dle aktualizace kodeku do Widli.
Viz muj druhy prispevek.
Neplest si privodni "trubku" s CPU na MB televizoru iDTV/STB.
A i tak to stejne dekomprimuje na obrazovku nejaka sada 2 az 8-mi DSP procesoru v jednou pouzdre. Dnesni multi procesory do STB/iDTV vetsinou maji 1-2 "ARM Linux" CPU , pak 1 CPU pro periferie a 2 az 8 DSP CPU pro zpracovani vysokeho vypoctu v realnem case...cili az MPEG21 s audiem MP4-AAC+v2 az v5 (THX-6 kanal zvlada v5 s SBR).
Faktem je ze tech 2 az 8 DSP CPU ridi ten druhej ARM Linux CPU, cili celkove na wafer desce je to oznacovano jako GPU....Graficka Procesorova Jednotka.
Nepletne Enigmu (operacni system) s obsahem PROMky v tunerovem cipu......do Enigmi jde dohrat drivery/knihovny i s MPEG21, kde obraz je ve vasem H.265, ale 8MHz sirokej COFDM radiovej kanal nezpracovava Enigma, ale CPU+DSP toho Sony cipu http://uloz.to/xxMmNma/sony-cxd2820r-pdf na zaklade obsahu PROMky toho integrace v kterem je CPU + DSP + uCPU pro periferni rizeni ADC/OSCILATORU/AGC + 3x IIC a vystup Transport Streamu (7pinu). Takze je sumak co je v Enigme za ovladace, do PROMky CXD2820R se to nedostane (prvni revize mela ROMku od dubna je tam PROMka a uvazuji o dvoucipove EEPROM...tedy 2ks EEPROM, jedna hlavni a druha zalozni pri spatnem upgrade fw).
Naposledy, nedavejte dohromady svab co na zaklade sveho fw zpracovava radiovej kanal (SDR prijimac) a ven vypousti nativni Transport Stream do ktereho nezasahuje. Teprve hlavni multiCPU STB/iDTV prijme tento transport stream a zacne z neho vytahovat zivej obraz, zvuk, EPG/TXT/TITULKY/NIT/PID/VID a dalsi "tabulky".
Ale jakej je kodek a komprese obrazu je Sonackemu cipu opravdu sumak.
Zajimave, ze se Toshiba, LG, Thomson, Sharp dohodli se Sony o nakupu jejich T2 cipu do svych televizoru (jeden typ s T2 se montuje 4km od meho baraku..... IPS Alpha, jsem ze Zatce), protoze nestihli vyvinou vlastni cip.
Kdezto Panasonic nema nic a nechce zebrat u Sonyho, vyviji uz 4 roky svuj multicip (T/T2/S/S2/C/C2/ISDB/ATSC/DAB III-L/FM) a stale nic.
Nepletu si hrušky s jablkama, vím, že tunerová část je u DVB-T2 již finální. "Takze vse (audio/video MPEG4/7/21) je otazkou pouze aktualizace fw v televizoru/STB a niceho jineho." - To je právě ono. Myslíte si, že když např. Samsung uvolnil aktualizaci zprovozňující HbbTV pouze pro letošní modely svých chytrých televizorů, že tomu bude v případě H.265 jinak? Zcela jistě ne. Výrobci televizorů podporují jen aktuální modely, na ty starší kašlou. Proto píši, že s TV tunery pro PC nebude problém. Tam si stáhneme nový kodek a jede to. Přijímače s Enigmou 2 jsem zmínil právě pro neustálý vývoj. Je však otázka, jak moc bude H.265 kompatibilní s H.264, jestli půjde využít alespoň částečně čipy pro HW akceleraci H.264, jestli bude stačit rychlost CPU (např. Dreambox používají 400MHz MIPS CPU, žádné vícejádrové 1 GHz a více ARM). Z toho co jsem četl jde o velmi výpočetně náročný kodek. Pokud bude kompatibilita nulová / mizerná, tak možná budou mít problém i např. současné tablety s Tegrou 3 a podobnými CPU.
Zadny STB (ani IceCryp ani DreamBox) ani TV nepouzivaji ciste jen CPU, jen hybridni tv MCU v kterem jsou periferni CPU/ridici CPU (ne moc vykonny)/jeden hodne vykonej DSP nebo vice stredne-mene vykonych DSP s razenim-prerusenim cinnosti mezi nima...to dela ridici CPU, vetsinou odnoz CPU 68k.
To je obsah soucasnych multicipu v jednom pouzdre jako je treba CPU Cheertek CT216T ( http://www.digizone.cz/clanky/opticum-7003t-plus-set-top-box-v-norme-dvb-t/ ) nebo CT212U ( http://www.digizone.cz/clanky/opticum-7002t-zakladni-set-top-box-pro-seniory/ ) a CPU ST Omega STi5119ALC ( http://www.digizone.cz/clanky/icecrypt-s1000c-set-top-box-v-norme-dvb-s/ ).
Jelikoz mam dokumentace od nekolika techto multi CPU, tak muzu potvrdit, ze jsem nenarazil na jedinej co by nemel bud aritmetickej cooprocesor pro dekompresni vypocty nebo rovnou DSP rady 56k nebo TI32.
Predpokladam, ze multiprocesory do TV/STB co obsahuji alespon trochu vykonej DSP ci nekolik DSP, tak tyto CPU zvladnou spocitat v realnem case i H.265. Problem je, jestli externim fw pujde "vypnout" vnitrni P/ROMku se zadratovanym MPEG4 H.264 nebo jestli pujde tuto cast vnitrni pameti preklenout datama z flash pameti o novem kodeku ci kodecich. Protoze DSPcku je jedno co pocita, klicovej je driver-ovladac pro tento DSP-CPU pripadne jestli je fw spravne napsanej..pro danej DSP.
Kdyz jsem mel ATARI 060 Falcon, tak na materske desce byl MC 68060 a MC DSP 56001, tedy 2 procesory a tak se programy museli psat tak, aby se vyuzivalo vykonu i DSP 56k, ktery je velmi rozsiren v autoCPU-strikackach, zvukovych kartach, GSM/UMTS telefonu atd...
99.3% vsech iDTV/STB ma tento cip:
http://uloz.to/xxMmNma/sony-cxd2820r-pdf
V PROMce je ulozena cela norma T/T2/C vcetne posledni aktualizace revize z 5/2012.
Tudiz to pochopitelne umi i CZ vysilani, mam vyzkouseno pres STB.
http://www.digizone.cz/clanky/stb-icecrypt-stc6000hdpvr-linuxovy-prijimac/
Na Ceskem, Berlinskem, Videnskem a Londynskem vysilani DVB-T2 to chodi bez problemu se spravnou diakritikou.
Kecy o D-booku jsou kecy, protoze vsechny cipy (ten nedodelek od Panaka jeste nechodi, ale bude umet i C2) musi umet to co rika ISO ETSI EN 302 755 a navazne normy. Fw pristroje si ze sveho fw vytahne ty spravne cestinarske normy cestiny EPG/TXT/TITLE + modulace/tabulky NIT-PID-atd...
A pokud neco schazi, nic se nedeje, lokalni aktualizace fw STB STC6000 neni problem, je to na Linuxu.
Kazdopadne cip zpracovava vse dle normy az do QAM256 se spravnym vystupem Transport Stream, takze se neni ceho bat.
Podle meho byl D-book jen vymluva, jelikoz si nekdo mocny a bohaty pral byt jeste bohatsi a proto si zaplatil politiky/CTU/urady atd..., aby mel jeste vyssi zisk.
Ano, Dbook neco ujasnuje, ale uz davno slo i bez Dbooku vysilat a ceskou tabulkove-znakovou lokalizaci a znaceni brat volne z DVB-T Dbooku co vydal vyhlaskou CTU pred lety.
Uz vidim, jak lidi zahazujou stare placky a CRT.
U me je problem ten, ze 21 let stary CRT Siemens doslouzil, lidi maji fialove obliceje co rude plapolaj 6cm doprava na 61cm obrazovce.
Z mazaniny me skutecne boli hlava a oci, protoze to nejde doostrit ocima.
nesouhlasím s tvou úvahou, že šlo vyrábět a vysílat bez D-booku, resp. předcházejících norem. Zjednodušení T2 na techniku jednoho čipu považuji za příšerné.
Proč se tedy standardizací, aplikací, výrobou a vysíláním DVB-T2 zabývá tolik lidí, a tak dlouho, když už božský čip byl vynalezen a vše obsahuje?
Aha - protože mocní a bohatí chtějí být mocnější a bohatší. Tak proto.