Page 1 sur 1

Streaming DVB-T en protocole UDP au travers d'un LAN [VLC]

MessagePosté: 22 Avr 2020 14:54
par kaskaï
Bonjour,

Le confinement donne le temps de réfléchir à des configuration jusqu'alors inenvisagées. Dans un 1er temps j'ai volontiers utilisé localement VLC comme player pour sa grande simplicité et sa rapidité.
Plus récemment j'ai découvert que bien que n'ayant qu'un seul PC équipé de stick dvb-t, je pouvais diffuser le flux au travers de mon réseau local. Ainsi depuis n'importe quel VLC installé sur android ou Windows (Linux probablement aussi), je peux jongler/zapper avec la playlist des chaines TV de la TNT.
Le fichier du PC distant le permettant, ressemble à ceci :
Code: Tout sélectionner
#EXTINF:0,TF1
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/TF1


#EXTINF:0,France 2
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/France%202

#EXTINF:0,F3 Paris Ile-de-France
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/F3%20Paris%20Ile-de-France

#EXTINF:0,CANAL+
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/CANAL%20PLUS

#EXTINF:0,France 5
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/France%205

#EXTINF:0,M6
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/M6

#EXTINF:0,Arte
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/Arte

#EXTINF:0,C8
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/C8

#EXTINF:0,W9
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/W9

#EXTINF:0,TMC
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/TMC

#EXTINF:0,CSTAR
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/CSTAR

#EXTINF:0,NRJ12
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/NRJ12

#EXTINF:0,LCP
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/LCP

#EXTINF:0,BFM TV
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/BFM%20TV

#EXTINF:0,France Ô
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/France%20Ô

#EXTINF:0,CNEWS
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/CNEWS

#EXTINF:0,Gulli
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/Gulli

#EXTINF:0,TFX
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/TFX

#EXTINF:0,France 4
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/France%204


#EXTINF:0,TF1 Séries Films
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/TF1%20Séries%20Films

#EXTINF:0,L'Equipe 21
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/L'Equipe%2021

#EXTINF:0,6ter
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/6ter

#EXTINF:0,RMC STORY
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/RMC%20STORY

#EXTINF:0,Chérie 25
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/Chérie%2025

#EXTINF:0,RMC Découverte
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/RMC%20Découverte

#EXTINF:0,LCI
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/LCI

#EXTINF:0,Franceinfo:
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/Franceinfo:

#EXTINF:0,France 24
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/France%2024


#EXTINF:0,RMC SPORT NEWS HD
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/RMC%20SPORT%20NEWS%20HD

#EXTINF:0,BFM Paris
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/BFM%20Paris

#EXTINF:0,Canal 31
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/Canal%2031

#EXTINF:0,IDF1
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/IDF1

#EXTINF:0,VIAGRANDPARIS
#EXTVLCOPT:dvb-adapter=0
http://192.168.1.161:8007/stream2/VIAGRANDPARIS


Cela marche assez bien et l'on notera que c'est le protocole HTTP qui est utilisé.
En contrepartie j'obtiens un flux assez lourd sur le réseau. Aussi je souhaiterais envisager le protocole UDP, plus adapté il me semble pour ce genre de taches ne nécessitant pas forcément la perfection dans les paquets transmis : je tolérerais volontiers quelques artefacts de paquets perdus, si le réseau était bien moins sollicité. L'Unicast serait dans un premier temps suffisant.

Est-ce faisable ? Car les 2 protocoles ne fonctionnent pas à l'identique : le protocole udp exige de démarrer préalablement VLC en tant que serveur sur le PC équipé de stick DVB-T, contrairement au protocole HTTP.
Pour la bonne marche d'un streaming UDP il faudrait donc que le PC client distant sur lequel on souhaite allumer la télé, initie préalablement le démarrage de VLC sur le PC diffuseur, dans une session serveur correctement renseignée quant à l'adresse IP destinataire.

J'ai possiblement pu dire de grosses bêtises et peut-être y a t-il une solution toute simple. Alors avant de tenter quoique ce soit sur du streaming DVB-T en protocole UDP, je voudrais m'assurer de mesurer si mon projet est réaliste, alors merci de me corriger pour m'aider à comprendre
Merci d'avance

