Streamer un flux uniquement sur le réseau local

[J3R3M51]

Bonjour à tous,

Je viens vers vous afin de trouver une solution simple pour streamer plusieurs flux sur un réseau local.
Chaque flux sera encodé par un ordinateur dédié avec OBS si possible, voire Wirecast si nécessaire, je pense que vous pourrez m'orienter sur la meilleure solution.

Après quelques recherches, je suis tombé sur pas mal de sujets qui traitent du stream sur les réseaux sociaux ou sur des services internet de streaming, mais peu sur le réseau local.
Ceux qui traitent du réseau local expliquent comment streamer le contenu d'un poste directement sur un autre, ce qui ne correspond pas à ce que je souhaite faire.

En schématisant, admettons que je souhaite que les postes 192.168.1.10, 192.168.1.11, 192.168.1.12 streament chacun un flux (en 1080p), j'aimerais que chaque poste faisant partie de ce réseau puisse voir ces flux, en connaissant bien évidemment les adresses en amont.

N'est-il pas possible que chaque "poste encodeur" puisse être son propre serveur ?
Ainsi, le flux serait accessible depuis une adresse type rtmp://192.168.1.10/live.

Ou faut-il absolument passer par un serveur local, type NAS?
Si oui, quel type de NAS / quelle configuration faut-il pour pouvoir streamer trois flux 1080p simultanément?

J'étais persuadé qu'une solution serait envisageable directement depuis les "postes encodeurs".
Je précise que le nombre de client sera d'environ 50 en simultané.

Je vous remercie de votre lecture et suis à votre disposition s'il est nécessaire de préciser davantage mon projet

Modifié le 2 mars 2019 par J3R3M51

[J3R3M51]

Messieurs, j'ai trouvé la solution!
Utilisant des Mac, il suffit d'installer ce petit utilitaire pour que la machine encodeuse soit également reconnue comme serveur RTMP.
Il doit certainement exister un utilitaire similaire pour les utilitaires de Windows.

Bonne journée à tous 🙂

[FraiseTagada]

Il y a 14 heures, J3R3M51 a dit :

Il doit certainement exister un utilitaire similaire pour les utilitaires de Windows.

Oui,  CrtmpServer,

Disponible sous Windows, Linux, Raspberry etc...  et OpenSource 

Il existe aussi, sous forme de bibliothèque, pour développer la même chose pour le protocol RTSP, par exemple: Crtspserver

[J3R3M51]

Bonjour @FraiseTagada et merci de ce complément de réponse.

À tout hasard, pourrais-tu m'informer sur les limites d'une telle utilisation ? J'ai en tête que le serveur met à disposition un flux en live. Mais que le flux soit visionné par 2 ou 200 personnes simultanément, celui-ci ne sera pas plus sollicité. Est-ce que je me trompe ?

Les seules limites de ce système sont-elles le réseau Gigabit? Ce qui donnerait environ 200 visionnages simultanés possibles pour un flux d'environ 5Mbps?

 

Pour moi, j'ai en tête que c'est le même principe que la TV, une chaîne est émise, si je la regarde je choppe le flux et m'y déconnecte quand je veux sans que ça puisse perturber l'émission de cette chaîne.

Modifié le 3 mars 2019 par J3R3M51

[FraiseTagada]

Salut

Des solutions comme CrtmpServer sont assez robustes mais pas destinées à une grande diffusion (volume en nombre),  200 ça reste à mon sens très raisonnable, faut tester, plusieurs VM en client et voir comment le system réagit ou se comporte (freeze aléatoire) et monter en charge. je n'ai jamais testé a plus de 50 avec ce genre d'outils, via des Serveur de Streaming c'est plus stable d'autant plus si tu fait de la répartition de charge)

Mais après tout rien ne t’empêche de te monter un pseudo CDN en interne, plusieurs machines dispos pour la diffusion, en frontal (le host de base) tu y met un Varnish et ça doit rouler (ok ok si tu connais pas la config Varnish c'est chiant mais ça se fait... c'est très stable et performant), j'ai déjà absorbé quelques 10-15000 diffusions temps réel instant T  avec ça.

