DiDiDi

Samsung, Google atd. s AI features v EU problém nemají...

Hlavní pointa šifrování DNS requestů/responsů je, aby je ISP neviděl...

HDCP přináší problémy, i když člověk má moderní GPU i monitor. Multimonitor nebo (nedejbože) multiGPU setup ve Woknech, Linux, adaptéry/splittery HDMI/DP atp. Můj monitor HDCP umí jen na některých vstupech (a ne v nejnovější verzi, což je u ne4k monitorů celkem normální, protože používají starší verze HDMI i DP, anžto nepotřebují bandwidth těch novějších). Taky MUSÍTE použít HW dekodér v GPU, se SW dekodérem to nefunguje.

? Kdyby byla možnost si pronajmout/koupit pouze DOCSIS 3.1 modem/bridge za menší prachy, tak to udělám, ale ta pokud vím u Vodafone není (naposledy DOCSIS 3.0 modem-only v dobách UPC).

Jestli mi seberou současné 3 veřejné (dynamické) IPv4, tak budu hodně mrzutý. Snad za to nabídnou aspoň full dual stack a stále aspoň tu jednu IPv4... A taky doufám, že se do té doby rozhoupe T-Mobile s IPv6 na mobilní síti. Pořád mi přijde vtipné, že kdybych měl v současnosti T-Mobile na mobilu i doma, tak se domů nepřipojím.

Jak to mám vědět? Já vidím jen mizerný (vzhledem k bitratu) výsledek. H264 při daných bitratech rozhodně může vypadat líp.

Pěkné, tj. kdyby to oboje bylo 1080p (což není, H264 je interlaced) a H264 enkodér použitý ČT nebyl takový paskvil (což bohužel je), tak by to při daných rozdílech v bitratech mohlo vypadat +- podobně kvalitně, možná kromě Sportu, kde HEVC s pouze o ~1,3 Mb/s nižším bitratem bude asi lepší každopádně. Za stávajících okolností (1080i + mizerné enkódování do H264) to bohužel vždy vyhraje HEVC (viz to staré vlákno). A samozřejmě platí, že se stejnými bitraty by HEVC bylo lepší ještě výrazně víc...

Úspornou patlaninou? 😄 H265 (za předpokladu použití rozumného enkodéru a rozumného nastavení) je za stejného bitratu vždy lepší než H264 (v podstatě s libovolným enkodérem). Jediná slabina H265 oproti H264 je výpočetní složitost a kompatibilita. A terestrální ČT mux je za všech okolností (během regionálního vysílání a mimo) vždy lepší obrazové kvality, než kabelový/satelitní, aspoň ČT Sport a ČT24, ale předpokládám, že i zbytek. Byť by ten rozdíl nemusel být takový, kdyby H264 verze používala nějaký lepší enkodér. Např. i ve srovnání s jinými H264 muxy je ten ČT horší.

V nějakém vlákně pár měsíců dozadu se toto řešilo. Kabel (VF) a satelit (Skylink) opravdu mají identický 1080i h264 mux/stream MIZERNÉ kvality - teď neřeším vysílání v době regionálního vysílání, ale běžné vysílání, které vypadá prostě špatně (artefakty, kostičkování) vzhledem ke kodeku a bitratu (h264 při daném bitratu rozhodně může a má vypadat o dost lépe). @Ondra - VodafonePokud tvrdíte, že toto 1080i h264 je LEPŠÍ obrazové kvality než 1080p h265, co je v terestrálním vysílání, tak jste se museli naprosto zbláznit. V pohybu (např. na sportovním kanálu) vypadá terestrální vysílání tak očividně a znatelně líp, že Vaši odpověď mám problém brát vážně... 😄 Během hokeje dokonce vypadal znatelně lépe ČT Sport ve vašem DVB-T bloku, což je reencode terestrálního vysílání do 1080i h264 s nižším bitratem než to co je v kabelu/satelitu. Tzn. váš h264 enkodér je zjevně o dost lepší, než ten ČT. Předpokládám, že reálný problém je ten, že z důvodů kompatibility nemůžete přejít na h265, takže prostě ten druhý lepší zdroj bez reenkódování použít nemůžete. Lepší ale opravdu není (kromě kompatibility)... Co se týče zvuku, ta 5.1 AC3 se mi zdá identická (bitrate atd.), takže předpokládám jde o tu stereo stopu (MPEG2 vs AAC, tuším).

