DiDiDi

Jestli sedí ty bitraty, tak 33mbps H265 by měl být - pokud někdo něco nepodělá v nastavení, nepoužije špatný enkodér atd. - logicky lepší než 38mbps H264. To není žádná záhada. Jde ale o to o kolik (fakt by za žádných okolností ten reencode do H264 neměl vyjít líp). Já bohužel v 1. patře DVB-T2 téměř nechytnu, multiplex s ČT ani nenaladím... 😞

To VF_DVB-T.ts je znatelně míň ostré (což dává smysl, každá komprese typicky trochu rozostřuje, pokud se někde nepoužije sharpening filter - a tohle je reencode z HEVC), ale s méně viditelnými artefakty než Skylink_DVB-S2.ts (do jaké míry díky tomu rozostření těžko říct). Já mám bohužel jen jednu DVB-C/T2 capture kartu, která může mít naladěn jeden kanál, nejsem schopen srovnat frame ke framu, protože bohužel přelaďuje mezi DVB/T a C pomaleji, než televize, kde díky zpoždění mám při DVB-C->T tak 0,5 vteřiny zopakované. Koukám jen na hokej, tak by mě zajímalo srovnání hokeje (v pohybu). Každopádně HEVC ve vzduchu vládne...

Já přece vůbec nerozporuji, že teoreticky má mít DVB-C/satelit lepší kvalitu než VF DVB-T, to je mi naprosto jasné a proto jsem taky založil toto vlákno! Realitou je, že špatný enkodér (ať už sw nebo hw), špatné nastavení enkodéru (resp. preferující jiné parametry než kvalitu, např. latenci) atd. může výsledek zprasit natolik, že to ani vyšší bitrate nezachrání. V tomto případě je DVB-C/S2 verze takový shit a HEVC ze vzduchu o tolik lepší, že mě nepřekvapuje, že dobrý reencode do H264 je ve výsledku lepší. Ad hokej vs fotbal atd. - teď běží nějaké fotbalové zpravodajství a je to (při záběrech na hru, ne na panáky ve studiu) očividné úplně stejně jako u hokeje. Ad televizní vylepšení obrazu: To určitě může pomoci a obraz vylepšit (ale často taky zkurvit, zdaleka ne každá TV má dobrý processing), ale pro jednodušší porovnání kvality "syrového" streamu jsem tyto funkce povypínal. Ale je to jedno, ten rozdíl kvality je patrný s těmato udělátkama i bez nich, koneckonců když nás s otcem kvalita začala štvát a začali jsme to řešit a porovnávat, byla původně zapnutá. Ad zvuk: Přiznám se, že ve zvuku (5.1 DD) neslyším žádný rozdíl. Při vší úctě, pokud vám kvalita satelitní/DVB-C verze přijde v pohodě, standardní, "good enough" atd., tak to neřešte a buďte spokojení. Nekomplikujte si život realitou... 😄

To je naprostá blbost... Samozřejmě, že extrémně záleží na poměru velikost(dpi/ppi):vzdálenost ("mapování" obrazu do zorného pole). Ztrátová komprese obrazu/videa (nebo třeba chroma downsampling) je vyloženě založená na tom, že chyby způsobené kompresí začnou splývat při dostatečné vzdálenosti sledování obrazu. Např. při JPEGu spousta chyb mnohdy není vidět (vůči bezztrátové verzi), ale jakmile si člověk zazoomuje, ty chyby začnou být očividné. A přesto je tomu tak. Já si můžu přepínat mezi VF DVB-C a DVB-T, díky zpoždění DVB-T při přepnutí C->T vidím i zopakovanou ~poslední sekundu a ten DVB-T reencode z toho vychází prostě líp. Vše nasvědčuje tomu, že těch zdrojů z ČT je víc (minimálně 2) a ten, který používá satelit i kabelovka je prostě o tolik horší a špatný encode do H264, že i ten reencode vyjde kvalitativně líp, když se to nezprasí.

Na pidi 50palcové televizi to možná není tolik vidět, samozřejmě taky záleží, jak daleko od bedny člověk sedí. Ten rozdíl pozorujeme jak u mě doma (65palcový Samsung S90C, DVB-C vs. DVB-T přes VF koax vs. O2 TV) i u rodičů (65palcové LG G3, DVB-S2 vs. DVB-T2 vs. O2 TV). O barvy vůbec nejde, jde vyloženě o kompresní artefakty. Když má člověk malou televizi nebo je od ní dost daleko, tak mu to možná tolik nepřijde. Kdybychom neměli srovnání a nedokázali si přepínat mezi verzemi během 2 vteřin, tak to neřešíme a bereme jako fakt, ale když člověk vidí ten rozdíl, tak to celkem zarazí... No nic, jdu si koupit terestrální anténu.