Au niveau de l'environnement technique, deux choses sont importante, la puissance de la machine et son volume mémoire, et le volume admissible du débit réseau (si ont reste dans une optique locale intranet)

Avoir 2 clients (qui visualisent) ou 200 c'est pas la même chose bien sur, et il ne suffit pas de diviser le débit théorique de la ligne par le nombre de client. j'avais il y a quelque année fait un abaque pour calculer ce genre de chose.

Compte aussi énormément le Protocol utilisé... ici tu prend RTMP qui à vu ses beau jour avec Adobe Server ou ses équivalents gratuit comme Red5 ou Wonza etc... c’était un des plus utilisé pour restituer des lives sur le Web à cette époque ou le Flash était à la mode. Je ne suis pas certains qu'aujourd'hui ce soit le choix le plus pertinent, même si il fonctionne bien et que surtout via un serveur RTMP il est possible de faire en // du temps réel d'info en plus de la vidéo.

Des protocol comme le RTSP sont à mon sens plus performant, il est aussi important de penser a faire de "l'Adaptative Streaming" afin de s'adapter au contrainte réseau de chaque client

Tu annonces un flux de 5 Mbps (Mbit/s) est il en flux constant (CBR) ou variable (VBR) ? ça peut jouer pas mal pour l'utilisation en charge de la lige réseau

Une dernière chose a prendre en compte dans la diffusion live c'est que c'est du live 🙂 je veux dire par la que l'image (une vidéo ce n'est rien de plus qu'une multitude d'image) qui est affichée compte peut si elle de mauvaise qualités si la ou les suivantes (25-30 images/s) rattrape le coup, l’œil ne verra pas le problème. en Live les images passées sont oubliées ce qui compte c'est l'instant T

Il est parfois (toujours dans une démarche Live) plus intéressant d'avoir un débit de flux vidéo plus faible mais avec un codage plus réfléchit (Compression, keyframe etc..) que de raisonner comme pour une vidéo  en lecture local ou ici le réseau ne rentre plus en compte. un live avec 500kps en 1280x720 peut donner un excellent résultat et comme tu l'imagine augmente d'autant l’audience admissible

Dernière chose,  un encodage d'un live, donc sa qualité, son débit, sont volume d’audience dépend aussi du type "d’événement" à retransmettre. Tu n'encode pas une diffusion d'un match de tennis comme celui d'un simple débat ou encore (le pire) d'un concert voir le notion des FastMotion vs SlowMotion.

Comme tu peux le comprendre, ce qui compte le plus n'est pas comment je vais diffuser (le support) mais avant c'est se poser la question du comment le mieux encoder, une fois l'encodage déterminé pour le résultat souhaité, tu as tous les éléments pour calculer l'auditoire possible (la couche transport).