??? Minimálně pro ČT Sport (během MS v hokeji) jsme toto na jiném vlákně řešili, terestrální verze byla o parník lepší. A taky to je (resp. aspoň během MS bylo) plnohodnotné 60p (ale např. při elektronické tužce ve studiu používali zjevně interlaced záznam). A i kdyby to bylo prokládané, H265 stream je MNOHEM kvalitnější, zejména kvůli tragické kvalitě H264 enkodéru, co ČT používá... Každopádně by mě (ještě jednou) zajímalo, s čím @Ondra - Vodafonesrovnává.

@CableGTo mě zajímá! Mám stále "gigabit napořád" 1000/50. Jak se "to ukázalo"? Měl jsem za to, že bych musel zvolit aktuální gigabitový tarif...

Vyšší než co? Terestrální/DVB-T2 H265 má rozhodně lepší kvalitu než satelit/kabel...

Nejde o žádný hack. Je to prostě nastavení chování ohledně ARP protokolu. Linux ve výchozím nastavení (arp_ignore=0) by měl bezproblémový přístup na web interface umožnit, jiné OS (popř. linuxová distra/routery, kde arp_ignore nastavili na jinou hodnotu) typicky ne. Tohle téma (přístup na web interface VFS) se tu již objevilo Xkrát (a ještě asi mnohokrát objeví), části lidí to vždycky funguje a části ne, podle mě právě proto, že různá zařízení (routery) jsou v tomto nastavená různě. Taky to může být o firewallu (nebo o fw a ARP zároveň), nemusí se líbit, když na WAN interface s IP z veřejného/internetového rozsahu přijde něco z 192.168.x.y... Je to určitě o firmwaru, v principu modem nemusí uchovávat nacachovaný ARP záznam připojeného zařízení, aby to fungovalo, Compal a další modemy tenhle problém neměly. Ale oba moje VFS, co jsem měl (jeden odešel), se chovaly takhle.

A bránu má nastavenou jak? Tuším standardně se ještě odpovídá na požadavky se source IP brány, bez ohledu na subnet. Plus teď si ještě čtu o ARP probe, která source IP (protocol address) nemá nastavenou vůbec a gratuitous ARP, tohle všechno může teoreticky způsobit, že nějaké první ARP requesty/responsy při startu modemu/routeru projdou, ale pak už ne... Jak chcete, za zkoušku s nějakým Linuxovým LiveCD nic nedáte, ale je to samozřejmě na Vás. Jsem zvědavý, jestli výměna pomůže.

@pmalecekJeště jednou si přečtěte můj starší příspěvek. Problém je v nastavení zařízení připojeného k modemu (pokud napřímo počítač do modemu, tak počítače, pokud to jde přes router, tak nastavení routeru), resp. faktu, že VFS vyžaduje ARP záznam připojeného zařízení, i když by nemuselo a nachází se v jiném subnetu... Windows tuším na ARP requesty z jiného subnetu odpovídat nebudou a asi to nejde změnit, takže pokud máte počítač připojený napřímo, tak to s Widlema prostě asi fungovat nebude... Leda zkusit nějaké live distro Linuxu nebo něco - a pohlídat si firewall a zejména nastavení arp_ignore: sysctl -a | grep arp_ignore To, co popisujete (chvíli po přiřazení veřejné IP to funguje, ale po chvilce ne), je přesně ono, v modemu po nějaké době vyprší starý ARP záznam počítače/routeru, který si to pamatuje z doby, kdy ještě všechna zařízení byla ve stejném subnetu, tj. s odpověďmi na ARP requesty nebyl problém, ale pokud nemáte připojený počítač/router nastavený tak, aby odpovídal i na ARP dotazy se zdrojovou IP adresou mimo subnet připojeného počítače/routeru, tak to prostě přestane běžet.