La Fibre
Télécom => Télécom => 
TV et codecs => Discussion démarrée par: Optix le 12 juillet 2017 à 11:33:02
-
Optix, ce qui vas tuer le multicast, c'est le client qui ne va plus regarder de flux en direct, mais avec un léger différé.
C'est justement sur quoi j'ai travaillé : pouvoir gérer le différé en multicast (la contrainte étant de ne pas toucher ni à l'infra existante déjà en multicast et avec les boxs implantés donc, ni au provisioning des FAI), le tout, sans réencodage, sans consommer davantage de débit ou d'espace disque, ni rien. En gros le principe est de partir d'un flux live, et d'envoyer ça dans des "pipes" (en anglais)... avec de la rétention... comme Newsoo. Et avec les requêtes reçues lors du zapping, je peux "binder" comme je veux, autant de viewers sur une chaine et/ou un différé précis. En test actuellement chez un client, j'espère proposer ça aux autres opé dès que c'est concluant.
Donc "tuer le multicast", mouais, faut voir qu'on peut faire des trucs vraiment top avec ça si on creuse un peu :)
-
sans consommer davantage de débit ou d'espace disque [..] En gros le principe est de partir d'un flux live, et d'envoyer ça dans des "pipes" (en anglais)... avec de la rétention
De la rétention qui n'est pas stocké, tu la fait où, dans le cloud ?
-
De la rétention qui n'est pas stocké, tu la fait où, dans le cloud ?
C'est stocké en RAM, pas sur disque.
Dans le cadre de la TV sur multicast, le protocole sous-jacent est UDP, qui est basé sur le fait qu'une perte de paquet n'a aucun impact, aucune gravité
Ce n'est pas le cas pour de la télévision : l'IPTV est donc défectueuse, par essence.
En conséquence, et pour s'approcher d'un système fonctionnel, de nombreux ajouts sont nécessaire.
Bah là on voit bien le problème : tu considères d'emblée l'IPTV comme défectueuse. C'est dommge.
D'emblée, tu t'enfermes dans une stratégie de repli où tu dois contourner les problèmes, que tu n'aurais pas eu en prenant le truc à l'envers.
Pose toi la question comme ça : qu'est ce qui fait que l'IPTV marche bien ? Pas de perte, respecter l'ordre des paquets, etc. Si un équipement ou un lien mélange tes paquets, et que tu te forces à utiliser TCP pour résoudre ça, OK c'est une solution, mais perso j'aurais plutôt attaquer le problème en frontal que de le contourner.
Conséquence logique : l'interopérabilité est sub-optimale.
Oui, il faut éviter de cumuler équipement sur équipement, je te rejoins. De ce que j'ai vu, pour éviter les cascades, les gens transportaient ça en L2, et au bout, seul un équipement faisait le dispatching avec le protocole qui va bien. Ca évite pas mal d'emmerdes. Mais là aussi, ça nécessite de maitriser le lien qui transporte pour éviter que l'acteur de la couche d'en dessous mélange tout ça, j'avoue c'est pas simple à résoudre ça, mais ça se résout.
-
C'est stocké en RAM, pas sur disque.
Outch
Pour information, le replay Ksys sur 8 jours, c'est 45TB utile.
Moultes $$ en ram, mais ok !
Bah là on voit bien le problème : tu considères d'emblée l'IPTV comme défectueuse. C'est dommge.
D'emblée, tu t'enfermes dans une stratégie de repli où tu dois contourner les problèmes, que tu n'aurais pas eu en prenant le truc à l'envers.
Pose toi la question comme ça : qu'est ce qui fait que l'IPTV marche bien ? Pas de perte, respecter l'ordre des paquets, etc. Si un équipement ou un lien mélange tes paquets, et que tu te forces à utiliser TCP pour résoudre ça, OK c'est une solution, mais perso j'aurais plutôt attaquer le problème en frontal que de le contourner.
C'est la réalité.
Il y a des congestions. Il y a des mélanges de paquets.
Il y a des pertes de paquets.
Le sage dit que la perfection n'est pas de ce monde.
Les systèmes qui se basent sur le fait que "tout va bien" sont voué à l'échec, l'histoire le prouve, et c'est logique.
Bref, si tu as des propositions pour me garantir la non congestion, la non perte de paquet et la non altération des paquets sur un réseau de classe opérateur, je t'écoute, prodigue moi ta sagesse.
-
N'empêche qu'il y a des opérateurs qui y arrivent donc ça me semble exagéré de dire que le multicast est inutilisable.
-
J'ai pas très bien compris Optix,tu récupères un flux DVB, tu récupère un TS ? Tu l'injectes dans un broadcaster qui bind sur une adresse multicast et tu injectes ou ton délai ? Tu commandes comment tes requêtes sur le flux ?
-
J'ai pas très bien compris Optix,tu récupères un flux DVB, tu récupère un TS ? Tu l'injectes dans un broadcaster qui bind sur une adresse multicast et tu injectes ou ton délai ? Tu commandes comment tes requêtes sur le flux ?
Et tu as combien de flux multicast à la fin ? Si on considere 1 flux time shifté toute les minutes sur une profondeur conséquente, ça va finir par en faire un sacré paquet de flux et ça pour une chaîne.
-
Il y a 2 parties bien distinctes :
- la récupération et la rétention du flux
- la diffusion du flux différé
Cette dernière partie est la plus complexe, car différente pour chaque opérateur. Je dois limite réécrire le code qui gère la diffusion en fait.
Pour la récupération, c'est un "worker" qui lit le contenu TS et qui l'injecte dans un gestionnaire de queues style RabbitMQ, dans une file dédiée à la chaine avec un timecode en argument pour chaque morceau que j'injecte. Je mets une limite à cette file pour qu'elle supprime automatiquement les plus vieilles données pour laisser place à la nouvelle.
Dès qu'un worker qui écoute le zapping de sa chaine, voit un téléspectateur taper dans le différé, et qu'il est le premier, bah je demande au gestionnaire de me donner toutes les données entre 5min et 5min+1sec avant l'heure actuelle, et je diffuse vers une adresse multicast. Et c'est une boucle infinie qui s'opère, tant qu'il y a des gens qui regardent. La majorité du code source, c'est du feeder Newsoo. Si le peer est connecté, je lui lis ma file et je la vide, sinon je stocke les messages dans une file limitée, le temps qu'il remonte, pendant que de l'autre côté, je remplis mes files avec ce qui rentre. Je suis dessus depuis 1 an à peu près pour l'adapter à un système IPTV, c'est une belle reconversion :)
Après en pratique, ça dépend fortement des boxs TV et de l'infra. Par ex, là je compte combien de fois d'affilé tu demandes France2 (une fois, le live, 2x je te remonte 1min en arrière, 3x, 5min, etc), sans toucher aux boxs TV déjà en place. L'idée principale c'est de proposer du différé sur 1min, 5min, 10, 30, et 1h par défaut, des tranches définies par l'opérateur pour maximiser le visionnage et donc l'intérêt du multicast. C'est nettement plus pratique que le timeshifting local ou l'enregistrement qui demande au téléspectateur de configurer un disque ou autre, là il appuye 2x et pouf il revient en arrière. La seule modif d'infra est l'ajout d'un Mikrotik CCR qui me pousse les données de zapping pour démarrer mon worker de différé en temps réel pour ne pas avoir de délai de zapping supplèmentaire (si c'est le premier visionneur que je vois) et ça me permet aussi de remplacer via API le flux France2 live, par le mien en différé pour LA box concernée (l'adresse multicast provisionnée ne change pas, pas besoin de reboot la box, etc).
Maintenant que la solution est stable et qu'elle fonctionne bien, reste plus qu'à refaire une maquette-type pour les démos, écrire la doc puis à commercialiser le bordel pour le tout début d'année prochaine.
Et tu as combien de flux multicast à la fin ? Si on considere 1 flux time shifté toute les minutes sur une profondeur conséquente, ça va finir par en faire un sacré paquet de flux et ça pour une chaîne.
Le flux est créé à la demande. Si personne n'écoute, aucun flux n'est créé. Si une personne écoute, j'en créé un. Si une deuxième personne écoute, elle va taper sur la même adresse que la première et là commence le gain d'économies. Voilà voilà ;)
-
Hum
Mon avis se résume, je pense, en ceci : ce n'est vraiment pas scalable ..
(et ultra rigide d'un point de vu utilisateur, au passage)
-
Hum
Mon avis se résume, je pense, en ceci : ce n'est vraiment pas scalable ..
(et ultra rigide d'un point de vu utilisateur, au passage)
Par contre, ça peut être intéressant pour des usages pros, où on peut avoir besoin de serveurs de time shift qui ne coutent pas le prix d'une berline allemande avec les options
un truc tout con qui réponde à une requete igmp avec des ip ou des ports qui déterminent le retard désiré
voir une web interface qui détermine le retard par rapport à l'entrée.
là, je verrais plus des SSD que de la ram, c'est plus dans le moov actuel du milieu
-
Un SSD est limité en nombre d'écriture. La RAM est par contre limité en taille...
Avoir un différé de 1h sur un bouquet de 70 chaînes, cela en fait de la RAM...
Maintenant, je pense que ce qui bloque le plus c'est la contrainte coté client vs un style unicast où il est possible de faire pause (là c'est impossible de faire pause et de reprendre où on en était)
Une idée : Cela pourrait servir par contre pour diffuser des chaînes en J+1 avec un buffer de 24h.
Free avait de nombreuses chaînes en J+1 à une époque (et même des chaînes en J+2 , J+3, J+4 et J+5)
Bouygues Telecom a eu Disney en J+1
-
Une idée : Cela pourrait servir par contre pour diffuser des chaînes en J+1 avec un buffer de 24h.
tu as la même idée que moi....
-
Bonjour à tous,
Très intéressant ton projet Optix 8)
Je me tâte depuis plusieurs années à faire quelques chose de sympa qui dispenserais le client d'enregistrement et de TV linéaire.
Je dispose d'un serveur Anevia SAT->IP, d'un serveur et de STB Amino (4-5) et d'un petit DSLAM ;) .
Je bricole beaucoup pour apprendre en autodidacte comme par exemple faire des SVI, Automation TV, régie etc.
Bon, je suis une quiche en dev, c'est pas trop mon truc mais mon truc à moi, c'est de trouver les solutions et j'y arrive plutôt pas mal.
Tout le monde me surnommais Google en BAC pro c'est dire ;D
Bon, je suis pas là pour étaler ma vie mais j'ai quelques bonnes idées pour réaliser de beaux projets.
Au plaisir de partager avec vous tous des connaissances sur ce forum :)
Ps: c'est mon premier message qui sert un peu de présentation :D
-
/me se demande si on ne peut pas faire ce genre de chose avec tc + multicat
-
Bonjour à tous,
Très intéressant ton projet Optix 8)
Je me tâte depuis plusieurs années à faire quelques chose de sympa qui dispenserais le client d'enregistrement et de TV linéaire.
Je dispose d'un serveur Anevia SAT->IP, d'un serveur et de STB Amino (4-5) et d'un petit DSLAM ;) .
Je bricole beaucoup pour apprendre en autodidacte comme par exemple faire des SVI, Automation TV, régie etc.
Bon, je suis une quiche en dev, c'est pas trop mon truc mais mon truc à moi, c'est de trouver les solutions et j'y arrive plutôt pas mal.
Tout le monde me surnommais Google en BAC pro c'est dire ;D
Bon, je suis pas là pour étaler ma vie mais j'ai quelques bonnes idées pour réaliser de beaux projets.
Au plaisir de partager avec vous tous des connaissances sur ce forum :)
Ps: c'est mon premier message qui sert un peu de présentation :D
Anevia mon dieu... C'est français mais à part ça...
Ces gateways avaient un avantage, tu pouvais savoir à 10 mètres si elles étaient alimentées, au bruit
-
Eh bah, visiblement mon travail suscite beaucoup d'intérêt, merci à tous pour vos messages et vos mails :)
Avoir un différé de 1h sur un bouquet de 70 chaînes, cela en fait de la RAM...
Je remonte des stats de différé, même pour des chaines qui n'ont pas de différé activé. Ca permet à l'opérateur de choisir quelles chaines à mettre en différé en priorité selon le matos qu'il a. Après, ce n'est pas scalable en nbre de chaines et en durée (ça se travaille, mais personne m'a demandé de rationaliser ça). Par contre, en nbre de viewers ça défonce tout (c'est le but initial : que l'opérateur n'ait aucun flux supplèmentaire à transporter) :)
Maintenant, je pense que ce qui bloque le plus c'est la contrainte coté client vs un style unicast où il est possible de faire pause (là c'est impossible de faire pause et de reprendre où on en était)
Au contraire. Le recul montre qu'une fois que les gens ont compris le principe, ils utilisaient davantage le différé qu'avant, et sans rien avoir configuré au préalable.
Par contre, le différé "à la carte" avec l'unicast etc, tu le fais en local sur un petit HDD connecté à/dans la box. C'est plus pertinent et plus léger pour le réseau. Sinon ce n'est plus scalable si tu dois transporter autant de flux que de viewers.
Bon, je suis une quiche en dev, c'est pas trop mon truc mais mon truc à moi, c'est de trouver les solutions et j'y arrive plutôt pas mal.
C'est la plus grosse partie en fait : un worker qui lit le direct et remplit la file, un worker qui lit la file en arrière et la diffuse en multicast, un worker qui écoute les requêtes poussées par ton équipement, un worker qui injecte des règles à ton routeur. Il ne faut pas négliger le dev, car si tu arrives à maitriser le réseau et le dev, tu peux faire des trucs de fou, vraiment.
Une idée : Cela pourrait servir par contre pour diffuser des chaînes en J+1 avec un buffer de 24h.
Bof, plus ton différé permet de remonter loin, moins les gens remontent loin.
En revanche, on m'a demandé (avec insistance ^^) de bosser sur les flux Youtube pour les réinjecter dans l'IPTV classique. La demande est forte sur la convergence.
Donc ce sera amené à évoluer en appliance plus complète qu'un "bête" différé.
-
En revanche, on m'a demandé (avec insistance ^^) de bosser sur les flux Youtube pour les réinjecter dans l'IPTV classique. La demande est forte sur la convergence.
Donc ce sera amené à évoluer en appliance plus complète qu'un "bête" différé.
Moi on me demande avec insistance de décoder canal et be in sans payer mais je ne le fais pas.
Sortir des flux youtube ? Alors là c'est pas de la dev qu'il faut. Par contre une armée d'avocats et spécialistes juridiques du domaine serait à propos.
-
Une idée : Cela pourrait servir par contre pour diffuser des chaînes en J+1 avec un buffer de 24h.
Bof, plus ton différé permet de remonter loin, moins les gens remontent loin.
Enfin là le but, plus que le différé, c'est de regarder une émission régulière le soir le lendemain, car tu étais absent le jour J.
Là aussi, du coté des droits, je pense qu'il faut négocier auprès de chaque chaîne.
TF1 / M6 n'aime pas trop le différé, qui permet de sauter les publicités (il suffit d'arriver 10min en retard et quand la coupure pub arrive, tu passe sur le direct)
Par contre un différé de 24h oblige a regarder les publicités, donc je ne sis pas sur qu'elles soient contres.
-
Moi on me demande avec insistance de décoder canal et be in sans payer mais je ne le fais pas.
Arrête de me prendre pour un con, stp.
Ce n'est pas compatible avec les flux protégés, donc c'est déjà mort et il n'a jamais été question de ne pas payer. Donc évite de débiter de la matière fécale, stp.
Sortir des flux youtube ? Alors là c'est pas de la dev qu'il faut. Par contre une armée d'avocats et spécialistes juridiques du domaine serait à propos.
Là on parle technique, restons dans le sujet.
Bien évidemment, je ne suis pas seul à bosser dessus (il y a des gens effectivement spécialisés sur ces sujets), les CGV délèguent les responsabilités au client opérateur (puisqu'il choisit ce qu'il veut transporter, normal), etc. Et aussi, les clients intéressés ont déjà un beau parc de plusieurs dizaines de milliers d'abo, je doute qu'ils fassent les cons avec les droits tu vois.
Et pour info, il y a des flux dits Creative Commons qui permettent la réutilisation libre, même à des fins commerciales. Allez, bisous !
Là aussi, du coté des droits, je pense qu'il faut négocier auprès de chaque chaîne.
Ce ne sont pas mes affaires, c'est du ressort de l'opérateur (comprenez bien que je ne fournis aucun flux hein). D'ailleurs, les contrats sont toujours confidentiels, sauf exceptions. Donc un peu idiot si tu veux vérifier qu'un FAI est en règle avec telle chaine.
Enfin là le but, plus que le différé, c'est de regarder une émission régulière le soir le lendemain, car tu étais absent le jour J.
En général, la chaîne ou le groupe te fournissent ça sur un plateau (oui donc ça implique de payer les droits sinon tu l'as dans l'oignon) donc pas besoin de se casser la tête ;)
-
Anevia mon dieu... C'est français mais à part ça...
Ces gateways avaient un avantage, tu pouvais savoir à 10 mètres si elles étaient alimentées, au bruit
C'est pas grave, eu sur Ebay vendu du stock de la BBC pour 100 balles ;)
-
Bof, plus ton différé permet de remonter loin, moins les gens remontent loin.
Enfin là le but, plus que le différé, c'est de regarder une émission régulière le soir le lendemain, car tu étais absent le jour J.
Là aussi, du coté des droits, je pense qu'il faut négocier auprès de chaque chaîne.
TF1 / M6 n'aime pas trop le différé, qui permet de sauter les publicités (il suffit d'arriver 10min en retard et quand la coupure pub arrive, tu passe sur le direct)
Par contre un différé de 24h oblige a regarder les publicités, donc je ne sis pas sur qu'elles soient contres.
Bonjour Vivien,
Techniquement, il suffit de faire un retard mais que tu ne peut ni avancer ni reculer, juste mettre en pause.
Après la chaine ou le FAI peut proposer un abonnement pour substituer la pub.
Moi, c'est ce que je ferais:
Gratuit sans avance et avec une imposition de retard de 1,2,3...........24h max par rapport à l'heure serveur
&
Payant /mois ou /chaine avec un retard au choix (30sec, 1min...........1semaine) avec avance/recul possible avec un enregistrement cloud offert de 50go par exemple.
Si travail avec la chaine qui nous fourni son flux avec des métas données de début et fin de pub destinées au delayer on peut même substituer la pub nationale par une locale ou autre.
On peut tout faire, suffit juste de savoir contourner et proposer à tout le monde quelque chose d'équitable ;D
-
Il ne faut pas négliger le dev, car si tu arrives à maitriser le réseau et le dev, tu peux faire des trucs de fou, vraiment.
Totalement d'accord mais le dev, c'est 1/3 du taf.
Le 2ième tiers réseau est un niveau au dessus mais le dernier tiers est le plus important, c'est le talent à manager le projet.
Et pour ça, ça se bouscule pas au portillon malheureusement alors que c'est celui qui peut faire aboutir le projet :-\
-
...
Tout le monde me surnommais Google en BAC pro c'est dire ;D
...
Ps: c'est mon premier message qui sert un peu de présentation :D
Et tu t'en es arrêté au bac pro ? Pourquoi tu bouscules pas le portillon pour faire aboutir le projet ?
-
Je trouve la solution curieuse et pas vraiment dans l'air de ce qui se dessine côté broadcasters & FAI
L'avenir pour ce type d'usages semble plus dans la catch-up en OTT ou dans les possibilités offertes par le HBBTV comme feu "salto" de France télévisions que dans des bricolages sur le multicast.
-
Et tu t'en es arrêté au bac pro ? Pourquoi tu bouscules pas le portillon pour faire aboutir le projet ?
C'est toujours une question de moyens.
J'aimerais vraiment faire quelque chose de mes connaissances 8)
-
Arrête de me prendre pour un con, stp.
Ce n'est pas compatible avec les flux protégés, donc c'est déjà mort et il n'a jamais été question de ne pas payer. Donc évite de débiter de la matière fécale, stp.
Tu vas te calmer? Ce n'est pas moi qui avance des conneries sans nom qui ne verront jamais le jour en France de par la législation et les ayants droits.
le V-Pvr c'est impossible en France dans l’état des choses.
J'ai été impliqué dans le clan des ayants droits quand Swisscom l'a fait, j'ai une assez bonne vue des forces en présence.
-
Ce n'est pas compatible avec les flux protégés
Dommage, car des chaînes tel que TF1 ou M6 demandent à ce que les flux soient chiffrés.
-
Je trouve la solution curieuse et pas vraiment dans l'air de ce qui se dessine côté broadcasters & FAI
L'avenir pour ce type d'usages semble plus dans la catch-up en OTT ou dans les possibilités offertes par le HBBTV comme feu "salto" de France télévisions que dans des bricolages sur le multicast.
L'ennui de HBBTV, c'est si la TV n'est pas connecté,tu es tributaire du carrousel de data "on air". La gestion de "Salto" ne devait pas être simple.
-
Je remonte ce sujet suite au lancement du service start over chez ByTel:
https://www.bbox-mag.fr/tv/6887118-bouygues-telecom-annonce-le-service-start-over-sur-bbox/
https://www.bbox-mag.fr/tv/6971722-le-service-start-over-est-disponible-sur-btv/
Aurait-il été possible d'avoir ce service en multicast avec les spams imposés au début du programme ? Je dirais non mais je manque de connaissance sur ce sujet.
-
Aurait-il été possible d'avoir ce service en multicast avec les spams imposés au début du programme ? Je dirais non mais je manque de connaissance sur ce sujet.
Non, c'est du flux sur demande. Il faut donc que cette fonctionnalité soit utilisée marginalement pour éviter les goulots d'étranglements.
-
Non, c'est du flux sur demande. Il faut donc que cette fonctionnalité soit utilisée marginalement pour éviter les goulots d'étranglements.
Salut Optix,
Je suis retombé sur ton sujet et je viens un peu aux nouvelles.
Où ça en est ton projet ?
Tu as réussi à te lancer ?
Tu as trouver des solutions ?
Moi, je suis libre d'obligations donc je vais me repencher sur un truc similaire.
J'ai peut être une piste pour limiter le traffic tout en ayant un système souple.
Voilà, si tu repasses par là 😉
-
Salut Optix,
Je suis retombé sur ton sujet et je viens un peu aux nouvelles.
Où ça en est ton projet ?
Tu as réussi à te lancer ?
Tu as trouver des solutions ?
Moi, je suis libre d'obligations donc je vais me repencher sur un truc similaire.
J'ai peut être une piste pour limiter le traffic tout en ayant un système souple.
Voilà, si tu repasses par là 😉
Ca va bien voir le jour, car j'ai enfin trouvé un contexte parfaitement adapté à ça : le FTTLA, grâce aux fréquences.
J'ai découvert qu'on pouvait faire passer du flux multicast à la demande sur des fréquences _dédiées_, donc le débit IP normal/unicast des abonnés ne sera pas amputé et les gens garderont leurs 100Mbps (quand bien même ils ont 6 TV). Je n'aurais pas pu faire ça sur du GPON, tout passe dans la même longueur d'onde.
Entre temps, le système s'est perfectionné :
- j'utilise les données EPG du satellite et du programme en cours pour déclencher le différé juste au début d'un programme plutôt que de faire bêtement du -1min, -10min, etc.
- ca marche avec les flux protégés (ça nécessite quand même une carte de droits côté abonné, car j'enregistre du flux chiffré, bêtement)
- les remontées IGMP permettent de démarrer le bon flux à la demande, et aggrege les requêtes trop rapprochées (20h10, si 2 abonnés veulent regarder le début du JT mais qu'elles ont 10sec d'écart, ça les envoie sur le même flux, au lieu de démarrer 2 flux séparés).
Du coup je vais pousser ça dans ma boite actuelle en premier, en grandeur nature :)
-
Je n'aurais pas pu faire ça sur du GPON, tout passe dans la même longueur d'onde.
Le 1550-1560 est pas fait pour ça justement ? De mémoire tu peux même ressortir en coax de l'ONT.
Je me demande même si Vialis ne le fait pas.
(après la nécessité est moins là, mais c'est toujours ça de gagné si on le souhaite absolument)
-
Le 1550-1560 est pas fait pour ça justement ? De mémoire tu peux même ressortir en coax de l'ONT.
Je me demande même si Vialis ne le fait pas.
(après la nécessité est moins là, mais c'est toujours ça de gagné si on le souhaite absolument)
C'est exact, sauf que le problème, la 1550 est faite pour véhiculer du DVB-T et les boxs traitent ce signal "bêtement" en le changeant de connecteur fibre->coax. J'ai besoin d'avoir une remontée IP en IGMP pour déclencher le différé et de ne pas balancer le flux VOD en DVB-T, sinon je me retrouverai vite à cours de modulateur :)
-
Ca va bien voir le jour, car j'ai enfin trouvé un contexte parfaitement adapté à ça : le FTTLA, grâce aux fréquences.
J'ai découvert qu'on pouvait faire passer du flux multicast à la demande sur des fréquences _dédiées_, donc le débit IP normal/unicast des abonnés ne sera pas amputé et les gens garderont leurs 100Mbps (quand bien même ils ont 6 TV). Je n'aurais pas pu faire ça sur du GPON, tout passe dans la même longueur d'onde.
Entre temps, le système s'est perfectionné :
- j'utilise les données EPG du satellite et du programme en cours pour déclencher le différé juste au début d'un programme plutôt que de faire bêtement du -1min, -10min, etc.
- ca marche avec les flux protégés (ça nécessite quand même une carte de droits côté abonné, car j'enregistre du flux chiffré, bêtement)
- les remontées IGMP permettent de démarrer le bon flux à la demande, et aggrege les requêtes trop rapprochées (20h10, si 2 abonnés veulent regarder le début du JT mais qu'elles ont 10sec d'écart, ça les envoie sur le même flux, au lieu de démarrer 2 flux séparés).
Du coup je vais pousser ça dans ma boite actuelle en premier, en grandeur nature :)
Ahah génial 😀
C'est clair, ton système est plus adapté au câble avec en plus tes flux protégés qui arrivent bruts dans la box et qui sont décodés par droits sur carte comme une chaîne classique.
Et c'est très ingénieux, ta création de flux à la demande en delay en exploitant le Node pour convertir le flux IP en flux DVB et ainsi éviter d'enlever de la BP au client qui ne reçoit finalement qu'un flux TV décalé comme si c'était une nouvelle chaîne de son abonnement 😉
Étonnant d'ailleurs que Numéricable/Noos/etc ne l'aient pas utilisé dans le passé 🤔
Bon parcontre, le client ne peux pas se balader dans le flux en lecture à part arrêter le flux et refaire une demande 10min après pour passer la pub, si la fonction le permet et ça c'est un point bloquant.
La solution accède à une demande mais le client va vite comprendre qu'elle est sacrèment limitée surtout que les chaînes diffusent leurs programmes avec + ou - 5min voir 10min d'avance/retard sur l'EPG.
Pour l'accès à ce nouveau flux, tu procèdes comment ?
- Sur la chaîne en direct, un retour arrière par une touche de la télécommande qui bascule automatiquement sur la nouvelle chaîne quand le flux arrive ?
- par un midlleware qui affiche une page sur la box pour lancer le restart de chaîne ?
- le client va dans l'EPG de la box et clique sur le programme qu"il veut revoir du début et hop ça bascule sur le flux créé pour lui ?
En tout cas, oui, le tester en grandeur nature sur un petit réseau est une bonne solution pour voir si cela apporte une plus-value et si les clients en sont satisfaits 😀
Après, je m'intéresse à faire ce système de delay depuis 2012 au moins.
C'est très utilisé au US car ils ont des fuseaux horaires différents sur tout le pays et ils font du +1/+2/+3/+4 etc tout les jours avec du matos dédié :
https://dveo.com/Streaming-Video-HTTP-RTSP-Flash-IPTV/IP-Time-Delay-for-IPTV-time-delay-server.html
https://www.imaginecommunications.com/products/playout/video-servers/nexio-specialty-servers/nexio-transport-stream-delay-server
https://broadstream.com/solutions/armada-time-delay/
http://ffv.com/time-shift-delay.html
Anevia, boîte française le fait aussi voir image en bas du post :
http://www.ixywf.com/index-8.html
C'est pour ça, après toutes ces années, je crois avoir trouvé ce qui permettra d'avoir quelque chose de souple, sécurisé et respectueux de la BP du client.
Faut que je me lance 😄
-
Du coup je vais pousser ça dans ma boite actuelle en premier, en grandeur nature :)
pour moi cet usage de nPVR n'est pas légal en france.
-
pour moi cet usage de nPVR n'est pas légal en france.
Il va sans dire qu'on les autorisations écrites des chaines pour le faire hein, notamment les plus petites ;)
-
Il va sans dire qu'on les autorisations écrites des chaines pour le faire hein, notamment les plus petites ;)
C'est surtout l'autorisation des plus grosses qui est intéressant , tu les as ?
-
C'est surtout l'autorisation des plus grosses qui est intéressant , tu les as ?
D'autant que les grosses chaines ont assez peu d'intérét à donner leurs accords, vu qu'elles monaient leurs services premium (rattrapage & start over) auprés des telcos.
Pour moi, ta solution arrive trop tard Optix, je ne vois pas du tout un industriel signer pour déployer ta solution, l'unicast et l'utilisation de codecs performants me semble plus à la mode.
-
D'autant que les grosses chaines ont assez peu d'intérét à donner leurs accords, vu qu'elles monaient leurs services premium (rattrapage & start over) aiprés des telcos.
Pour moi, ta solution arrive trop tard Optix, je ne vois pas du tout un industriel signer pour déployer ta solution, l'unicast et l'utilisation de codecs performants me semble plus à la mode.
Sa solution existe depuis des années chez Swisscom par exemple.
En France, les ayants droits ont vite compris que le système qui permettaient de faire péter les pubs et sponsorings divers, ça n'allait pas le faire.
C'est pour ça qu'il y a en France les plateformes de replay avec les pubs inclusent pas virables.
j'aimerais beaucoup voir une autorisation de full npvr provenant des groupes TF1 ou m6 par exemple.
Et même chez france télé ça ne doit pas être facile à obtenir....
-
Je viens aux nouvelles pour savoir qui a donné son autorisation pour faire du full NPVR sur le territoire français....
-
Je pense à des accords historiques pour un câblo opérateur qui existait il y a 15 ans.
Par exemple CitéFibre diffusait ses débuts les chaînes du groupe TF1 et M6 sans autorisation (les chaînes n'apparaissaient pas sur le site web) mais citéFibre a réussi à avoir une lettre qui l'oblige a reprendre les chaînes hertzienne (must cary) et donc TF1 / M6 car en tant que premier opérateur FTTH qui diffuse la TV en France son réseau a été associé au câblo-opérateurs qui avaient a l'époque une obligation de must cary contrairement aux opérateurs ADSL. (Free n'avait ni TF1, ni M6 à l'époque)
On avais les autorisations pour toutes ces chaînes, diffusées en clair : https://lafibre.info/site/citefibre/offres_premium_tvnumerique.htm
Là où on était limite, c'est XXL qui pouvait être visionné par VLC sans le code parental, vu que les flux étaient en clair.
-
Les choses ont changé en 15 ans....
Et là on parle de faire du full npvr sur des chaînes qui ont du contenu à valoriser dans leur territoire d'origine.
Pourquoi les enregistrements des grosses privées ne sont pas accessible par le FTP des freebox, par exemple ?
Sinon, orange ne s'enm...... pas à mettre des disques durs dans les livebox et ferait du replay/time shift over the cloud...
Meme si on parle de petits opérateurs, connaissant le juridique de TF1 et M6, une autorisation de la sorte m'étonne.
Ce qu'il veut faire, ce n'est pas du time shift mais du nPVR. Légalement c'est très différents.
Je pense à des accords historiques pour un câblo opérateur qui existait il y a 15 ans.
Par exemple CitéFibre diffusait ses débuts les chaînes du groupe TF1 et M6 sans autorisation (les chaînes n'apparaissaient pas sur le site web) mais citéFibre a réussi à avoir une lettre qui l'oblige a reprendre les chaînes hertzienne (must cary) et donc TF1 / M6 car en tant que premier opérateur FTTH qui diffuse la TV en France son réseau a été associé au câblo-opérateurs qui avaient a l'époque une obligation de must cary contrairement aux opérateurs ADSL. (Free n'avait ni TF1, ni M6 à l'époque)
On avais les autorisations pour toutes ces chaînes, diffusées en clair : https://lafibre.info/site/citefibre/offres_premium_tvnumerique.htm
Là où on était limite, c'est XXL qui pouvait être visionné par VLC sans le code parental, vu que les flux étaient en clair.
-
Attention, mon système n'est pas du NPVR : ça reste un bête différé, avec différents timecode pour remonter à un événement précis dans le flux (genre le commencement du journal). Déjà ça n'a rien de "personnel", vu que ce n'est pas le viewer qui déclenche l'enregistrement. Ensuite, le visionnage en différé n'est possible au-delà de qq heures suivant les capacités et les pubs restent présentes (c'est un flux linéaire, on ne modifie pas le contenu des diffuseurs). Donc rien à voir avec de l'enregistrement ou du replay que tu peux regarder 5 jours après.
Il me semble que K-Net fait exactement la même chose, mais à l'échelle de la seconde : les flux sont enregistrés dans des bouts de qq secondes par fichier, et toutes les boxs tapent dessus.
Evidemment, d'autres gros FAI ont déjà un truc équivalent mais depuis je m'adresse aux petits FAI, genre les petites régies qui ont un réseau câble, qui ont les autorisations qui vont bien et qui n'ont pas les moyens.
-
Attention, mon système n'est pas du NPVR : ça reste un bête différé, avec différents timecode pour remonter à un événement précis dans le flux (genre le commencement du journal). Déjà ça n'a rien de "personnel", vu que ce n'est pas le viewer qui déclenche l'enregistrement. Ensuite, le visionnage en différé n'est possible au-delà de qq heures suivant les capacités et les pubs restent présentes (c'est un flux linéaire, on ne modifie pas le contenu des diffuseurs). Donc rien à voir avec de l'enregistrement ou du replay que tu peux regarder 5 jours après.
Il me semble que K-Net fait exactement la même chose, mais à l'échelle de la seconde : les flux sont enregistrés dans des bouts de qq secondes par fichier, et toutes les boxs tapent dessus.
Evidemment, d'autres gros FAI ont déjà un truc équivalent mais depuis je m'adresse aux petits FAI, genre les petites régies qui ont un réseau câble, qui ont les autorisations qui vont bien et qui n'ont pas les moyens.
ce n'est pas un bête différé, car le client va arriver à des endroits prédéfinis.
si tu fais un différé, par exemple de tf1 20H, tu zappes la pub et le sponsoring d'avant journal.
C'est donc plus qu'un différé à -30min, -1h, -2h....
tu es dans le cas de Npvr partiel ou time shift évolué, et là juridiquement, chaque camps voyant la vérité à sa porte, ce n'est pas simple.
Les ayants droits t'ont autorisé explicitement cet usage là?