Re: Flux DVB-T en protocole UDP au travers d'un LAN [VLC]

MessagePosté: 22 Avr 2020 17:04
par etdu24
Bonjour, je pense qu'il faudrait plutôt chercher du coté du protocole RTSP (qui est un protocole mixte entre l'UDP pour les flux audios/Video et TCP pour la partie signalisation). Dans VLC tu as la possibilité de filtrer par identifiant de programme (pour ne diffuser que les flux d'une chaine en particulier, il me semble qu'il faut ajouter une option "program=" dans les options du vlc qui sert de serveur).
Il doit également y avoir moyen d'assigner un point de montage pour chaque chaine, mais il faut passer dans le mode console de VLC, donc un truc assez complexe.
Sinon tu peux aussi tenter avec TvHeadend si ton dongle DVB-T fonctionne sous linux.

Re: Flux DVB-T en protocole UDP au travers d'un LAN [VLC]

MessagePosté: 23 Avr 2020 10:23
par kaskaï
Merci de ta réponse,
Le protocole RTSP est intéressant et pour ne pas trop charger mon 1er post, j'avais prévu de l'aborder peut-être un peu plus tard : après avoir testé l'UDP, protocole moins évolué, plus simple et aussi plus léger. D'ailleurs en esquissant quelques étapes sur la piste RTSP, tu laisses clairement percevoir la complexité de la tache. Je mets donc de côté ...
Etant sur Windows, je souhaite vraiment savoir si mon 1er post établit correctement le diagnostique ou si avec ce "streaming UDP", je me lance sur un objectif insensé et totalement vain.
Je ne m'attends à une réponse immédiate mais peut-être le référencement google finira-t-il pas attirer quelques spécialistes de VLC
Bonne journée à tous

Re: Streaming DVB-T en protocole UDP au travers d'un LAN [VL

MessagePosté: 23 Avr 2020 12:25
par kmf31
J'utilise la methode streaming, a l'interieure d'un PC Linux, pour gerer de facon pratique l'enregistrement de plusieurs chaines sur le meme multiplexe. D'abord je lance une instance de vlc pour capter la TNT, et creer 5-6 streams upd qui apres peuvent etre captes par d'autres instances vlc (sur le meme PC mais aussi d'autres PC sur le meme sous-reseau) pour soit regarder, soit enregistrer.

Au debut j'ai utilise pour les streamings des IPs de type 192.168.1.x de mon reseau local mais je me suis vite apercu que cela ne permet pas de multicast car quand qu'une instance vlc regarde/engistre un stream ca le coupe pour une instance anterieure de vlc qui le regarde/enregistre deja.

Pour faire de multicaste c'est tres simple: simplement utiliser des IPs de type 234.y.z.x, par exemple 234.0.0.1 et apres on met des ports selon stream genre:
234.0.0.1:2001 pour le 1er flux du multiplex et 234.0.0.1:2002 pour le 2eme etc.
Apres simplement faire (pour un "vlc client"):
vlc udp://@224.0.0.1:2001
pour acceder au flux mais il faut en effet que le serveur streaming soit lance au prealable.

Ca marche aussi avec les addresses de type 192.168.y.x mais dans ce cas pas de multicaste => pas d'acces simultane de deux instances vlc au meme stream.

Apres il y a pas mal de parametres notamment pour des valeurs de cache (en ms) pour le stream (mais aussi le dvb, les fichiers etc.) pour que la qualite soit bonne.

Il y a (ou avait ???) aussi un bogue dans vlc pour la partie demuxage TNT dont j'ai parle dans un autre poste il y a longtemps (je ne connais pas le lien par coeur). Je pense j'avais fait un poste apart et/ou dans un des sujets sur la TNT sur PC etc. En principe il fallait patcher/recompiler vlc mais peut-etre avec les dernieres versions ce n'est plus le cas ? Enfin, est-ce que tu arrives correctement a enregistrer la TNT sur le PC avec vlc ? Si oui je crois ca doit etre bon.
Attention: ce bogue ne joue pas pour regarder la TNT en directe (si on le fait directement et sans streaming).
Le probleme est que les developpeurs considerent c'est un bogue dans le flux TNT en France (avec les doubles packages/trames ou quelque choses comme ca) et ne le reparent peut-etre pas dans vlc.

Re: Streaming DVB-T en protocole UDP au travers d'un LAN [VL

MessagePosté: 23 Avr 2020 15:48
par kaskaï
Bonjour kmf31,
Je vais essayer de mettre mes pas ds les vôtres tant vs me devancez ds mon entreprise.
Initialement je souhaitais me limiter à l'unicast, mais après tt pourquoi ne pas partir directement sur le multicast...

1) Si je comprends bien il faut disposer d'1 stick dédié pour chaque multiplex. A Paris ce serait donc 8 sticks puisque 8 fréquences (482166000, 490166000, 498166000, 506166000, 514166000, 522166000, 562166000, 586166000). Avec 2 sticks simples plus un dual tuner, moi qui me pensais ferré, je vois que je suis loin du cpte

