matteocontrini Era un

simonebortolin magari via RTSP

dopo che lo hai nominato tu, nel senso che era una ipotesi, so che l'RTSP non essendo incapsulato via http permette il multicast, ma la mia è una ipotesi, infatti avevo scritto anche di BCC che usava pacchetti DASH multicast non so bene come.

matteocontrini Bitmovin Developer Report 2020, HLS 79%, DASH 65% (ricordavo di meno). HLS è d'obbligo se hai un'app iOS, DASH è d'obbligo se il target sono le smart TV. Ma DASH implica anche questioni di royalty, quindi se il target sono app mobile e browser conviene usare HLS, a meno che non ti serva DRM o altro. È il mio day job quindi ho dovuto fare questa scelta anche io.

79+65%😃 Ok

So di iOS e delle SmartTV, per questo pensavo fosse il contrario.

Comprendo in pieno.

edofullo Poi vorrei provare a configurarlo sul Mikrotik, se non fosse che gli indirizzi 10.10.10.0/30 sono esattamente gli stessi che uso come loopback per IPSec, che quindi dovrei riconfigurare...

Noo
🤣

edofullo @matteocontrini si può spostare l'ultima parte in una discussione più appropriata? Sarebbe interessante continuarla

concordo.

    simonebortolin 79+65%😃 Ok

    La somma non deve fare 100, immagino che non siano mutuamente esclusivi.

      edofullo La somma non deve fare 100, immagino che non siano mutuamente esclusivi.

      Quindi non è la percentuale di diffusione, ma bensì la percentuale di adesione.

        @matteocontrini @gandalf2016 come posso esservi utile?

        la situazione attuale è che a me il multicast non sta funzionando... si vedo i contatori del demone m-abr sul timbox che salgono numericamente ma salgono troppo lentamente ed "a prescindere" da quello che si vede.
        Per quanto riguarda ssh/telnet le porte apere sono queste:
        Starting Nmap 7.91 ( https://nmap.org ) at 2021-08-22 12:24 CEST
        Nmap scan report for 192.168.1.202
        Host is up (0.00032s latency).
        Not shown: 65524 closed ports
        PORT STATE SERVICE
        6466/tcp open unknown
        6467/tcp open unknown
        8008/tcp open http
        8009/tcp open ajp13
        8012/tcp open unknown
        8443/tcp open https-alt
        9000/tcp open cslistener
        9080/tcp open glrpc
        10101/tcp open ezmeeting-2
        33111/tcp open unknown
        60221/tcp open unknown

        nessuna risponde alla chiamata ssh root o telnet...

        lo schema della mia connessione attuale è ONT HUAWEI -> SWITCH ES-16-XG -> TIM HUB ->TIMVISIONBOX.
        probabilmente devo forzare igmp V2 sullo switch per farlo funzionare... igmp proxy sulla vlan 836 impostata.
        Se funzionasse non sarebbe complicato fare cattura di pacchetti😅

        Se riesco ad avere 20 minuti consecutivi liberi posso provare a bypassare del tutto lo switch e vedere se cambia qualcosa. In caso affermativo collegherei subito il draytek come router forzando i pacchetti da e per il timvisionbox sulla wan dell'ont tim e farei packet capture...
        In questo momento, secondo le mie modeste competenze, è lo switch che mi blocca il multicast... Infatti (sul draytek) provando ad abilitare la wan "virtuale" per iptv multicast sulla vlan 836 non riceve un c@z:

        Si accettano suggerimenti su come configurare lo switch per fargli fare da proxy multicast igmp V2🤔
        Non accetto di sprecare una connessione ftth solo per il timvisionbox...

          simonebortolin Quindi non è la percentuale di diffusione, ma bensì la percentuale di adesione.

          È l'uso delle tecnologie da parte di chi fa streaming video. Si possono ovviamente usare entrambe (e a volte non c'è scelta per i motivi sopra). Poi cosa viene usato client per client è effettivamente un'altra storia ma più difficile da valutare. A me nei browser sembra di vedere di gran lunga più HLS che DASH...

          DrGix perché lo switch dovrebbe bloccarlo?
          Al massimo fa broadcast su tutte le porte se non supporta snooping.

          Dovrebbe funzionare se passi in tag la vlan 836 e 835 all ONT e anche al TIMHUB, come penso tu stia facendo.

          Poi hai connesso diretto al Tim hub il TIMVISION box (o c’è altro in mezzo ?)

          A questo punto mettendo in port mirroring la porta dove è connesso il tim hub verso una dell’edgeswitch dove collegherai il tuo PC con wireshark dovresti catturare tutto.

          Al draytek invece passerai solo internet con la 835, lasciandolo fuori dal multicast

          Segue che il TIMVISION sarà isolato su un suo segmento L2 da tutta la rete e andrà su internet con una sua PPP fatta dal TimHub + multicast.

          • [cancellato]

          • Modificato

          handymenny Insomma hanno reso proprietario e a pagamento udpxy/gigapxy con un pelo di scripting per pubblicare gli stream sottoscrivibili?

          @matteocontrini

            simonebortolin Oddio io ho sempre sentito che era meglio AVC1 che HEVC

            Forse stai facendo confusione con AV1 che al momento non è adottabile su larga scala perché sono davvero pochi i dispositivi che supportano l'accelerazione video per questo formato.

            AVC1 è H264.

              [cancellato] è un po' più complicato, questo è ABR, c'è lo switch tra risoluzioni che sono flussi diversi, non la vedo banale

              Pytony98 anche tu te le cerchi usando il codice fourcc ahah

              EDIT: no forse non è nemmeno quello

                • [cancellato]

                • Modificato

                matteocontrini è un po' più complicato, questo è ABR, c'è lo switch tra risoluzioni che sono flussi diversi, non la vedo banale

                "Semplicemente" spari più flussi Mcast a risoluzioni diverse e invii al client-proxy una playlist con i vari bandwidth e corrispondenti indirizzi su cui sono disponibili i flussi; se i pacchetti persi superano una certa soglia, il proxy passa al flusso a bitrate inferiore.
                Non è magia...

                  Pytony98
                  🤣🤣🤣🤣🤣letto male 🤣🤣🤣🤣

                  Opps non ho neanche notato che c'era la C avevo letto AV1 🤣🤣🤣🤣
                  Potevi scrivere AVC 😉

                  [cancellato] non funziona così, è il player a fare una stima della banda in base alla velocità di download dei segmenti e l'agente deve essere completamente trasparente facendo credere al player che sia una CDN e non un server web in rete locale. Quando il player inizia a richiedere segmenti video di un'altra variante (anche mentre sta ancora scaricando la variante precedente), in modo trasparente l'agente deve adeguarsi. È una cosa complicata da calibrare già normalmente con HTTP, e penso lo dimostrino ampiamente i problemi che si hanno senza M-ABR, quindi l'agente deve essere perfetto nell'astrarre il multicast in modo che non rompa algoritmi, euristiche e assunzioni che tutti i player fanno (e in modo diverso, più o meno schizzinoso/conservativo, ecc.). Sviluppare software non è questione di fare due script con ffmpeg, se poi vi sembra tutto così semplice fate una versione open source e vediamo come andrà bene, aspetto 😉

                  Ho il tim hub e il tim box android 8, il multicast con nanocdn funziona anche se il box è collegato a un wifi extender o a una powerline sempre in wifi?

                  L'app per le smart tv non supporta ancora nanocdn? Il tim box lo vedo molto poco performante con diversi microstutter durante la visione.

                    arthem56 Ho il tim hub e il tim box android 8, il multicast con nanocdn funziona anche se il box è collegato a un wifi extender o a una powerline sempre in wifi?

                    arthem56 L'app per le smart tv non supporta ancora nanocdn? Il tim box lo vedo molto poco performante con diversi microstutter durante la visione.

                    Dovrebbe supportare nanocdn

                    simonebortolin su telegram diceva che era un bug.

                    Esatto, penso sia un bug della GUI. Ho già scalato la questione e sono in attesa di riscontro.

                    ho provato a inserire sul 7530 poi vediamo stasera se il monitor mostra qualcosa, ieri durante la partita dell'Inter era su 8-10 in download con colore giallo (Internet download) e no IPTV.

                      Da digital forum:

                      se hai il TIM box e abbonamento Dazn, metti un evento live e nel registro degli eventi dovresti avere una voce relativa a IGMP active.

                      Altri spunti interessanti:

                      "Le versioni sono sempre retrocompatibili, per cui un dispositivo IGMPv3 supporta automaticamente anche le versioni 1 e 2."

                      Mi domando ma se la versione IGMPv3 è retrocompatibile, mi si deve spiegare:

                      1) perchè TIM ha deciso di utilizzare IGMPv2;

                      2) perchè si è data un cosi gran da fare, affinchè su alcuni FritzBox! 7590 di propietà è andata a modificare questo parametro IGPM da 3 a 2;

                      3) TIM si è posto il problema che una volta aggiornato questo IGMPv2 con la versione 7.28 del FritzBox! 7590, rilasciata a poco più di tre giorni da quella di TIM, di fatto, il parametro è tornato a IGMPv3.

                      I modem di proprietà devono essere configurati per il multicast di tim e poi(forse) funziona con timbox

                      Sempre da digital forum è emerso che i setting rilasciati da TIM per il multicast senza nano-cdn NON VANNO USATI con connessioni Wi-Fi.

                      Confermo il funzionamento del multicast sul Fritz box 3490 con le modifiche sopracitate, il traffico viene letto come IPTV dal monitor del consumo di bandwidth.

                      Grazie a chi ha estrapolato e condiviso le righe di codice.

                        Pytony98 condivido grazie per le info

                        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