Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
16
Zemské digitální vysílání (DVB-T) / Re:Zasekavani obrazu Telka, Smichov, Fanda v mux4
« kdy: 23. 09. 2013, 15:40:56 »http://www.digizone.cz/clanky/nova-cinema-zacala-vysilat-v-multiplexu-4-zmizela-nova-hd/Uf, tak to sorry, nějak mi to uniklo (nemám potřebu lovit to co už jednou mám).
17
Zemské digitální vysílání (DVB-T) / Re:Zasekavani obrazu Telka, Smichov, Fanda v mux4
« kdy: 23. 09. 2013, 10:17:22 »
Malá opravka. Nova Cinema je v muxu 2 a problémy s ní nejsou. Jinak to sedí.
18
Zemské digitální vysílání (DVB-T) / Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« kdy: 22. 09. 2013, 23:36:37 »
Pokud to chcete někdo testnout a nechce se vám to buildovat, ProjectX s Ondřejovým patchem je ke stažení zde:
http://ulozto.cz/x5p76D2b/projectx-fe-patch-zip
http://ulozto.cz/x5p76D2b/projectx-fe-patch-zip
19
Zemské digitální vysílání (DVB-T) / Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« kdy: 22. 09. 2013, 18:32:25 »
Dobrá práce! 
Na vzorku cca 2 GB z Fandy a 1,5 GB z Déčka mi patchnutý PX žádné chyby nehází. Jestli to pořád ještě synchronizuje je možná zatím předčasné hodnotit, ale vypadá to dobře. Fakt díky moc 
.
Na vzorku cca 2 GB z Fandy a 1,5 GB z Déčka mi patchnutý PX žádné chyby nehází. Jestli to pořád ještě synchronizuje je možná zatím předčasné hodnotit, ale vypadá to dobře. Fakt díky moc .
20
Zemské digitální vysílání (DVB-T) / Re:Zasekavani obrazu Telka, Smichov, Fanda v mux4
« kdy: 22. 09. 2013, 09:48:47 »Také bych chtěl, aby bylo všechno tak jednoduché, jak si řada lidí představuje. Bohužel, realita je trošku někde jinde a vyjít s některými manažery bývá dost složité... Konkrétně jmenovat nebudu.Vy chcete vyjít s manažery? K tomu jsou nezávislá média? No, to snad špatně slyším
. Proč nenapíšete článek, že čtenáři DZ (nevyjímaje zástupce profesionálních instalačních firem) si už několik měsíců stěžují na nekompatibilitu vysílání v sítích muxů 4 a RS7 s některými typy přijímačů, ale pan Pařízek to zatím nebyl schopen vyřešit, ani se k tomu uspokojivě vyjádřit? Tak řekněte, co nebo kdo Vám brání? Proč se krucinál ohlížíte na nějaký manažerský jemnocit a čekáte nekonečné měsíce na vyřešení, které je pravděpodobně jen v přenastavení jednoho jediného parametru na kodéru? Hrozí Vám poskytovatelé nebo televize, že když o nich napíšete kritický článeku, nebudou Vám poskytovat informace? No ale kde to pak sakra jsme!? K čemu pak jako médium jste? Hanba! 
21
Zemské digitální vysílání (DVB-T) / Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« kdy: 22. 09. 2013, 09:07:10 »Tohle by nemusel být tak velký problém opravit v ProjectX.Taky mi to tak přijde. Zvlášť když není potřeba snímky fyzicky rekonstruovat (v náhledu by nekompatibilita nevadila, podstatný je výstup demuxu), snad by stačilo po detekci půlsnímkového kódování počet vzorků (v tomto případě půlsnímků) v GOPu vydělit dvěma a pak by následující PTS nejspíš sedět měl. Pokud se do toho pustíte, dejte určitě vědět. Já teď bohužel absolutně nemám čas
, ale pokud by s tím byl problém, snad se na chvilku urvu a mrknu na to.
22
Zemské digitální vysílání (DVB-T) / Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« kdy: 20. 09. 2013, 03:25:27 »
Přesně tuhle informaci jsem potřeboval. Díky moc.
Používám nejčastěji verzi 0.90.4 (rozzáložkované GUI novějších verzí mi nevyhovuje), ale zjevně to tím není. PX to prostě neumí :-(.
Norma je věc jedna. Jiná věc ovšem je, jestli např. CME nebo ČT vůbec ví o tom, že s tím někteří diváci můžou mít (a podle vašeho příspěvku i mají) problémy a jediné co je potřeba udělat pro to aby ty problémy zmizely, je jemně přenastavit kodér. Negativní efekt (méně účinná komprese?) by byl podle mě naprosto minimální (subjektivně nepozorovatelný) a přínos jednoznačný.
Spíš mi ale přijde to ani nebyl záměr. Prostě Pařízkovi chlapci nevěděli co, proč a jak nastavit, tak tam dali AUTO. Poradit se jak se to nastavuje ve veřejných DVB sítích jinde (a zdá se že jinak úplně všude)? To by ale bylo pod jejich úroveň se na něco ptát zkušenějších kolegů. Že jsou pak za trubky zcela veřejně jim zřejmě nevadí ;-).
Používám nejčastěji verzi 0.90.4 (rozzáložkované GUI novějších verzí mi nevyhovuje), ale zjevně to tím není. PX to prostě neumí :-(.
Norma je věc jedna. Jiná věc ovšem je, jestli např. CME nebo ČT vůbec ví o tom, že s tím někteří diváci můžou mít (a podle vašeho příspěvku i mají) problémy a jediné co je potřeba udělat pro to aby ty problémy zmizely, je jemně přenastavit kodér. Negativní efekt (méně účinná komprese?) by byl podle mě naprosto minimální (subjektivně nepozorovatelný) a přínos jednoznačný.
Spíš mi ale přijde to ani nebyl záměr. Prostě Pařízkovi chlapci nevěděli co, proč a jak nastavit, tak tam dali AUTO. Poradit se jak se to nastavuje ve veřejných DVB sítích jinde (a zdá se že jinak úplně všude)? To by ale bylo pod jejich úroveň se na něco ptát zkušenějších kolegů. Že jsou pak za trubky zcela veřejně jim zřejmě nevadí ;-).
23
Zemské digitální vysílání (DVB-T) / Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« kdy: 17. 09. 2013, 02:03:00 »...letmý pohled do CVS naznačuje, že se toho moc neděje...Ona ta norma pro MPEG-2 TS taky moc změn neprodělala. Z funkčního hlediska v zásadě nevidím důvod ho upgradovat (kromě podpory H.264, freeware na způsob ProjectX pro H.264 zoufale chybí). V tomto případě jde podle mě asi opravdu o chybový stav na vysílací straně, tj. enkodér produkující TS mimo normu. Nevidím nejmenší důvod proč by měl GOP podle PTS začínat dřív než má podle PTS + počtu snímků končit GOP předchozí. Každý program, který vnímá PTS a kontroluje jeho validitu, s tím musí mít problém. Playery a simple demuxery na kontrolu PTS zjevně kašlou.
...Já už jsem delší dobu v pokušení napsat si vlastní obdobu ProjectX.Tak tohle už mám za sebou. Není to bohužel vůbec legrace. Mezi tím co všechno norma pro MPEG-2 TS teoreticky umožňuje a co a jak se pak reálně používá je propastný rozdíl. Co TS, to originál. Nejspíš by šlo do ProjectX sáhnout a tu kontrolu asynchronního PTS vypnout (v nastavení PX jsem to nenašel), ale pak je otázka jestli bude pro synchronizaci AV z TS ještě tak spolehlivý jak tradičně je.
24
Zemské digitální vysílání (DVB-T) / Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« kdy: 17. 09. 2013, 01:46:46 »Mam k dispozici IceCrypt STC6000HDPVR a ten uklada program z MUXu DVB-T/T2/S/S2/C do nativniho souboru.ts .Díky za info. Prosím jen o konkrétní postup konverze z TS do DivX a hlavně způsob jak zajistíš synchronizaci obrazové a zvukové stopy. Já se při tom bez ProjectX neobejdu. Můj běžný postup je následující:
Kdyz pote soubor zkonvertuji do DivX (VirtualDub), tak nepozoruji zadne problemy.
Mohu nahravat vsechny programy z MUXu najednou a vsechny se nahravaji v poradku.
Tudiz bych rekl, ze problem bude na tve prijimaci strane.
- ProjectX (demultiplex, synchronizace, střih)
- DGIndex (vyrobí D2V, indexy pro AviSynth plugin DGDecode)
- VirtualDub (otevřu AVS script s případnými dalšími úpravami)
Pokud existuje jiný postup, který synchronizaci AV z TS zajistí taky a navíc funguje na TS ze všech muxů, pak šup sem s ním! Díky.
25
Zemské digitální vysílání (DVB-T) / Re:Decko/Art vypadky distribucni trasy a kvalita obrazu
« kdy: 16. 09. 2013, 00:52:14 »
Jestli ono to celé nebude nějak souviset, viz Formální chyby v transportních tocích z muxů 4 a RS7?
http://forum.digizone.cz/index.php?topic=3468.0
Tak jako tak, všechno nasvědčuje tomu, že transportní tok muxu RS7 (datově) produkuje Pařízek a nikoli ČT, jak tu nedávno tvrdil v rozhovoru Pavel Hanuš. A tudíž se asi ani nelze divit nějaké té čuňačince v nastavení head-endu...
http://forum.digizone.cz/index.php?topic=3468.0
Tak jako tak, všechno nasvědčuje tomu, že transportní tok muxu RS7 (datově) produkuje Pařízek a nikoli ČT, jak tu nedávno tvrdil v rozhovoru Pavel Hanuš. A tudíž se asi ani nelze divit nějaké té čuňačince v nastavení head-endu...
26
Zemské digitální vysílání (DVB-T) / Formální chyby v transportních tocích z muxů 4 a RS7?
« kdy: 16. 09. 2013, 00:43:09 »
Už pěkně dlouhou řadu let používám pro zpracování záznamů z DVB-T i DVB-S programy ProjectX a PVAStrumento. Pokud nevíte, jsou dobré hlavně k tomu, aby se po demultiplexu obrazové a zvukové stopy v případě sebedrobnějších výpadků postupně nerozjela synchronizace. Při zpracování transportních toků z Pařízkových multiplexů 4 (např. Fanda) nebo RS7 (např. Déčko/Art) mi ale oba zmíněné programy zahazují podstatné kusy záznamu kvůli masově se vyskytujícím formálním chybám tohoto typu:
!> startPTS of GOP# 35 is earlier than the end of last GOP.. (exp. 1676262094)
!> PTS difference of -14400 (23:59:59.840) to last exported GOP detected
!> dropping useless B-Frames @ GOP# 35 / new Timecode 00:00:20.080
TS přitom jde normálně přehrávat playery (VLCPlayer, MPC) bez nějakého subjektivního výpadku a i běžný nesynchronizovaný demultiplex (např. TSDemuxer) vyplivne M2V+MP2 prakticky v celé jejich délce v pořádku. Bohužel nesynchronizovat záznamy právě z těchto signálově sporných muxů je dost velký risk, že se to dříve či později někde rozjede (to si dobře pamatuju ještě z dob začátků DVB-T, než jsem tyto - doposud skvělé - nástroje objevil). Nezáleží ani jak TS pořídím, zda na PC (DVB-T karta + DVBViewer) nebo přes PVR (Dreambox 8000), takže chybu zachytávacího zařízení bych skoro vyloučil. Při zpracování TS z muxů 1, 2, 3 ani ze satelitu se mi nic takového neděje.
Zaznamenali jste něco podobného? Má podle vás Pařízek head-endy špatně nastavené nebo jde o nějakou dosud prakticky nevyuživanou větev v normě MPEG-2 transport streamu, kterou nemají uvedené programy dosud implementovanou? A co s tím? Co pro synchronizovaný demultiplex takto uplácaných transportních toků použít?
P.S. Pavel Hanuš tu v nedávném rozhovoru tvrdil, že transportní tok jako takový (na datové úrovni) produkuje kompletně ČT, zatímco Pařízek ho jen odvysílá. Vzhledem k tomu, že při zpracování TS z muxu 4 a muxu RS7 dochází k úplně stejným typům chyb, k nimž v muxu 1 nedochází, mám silné podezření, že pan Hanuš buďto neví (a to bych se dost divil), anebo tak trochu kecá
.
!> startPTS of GOP# 35 is earlier than the end of last GOP.. (exp. 1676262094)
!> PTS difference of -14400 (23:59:59.840) to last exported GOP detected
!> dropping useless B-Frames @ GOP# 35 / new Timecode 00:00:20.080
TS přitom jde normálně přehrávat playery (VLCPlayer, MPC) bez nějakého subjektivního výpadku a i běžný nesynchronizovaný demultiplex (např. TSDemuxer) vyplivne M2V+MP2 prakticky v celé jejich délce v pořádku. Bohužel nesynchronizovat záznamy právě z těchto signálově sporných muxů je dost velký risk, že se to dříve či později někde rozjede (to si dobře pamatuju ještě z dob začátků DVB-T, než jsem tyto - doposud skvělé - nástroje objevil). Nezáleží ani jak TS pořídím, zda na PC (DVB-T karta + DVBViewer) nebo přes PVR (Dreambox 8000), takže chybu zachytávacího zařízení bych skoro vyloučil. Při zpracování TS z muxů 1, 2, 3 ani ze satelitu se mi nic takového neděje.
Zaznamenali jste něco podobného? Má podle vás Pařízek head-endy špatně nastavené nebo jde o nějakou dosud prakticky nevyuživanou větev v normě MPEG-2 transport streamu, kterou nemají uvedené programy dosud implementovanou? A co s tím? Co pro synchronizovaný demultiplex takto uplácaných transportních toků použít?
P.S. Pavel Hanuš tu v nedávném rozhovoru tvrdil, že transportní tok jako takový (na datové úrovni) produkuje kompletně ČT, zatímco Pařízek ho jen odvysílá. Vzhledem k tomu, že při zpracování TS z muxu 4 a muxu RS7 dochází k úplně stejným typům chyb, k nimž v muxu 1 nedochází, mám silné podezření, že pan Hanuš buďto neví (a to bych se dost divil), anebo tak trochu kecá
.
27
Skylink / Re:Surflock bude uspěšný?
« kdy: 30. 08. 2013, 22:48:07 »SkyLink zřejmě vůbec netuší jak moc riskuje ztrátu dalších platících zákazníků. Zřejmě se firmě nadmíru ekonomicky daří. No uvidíme.
Akú stratu?
Tí čo zdieľajú aj tak platia len za jednu kartu. Ak sa im zablokuje zdieľanie, tak pravdepodobnosť toho, že si kúpia kartu NEXT je zhruba rovnaká, ako že sa vykašlú na sat. príjem. Nehovoriac o tom, že časť ľudí proste mávne rukou a bude ďalej platiť len za jednu kartu tak ako doteraz, len bez sharingu.
Dokonca je možné, že im zákazníci pribudnú - existuje dosť prípadov, že karty zdieľajú susedia na jednom poschodí. Pri bloknutí zdieľania (čo sa aj tak asi úplne nepodarí) príde časť ľudí o signál - a je možné že sa rozhodnú práve pre kúpu karty Skylink (keď už majú všetko nastavené na Astru).
A vy si jako myslíte, že lidi co si nakupovali Dreamboxy za 20 litrů, si budou chtít užívat PiP nebo vícenásobné nahrávání jen na FTA programech? Nebo Dreamy vyhodí a koupí si nějaký "SkyLink ready" šmejd, který nic z toho neumí? Ne ne, milý pane. Pokud bude M7 se surflockem ještě chvíli provokovat, všichni tihle nejbonitnější zákazníci jim utečou. Ti poctivější asi k UPC, ti pragmatičtější možná využijí placených služeb nelegálních serverů, které nejenže fungovat nepřestanou, ale bude jich přibývat stejným tempem, jakým začne přibývat zoufalců, z jejichž luxusních Dreamů udělala M7 kvůli své zaslepené nenasytností polofunkční šmejdy. Pro komerčně orientované profi sdílecí servery přece není nic jednoduššího než mít na každý program jednu legální kartu, a dekódovat jeden program jednou kartou bude přece z principu možné vždycky (bingo!). Úvaha o zavadení surflocku na jeden jediný dekódovaný program je tedy i z čistě ekonomického pohledu hodně, hodně hloupá. Ale jak řekl Enik, kdo chce kam...
28
Televizory / Re: Umí se některá LCD TV probrat ze stand-by po zapnutí HDMI zařízení?
« kdy: 26. 10. 2011, 14:34:25 »LG50PJ550-plasma 1ks HDMI-HDCPŠmarjá co to je za tip?
Vždyť to ani nemá Full HD rozlišení 
. A to DVI taky nějak nevidím ... HDMI s HDCP má přece každá LCD/PDP TV.
29
Televizory / Re: Umí se některá LCD TV probrat ze stand-by po zapnutí HDMI zařízení?
« kdy: 24. 10. 2011, 21:44:20 »
Reakce Samsungu: Bohužel televizor se bude v tomto případě chovat jako že nemá žádný
příjem a nevypnese pokud tak nezvolíte pomocí dálkového ovladače.
Doporučujeme tedy použí některý z nových monitorů pro rok 2011 . např.: Samsung TA350 nebo TA550.
Jenom dodám, že monitory TA350 a TA550 jsou sice Full HD, ale mají uhlopříčku jen 22, resp. 24". Takže zase nic
.
To sakra fakt žádný "normální" LCD televizor nemá DVI vstup s podporou HDCP (lze ho pak bezeztrátově zredukovat z HDMI)? A proč ne?
příjem a nevypnese pokud tak nezvolíte pomocí dálkového ovladače.
Doporučujeme tedy použí některý z nových monitorů pro rok 2011 . např.: Samsung TA350 nebo TA550.
Jenom dodám, že monitory TA350 a TA550 jsou sice Full HD, ale mají uhlopříčku jen 22, resp. 24". Takže zase nic
.To sakra fakt žádný "normální" LCD televizor nemá DVI vstup s podporou HDCP (lze ho pak bezeztrátově zredukovat z HDMI)? A proč ne?
30
Televizory / Re: Umí se některá LCD TV probrat ze stand-by po zapnutí HDMI zařízení?
« kdy: 24. 10. 2011, 11:23:36 »
Tak jsem rozeslal dotazy snad na všechny významější výrobce. Panasonic, Sony, Samsung, LG, Philips a Sharp. Zatím odpověděl jen Philips a LG, z toho jen LG konkrétně.
Reakce LG: Bohuzel zadna nase televize nema pozadovanou Vami funkci. Nejvetsi nasi monitory maji uhlopricku 27".
Reakce Philips: Doporučujeme kontaktovat přímo oddělení monitorů a hotelových TV - tel. 800 142 100, kde je možné získat bližší informace ohledně tohoto typu produktu.
Mimochodem, na tu Philipsí linku jsem opravdu volal, ale je tam jen smyčka vyzývající k tónové volbě, která ovšem pro jistotu nereaguje vůbec na nic (ani timeout tam není, výzva k tónové volbě se pořád opakuje). Docela vtipná (a jistě i levná) hotline, zkuste si to taky. Je to zadarmo!
Reakce LG: Bohuzel zadna nase televize nema pozadovanou Vami funkci. Nejvetsi nasi monitory maji uhlopricku 27".
Reakce Philips: Doporučujeme kontaktovat přímo oddělení monitorů a hotelových TV - tel. 800 142 100, kde je možné získat bližší informace ohledně tohoto typu produktu.
Mimochodem, na tu Philipsí linku jsem opravdu volal, ale je tam jen smyčka vyzývající k tónové volbě, která ovšem pro jistotu nereaguje vůbec na nic (ani timeout tam není, výzva k tónové volbě se pořád opakuje). Docela vtipná (a jistě i levná) hotline, zkuste si to taky. Je to zadarmo!