Teď koukám na Skylink (Astra 23.E, 12344, H, 29900) a je to opravdu ten samej hnus. Pokud to někomu přijde "naprosto v pohodě", tak má laťku hodně nízko - doporučím porovnat s verzí ve vzduchu. O2 TV, HEVC verze v DVB-T2 vzduchu a dokonce i ta do h264 reenkódovaná verze ve Vodafone DVB-T je prostě znatelně lepší. Teorie: Nedává ČT do distribuce 2 verze? H264 a HEVC/H265? S tím, že ta HEVC verze je o tolik lepší, že když se rozumně reenkóduje do H264, vyjde to furt líp, než to H264, co leze přímo z distribuce?

No, já na to taky tak byl zvyklý. Táta má na Skylinku (který to taky bere přímo, AFAIK) stejný problém, ta kvalita vypadá identicky s mojí DVB-C. O2 TV má suverénně nejlepší kvalitu (jen taky skoro 15s zpoždění), DVB-C a satelit nejhorší, něco musí být špatně... 😄

Koukáme na hokej. DVB-C i DVB-T přijímám přes stejný Vodafone koaxiální kabel. DVB-T verze ČT Sport HD je o pár vteřin pozadu, ale kvalitou je o parník lepší než DVB-C verze, která má viditelné artefakty u pohybujících se hráčů na ledě, zkrátka jako by byl bitrate příliš nízko a/nebo se jednalo o několikanásobný encode. Proč? Dochází u DVB-C verze k nějakému reenkódování, ke kterému u DVB-T nedochází, nebo má prostě nižší bitrate? Musel bych najít USB DVB-C/T kartu, abych to mohl nějak zanalyzovat, ale ten rozdíl je při pohybu vidět na první pohled. Brno, kdyby na tom záleželo...

IP řešení samozřejmě může (a časem snad i bude muset) DVB-C překonat v podstatě ve všech parametrech, včetně latence i efektivity využití pásma (lepší kodeky a multicast). Jen to vyžaduje dost vývoje a práce na infrastruktuře (opět: multicast) a aplikaci (kterou nesmí psát dementní opice). Jestli se to Vodafone někdy podaří (a kdy) je samozřejmě jiná otázka.

A ví se, co to přesně je? Tipuju toto: https://www.broadcom.com/products/broadband/cable/modems/bcm3390 ...ale z webu Broadcomu se člověk nedozví nic... OpenWrt má toto: bcm3390 1.5Ghz ARM (2x), 675Mhz MIPS (2x) (armv7-a/mips32) USB 2.0/3.0 wifi miniPCI DOCSIS 3.1

Hmm, tam jsem se toho teda moc nedozvěděl (zajímá mě chipset/SoC/CPU atd.), ale našel jsem toto: https://www.lteforum.at/tags/technicolor-cga4336/ ARMv7 teda taky žádná sláva...

Víme něco o střevech Technicolor CGA4336, co dává T-Mobile?

V první řadě bych zkontroloval, jestli nejde o konflikt (rozsahů) IP adres - podívejte se, jakou IP dává VPN a jakou router/modem, jakou IP má brána apod.

Já jsem celkem překvapený, že to (VfS odkoupený z DE na CZ T-Mobile Cable Internet) vůbec jde... 😄 Ve smyslu, že to u TM akceptovali namísto pronájmu toho jejich modemu s 2.5GBASE-T portem, technicky/teoreticky to samozřejmě jde.

Já to mám (1000/50@VfS) stejně: 13 OFDMA 61.8~87.0 16_QAM 40.2/100.2 SUCCESS 14 OFDMA 108.5~203.3 16_QAM 40.2/100.2 SUCCESS 3 SC-QAM 51 64QAM 36.5/96.5 SUCCESS 4 SC-QAM 58 64QAM 36.8/96.8 SUCCESS 1 SC-QAM 38 64QAM 36/96 SUCCESS 6 SC-QAM 31 64QAM 36/96 SUCCESS 2 SC-QAM 44 64QAM 36.3/96.3 SUCCESS Je něco špatně? Fakt je, že i při pingování brány mám pořádný jitter, od ~3.5 ms do 16 ms. Rychlost uploadu v pohodě, fakt jen ty rozdíly v latenci / jitter...