Ne pas oublier le coté client, qui suivant les cas ne sont pas tous équipés de la même manière tant au niveau du débit réseau (d'ou importance de l’adoptive Streaming) que de leur ordi propre (si tu envoi du mp4 ou autre, faut le décoder derrière en plus de le récupérer et le restituer) 

Je ne connais pas le contexte de ton besoin, mais c'est un sujet passionnant, qui a beaucoup évolué ces dernières années, mais qui répond toujours aux mêmes règles de bases. Encoder un Live n'a rien à voir avec l'encodage d'une vidéo classique.

Si tu dois conserver un enregistrement du Live pour faire un "Replay" ou une vidéo à la demande, il faut le faire via un enregistrement et encodage en // mais différent.

Il existe des serveurs de Streaming qui même en réseau interne peuvent t'aider pour la diffusion, je n'ai pas de nom sous la main (ou de trop ancienne référence) mais imaginer le process suivant reste possible (dans le cas d'internet les Serveur de diffusion sont sur le net):

Captation (1 ou +) -> Machine avec règie de montage des flux et add-on (bandeaux etc...) -> Flux final -> Machine Encodage -> Serveur de Diffusion (1 ou + avec répartition de charge)

(En souvenir de mes nombreuses nuit blanches à déterminer le meilleur encodage pour différent événements Live 😉)

AD

 

Modifié le 4 mars 2019 par FraiseTagada

[FraiseTagada]

Une petite dernière chose "pratique"...

un Live (un Direct) est un Direct pour le client, lui il regarde en Direct une diffusion, mais ce Direct ne sera pas le même chez tous les clients au même moment, il peut pour certain y avoir un décalage plus ou moins important.

Au final c'est pas important puisque le client lui voit ce qu'il voit, mais si il compare il verra que toutes les diffusion ne sont pas réellement en même temps à un instant T

C'est con, mais c'est a savoir

C'est ce fameux décalage que l'ont constate dans les reportages en direct par exemple à la TV ou l'animateur veut couper le journaliste en reportage, et que le journaliste réagit que quelque secondes plus tard... Ont vois le journaliste en direct, mais en fait il est en direct décalé par rapport au direct studio de l'animateur, pourtant c'est du direct 🙂

C'est le même phénomène quand tu regardes un match de foot à la TV tranquillement et que tu sais qu'il va y avoir un but car par la fenêtre tu a entendu des gens hurler 🙂 quelques secondes (+ ou - longues) plus tard tu verra le but sur ta TV. Pourtant tous le monde regarde en...Direct

Tous ça pour dire que c'est normal !!

C'est une des raisons pour laquelle il n'est pas de bon usage de coller l'heure (et encore moins avec les secondes) sur un Live 🙂

Modifié le 4 mars 2019 par FraiseTagada

[J3R3M51]

Salut @FraiseTagada et un grand merci du temps accordé et tes réponses précises!

Il y a 15 heures, FraiseTagada a dit :

Des solutions comme CrtmpServer sont assez robustes mais pas destinées à une grande diffusion (volume en nombre),  200 ça reste à mon sens très raisonnable, faut tester, plusieurs VM en client et voir comment le system réagit ou se comporte (freeze aléatoire) et monter en charge. je n'ai jamais testé a plus de 50 avec ce genre d'outils, via des Serveur de Streaming c'est plus stable d'autant plus si tu fait de la répartition de charge)

Le but est effectivement d'avoir quelque chose de forcément fonctionnel, performant et stable. Je n'aurai malheureusement pas l'occasion de faire d'essais avec autant de clients avant, c'est pour cela que je cherche finalement à me diriger vers une solution sûre. Visiblement, celle-ci pourrait fonctionner, mais n'est pas garantie sans erreur, dommage.

Il y a 15 heures, FraiseTagada a dit :

Mais après tout rien ne t’empêche de te monter un pseudo CDN en interne, plusieurs machines dispos pour la diffusion, en frontal (le host de base) tu y met un Varnish et ça doit rouler (ok ok si tu connais pas la config Varnish c'est chiant mais ça se fait... c'est très stable et performant), j'ai déjà absorbé quelques 10-15000 diffusions temps réel instant T  avec ça.

Je ne connaissais pas cette abréviation. Quelques recherches plus tard, j''en sais un peu plus. Mais cela implique l'utilisation de plus de machines. Les machines (iMac) servant à encoder seront louées, cela signifie donc une augmentation des coûts en mettant cela en place. Le coût serait à comparer avec une installation en bon et dû forme je pense.

Il y a 16 heures, FraiseTagada a dit :

Avoir 2 clients (qui visualisent) ou 200 c'est pas la même chose bien sur, et il ne suffit pas de diviser le débit théorique de la ligne par le nombre de client. j'avais il y a quelque année fait un abaque pour calculer ce genre de chose. 

Effectivement, je n'étais pas bon de ce côté là. J'ai appris que ça serait vrai si du multicast était mis en place et c'est donc à ça que je pense.

Il y a 16 heures, FraiseTagada a dit :

Compte aussi énormément le Protocol utilisé... ici tu prend RTMP qui à vu ses beau jour avec Adobe Server ou ses équivalents gratuit comme Red5 ou Wonza etc... c’était un des plus utilisé pour restituer des lives sur le Web à cette époque ou le Flash était à la mode. Je ne suis pas certains qu'aujourd'hui ce soit le choix le plus pertinent, même si il fonctionne bien et que surtout via un serveur RTMP il est possible de faire en // du temps réel d'info en plus de la vidéo.

Des protocol comme le RTSP sont à mon sens plus performant, il est aussi important de penser a faire de "l'Adaptative Streaming" afin de s'adapter au contrainte réseau de chaque client

Oui, je parle de RTMP puisque c'est le seul protocole que j'ai été amené à utiliser jusqu'à présent. Je n'ose pas m'aventurer en eaux troubles... Mais je suis bien entendu ouvert à d'autres protocoles, surtout s'il y a un gain en efficacité. Je comprends d'ailleurs tout à fait le besoin de s'adapter à la connexion du client, il vaut mieux qu'il voit quelque chose d'un moins bonne qualité qu'un rien du tout en bonne qualité.

Il y a 16 heures, FraiseTagada a dit :

Tu annonces un flux de 5 Mbps (Mbit/s) est il en flux constant (CBR) ou variable (VBR) ? ça peut jouer pas mal pour l'utilisation en charge de la lige réseau

Pour le coup, j'ai l'habitude d'utiliser du VBR. Pour info, autres réglages que j'ai l'habitude d'utiliser : Framerate 25fps / Keyframe interval : 2s / Profil Main / Codec Son AAC-LC / 96kbps 48kHz.

Il y a 16 heures, FraiseTagada a dit :

Une dernière chose a prendre en compte dans la diffusion live c'est que c'est du live 🙂 je veux dire par la que l'image (une vidéo ce n'est rien de plus qu'une multitude d'image) qui est affichée compte peut si elle de mauvaise qualités si la ou les suivantes (25-30 images/s) rattrape le coup, l’œil ne verra pas le problème. en Live les images passées sont oubliées ce qui compte c'est l'instant T

