Métadonnées de bande latérale

Les métadonnées de bande latérale (SBM) constituent un mécanisme de transport de métadonnées proposé aux lecteurs qui ne sont pas en mesure d'utiliser de métadonnées multiplexées dans le flux lui-même (comme pour FLV, Shoutcast V1/V2, etc.), soit parce que c’est impossible, difficile, soit parce que beaucoup de ressources sont nécessaires. Par exemple, les lecteurs qui utilisent la balise HTML5 <audio>  ou qui délèguent la lecture instantanée du flux au lecteur multimédia standard du système d'exploitation (par exemple, iOS ou Android) ont besoin d'un moyen de recevoir des marqueurs sans avoir à traiter le flux lui-même.

Cela est effectué en utilisant une connexion aux métadonnées séparée (corrélée au flux), à l'aide de Server-Sent Events (SSE). Les lecteurs sont responsables de la mise en file d'attente des événements reçus et de leur déclenchement lorsque le lecteur multimédia atteint l'horodatage correspondant à chaque événement.

Identifiant de session de métadonnées de bande latérale

Afin de corréler une connexion au flux à celle de ses métadonnées associées, il est nécessaire d'utiliser un identifiant commun partagé par les deux connexions.

Le lecteur est chargé de générer cet identifiant de session SBM, qui prend la forme d'un UUID de type 4 (c'est-à-dire aléatoire), présenté sous forme de chaîne hexadécimale en minuscules, comme par exemple :

fde807eb-6931-47db-a758-9c3b0c7e84d5

Le lecteur est également responsable de la transmission de l'identifiant de session SBM lors de la connexion au flux, et de celle du point de terminaison du SSE SBM. Cela est expliqué dans les sections suivantes.

Connexion au flux

En ce qui concerne les lecteurs HTML5, le lecteur doit se connecter au flux standard Shoutcast ou HTTP Live Streaming (HLS) (p. ex. les transports shoutcast et hls ). En outre, si le lecteur choisit d'utiliser le SBM, il doit inclure l'ID de session des métadonnées en bande latérale décrit dans la section précédente via le paramètre de requête sbmid. Dans le cas contraire, le lecteur ne devra pas intégrer le paramètre sbmid (car la conservation des informations de session SBM coûte des ressources aux serveurs de diffusion en continu).

Par exemple :

http://1234.live.streamtheworld.com:80/KROQFM_SC?sbmid=fde807eb-6931-47db-a758-9c3b0c7e84d5

Comme mentionné précédemment, un nouvel identifiant de session SBM doit être généré à chaque fois que le lecteur se connecte ou se reconnecte au flux.

Une fois que la connexion au flux a été établie, le lecteur peut créer sa connexion aux métadonnées, dans Connexion aux métadonnées.

Connexion aux métadonnées

Pour recevoir ses métadonnées, le lecteur utilise une connexion SSE (Server-Sent Events) au point de terminaison de la connexion aux métadonnées. Le lecteur doit se connecter à la même instance de serveur de streaming à laquelle il s’est connecté pour son flux (c’est-à-dire à la même adresse IP et au même port).

La connexion aux métadonnées applique le suffixe (spécifié par l’élément <sse-sideband mountSuffix= »..."> reçu de l’API d’approvisionnement du lecteur), ajouté au nom du montage. Le même sbmid utilisé pour la connexion au flux doit également être transmis par le lecteur. Par exemple, pour la connexion au flux présentée dans l'exemple précédent, l'URL associée de connexion aux métadonnées serait :

http://1234.live.streamtheworld.com:80/KROQFM_SBM?sbmid=fde807eb-6931-47db-a758-9c3b0c7e84d5

Si, pour une raison quelconque, le lecteur ne peut pas se connecter au point de terminaison SBM ou reçoit une erreur de la part de la MG, il doit limiter ses tentatives de reconnexion, en utilisant le même algorithme exponentiel que celui employé lors des connexions au flux (comme indiqué en détail dans ce document).

Les marqueurs individuels seront envoyés en tant que Server-Sent Events séparés sur la même connexion. Le lecteur reste alors connecté au point de terminaison des SBM jusqu'à ce que la connexion au flux soit interrompue. Si la connexion aux SBM est interrompue prématurément, et que la connexion au flux reste active, le lecteur doit se reconnecter au point de terminaison des SBM à l'aide du même identifiant de session SBM précédemment utilisé. Toutefois, si la connexion au flux a été interrompue (volontairement ou involontairement), la connexion au SBM doit également être arrêtée. La reconnexion nécessite de générer un nouvel identifiant de session SBM, avant de se reconnecter au flux et aux points de terminaison SBM.

Gestion des métadonnées côté lecteur

Avec les métadonnées de bande latérale (SBM), les marqueurs arriveront à l'avance et cela doit être géré par le lecteur.  Le lecteur doit mettre en file d'attente tous les marqueurs reçus (en tant que Server-Sent Events) sur la connexion aux SBM. La file d'attente doit prendre en charge le retrait des événements en fonction de leur horodatage. Le retrait de la file d'attente s'effectue (généralement) dans un gestionnaire d'événement timeupdate attaché à la balise HTML5 <audio>. La file d’attente doit renvoyer l’événement suivant dans la file d’attente, à condition que son horodatage soit inférieur à l’horodatage actuel du flux. Lorsqu'un événement est retiré de la file, il doit être géré comme un marqueur normal (c.-à-d. déclenchement des modifications de libellé, présentation de l'annonce d'accompagnement, etc.).

Charge utile des métadonnées de bande latérale

Les métadonnées sont envoyées dans le format de données JSON. Le format JSON est un mappage direct des marqueurs FLV.

Tous les marqueurs sont conformes au dictionnaire de métadonnées STWCue de Triton Digital. Les montages utilisant AndoXML ne prennent pas en charge les métadonnées de bande latérale HTML5.

Exemple de marqueur « ad »

{
  "type": "onCuePoint",
  "name": "ad",
  "timestamp": 114832,
  "parameters": {
    "ad_id": "cm-2134",
    "ad_type": "break",
    "cue_time_duration": "32000",
    "cue_title": "Annoying Ad"
                }
}

Comme pour les marqueurs STWCue standard, toutes les valeurs des paramètres sont des chaînes. Notez que l’attribut timestamp est un entier qui représente le nombre de millisecondes écoulées depuis le début du flux.

Il existe quatre types d'événements pouvant être reçus, comme indiqué dans le tableau ci-dessous.

Types d'événements de marqueur « Ad »