UPC mi kdysi dávalo 4 veřejné IPv4 a Vodafone mi (aspoň ke gigabitu) stále dává 3. A jejich ztrátu budu považovat za dost zásadní downgrade služby (který budu mít problém skousnout, i kdybych na oplátku měl dostat dual stack).

Nic z toho, co popisujete, nemůže (rozumně/bez hacků) podporovat stávající funkcionalitu: Přidělování nepevných/dynamických adres více než 1 zařízení za modemem.

Protože ve VfS vyprší nacahovaný ARP záznam připojeného zařízení (který VfS z nějakého důvodu potřebuje, i když by v principu nemusel) a už se neobnoví - nejspíš protože zařízení už má (narozdíl od startu, kdy modem přiděluje dočasné adresy ve svém 192.168.100.0/24 subnetu) přidělenou veřejnou / Vodafone interní IP z jiného subnetu a mnoho zařízení ignoruje ARP requesty mimo vlastní subnet. V linuxu se toto nastavuje pomocí arp_ignore: https://sysctl-explorer.net/net/ipv4/arp_ignore/ - hodnoty 0 a 1 budou fungovat, ale 2 ne...

Ale momentálně mám 3 adresy, na základě čeho se budou přiřazovat (a čemu? jsem v bridge mode, VfS používám jen jako modem)? Jestli jde jen o změnu MAC adresa -> DHCP client ID (což je v mé konfiguraci stejně taky MAC adresa) nebo něco, tak budiž, to pak nemění na věci skoro nic, ale když tři různá zařízení požádají o DHCP lease, na základě NĚČEHO se mezi něma rozlišit musí...

Doufal jsem aspoň v jeden 2.5GBASE-T port, jako u T-Mobile. U gigabitu by tím člověk získal 40-70 Mbps downloadu navíc - a taky jsem doufal, že multigigabitová budoucnost je blíž (ale je fakt, že nejpalčivější problém je teď tragický upload).

Mně (Brno u Lužánek) nabízí 100Mb jen T-Mobile, Vodafone ne... 🙂 Škoda té absence veřejné IPv4...

Ujistěte se, že router/zařízení připojené k VFS odpovídá na ARP requesty tazatelů, kteří nespadají do sítě/netmasky přidělené (veřejné nebo Vodafone interní) IP. Spousta zařízení tyto ARP requesty (po právu, normálně by ARP měl operovat jen v rámci sítě) zahazuje a pak komunikace s 192.168.100.1 přestane fungovat, jakmile router/zařízení dostane IP od VF DHCP serveru. V Linuxu (a potažmo OpenWRT, Turris atd.) je tak třeba zajistit, že https://sysctl-explorer.net/net/ipv4/arp_ignore/ nemá pro all ani daný interface hodnotu 2.

Nemáte, lišíte se v aktivním CSC (jestli se tomu ještě tak říká), což je branding/konfigurace od operátora a právě tím to možná bude. VDC - český Vodafone, EUX - EU univerzál. Myslel jsem teda, že čeští operátoři jsou v EUX už zahrnutí všichni tři, ale možná tomu u S23 tak nebude (já mám T-Mobile, S23 Ultra koupené v CZC, telefon zůstal na univerzálním EUX i po vložení SIMky a VoLTE normálně funguje). Každopádně tyhle problémy nastávají (a nastávaly hlavně v minulosti, když každá kombinace země a operátora měla vlastní CSC), když někdo zapnul zařízení bez SIM karty a po vložení SIMky odmítl factory reset (který změní CSC na to, které odpovídá SIMce). Tj. zkusil bych reset do továrního nastavení, popř pak existují (nebo aspoň existovaly) další způsoby, jak CSC změnit.

Teď jsem to zkoušel (přivěsil jsem několik macvlan interfaců na wan): S gigabitem a VF Station dostávám 3 veřejné IP. 4. MAC adresa má už smůlu... 🙂 V dobách 300mbitu a Ubee modemu jsem měl tuším 4.

Taková věc, na kterou jsem přišel: Pokud používáte VS v bridge/modem režimu a po získání veřejné IP adresy přes DHCP nefunguje administrace na 192.168.100.1, problém může být v tom, že zařízení, kterým (resp. skrz které) se na administraci připojujete neodpovídá na ARP requesty modemu - typicky protože 192.168.100.1 je mimo subnet přidělené veřejné IP. V Linuxu tomu odpovídá net.ipv4.conf.{all, interface}.arp_ignore, hodnota 2 způsobí, že se ARP requesty modemu budou zahazovat. Některé routery/zařízení se takhle zřejmě chovají by default.