Je suis totalement d'accord avec toi sur ce point!

Il y a 16 heures, FraiseTagada a dit :

Il est parfois (toujours dans une démarche Live) plus intéressant d'avoir un débit de flux vidéo plus faible mais avec un codage plus réfléchit (Compression, keyframe etc..) que de raisonner comme pour une vidéo  en lecture local ou ici le réseau ne rentre plus en compte. un live avec 500kps en 1280x720 peut donner un excellent résultat et comme tu l'imagine augmente d'autant l’audience admissible

Et je suis également d'accord avec cela, beaucoup ne verraient pas de différence. Mais techniquement, un full HD doit être retransmis. Le but est de prouver qu'il est possible de remplacer la modulation d'une retransmission en câble d'antenne, avec la même qualité. Je vais préciser cela plus bas 🙂

Il y a 16 heures, FraiseTagada a dit :

Dernière chose,  un encodage d'un live, donc sa qualité, son débit, sont volume d’audience dépend aussi du type "d’événement" à retransmettre. Tu n'encode pas une diffusion d'un match de tennis comme celui d'un simple débat ou encore (le pire) d'un concert voir le notion des FastMotion vs SlowMotion.

Si je te dis qu'on parle d'un concert, tu acceptes quand même de m'aider à trouver un compromis ? 😄

Il y a 16 heures, FraiseTagada a dit :

Comme tu peux le comprendre, ce qui compte le plus n'est pas comment je vais diffuser (le support) mais avant c'est se poser la question du comment le mieux encoder, une fois l'encodage déterminé pour le résultat souhaité, tu as tous les éléments pour calculer l'auditoire possible (la couche transport).

Les clients seraient des Raspberry branchés en HDMI sur des téléviseurs, sur lesquels nous aurions la main. Ils seraient tous câblés en RJ45, sauf si difficultés, le wifi pourrait être envisagé pour quelques postes clients.

Il y a 16 heures, FraiseTagada a dit :

