Per il multicast in senso stretto, passo, se non altro per non dire imprecisioni.

Per lo streaming, il multicast si scontra con il modello con cui viene fatto streaming di solito, cioè l'Adaptive Bitrate Streaming su HTTP. C'è, in breve, un file di manifest che elenca le varianti video disponibili per un determinato contenuto, con potenzialmente tracce audio e di sottotitoli multiple (alternative). Il client poi va a scegliere tramite algoritmi complicati (e imperfetti) qual è il flusso migliore e scarica i segmenti video. C'è tutto un filone di studi su questo problema. Il fattore principale preso in considerazione è chiaramente la banda Internet che si ha a disposizione sul client, che viene continuamente stimata in modo da evitare il buffering.

Il player quindi switcha più o meno frequentemente (in base agli algoritmi sopra, che a volte lasciano il tempo che trovano) il flusso cambiando di fatto la qualità di visione. Ovviamente lo fa anche DAZN, e finora se non sbaglio arrivava al massimo a 720p/50 con circa 7 Mbps (bitrate abbastanza alto pur trattandosi di sport). Se tu hai 20 Mbps di connessione, non è però detto che resterai sempre sul flusso da 7 Mbps, perché ci possono essere problemi transitori o saturazione a qualche livello.

Ora, però, questa cosa non funziona con il multicast, perché questo modello è di tipo "pull", cioè il client apre connessioni TCP verso il server (la CDN) e scarica piccoli file video continuamente. Il multicast usa un modello opposto, cioè tu ti "iscrivi" a un gruppo e ricevi poi i relativi pacchetti. E arrivano e basta, uguali per tutti.

L'"ABR multicast" che è stato menzionato dovrebbe combinare le due cose, anche se non ho ancora del tutto chiaro come funzioni. Quello che capisco io dalle poche informazioni che si trovano online, e potrei sbagliarmi, è che il TIMVISION Box costruisce on the fly questo manifest, nascondendo il fatto che dietro ci sia una trasmissione in multicast. È circa come avere una CDN in casa, solo per il tuo dispositivo. Mi sembra l'unico modo per utilizzare i player esistenti e sfruttare lo streaming ABR come spiegato sopra, senza stravolgere troppo il client. (Non mi risulta esista un protocollo di streaming compatibile con multicast che abbia anche la componente "adaptive".)

A questo punto la trasmissione video in multicast tra cloud e Box avviene con un qualche protocollo adatto al multicast e a questa conversione (packaging), garantendo tutte le funzionalità richieste come DRM, trasporto sicuro, ecc.