2) Comme ttes mes adresses locales sont en 192.168.1.XXX, cela implique de les réassigner toutes (sauf le diffuseur) en 234.y.z.x.

3) Je ne suis vraiment pas à l'aise sur les ports à ouvrir sortant ou entrant, tant du côté du PC 'serveur VLC' que des PC distant 'client VLC'.
Pouvez-vs à partir de votre exemple m'indiquer comment je dois procéder ? Si j'ai bien suivi, il me faut donc ouvrir au moins 8 ports (2000-2008)
234.0.0.1:2001 pour le 1er flux du multiplex et 234.0.0.1:2002 pour le 2eme etc.


4)
pour accéder au flux mais il faut en effet que le serveur streaming soit lance au préalable.

Donc si je comprends bien, pour bénéficier d'une souplesse (à la volée) et disponibilité totale (théorie), il faudrait lancer les 8 instances simultanément dés le boot du PC diffuseur. Sur votre installation, j'imagine que cela représente une occupation CPU non négligeable. Je pose la question ainsi car si j'ai bien compris, votre réseau fonctionne au quotidien selon ce scénario ambitieux

Pour l'enregistrement avec VLC, j'ai testé et à priori ça fonctionne (via l'interface graphique, clic droit 'bouton enregistrer' j'obtiens un fichier .ts). Je ne suis pas sûr de bien comprendre le lien avec le streaming.
[A l'instant je viens de pousser un plus le test d'enregistrement. Et là petite surprise : pas de pb d'artefact ou bug video mais une chaine de sport (RMC sport) a un étrange comportement : le live est nickel, l'enregistrement aberrant. Il a enregistré un écran noir et une bande son complètement différente d'un pgm de sport. J'ai fini par reconnaître la voix d'un journaliste radio. C'est bien France Inter qui était parfaitement restitué. Bon peu importe, plutôt drôle finalement et assez insignifiant car c'est une chaîne liée à bon abo SFR. Drôle de bogue quand même !!!]

Re: Streaming DVB-T en protocole UDP au travers d'un LAN [VL

MessagePosté: 23 Avr 2020 21:56
par kmf31
Bonjour kaskai,

kaskaï a écrit:Bonjour kmf31,
Je vais essayer de mettre mes pas ds les vôtres tant vs me devancez ds mon entreprise.
Initialement je souhaitais me limiter à l'unicast, mais après tt pourquoi ne pas partir directement sur le multicast...

1) Si je comprends bien il faut disposer d'1 stick dédié pour chaque multiplex. A Paris ce serait donc 8 sticks puisque 8 fréquences (482166000, 490166000, 498166000, 506166000, 514166000, 522166000, 562166000, 586166000). Avec 2 sticks simples plus un dual tuner, moi qui me pensais ferré, je vois que je suis loin du cpte


En theorie oui si on veut les laisser tourner tout le temps pour l'ensemble des Multiplexes.

2) Comme ttes mes adresses locales sont en 192.168.1.XXX, cela implique de les réassigner toutes (sauf le diffuseur) en 234.y.z.x.

En fait je me suis trompe, c'est 224.y.z.x mais je crois la plage est plus grande. Regarde ici:
https://fr.wikipedia.org/wiki/Multicast ... rv%C3%A9es
pour des infos et des details. Bref si je comprends bien ces IPs sont aussi locales et ne sont pas routes sur l'internet. Donc on peut les ouvrir sur les pares feu des PC clients en direction entrants. Cote securite il ne doit pas avoir de probleme de ce cote la. Sur le serveur il faut bien sur ouvrir la direction sortant (normalement c'est automatique si vlc est "autorise" dans le pare feu et sauf config pare feu Windows parano; en Linux j'ouvre toujours la direction sortante).

3) Je ne suis vraiment pas à l'aise sur les ports à ouvrir sortant ou entrant, tant du côté du PC 'serveur VLC' que des PC distant 'client VLC'.

Je crois sur le routeur de ne fais rien car tu ne veux pas quitter ton sous-reseau. Sur les PC client tu ouvres simplement tous les ports UDP venant de 224.0.0.1 (si tu veux utiliser cette adresse).

Pouvez-vs à partir de votre exemple m'indiquer comment je dois procéder ? Si j'ai bien suivi, il me faut donc ouvrir au moins 8 ports (2000-2008)
234.0.0.1:2001 pour le 1er flux du multiplex et 234.0.0.1:2002 pour le 2eme etc.

Disons: 224.0.0.1:2001 -> 224.0.0.1:2008 car je me suis trompe dans mon 1er poste.

Je crois le choix exacte de l'P et des ports udp n'importe pas. On est libre pour ca tant c'est dans la bonne plage pour les IPs.
Moi j'ai deux tuners TNT et j'utilise (par des scripts) les ports 2000-2004 pour les 5 chaines du multiplex associe au 1er tuner et 2010-2014 pour les 5 chaines du muliplexe associe au 2eme tuner. (Ca peut aussi etre 6 ou 7 chaines selon multiplex. On peut aussi prendre les ports 10000+X etc. ou 33333+X, comme on veut). C'est seulement une histoire de choisir un port par chaine. Je crois en udp il n'y a pas de ports speciaux (comme quelques ports TCP en dessous de 1024).

4)
pour accéder au flux mais il faut en effet que le serveur streaming soit lance au préalable.

Donc si je comprends bien, pour bénéficier d'une souplesse (à la volée) et disponibilité totale (théorie), il faudrait lancer les 8 instances simultanément dés le boot du PC diffuseur. Sur votre installation, j'imagine que cela représente une occupation CPU non négligeable. Je pose la question ainsi car si j'ai bien compris, votre réseau fonctionne au quotidien selon ce scénario ambitieux.


Le CPU pour faire de streaming est assez modeste. Ca ne fait pas de decodage du codec etc. Ca ne manipule que l'encapsulation du flux TS. Je n'ai aucun probleme de CPU (j'ai une CPU 4 coeurs assez rapide mais datant deja de 8 ans) pour faire tourner deux streams (donc 2 multiplexes), enregistrer 2,3,4,... chaines de ca et en meme temps de regarder un fichier deja enregistre (ou en train d'etre enregistre) ou un de ces flux a l'ecran (ou a la TV avec PC branche en HDMI a la TV). C'est de regarder qui bouffe de CPU !
Par contre cote charge reseau ca peut etre lourd. Il me semble si on fait de maniere naive ca transmet tout le temps dans les 22 Mb/s a tout le reseau par Multiplex (donc 6 ou 8 fois 22 Mb/s). Avec des cartes Gigabit ethernet ca marche mais avec le wifi ca peut poser un vrai probleme.

Moi je lance les streams uniquement quand c'est necessaire mais je reste aussi sur un PC en local. (A l'instant j'enregistre 3 chaines sur 2 Multiplexes. ;) ) par des scripts.
Il y a dans VLC un parametre pour le nombre de "hop" ou saut reseau (l'option --ttl = X ou X=nombre de hop ). Moi j'ai mis cela a zero pour rester dans le PC serveur. Si on veut aller vers un autre PC il faut y mettre une valeur de 1 ou plus. Mais a ce moment je crois ca transmet a tous les PC. Je crois c'est ca l'udp en multicaste. Ca va partout.

Pour l'enregistrement avec VLC, j'ai testé et à priori ça fonctionne (via l'interface graphique, clic droit 'bouton enregistrer' j'obtiens un fichier .ts). Je ne suis pas sûr de bien comprendre le lien avec le streaming.
Vlc est capable de demuxer le flux TS et remuxer des flux individiuel par chaine. C'est ici ou ca bogue. Quand on fait de streaming ou quand on fait un enregistrement ca utilise exactement le meme type de demuxage/remuxage. Quand on regarde en directe ca marche apparement "autrement". Bizarrement l'enregistrement par le mode timeshift de vlc (cliquer sur pause) etc. semble aussi de marcher sans probleme mais avec ca on ne peut pas produire un fichier TS convenable. (Le format du fichier timeshift semble tres bizarre et totalement inutilisable pour un traitement ulterieure).

[A l'instant je viens de pousser un plus le test d'enregistrement. Et là petite surprise : pas de pb d'artefact ou bug video mais une chaine de sport (RMC sport) a un étrange comportement : le live est nickel, l'enregistrement aberrant.

C'est exacement le bogue !!!
Il se manifesteme fortement pour de live, la musique, des concerts, docus produits en France (les emissions de telerealite ou sur la police en France, genre Capital sur M6 ou 7 a 8 sur TF1 etc.) et il se manifeste moins (mais PAS a zero !!) pour les films, series preenregistres ou les chaines produisent apparement aussi un autre type de flux TS. Le bogue peut aussi dependre des chaines. Avant le passage au HD total en 2016 le bogue existaient deja sur les nouvelles chaines HD (les multiplexs R7 et R8 de l'epoque) mais de maniere moindre et aussi selon type d'emission pendant les versions HD de TF1, M6, ARTE et FR2 n'avaient pas encore le bogue. Par contre apres 2016 ou tout le monde est passe en HD avec reduction des debits alors le bogue etaient partout.

Il a enregistré un écran noir et une bande son complètement différente d'un pgm de sport. J'ai fini par reconnaître la voix d'un journaliste radio. C'est bien France Inter qui était parfaitement restitué. Bon peu importe, plutôt drôle finalement et assez insignifiant car c'est une chaîne liée à bon abo SFR. Drôle de bogue quand même !!!]


Pour reparer le bogue il suffit de modifier deux lignes du code source et il faut recompiler vlc. Moi j'ai fait ca en Linux en utilisant une ancienne version de vlc (2.0.x) qui me semble le plus stable pour ca. Par contre en Windows ca doit etre complique. Je crois meme les versions Windows de vlc sont compilees sur des PCs Linux par l'equipe de vlc (ca s'appelle "cross-compilation", compiler sur un systeme X pour faire tourner sur un autre systeme Y).

Vers avril/mai 2016 j'ai fait un poste long ici et aussi sur le forum videolan associe a vlc avec l'espoir d'avoir plus de retour. Meme s'il y a eu quelques reponses il semble il y a peu de monde qui s'est interesse a ca et qui utilise vlc pour enregistrer la TNT sur PC (meme en Linux il y a des softs alternatifs mais pas aussi fonctionnel).
Le probleme meme si tu ne veux pas enregistrer mais faire de streaming par chaine (donc demuxage/remuxage) et regarder le stream en directe tu tomberas aussi sur ce bogue. Seulement la vision directe pour une instance de vlc qui lance lui meme le tuner TNT n'est pas affecte.

Re: Streaming DVB-T en protocole UDP au travers d'un LAN [VL

MessagePosté: 24 Avr 2020 03:06
par kmf31
Voici mon ancien sujet sur videolan sur le bogue d'enregistrement TNT par vlc:
https://forum.videolan.org/viewtopic.ph ... 31#p440916
(mais c'est ecrit en anglais).