Hlavní navigace

Vlákno názorů ke zprávičce Raspberry Pi TV HAT umí přijímat DVB-T2 od darebacik - Ono to tu uz bolo spomenute. RPI +...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 19. 10. 2018 12:13

    darebacik

    Ono to tu uz bolo spomenute. RPI + DVB-T2 tuner by v tomto pripade mal sluzit ako DVB-T2 server. RPI nic nemusi prehravat, len vezme DVB stream a prekonvertuje ho do IP streamu. Potom na kazdom zariadeni v sieti, ktore pozna prislusny protokol sa bude dat stream prehrat.
    Dolezite je povedat, ze jeden DVB-T2 adapter pokryje jeden multiplex. Ak sa to pouzije na jeden TV (zobrazovac) tak je to OK. Ak mate v domacnosti viac TV (zobrazovacov, tablet, tv, pc,smartfon, ntb atd ....) a chces sledovat program z ineho multiplexu, tak to nepojde.
    A co sa tyka tvheadend, tak ten nevie multicasting, takze sledovanie jedneho kanalu na viac zariadeniach, traffic znasobuje.
    Chcelo by to skor dvblast, ktory multicast vie (+ samozrejme router s igmp)

  • 19. 10. 2018 12:59

    Petr M (neregistrovaný)

    No ten multicast v LAN stejně nepomůže. Agreguje provoz před routerem a router ho rozesílá dalším routerům, nebo koncovým zařízením. Takže to vypadá tak, že do baráku by čel jeden stream a rozdělil se třeba na pět kopií v rámci LAN. Pokud streamuješ přímo v LAN, stejně musíš posílat pakety individuálně na každou MAC adresu s registrovaným odběrem.

    To bys musel vysílat do VLANy, kterou rozstřelíš až na routeru. Teda ne že by to nebylo, vzhledem k LAN na USB2, celkem praktický z pohledu provozu...

  • 27. 10. 2018 7:48

    František Ryšánek

    > No ten multicast v LAN stejně nepomůže. Agreguje provoz před routerem
    > a router ho rozesílá dalším routerům, nebo koncovým zařízením.
    > Takže to vypadá tak, že do baráku by čel jeden stream a rozdělil se třeba na pět kopií v rámci LAN.
    > Pokud streamuješ přímo v LAN, stejně musíš posílat pakety individuálně na každou MAC adresu
    > s registrovaným odběrem.
    >
    Je to trochu jinak.
    IP multicast cílová adresa (a.k.a "multicast group") se v LAN mapuje na L2 multicast mac adresy. (Je tam jakési překryvné / neunikátní mapování, protože tuším těch L2 adres je míň než L3 "multicast groups", ale to sem teď netahejme.)
    Hloupý L2 switch, který neumí s multicastem inteligentně pracovat, pracuje s multicastem jako by se jednalo o broadcast. Bavíme se o zpracování cílových adres paketů a forwardovací rozhodnutí.

    Čili první korekce z mé strany: směrem do LAN se provoz nerozplétá (nenásobí) na několik unicastů, pouze se v horším případě v konečném důsledku tupě broadcastuje na všechny porty. Šířka pásma se nenásobí.

    Aby fungovalo "přihlašování příjemců do multicastových skupin" (přihlašování k odběru "na konkrétní multicastovou L3 adresu"), toto v LANce na L3 zajišťuje protokol IGMP. On multicast může jistě fungovat i bez IGMP, ale v tom případě se bude efektivně jednat o broadcasting a prostě který klient si ten provoz zpracuje a který ne, to už je jejich věc (softwarově ten paket musí vzít do ruky každej, což znamená zátěž pro "nevinné kolemjdoucí", pokud si multicast nějak neofiltrují s offloadem filtru do hardwaru).

    Ono je to nakonec úplně přesně tak, že na hloupém L2 switchi se stejně bude mcast broadcastovat, i pokud L3 příjemci zdvořile používají proti lokálnímu L3 multicast routeru IGMP. Prostě jakmile se přihlásí první příjemce, dostane výsledný multicastový stream celá LANka, jakoby se jednalo o broadcast.

    Pokud si ovšem pořídíte LAN switch, který umí IGMP *snooping*, můžete dosáhnout toho, aby i v LANce multicastový provoz dostávali pouze ti klienti, kteří si o něj explicitně řeknou. L2 switch lstivě naslouchá vrstvě L3 (IP) a pokud detekuje IGMP paket, tak si ho podrobněji rozebere - a řídí se "přihláškami" IGMP klientů k jednotlivým "multicast groups", tzn. následně podle toho forwarduje L2 multicast traffic. Tato fičura je výsadou "managed" L2 switchů, a to možná nikoli všech. Minimálně u levných kancelářských web-smart krabiček bych IGMP snooping úplně nehledal. Pokud tuhle schopnost potřebujete, hledejte ve specifikacích. Průmyslové managed switche IGMP snooping obvykle "umí", a snad jsem viděl i nějaké levné primitivní varianty téměř bez managementu, například bez podpory VLAN, které zrovna IGMP snooping podporovaly.

    Jeden populární zádrhel pro začátečníky spočívá v tom, že pokud zapnete na switchi IGMP snooping, tak Vám přestane fungovat multicastový provoz mezi účastníky, kteří IGMP řádně nepoužívají. A některé switche mají IGMP snooping ve factory defaultech zapnutý. Zbytek toho vtipu si asi domyslíte...

    Kromě toho ještě existuje scénář, kdy by si multicastoví klienti rádi říkali o příjem multicastu pomocí IGMP, ale "zdroj streamu" na své straně IGMP neumí :-) Třeba protože je pouze přímým zdrojem mcast paketů (IQ tykve) a neběží na něm L3 multicast routing služba, která by se o IGMP postarala na serverové straně. Resp. OS, ve kterém běží zdroj mcast trafficu, nemá zabudovanou podporu pro IGMP na "serverové straně". Pro tyto případy některé switche nabízejí službu "IGMP querier". Jako že switch to IGMP bude pást v zastoupení za hloupý a neschopný zdroj multicast provozu.
    A někdy je k vidění i podrobnější per-port konfigurace.

    Fičurky IGMP snooping a querier jsou obvykle k dispozici pouze na switchích, které umí management včetně podpory VLAN. A potažmo lze tyto dvě multicastové vlastnosti zapnout/vypnou­t/provozovat per VLAN.

    Čili sumárum: i v LANce je možné, aby multicast provoz tekl jenom k tomu, kdo si o něj řekne, aby se nic nejen že neduplikovalo unicastem, ale dokonce aby ani "nezúčastnění" nebyli obtěžováni objemem irelevantních "broadcastů". Je k tomu potřeba trochu slušný managed L2 switch, a je k tomu potřeba podpora IGMP od všech zúčastněných.

    Mimochodem pro multicast routing mezi L3 routery existují protokoly DVMRP a PIM.

    A poté co se pokusíte něco takového si postavit, můžete s úžasem zjistit, že dodnes, po 20+ letech používání / ustalování / skoro žádného vývoje, je v tom u různých výrobců dodnes spousta bugů, nedodělků, částečné podpory, rozdílných přístupů a vzájemných nekompatibilit. Takže pasivní sondu, wireshark pod Linuxem a hajdy ladit :-)

    V tomto světle, jestli TVheadend jede jenom unicastem, tak mě to vlastně nepřekvapuje. Ono už jenom když uvážím schéma, že by si klienti říkali headendu "já chci přijímat tenhle TV kanál" a on by odpovídal "fajn, chytni si ho na multicast grupě xyz", přičemž by pro každý TV kanál otevřel právě jednu skupinu, ale až pokud ten kanál někdo bude chtít... Je pro to nějaký standard?

  • 19. 10. 2018 13:29

    SB (neregistrovaný)

    Vzhledem k tomu, že ten H265 musím stejně někde dekódovat, abych nemusel kupovat novou bednu, tak mi řešení se streamováním multiplexu nijak nepomůže. A to se nebavím o tom, že 1 multiplex zaráz je málo.

  • 19. 10. 2018 13:35

    Petr M (neregistrovaný)

    No ono by se to hodilo, pokud jako set-top-box chceš použít HTPC a náhodou k TV máš místo koaxu UTP. Nebo pro každý MUX jeden a obsluhovat tak někde v hotelu 20 pokojů, kde už HTPC všude je, ale TV neznají T2. Ale to už je celkem divoký use case...