Ne pas oublier le coté client, qui suivant les cas ne sont pas tous équipés de la même manière tant au niveau du débit réseau (d'ou importance de l’adoptive Streaming) que de leur ordi propre (si tu envoi du mp4 ou autre, faut le décoder derrière en plus de le récupérer et le restituer) 

Effectivement, il y a un juste milieu à trouver entre la bande passante et la capacité de décoder le signal à l'arrivée. Le x264 semble être un bon compromis pour cette utilisation. Qu'en penses-tu ?

Il y a 16 heures, FraiseTagada a dit :

Je ne connais pas le contexte de ton besoin, mais c'est un sujet passionnant, qui a beaucoup évolué ces dernières années, mais qui répond toujours aux mêmes règles de bases. Encoder un Live n'a rien à voir avec l'encodage d'une vidéo classique.

En effet, c'est passionnant, mais tellement vague quand on commence à plonger dedans. Les possibilités semblent être multiples, mais pas moins complexes. Jusqu'à présent, je me contentais d'encoder différents flux sur des serveurs web adéquats. Avoir soudainement à réfléchir à l'architecture complète du réseau local pour rester en intranet, c'est quelques niveaux au-dessus.

Il y a 16 heures, FraiseTagada a dit :

Si tu dois conserver un enregistrement du Live pour faire un "Replay" ou une vidéo à la demande, il faut le faire via un enregistrement et encodage en // mais différent.

Effectivement, ça pourra être fait directement dans le logiciel en créant un profil spécifique pour l'enregistrement en amont. C'est le plus simple, mais l'enregistrement n'est pas prévu normalement.

Il y a 16 heures, FraiseTagada a dit :

Il existe des serveurs de Streaming qui même en réseau interne peuvent t'aider pour la diffusion, je n'ai pas de nom sous la main (ou de trop ancienne référence) mais imaginer le process suivant reste possible (dans le cas d'internet les Serveur de diffusion sont sur le net):

Captation (1 ou +) -> Machine avec règie de montage des flux et add-on (bandeaux etc...) -> Flux final -> Machine Encodage -> Serveur de Diffusion (1 ou + avec répartition de charge)

J'y avais aussi pensé, ça serait tellement plus simple! Mais une solution la plus indépendante possible doit être mise en place, donc indépendante d'internet si possible. Pour info, les flux récupérés seront déjà habillés, seuls les flux finaux seront traités.

Il y a 15 heures, FraiseTagada a dit :

un Live (un Direct) est un Direct pour le client, lui il regarde en Direct une diffusion, mais ce Direct ne sera pas le même chez tous les clients au même moment, il peut pour certain y avoir un décalage plus ou moins important.

Merci de ces précisions. Je l'avais effectivement bien en tête. Même en maîtrisant toute une chaine, les traitements ne se feront pas toujours exactement au même moment, ce qui impliquera quelques petits décalages, mais ça ne pose pas de problème, les clients seront dans des espaces distincts, rien ne sera perceptible, même en passant d'un espace à l'autre.

Il y a 16 heures, FraiseTagada a dit :

(En souvenir de mes nombreuses nuit blanches à déterminer le meilleur encodage pour différent événements Live 😉)

En tous cas, elles semblent t'avoir été utiles. Et même plus que ça, elles sont désormais utiles à bien d'autres personnes, dont moi!

 

Je vais essayer de préciser davantage mon besoin. Je récupère 3 flux de concerts live différents que je souhaite streamer chacun sur un encodeur (iMac avec OBS ou Wirecast). Le but étant que ces flux (en 1080p au mieux, mais 1080i serait déjà très bien, surtout si besoin de libérer de la bande passante) soient récupérés à la demande par des clients. Chaque client pourra sélectionner l'un de ces trois flux via une interface en cours de développement.
Je dois avoir un système fiable et performant avec une qualité optimale, comment conseilles-tu de le faire avec les contraintes du réseau local? Il semblerait qu'il faille mettre en place un réseau multicast, ce qui impliquerait au minimum l'utilisation d'un switch L2. Certains sites affirment qu'il est plus judicieux de le faire avec un switch L3. Problème, je n'ai jamais utilisé de switchs manageables et n'en ai pas sous la main, même si je pense que la base de sa gestion peut être rapidement maitrisée. Bref, au niveau de l'architecture réseau, ce n'est pas encore très clair à l'heure actuelle. Et une fois que celle-ci sera plus claire, il restera à mettre en pratique le streaming au sein de celle-ci.

Penses-tu pouvoir m'aider à y voir plus clair ? 😄