Quando inizieranno le trasmissioni sarà più semplice verificare probabilmente. Se qualcuno ha qualche info più precisa già ora, sono curioso anche io. Ho un esame ciaooo

    [cancellato] TIM lo utilizzava con la vecchierrima offerta IPTV successivamente dismessa...

    Ah, la Alice Home TV... troppo in anticipo sui tempi per un paese come l'Italia.

    In due parole comunque, il concetto di multicast è che invece che aprire un flusso dal server al client, uno ciascuno, il server invia i pacchetti una sola volta per ogni "canale". Invece che uno a uno, è uno a molti (ma non uno a tutti, quello è broadcast).
    Lungo la strada, i router abilitati replicano i pacchetti sulle interfacce da dove hanno ricevuto richieste di visualizzare il contenuto, quindi:

    matteocontrini tu ti "iscrivi" a un gruppo e ricevi poi i relativi pacchetti

    Questo fa risparmiare banda lato server e trasporto perchè hai solo un flusso invece che x, tanti quanti sono i clienti che stanno guardando quel contenuto.
    In soldoni. Poi c'è il discorso dell'implementazione...
    Per richiedere i flussi, client e router dialogano usando IGMP (non ICMP, quello del ping). Il multicast se non specificamente abilitato non attraversa infatti i router, ma su richiesta il router fa da tramite e richiede al livello superiore di ricevere il "canale" (parlo di canale perchè di fatto puoi immaginarlo così).
    E qui si aprono varie speculazioni, come ad esempio riguardo quello che è successo ai FritzBox collegati su TIM nei giorni scorsi, perchè per far funzionare multicast è fondamentale che il router di casa sia configurato a dovere, uno per il supporto ad esso e due per il seguente motivo: aspetto interessante del caso specifico è che usando PPPoE di fatto non c'è più questa efficienza, perchè dal BRAS al cliente occorrerebbe n-uplicare i flussi dentro ogni chiamata PPP.
    Multicast ha più senso se la rete è IPoE, ancora meglio se arriva fino alle ONUCab.
    L'ipotesi plausibile IMHO è che TIM avrà una VLAN dedicata per il trasporto video multicast usando DHCP e IP privati, la stessa cosa che accadeva con la Alice HomeTV piuttosto che la TV di Fastweb e vari altri precedenti tentativi di vendere TV via cavo in Italia (mai decollate). Quindi lato WAN ipoteticamente il router avrà due interfacce virtuali, VLAN 835 la classica dati con PPPoE e (invento, non so il numero) VLAN 635 con DHCP per il video. Questo renderebbe anche fattibile tecnicamente l'accesso alla VLAN multicast per i clienti di altri OLO, basta che TIM abiliti dalla ONUCab la VLAN tagged necessaria (e ovviamente OLO configuri tutti i suoi router adeguatamente per usufruirne). Il rebus saranno i router liberi che non possono ricevere comandi di telegestione, per cui potenzialmente il multicast potrebbe anche non funzionare proprio.

      x_term pregiudica il delay della diretta? Non sarà mai live come TV questo ok.

        x_term Sì la 836 su Tim era già esistente da tempo (User VLAN Video Unicast), ben prima che si iniziasse a parlare di dazn.

          • [cancellato]

          • Modificato

          spywork

          Se fatto bene è più efficiente per questo uso dell'unicast, e volendo è più semplice fare QoS per ridurre la latenza, senza impattare in maniera eccessiva sul resto del traffico.

          Rimane comunque diverso dal trasmettere un puro segnale video, ma anche il satellite ha già inevitabilmente una latenza più elevata sia per la necessità di codificare/crittare che per le distanze in gioco.

          Però farlo bene non è banale, specialmente poi con la pletora di router consumer in circolazione.

          Ma una cosa che mi chiedo, quanto è "adattivo" il multicast?

          Nel senso con lo streaming classico tra buffering e cambi molto repentini (in caso ci sia bisogno) del flusso video, si riesce a garantire direi tranquillamente una esperienza senza blocchi.
          Invece col multicast? Si riesce a cambiare velocemente il flusso a cui si è "abbonati"?
          Es. nel caso in cui il tim box sia collegato con un wifi abbastanza scadente

            • [cancellato]

            Beh ad esempio mi risulta che da standard la modalità mc non preveda controllo di errore quindi i pacchetti errorati sono scartati e non recuperati...

              [cancellato] se (molto) ipoteticamente si volesse fare la configurazione manuale di questa vln aggiuntiva, come si fa? la si mette di fila alla 835 per i dati, tipo 835, 836?
              voglio dire: chi è interessato al multicast del tim vision e ha il tr069 disattivato (e quindi si è risparmiato la piallatura di mamma tim), come lo configura sul fritz?
              (è solo curiosità, il calcio lo odio, ma mi interessa la tecnica)

                • [cancellato]

                • Modificato

                handymenny quanto è "adattivo" il multicast?

                Zero. Ricevi e basta, se il canale è saturo scarta i pacchetti.

                Poi si potrebbe ragionare su un client evoluto che possa scegliere tra più flussi (e quindi possa iscriversi a più gruppi multicast) passando dall'uno all'altro sulla base del bitrate che stima possa avere la connessione.
                Ovviamente il tutto funziona relativamente bene fintantoché c'è del sano QoS sotto (quindi forse fino agli ONUCab/OLT, se l'operatore arriva a fare la rete "bene"); ci fossero possibilità di QoS differenziati nel canale (quindi livelli di CoS differenziati e soprattutto onorati, che a mettere il byte giusto nei pacchetti è facile ma se nessuno lo guarda...) si potrebbero usare algoritmi di compressione video rate adaptive (i dettagli migliori hanno QoS inferiore, in modo da essere scartati per primi in caso di congestione).

                handymenny Invece col multicast? Si riesce a cambiare velocemente il flusso a cui si è "abbonati"?

                I tempi tecnici sono quelli di join e leave di un gruppo multicast, parliamo di millisecondi... ma il problema è che non hai un buffer o un segmento precedente da recuperare alla bisogna, quello che hai perso hai perso.

                handymenny il tim box sia collegato con un wifi abbastanza scadente

                Dimenticavo... Multicast/Broadcast e WiFi, anche no grazie.
                Tutti i pacchetti molti-ad-uno sono trasmessi, come i frame di management, alla minima velocità accettata dall'AP e soprattutto senza ACK/re-TX; i sistemi più evoluti (parliamo di fasce alto-SOHO a salire) n-uplicano il broadcast facendolo diventare traffico unicast per ogni subscriber, così da poter trasmettere a piena banda e soprattutto avere il controllo errore.

                Video (ha fatto svariati video sul multicast, tutti molto interessanti anche se non scende in modo esasperato nel tecnico-teorico, niente roba da CCNP per capirsi).

                [cancellato] La FEC è insita nel layer 7 per tutti i protocolli "transmission stream" (es. MPEG2-TS del DVB-T) 😉

                MircoT Ti servono come minimo due WAN/interfacce, dipende da come li chiama il router. Nei modem ADSL si parlava di PVC.

                  • [cancellato]

                  [cancellato] La FEC è insita nel layer 7 per tutti i protocolli "transmission stream" (es. MPEG2-TS del DVB-T)

                  Mi rifacevo con la memoria a quanto letto tempo dietro su alcune normative interne, probabilmente lo scenario di riferimento era differente, non saprei.

                  • [cancellato]

                  • Modificato

                  MircoT se (molto) ipoteticamente si volesse fare la configurazione manuale di questa vln aggiuntiva

                  No, devi avere un router che supporta la possibilità di avere PVC (Permanent Virtual Circuit) separati, ognuno con la sua VLAN. In pratica un PVC è una connessione logica con i suoi parametri (come l'ID della VLAN) sopra una connessione fisica (xDSL, GPON, ecc.).

                  Se vedi l'esempio sopra di x_term, in questo caso su ADSL con ATM, immagino, ci sono due PVC.

                  La sezione "IPTV" di molti router è di fatto un PVC separato, ma se non è possibile configurare correttamente almeno due PVC la vedo dura se il sistema usato è quello. Con il Fritz non ho la minima idea di cosa sia possibile.

                  [cancellato] Nei modem ADSL si parlava di PVC.

                  Il Draytek che uso le chiama "Multi-PVC/VLAN"

                  [cancellato] Ti servono come minimo due WAN/interfacce, dipende da come li chiama il router. Nei modem ADSL si parlava di PVC.

                  quindi come potrebbero aver operato sui fritz?
                  facendosi fare da avm un firmware custom con un pezzo di configurazione nascosto per adattarsi al mc dei tim vision?

                    • [cancellato]

                    MircoT Dipende se ha funzioni di IPTV o similari. Dato che non voglio nemmeno toccare una scatola di un Fritz, non ho idea francamente di cosa abbiano combinato.

                      usare na strada alternativa come Peer-to-Peer Streaming Peer Protocol (PPSPP)
                      RFC 7574 forse sarebbe stato interessante come studio.

                        • [cancellato]

                        MircoT Meglio prevenire. 😉

                        spywork
                        Definisci "live".
                        Non pensarai che digitale terrestre o satellite non introducano ritardi... 😄

                        Informativa privacy - Informativa cookie - Termini e condizioni - Regolamento - Disclaimer - 🏳️‍🌈
                        P.I. IT16712091004 - info@fibraclick.it

                        ♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile