WebRTC est de plus en plus utilisé pour construire des consoles de répartition basées sur navigateur pour la commandement d'urgence, les communications convergées, le contrôle industriel, la sécurité publique et les opérations à distance. Ses capacités audio et vidéo en temps réel permettent de combiner les appels, les conférences, les fonctions de commandement et les communications multimédias dans une seule interface web, sans que les opérateurs aient à installer un client de bureau traditionnel.

Le défi apparaît lorsque la plateforme de répartition doit également afficher la vidéo des systèmes de surveillance existants, des caméras de surveillance portables, des drones, des dispositifs portés sur le corps ou des plateformes vidéo tierces. Ces systèmes peuvent utiliser différents codecs, protocoles de transport, résolutions, fréquences d'images et formats de streaming. Un flux vidéo qui fonctionne correctement au sein d'une plateforme de surveillance peut donc ne pas être lu directement dans une console de répartition WebRTC. La solution pratique n'est pas de redéfinir l'ensemble de l'application de répartition, mais de placer une couche de conversion des médias et d'adaptation des protocoles entre la source vidéo et la console basée sur navigateur.

Pourquoi l'accès vidéo devient difficile

Un système de répartition moderne est rarement limité à la voix. Les opérateurs peuvent avoir besoin de répondre aux appels, de communiquer avec le personnel sur le terrain, de surveiller les flux de vidéosurveillance, de visualiser une caméra de drone, de participer à une visioconférence et d'inspecter un lieu d'incident depuis le même poste de travail. Le système est donc censé connecter des ressources de communication qui ont été conçues à l'origine de manière indépendante.

WebRTC fonctionne particulièrement bien pour la communication interactive par navigateur. Il offre une transmission multimédia à faible latence et est largement utilisé pour les applications audio, vidéo et de conférence basées sur navigateur. Une console de répartition construite autour de WebRTC peut exposer des commandes de communication via une interface web standard et peut être intégrée plus facilement à d'autres applications métier qu'un client de bureau fermé.

L'infrastructure de surveillance, cependant, suit une histoire technique différente. Les caméras, les enregistreurs vidéo réseau, les systèmes de gestion vidéo, les terminaux de surveillance portables, les drones et les plateformes de surveillance spécifiques à l'industrie peuvent fournir des flux via GB/T28181, RTSP, RTP, RTMP, HLS, SIP ou d'autres interfaces. Ils peuvent également utiliser des codecs vidéo choisis principalement pour l'efficacité du stockage plutôt que pour la lecture sur navigateur.

Le problème qui en résulte est un fossé d'interopérabilité. La source vidéo est disponible, la console de répartition fonctionne normalement et la connexion réseau est active, mais le navigateur ne peut toujours pas décoder ou consommer le flux dans sa forme originale.

Produit associé : Console de répartition Becke

Là où H.265 crée un fossé de compatibilité

L'un des problèmes d'intégration les plus courants apparaît lorsqu'un système de surveillance diffuse de la vidéo H.265. H.265, également connu sous le nom de HEVC, est attrayant pour les applications de surveillance car il peut réduire les exigences de bande passante et de stockage par rapport aux méthodes de codage plus anciennes, à qualité d'image comparable. Pour les grandes installations de caméras, cette efficacité peut être précieuse.

Le problème est que la prise en charge de la lecture H.265 n'est pas disponible de manière homogène dans les environnements WebRTC et navigateurs typiques. Une plateforme de surveillance peut donc fournir un flux H.265 parfaitement valide qui ne peut pas être consommé directement par l'application WebRTC utilisée au poste de répartition.

Remplacer toutes les caméras ou modifier toute la plateforme de surveillance simplement pour satisfaire le navigateur est généralement peu pratique. Modifier la console de répartition autour de chaque codec tiers possible crée également une complexité de développement inutile. Une approche plus gérable consiste à normaliser les médias avant qu'ils n'atteignent WebRTC.

Dans cette architecture, un service de transcodage vidéo reçoit le flux H.265 original et le convertit en H.264 ou dans un autre format pris en charge par l'environnement WebRTC cible. La console de répartition consomme alors le flux converti plutôt que d'essayer de décoder directement les médias H.265 d'origine.

Cette séparation est importante car elle maintient la compatibilité multimédia en dehors de l'application de répartition principale. L'interface navigateur peut continuer à utiliser son flux de travail WebRTC normal tandis que la passerelle gère l'adaptation du codec en arrière-plan.

Une architecture pratique de passerelle de transcodage

Une passerelle de transcodage vidéo agit comme le pont multimédia entre les ressources de surveillance et la couche de répartition WebRTC. Son rôle est plus large que la simple conversion de codec. Dans un projet de communications convergées réel, elle peut avoir besoin de recevoir des flux de plusieurs plateformes vidéo, de convertir les paramètres multimédia, de reconditionner les flux et de les publier dans un format que le système de répartition peut utiliser.

Un flux de travail typique peut être divisé en cinq étapes :

1. La plateforme de répartition demande une caméra, un drone, un dispositif de surveillance portable ou une ressource vidéo tierce spécifique.

2. La passerelle obtient le flux source via le protocole de surveillance ou de streaming disponible.

3. Le service multimédia vérifie le codec entrant, la résolution, la fréquence d'images, le débit binaire et le format du flux.

4. Si nécessaire, la vidéo est transcodée ou reconditionnée dans un format adapté à l'environnement WebRTC.

5. Les médias convertis sont livrés à la console de répartition basée sur navigateur pour une visualisation en temps réel.

Pour une source H.265, l'étape la plus importante est généralement la conversion H.265 vers H.264. Dans d'autres projets, le codec peut déjà être compatible mais la résolution, le débit binaire, la fréquence d'images ou le conditionnement du protocole peuvent encore nécessiter un ajustement.

Cette architecture réduit également le couplage entre les systèmes. La plateforme de surveillance n'a pas besoin de comprendre comment l'interface de répartition est implémentée, et l'application WebRTC n'a pas besoin de contenir une logique dédiée pour chaque fournisseur de caméras ou format de streaming. Chaque côté se connecte à une couche d'adaptation multimédia conçue spécifiquement pour l'interopérabilité.

Interfonctionnement des protocoles entre systèmes vidéo

La conversion de codec ne résout qu'une partie du problème d'intégration. Différents systèmes peuvent également utiliser des protocoles de signalisation et de transport différents. Une passerelle vidéo complète doit donc effectuer une adaptation de protocole ainsi qu'un traitement multimédia.

Les interfaces courantes rencontrées dans les environnements de commandement et de surveillance incluent GB/T28181, RTSP, RTP, RTMP, FLV, HLS, SIP et WebRTC. Leurs objectifs ne sont pas identiques. Certaines sont utilisées pour l'accès et le contrôle des dispositifs de surveillance, certaines pour le transport multimédia en temps réel, certaines pour la distribution en streaming, et d'autres pour la signalisation de session ou la communication par navigateur.

Une passerelle positionnée entre ces systèmes peut recevoir un flux dans un format et le fournir via une autre interface requise par la plateforme de répartition. Par exemple, une caméra de surveillance peut être accessible via RTSP, tandis qu'une plateforme de surveillance existante peut exposer des ressources via GB/T28181. L'application de répartition n'a pas besoin de consommer ces protocoles directement si la passerelle les convertit en un chemin de livraison compatible WebRTC.

Un service de streaming intégré peut également gérer l'extraction et la publication des flux. Lorsqu'un opérateur sélectionne une caméra, le système peut initier une opération d'extraction depuis la plateforme source, traiter les médias et publier le flux résultant vers la console de répartition. Cela évite de maintenir des flux inutiles lorsqu'une ressource n'est pas visualisée.

La même architecture est utile au-delà de la vidéosurveillance. Les caméras de surveillance portables, la vidéo drone, les visiophones, les systèmes de conférence et d'autres ressources multimédias en temps réel peuvent tous entrer dans l'environnement de commandement unifié via différents protocoles. Une passerelle consciente des protocoles fournit un point commun pour gérer ces différences.

Flux de travail de déploiement pour les projets réels

Un projet d'intégration réussi doit commencer par l'environnement vidéo existant plutôt que par la seule interface WebRTC. La première tâche consiste à identifier les ressources à afficher et comment ces ressources sont actuellement exposées.

Cartographier les sources vidéo existantes

L'équipe du projet doit lister les plateformes de surveillance, les caméras fixes, les caméras portables, les drones, les systèmes de conférence, les visiophones et toute autre source pertinente. Pour chaque ressource, le protocole disponible, le codec, la résolution, la fréquence d'images, la méthode d'authentification et l'emplacement réseau doivent être documentés.

Séparer la signalisation des médias

Dans certains systèmes, la signalisation détermine à quel appareil accéder tandis que les médias sont transportés via un autre protocole. Traiter la signalisation et les médias comme des couches d'intégration séparées facilite le dépannage. Une caméra peut s'enregistrer et être contrôlée avec succès alors que son flux vidéo échoue encore en raison d'une incompatibilité de codec ou de transport.

Normaliser uniquement lorsque c'est nécessaire

Le transcodage consomme des ressources informatiques et peut introduire un délai de traitement supplémentaire. Une passerelle pratique doit donc éviter les conversions inutiles. Si la source utilise déjà un codec et un profil multimédia acceptés par l'environnement WebRTC, le reconditionnement ou le réacheminement peut être suffisant. Le transcodage complet doit être utilisé lorsque les codecs ou les paramètres multimédia sont véritablement incompatibles.

Utiliser l'extraction de flux à la demande

Les grands systèmes de surveillance peuvent contenir des centaines ou des milliers de caméras, mais un opérateur de répartition visualise normalement seulement un petit sous-ensemble à la fois. Démarrer un flux uniquement lorsqu'un opérateur le demande peut réduire la bande passante, la charge de traitement multimédia et la consommation inutile de ressources du serveur.

Garder le flux de travail de l'opérateur simple

