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 ?

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.

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 ?

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)

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

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....