Blog-note de Sasha
gitlab github rss
/réalisations/thèmes/résumés
Omniroom.
    Découverte du WHIP.
    Posted on 2023-05-27

    J'ai pu découvrir récemment le protocole WHIP qui vise a standardiser la négociation webrtc.
    Une implémentation en go est dispo et s'appelle Broadcast-box

    Après avoir pas mal joué avec cette implémentation c'est cool mais 2 features sont manquantes:

    • Le STUN, plutot que d'avoir à donner en dur l'IP qui sera utilisée pour les candidats ICE
    • Les PATCH pour la négociation des candidats ICE à postériori, car pour l'instant il faut obligatoirement que les candidats se trouvent dans l'offre SDP de départ. Ce qui réduit la modularité d'architecture, car un SDP déjà fourni de candidats ICE ne peut se faire que dans le cas d'une négociation provenant d'une URL identique à celle du serveur WHIP. (Ne fonctionne pas dans le cas d'une page locale ou d'une extension par exemple) (ou alors j'ai pas trouvé)

    Je vais voir pour implémenter ca et soumettre une PR à Broadcast-box Afin de pouvoir ensuite dev une extension Firefox pour indiquer si un stream est actuellement dispo via WHIP

    Il y a de fortes chances que je finisse par implémenter le WHIP dans Omniroom plutot que mon protocole maison

    Présentation et état des lieux d'Omniroom.
    Posted on 2023-01-03

    Ce logiciel trouve ses début lors d'un événement où nous avons concu et animé une escape game avec des amis et nous avions un besoin de monitoring video très réactif afin d'aider les joueuses.

    Le besoin:

    • Avoir des cameras très légères et facilement déployable dans une ou plusieurs pièces
    • Pouvoir consulter les flux vidéos rapidement et de facon accessible (sans installation de binaire sur le système)
    • Le flux doit être le plus faible latence possible

    Je suis donc partie sur le WebRTC:
    latences
    Car cela solutionne à la fois la latence et l'accessibilité car compatible avec les naviguateurs actuels

    La négociation WebRTC se fait souvent au travers d'un "signaling server", l'architecture se décrit donc comme ceci:
    Clients <-> Signaling server <-> Cameras
    Puis, une fois la négociation faite, voici l'échange des flux:
    Clients <-> Cameras
    (Ici j'ignore le fait qu'il puisse y avoir de la surcharge réseau)

    La première version était en:

    • Client: html+css+js
    • Server: python
    • Camera: C

    J'utilise GStreamer pour la gestion du flux video et la négociation WebRTC, cela pourra changer à l'avenir en utilisant Gstreamer + Webrtc-rs ou même ffmpeg + Webrtc-rs

    J'ai depuis refondu tout ca et maintenant tout est en Rust

    Il reste cependant un soucis de fonctionnement qui empeche le flux de passer alors que la négociation s'effectue bien.

    Dépots git:

    • Client
    • Server
    • Camera