La conversion multimédia doit rester invisible pour l'opérateur de répartition. Idéalement, l'opérateur sélectionne une caméra à partir d'une liste de contacts, d'une carte SIG, d'une page d'incident ou d'un panneau de ressources vidéo et l'image s'ouvre directement. La sélection du protocole, la conversion du codec, l'établissement du flux et la récupération doivent être gérés par le backend.

La fiabilité et la qualité des médias sont importantes

Rendre un flux visible n'est que la première étape. Les applications de commandement d'urgence et de répartition industrielle ont également besoin d'une vidéo stable dans des conditions de réseau changeantes. Une couche multimédia utilisable doit donc être capable de s'adapter à plus que le seul codec.

L'ajustement de la résolution peut être utile lorsqu'une caméra haute résolution doit être affichée dans une fenêtre de répartition plus petite ou délivrée via une connexion réseau restreinte. La conversion de la fréquence d'images peut réduire les exigences de traitement et de bande passante pour les scénarios de surveillance où des fréquences d'images extrêmement élevées ne sont pas nécessaires. Le contrôle du débit binaire peut aider à maintenir la continuité lorsque la capacité réseau disponible change.

Ces capacités sont également utiles lorsque deux systèmes vidéo utilisent des profils multimédias différents bien que tous deux supportent nominalement H.264. Les différences de résolution, de profil, de fréquence d'images, de débit binaire ou de segmentation peuvent encore empêcher une interopérabilité fluide.

La passerelle multimédia peut donc servir de point de normalisation entre les visiophones, les plateformes de conférence, les systèmes de vidéosurveillance, les flux de drones et les applications de répartition basées sur navigateur. Au lieu d'exiger que chaque sous-système corresponde directement à chaque autre sous-système, chaque système n'a besoin que d'une connexion fiable à la passerelle.

La conception du réseau doit également prendre en compte le délai, la perte de paquets, la récupération de flux, l'authentification, le contrôle d'accès et les exigences de visualisation simultanée. Un centre de commandement peut avoir besoin de plusieurs opérateurs pour visualiser la même source, tandis qu'un incident peut soudainement nécessiter l'ouverture simultanée de plusieurs ressources vidéo. La planification de la capacité doit refléter des flux de travail de pointe réalistes plutôt qu'un seul flux de test.

Remarques finales

WebRTC fournit une base efficace pour les consoles de répartition basées sur navigateur, mais les systèmes de commandement réels doivent connecter bien plus que les points d'extrémité WebRTC natifs. Les plateformes de vidéosurveillance, les drones, les équipements de surveillance portables, les systèmes de conférence et les ressources vidéo héritées introduisent souvent différents codecs et protocoles de streaming.

H.265 est une source particulièrement courante d'incompatibilité. Au lieu de redéfinir la console de répartition ou de remplacer l'équipement de surveillance existant, une passerelle de transcodage multimédia peut recevoir le flux original, convertir H.265 en H.264 si nécessaire, adapter la résolution, la fréquence d'images et le débit binaire, et livrer le résultat via un chemin compatible WebRTC.

Lorsque la même passerelle prend également en charge des interfaces telles que GB/T28181, RTSP, RTP, RTMP, FLV, HLS, SIP et WebRTC, elle devient une couche d'interopérabilité pratique pour une architecture de communications convergées plus large. Le résultat est un flux de travail de répartition dans lequel les opérateurs peuvent accéder à des ressources vidéo hétérogènes via une seule interface tandis que la conversion de codec et l'adaptation de protocole restent en arrière-plan.

FAQ

Chaque flux de surveillance doit-il être converti en permanence avant qu'un opérateur ne le demande ?

Généralement non. Dans les grandes installations, le traitement à la demande est souvent plus efficace. Le service multimédia peut commencer à extraire et à adapter un flux lorsqu'un opérateur ouvre la ressource correspondante, puis libérer la capacité de traitement lorsque le flux n'est plus nécessaire.

Le même flux de caméra peut-il être livré à plusieurs opérateurs de répartition ?

Oui, à condition que l'architecture de streaming soit conçue pour une distribution de un à plusieurs. Un service multimédia peut recevoir une source une fois et distribuer la sortie traitée à plusieurs visualisateurs autorisés au lieu d'ouvrir une connexion montante séparée pour chaque opérateur.

Comment les autorisations d'accès vidéo doivent-elles être gérées ?

L'accès aux caméras doit normalement suivre les autorisations d'utilisateur et de rôle de la plateforme de répartition. Les opérateurs peuvent être autorisés à visualiser uniquement des régions, installations, groupes de caméras ou ressources liées à des incidents spécifiques, tandis que les administrateurs peuvent recevoir des privilèges de contrôle et de configuration plus larges.

Que se passe-t-il lorsque la source vidéo originale devient temporairement indisponible ?

L'application de répartition doit recevoir un état clair hors ligne ou en cours de reconnexion plutôt que d'afficher une image figée indéfiniment. Le backend peut tenter une reconnexion selon des politiques de reprise définies et restaurer automatiquement le flux après que la source en amont redevienne disponible.