Protocoles de streaming du lecteur-récepteur Web

Actuellement, le SDK Web Receiver est compatible avec trois types de protocoles de streaming:

DASH, HTTP Live Streaming et Smooth Streaming.

Dans ce document, nous listons notre prise en charge pour chacun des protocoles de streaming. Notez que l'explication des tags compatibles avec chaque protocole est assez abrégée par rapport aux spécifications détaillées du protocole. L'objectif est de vous donner un aperçu rapide de l'utilisation de chaque protocole, ainsi que des fonctionnalités compatibles avec les appareils compatibles Cast afin de proposer des expériences de streaming.

Streaming adaptatif dynamique sur HTTP (DASH)

Spécification ISO de DASH.

DASH est un protocole de streaming à débit adaptatif qui permet de diffuser des vidéos en streaming de haute qualité via des serveurs HTTP(S). Un fichier manifeste, composé en XML, contient la plupart des informations de métadonnées permettant d'initialiser et de télécharger le contenu vidéo. Les concepts clés compatibles avec le lecteur Web récepteur sont <Period>, <AdaptationSet>, <Representation>, <SegmentTemplate>, <SegmentList>, <BaseUrl> et <ContentProtection>.

Un fichier manifeste DASH commence par une balise <MPD> racine et contient une ou plusieurs balises <Period>, qui représentent un contenu en streaming. Les balises <Period> permettent de classer différents contenus en streaming. Elles sont souvent utilisées pour séparer le contenu principal et la publicité ou plusieurs contenus vidéo consécutifs.

Un <AdaptationSet> sous <MPD> est un ensemble de représentations pour un type de flux multimédia, dans la plupart des cas des vidéos, de l'audio ou des sous-titres. Les types MIME les plus couramment acceptés sont "video/mp4", "audio/mp4" et "text/vtt". Un élément <ContentComponent contentType="$TYPE$"> facultatif peut être inclus sous <AdaptationSet>.

Dans chaque élément <AdaptationSet>, une liste de balises <Representation> doit être présente. Le lecteur Web récepteur utilise les informations codecs pour initialiser le tampon source du MSE et les informations bandwidth pour choisir automatiquement la représentation/débit à lire.

Pour chaque <Representation>, les segments multimédias sont décrits à l'aide d'un <BaseURL> pour la représentation d'un seul segment, de <SegmentList> pour la liste de segments (semblable à HLS) ou de <SegmentTemplate>.

Pour une <SegmentTemplate>, il indique comment le segment d'initialisation et les segments multimédias peuvent être représentés par des modèles. Dans l'exemple ci-dessous, $Number$ indique le numéro de segment disponible à partir du CDN. Cela se traduit donc par seg1.m4s, seg2.m4s, etc. au fur et à mesure de la lecture.

<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:ns2="http://www.w3.org/1999/xlink"
  profiles="urn:mpeg:dash:profile:isoff-live:2011,http://dashif.org/guidelines/dash264" type="static"
  publishTime="2016-10-05T22:07:14.859Z" mediaPresentationDuration="P1DT0H0M0.000S" minBufferTime="P0DT0H0M7.500S">
  <Period id="P0">
    <AdaptationSet lang="en" segmentAlignment="true">
      <ContentComponent id="1" contentType="audio"/>
      <SegmentTemplate media="seg$Number$.m4s" initialization="seginit.mp4"
        duration="10000" startNumber="1" timescale="1000" presentationTimeOffset="0"/>
      <Representation id="1" bandwidth="150123" audioSamplingRate="44100"
        mimeType="audio/mp4" codecs="mp4a.40.2" startWithSAP="1">
        <AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"/>
        <BaseURL>http://www.google.com/testVideo</BaseURL>
      </Representation>
    </AdaptationSet>
    <AdaptationSet segmentAlignment="true">
      <ContentComponent id="1" contentType="video"/>
      <SegmentTemplate media="seg$Number$.m4s" initialization="seginit.mp4"
        duration="10000" startNumber="1" timescale="1000" presentationTimeOffset="0"/>
      <Representation id="1" bandwidth="212191" width="384" height="208" sar="26:27"
        frameRate="25" mimeType="video/mp4" codecs="avc1.42c01f" startWithSAP="1">
        <BaseURL>http://www.google.com/testVideo/bitrate1/</BaseURL>
      </Representation>
      <Representation id="1" bandwidth="366954" width="512" height="288" sar="1:1"
        frameRate="25" mimeType="video/mp4" codecs="avc1.42c01f" startWithSAP="1">
        <BaseURL>http://www.google.com/testVideo/bitrate2/</BaseURL>
      </Representation>
      <Representation id="1" bandwidth="673914" width="640" height="352" sar="44:45"
        frameRate="25" mimeType="video/mp4" codecs="avc1.42c01f" startWithSAP="1">
        <BaseURL>http://www.google.com/testVideo/bitrate3/</BaseURL>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

Pour <SegmentTemplate>, il est courant d'utiliser la balise <SegmentTimeline> pour indiquer la longueur de chaque segment et les segments qui se répètent. Un timescale (unités représentant une seconde) est souvent inclus dans les attributs de <SegmentTemplate> afin que nous puissions calculer l'heure du segment en fonction de cette unité. Dans l'exemple ci-dessous, la balise <S> correspond à une balise de segment, l'attribut d indique la durée du segment et l'attribut r spécifie le nombre de segments de même durée qui se répètent afin que $Time$ puisse être calculé correctement pour télécharger le segment multimédia, comme spécifié dans l'attribut media.

<SegmentTemplate>
  timescale="48000"
  initialization="$RepresentationID$-init.dash"
  media="$RepresentationID$-$Time$.dash"
    startNumber="1">
    <SegmentTimeline>
      <S t="0" d="96256" r="2" />
      <S d="95232" />
      <S d="96256" r="2" />
      <S d="95232" />
      <S d="96256" r="2" />
   </SegmentTimeline>
</SegmentTemplate>

Voici un exemple pour la représentation à l'aide de <SegmentList>:

<Representation id="FirstRep" bandwidth="2000000" width="1280"
  height="720">
  <BaseURL>FirstRep/</BaseURL>
  <SegmentList timescale="90000" duration="270000">
     <RepresentationIndex sourceURL="representation-index.sidx"/>
     <SegmentURL media="seg-1.ts"/>
     <SegmentURL media="seg-2.ts"/>
     <SegmentURL media="seg-3.ts"/>
  </SegmentList>
</Representation>

Pour un fichier segment unique, un <SegmentBase> est souvent utilisé avec les requêtes de plage d'octets pour spécifier quelle partie d'un fichier <BaseURL> contient l'index. Le reste peut être récupéré à la demande lorsque la lecture ou une recherche se produit. Ici, la plage Initialization spécifie la plage de métadonnées d'initialisation et indexRange spécifie l'index des segments multimédias. Notez qu'à l'heure actuelle, nous n'acceptons que les plages d'octets consécutives.

<Representation bandwidth="4190760" codecs="avc1.640028"
  height="1080" id="1" mimeType="video/mp4" width="1920">
  <BaseURL>video.mp4<BaseURL>
  <SegmentBase indexRange="674-1149">
    <Initialization range="0-673" />
  </SegmentBase>
</Representation>

Quelle que soit la représentation utilisée, si les flux sont protégés, une section <ContentProtection> peut apparaître sous <AdaptationSet>, où un schemeIdUri identifie de manière unique le système DRM à utiliser. Un ID de clé facultatif peut être inclus pour le chiffrement courant.

<!-- Common Encryption -->
<ContentProtection
  schemeIdUri="urn:mpeg:dash:mp4protection:2011"
  value="cenc"
  cenc:default_KID="7D2714D0-552D-41F5-AD56-8DD9592FF891">
</ContentProtection>

<!-- Widevine -->
<ContentProtection
  schemeIdUri="urn:uuid:EDEF8BA9-79D6-4ACE-A3C8-27DCD51D21ED">
</ContentProtection>

Pour plus d'exemples et de détails, consultez la spécification MPEG-DASH. Vous trouverez ci-dessous une liste d'attributs DASH supplémentaires pour les balises non mentionnées ci-dessus, actuellement compatibles:

Nom de l'attribut Fonction d'attribut
mediaPresentationDuration La durée du contenu vidéo.
minimumUpdatePeriod Attribut de la balise <MPD>. Indique la fréquence à laquelle nous devons actualiser le fichier manifeste.
type Attribut de la balise <MPD> : "dynamique" pour indiquer qu'il s'agit d'une diffusion en direct.
presentationTimeOffset Attribut de la balise <SegmentBase> ; spécifie le décalage temporel de présentation par rapport au début de la période.
startNumber Spécifie le numéro du premier segment multimédia d'une présentation au cours d'une période. Cette fonction est souvent utilisée dans les diffusions en direct.

Nous prenons également en charge la reconnaissance de la zone EMSG dans les fragments MP4 pour DASH et fournissons un EmsgEvent aux développeurs.

Bien que notre lecteur Web récepteur Web actuel soit compatible avec les principaux cas d'utilisation de DASH, voici une liste d'attributs courants que notre implémentation actuelle de DASH ignore ou n'utilise pas. Cela signifie que, que le fichier manifeste les contienne ou non, ils n'ont aucune incidence sur l'expérience de lecture du contenu.

  • availabilityStartTime
  • segmentAlignment

HTTP Live Streaming (HLS)

La présentation et les spécifications complètes de la diffusion en direct HTTP sont disponibles sur cette page.

L'un des points forts du lecteur Web récepteur est sa capacité à prendre en charge la lecture du HLS dans MSE. Contrairement à DASH, où un fichier manifeste se compose d'un seul fichier, HLS envoie la playlist principale contenant la liste de tous les flux de variantes avec leur URL respective. La playlist de variantes est la playlist de contenus multimédias. Les deux principales balises HLS actuellement compatibles avec la playlist principale sont les suivantes:

Nom de la balise Fonctionnalité
#EXT-X-STREAM-INF Spécifie un débit ou un flux de variantes. L'attribut BANDWIDTH, qui est compatible avec la sélection de streaming à débit adaptatif, est requis. L'attribut CODECS est vivement recommandé pour initialiser MSE, tel que "avc1.42c01e,mp4a.40.2". Si aucune valeur n'est spécifiée, le cas par défaut est défini sur le profil principal H264 3.0 pour le contenu vidéo et "mp4a.40.2" encodé en audio.
#EXT-X-MEDIA Spécifie une playlist de contenus multimédias supplémentaire (dans l'attribut URI) qui représente le contenu. Il s'agit généralement d'autres flux audio dans un autre format (son surround 5.1) ou dans une autre langue. Un attribut de TYPE contenant VIDEO, AUDIO, SUBTITLES ou CLOSED-CAPTIONS est autorisé. Définir l'attribut DEFAULT sur YES indique le choix de ce flux alternatif par défaut.

Voici la liste des tags HLS actuellement compatibles avec la playlist de contenus multimédias par le lecteur Web récepteur:

Nom de la balise Fonctionnalité
#EXTINF Informations relatives au flux, généralement suivies de la durée du segment en secondes et de l'URL du segment sur la ligne suivante.
#EXT-X-TARGETDURATION Durée de chaque segment, en secondes. Cette valeur détermine également la fréquence de téléchargement/d'actualisation du fichier manifeste de playlist pour un flux en direct. Web Receiver Player n'est pas compatible avec les durées inférieures à 0,1 s.
#EXT-X-MEDIA-SEQUENCE Numéro de séquence (souvent pour une diffusion en direct) que le premier segment de cette playlist représente.
#EXT-X-KEY Informations importantes concernant la DRM. L'attribut METHOD nous indique le système de clés à utiliser. Aujourd'hui, nous acceptons AES-128 et SAMPLE-AES.
#EXT-X-BYTERANGE Plage d'octets à extraire pour une URL de segment.
#EXT-X-DISCONTINUITY Indique une discontinuité entre des segments consécutifs. Cela se produit souvent avec l'insertion d'annonces côté serveur, où un segment d'annonces apparaît au milieu du flux principal.
#EXT-X-PROGRAM-DATE-TIME Heure absolue du premier échantillon du segment suivant, par exemple "2016-09-21T23:23:52.066Z".
#EXT-X-ENDLIST s'il s'agit d'une vidéo à la demande ou d'une diffusion en direct ;

Pour le streaming en direct, nous utilisons #EXT-X-PROGRAM-DATE-TIME et #EXT-X-MEDIA-SEQUENCE comme facteurs clés pour déterminer comment fusionner un fichier manifeste récemment actualisé. S'il est présent, #EXT-X-PROGRAM-DATE-TIME permet de faire correspondre les segments actualisés. Sinon, c'est le numéro #EXT-X-MEDIA-SEQUENCE qui sera utilisé. Notez que conformément à la spécification HLS, nous n'utilisons pas la comparaison des noms de fichiers pour la mise en correspondance.

Notre implémentation HLS permet de sélectionner un autre flux audio, par exemple le son surround 5.1, comme lecture audio principale. Pour ce faire, vous pouvez disposer d'une balise #EXT-X-MEDIA avec les autres codecs et fournir le format de segment dans la configuration du flux.

Le lecteur Web récepteur s'attend à un comportement spécifique, conformément aux spécifications. Par exemple, après une balise #EXT-INF, nous attendons un URI. S'il ne s'agit pas d'un URI, par exemple, #EXT-X-DISCOUNTINUITY entraînera l'échec de l'analyse pour la playlist.

Toutes les #EXT-X-TARGETDURATION secondes, nous actualisons la playlist/le fichier manifeste pour obtenir de nouvelles listes de segments, et nous mettons à jour la nouvelle représentation interne de tous les segments vers la nouvelle représentation. Chaque fois qu'une recherche est demandée, la recherche s'effectue uniquement dans la plage de recherche. Pour les diffusions en direct, nous n'autorisons la recherche qu'à partir du début de la liste la plus récente et jusqu'à une durée cible de trois à partir de la fin. Par exemple, si vous avez une liste de 10 segments et que vous vous trouvez sur le segment 6, vous pouvez rechercher jusqu'à 7, mais pas 8.

Compatibilité des formats de segment

Le SDK CAF permet de lire du contenu diffusé dans plusieurs formats, comme référencé dans HlsSegmentFormat pour l'audio et HlsVideoSegmentFormat pour la vidéo. Cela inclut la prise en charge du contenu audio empaqueté tel que la lecture AAC et AC3, qu'il soit chiffré ou non. Vous devez spécifier ces informations dans le MediaInformation du LoadRequestData afin de décrire correctement votre contenu au lecteur. Si aucune valeur n'est spécifiée, la configuration du lecteur par défaut tente de lire le contenu en tant que contenu empaqueté dans Transport Stream. Cette propriété peut être définie à partir de n'importe quel expéditeur dans les données de requête de chargement (Android, iOS et Web) ou dans le destinataire via des intercepteurs de messages.

Consultez l'exemple d'extrait de code ci-dessous ou le guide Charger un contenu multimédia à l'aide de contentId, contentUrl et entity pour en savoir plus sur la préparation du contenu sur Web Receiver.

playerManager.setMessageInterceptor(
    cast.framework.messages.MessageType.LOAD, loadRequestData => {
      ...
      // Specify segment format for an HLS stream playing CMAF packaged content.
      loadRequestData.media.contentType = 'application/x-mpegurl';
      loadRequestData.media.hlsSegmentFormat = cast.framework.messages.HlsSegmentFormat.FMP4;
      loadRequestData.media.hlsVideoSegmentFormat = cast.framework.messages.HlsVideoSegmentFormat.FMP4;
      ...
      return loadRequestData;
    });

Protection du contenu

Comme indiqué dans la section sur le tag #EXT-X-KEY ci-dessus, le SDK Cast est compatible avec SAMPLE-AES ou SAMPLE-AES-CTR, où un URI vers la clé d'un vecteur d'initialisation peut être spécifié:

EXT-X-KEY: METHOD=SAMPLE-AES, \
URI="data:text/plain;base64,XXXXXX", \
IV=0x6df49213a781e338628d0e9c812d328e, \
KEYFORMAT="com.widevine", \
KEYFORMATVERSIONS="1"

Le KEYFORMAT que nous prenons désormais en charge est Widevine. L'URI contient une information DRM encodée en base64 XXXXXXX qui, lorsqu'elle est décodée, contient l'ID de clé:

{
   "content_id": "MTQ1NjkzNzM1NDgxNA==",
   "key_ids": [
      "xxxxxxxxxxxxxxxx"
   ]
}

La version 1 définit les attributs suivants:

Attribut Exemple Description
KEYFORMATVERSIONS "1" Cette proposition définit la version 1 du format de clé
KEYFORMAT "urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed" L'UUID correspond à l'UUID Widevine de DASH IF IOP. La même chaîne est utilisée dans la description de la présentation du média avec les flux chiffrés Widevine.
URI "data:text/plain;base64, <base64 encoded PSSH box>" URI du flux contenant le type de données et la zone PSSH.
METHOD SAMPLE-AES-CTR Indique l'algorithme de chiffrement utilisé pour chiffrer le contenu. La norme Sample-AES indique que le contenu est chiffré à l'aide de "cbcs", tandis que la norme Sample-AES-CTR indique que le contenu est chiffré à l'aide de l'un des schémas de protection AES-CTR, à savoir "cenc".

Attributs mappés à la description de la présentation du média DASH:

Attribut Description
KEYFORMAT Attribut schemaIdUri de l'élément ContentProtection.
URI Contenu de l'élément cenc:pssh.
KEYID Chaîne hexadécimale de 16 octets codant l'ID de clé ayant le même rôle que default_kid dans un fichier MPEG DASH. Si vous utilisez un schéma de clé hiérarchique, il s'agit de la clé "racine".

Exemple de playlist HLS avec signal V2:

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:2
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-MAP:URI="init_segment.mp4"
#EXTINF:1.001,
output_video-1.mp4
#EXT-X-DISCONTINUITY
#EXT-X-KEY:METHOD=SAMPLE-AES,URI="data:text/plain;base64,AAAAPXBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAAB0aDXdpZGV2aW5lX3Rlc3QiDHRlc3QgY29udGVudA==",KEYID=0x112233445566778899001122334455,KEYFORMAT="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed",KEYFORMATVERSION="1"
#EXTINF:1.001,
output_video-2.mp4
#EXTINF:0.734,
output_video-3.mp4
#EXT-X-ENDLIST

Vous trouverez ci-dessous la liste des fonctionnalités et des tags HLS que nous n'utilisons ou ne prenons pas en charge pour le moment. Leur présence ou leur absence n'affecte pas le comportement du streaming.

  • L'attribut RESOLUTION= dans #EXT-X-STREAM-INF est ignoré.
  • L'attribut AUTOSELECT= dans #EXT-X-MEDIA n'est pas utilisé. Nous nous appuyons plutôt sur DEFAULT=.
  • #EXT-X-I-FRAME-STREAM-INF dans la playlist principale est ignoré.
  • #EXT-X-DISCONTINUITY-SEQUENCE est ignoré
  • #EXT-X-PLAYLIST-TYPE:EVENT peut être présent dans une diffusion en direct et #EXT-X-PLAYLIST-TYPE:VOD peut être présent dans un flux de VOD, mais notre lecteur Web récepteur ne s'appuie actuellement que sur l'existence de #EXT-X-ENDLIST pour déterminer si un contenu est diffusé en direct ou non.

Streaming fluide

La spécification Smooth Streaming officielle de Microsoft.

Le streaming fluide fournit un protocole de streaming adaptatif et une spécification XML via HTTP (semblable à DASH). Contrairement à DASH, Smooth Streaming ne recommande que le format MPEG-4 pour les segments multimédias.

Vous trouverez ci-dessous un tableau des tags et des attributs les plus courants pour le streaming fluide qui sont actuellement compatibles avec le lecteur Web récepteur. De nombreux concepts sont déjà expliqués dans la section "DASH" ci-dessus.

Tag/Attribut Utilisation
<SmoothStreamingMedia> La balise principale du fichier manifeste contient les attributs suivants :
  • TimeScale: nombre d'unités représentant une seconde, généralement par incrément de 10 000 000.
  • Durée: durée du contenu dans l'échelle de temps. Web Receiver Player n'est pas compatible avec les durées inférieures à 0,1 seconde.
  • IsLive: indique si le fichier manifeste est un support en direct.
<StreamIndex> Un seul ensemble de flux, semblable au AdaptationSet de DASH. Le type est généralement "text", "video" ou "audio". L'attribut d'URL contient généralement une URL de fragment modélisée utilisant des informations telles que le débit ou l'heure de début.
<QualityLevel> Chaque balise QualityLevel indique son débit et un codec FourCC. Le code FourCC correspond souvent à "H264", "AVC1", "AACL", etc. Pour la vidéo, il spécifie ses résolutions via MaxWidth et MaxHeight. Pour le contenu audio, il spécifie sa fréquence (par exemple, 44100) via SamplingRate et le nombre de canaux.
<c> Élément de fragment de flux. Contient :
  • d: la durée d'un fragment.
  • t: date et heure du média du fragment.
<Protection> Balise avec l'attribut SystemID facultatif qui indique l'ID du DRM du système à utiliser sous la balise <SmoothStreamingMedia>.
<ProtectionHeader> Sous <Protection>, peut contenir un attribut d'ID système et de données personnalisées, généralement encodés en base64. Pour Widevine, ce champ contient l'ID de clé, la longueur de la clé et l'ID de l'algorithme, tel que AESCTR, l'URL LA_URL (URL d'acquisition de la licence), LUI_URL (URL de l'interface utilisateur de la licence) et DS_ID (ID du service de domaine).

Protection du contenu

Pour encoder correctement les ID du système de protection, veuillez utiliser le mappage ci-dessous:

  • WIDEVINE: 'EDEF8BA9-79D6-4ACE-A3C8-27DCD51D21ED',
  • CLEARKEY: '1077EFEC-C0B2-4D02-ACE3-3C1E52E2FB4B',
  • MPEG_DASH_MP4PROTECTION: 'URN:MPEG:DASH:MP4PROTECTION:2011'

Pour <ProtectionHeader>, vous trouverez ci-dessous un exemple de données encodées en base64. Lorsqu'elles sont décodées, les données sont conformes au même format décodé que celui décrit dans la prise en charge de la protection du contenu DASH ci-dessus.

<Protection>
  <ProtectionHeader SystemID="9a04f079-9840-4286-ab92-e65be0885f95">
    $BASE64ENCODED_DATA
  </ProtectionHeader>
</Protection>

Vous trouverez ci-dessous un exemple de fichier manifeste de streaming fluide en direct avec un contenu de 3 000 secondes:

<?xml version="1.0"?>
  <SmoothStreamingMedia MajorVersion="2" MinorVersion="0" Duration="3000000000"
    TimeScale="10000000" IsLive="TRUE" LookAheadFragmentCount="2" DVRWindowLength="600000000" CanSeek="TRUE" CanPause="TRUE">
    <StreamIndex Type="text" Name="textstream301_swe" Language="swe" Subtype="CAPT" Chunks="0"
      TimeScale="10000000" Url="QualityLevels({bitrate})/Fragments(textstream301_swe={start time})">
      <QualityLevel Index="0" Bitrate="20000" CodecPrivateData="" FourCC="DFXP"/>
        <c d="40000000" t="80649382288125"/>
        <c d="39980000"/>
        <c d="40020000"/>
    </StreamIndex>
    <Protection>
      <ProtectionHeader> SystemID="$BASE64ENCODEDDRMDATA$"</ProtectionHeader>
    </Protection>
    <StreamIndex Type="audio" Name="audio101_eng" Language="eng" Subtype="AACL" Chunks="0"
      TimeScale="10000000" Url="QualityLevels({bitrate})/Fragments(audio101_eng={start time})">
      <QualityLevel Index="0" Bitrate="128000" CodecPrivateData="1290" FourCC="AACL" AudioTag="255"
        Channels="2" SamplingRate="32000" BitsPerSample="16" PacketSize="4"/>
      <c d="40000000" t="80649401327500"/>
      <c d="40000000"/>
      <c d="40000000"/>
    </StreamIndex>
    <StreamIndex Type="video" Name="video" Subtype="AVC1" Chunks="0" TimeScale="10000000"
      Url="QualityLevels({bitrate})/Fragments(video={start time})">
      <QualityLevel Index="0" Bitrate="400000" CodecPrivateData="000000016742E01596540C0EFCB808140000000168CE3880"
        FourCC="AVC1" MaxWidth="384" MaxHeight="216"/>
      <QualityLevel Index="1" Bitrate="800000" CodecPrivateData="00000001674D401E965281004B6020500000000168EF3880"
        FourCC="AVC1" MaxWidth="512" MaxHeight="288"/>
      <QualityLevel Index="2" Bitrate="1600000" CodecPrivateData="00000001674D401E965281B07BCDE020500000000168EF3880"
        FourCC="AVC1" MaxWidth="854" MaxHeight="480"/>
      <QualityLevel Index="3" Bitrate="2200000" CodecPrivateData="00000001674D401F96528080093602050000000168EF3880"
        FourCC="AVC1" MaxWidth="1024" MaxHeight="576"/>
      <c d="40000000" t="80649401378125"/>
      <c d="40000000"/>
      <c d="40000000"/>
    </StreamIndex>
  </SmoothStreamingMedia>

Dans l'exemple de flux vidéo ci-dessus, le modèle d'URL est:

QualityLevels({bitrate})/Fragments(video={start time})

Les deux premiers segments (en supposant que nous sommes au niveau de qualité de l'indice 2) sont les suivants, avec la durée initiale extraite de t="80649401378125" dans le StreamIndex de la vidéo et l'incrément de 4 secondes * 10000000 par segment:

QualityLevels(2)/Fragments(video=80649401378125)
QualityLevels(2)/Fragments(video=80649441378125)
...

Voici une liste des attributs de streaming fluide que nous ignorons actuellement et n'ont aucun effet sur les expériences de streaming, qu'ils soient fournis ou non:

  • CanSeek, CanPause dans la balise <SmoothStreamingMedia>.
  • Chunks et QualityLevels dans la balise <StreamIndex>. À la place, nous calculons le nombre de segments et le nombre de niveaux de qualité en fonction des informations fournies dans <StreamIndex>, comme la balise QualityLevel réelle et les balises <c>.
  • BitsPerSample et PacketSize dans <QualityLevel> ne sont pas utilisés.

Vérifier le type d'affichage

La méthode canDisplayType vérifie les fonctionnalités vidéo et audio de l'appareil Web receiver et les affiche en validant les paramètres multimédias transmis, en renvoyant une valeur booléenne. Tous les paramètres, à l'exception du premier, sont facultatifs. Plus vous incluez de paramètres, plus la vérification sera précise.

Sa signature est canDisplayType(<em>mimeType</em>,<em>codecs</em>,<em>width</em>,<em>height</em>,<em>framerate</em>)

Exemples :

Vérifie si le récepteur Web et l'écran sont compatibles avec le type MIME vidéo/mp4 avec le codec, les dimensions et la fréquence d'images suivants:

canDisplayType("video/mp4", "avc1.42e015,mp4a.40.5", 1920, 1080, 30)

Vérifie si le récepteur Web et l'écran sont compatibles avec le format vidéo 4K pour ce codec en spécifiant la largeur de 3 840 et la hauteur de 2 160:

canDisplayType("video/mp4", "hev1.1.2.L150", 3840, 2160)

Vérifie si l'écran et le périphérique Web récepteur sont compatibles avec la technologie HDR10 pour ce codec, ces dimensions et cette fréquence d'images:

canDisplayType("video/mp4", "hev1.2.6.L150", 3840, 2160, 30)

Vérifie si le récepteur Web et l'écran sont compatibles avec Dolby Vision (DV) pour ce codec, ces dimensions et cette fréquence d'images:

canDisplayType("video/mp4", "dvhe.04.06", 1920, 1080, 30)

DRM

Certains contenus multimédias nécessitent la gestion des droits numériques (DRM). Pour le contenu multimédia dont la licence DRM (et l'URL de la clé) sont stockées dans leur fichier manifeste (DASH ou HLS), le SDK Cast gère ce cas pour vous. Un sous-ensemble de ce contenu nécessite une licenseUrl, nécessaire pour obtenir la clé de déchiffrement. Dans Web Receiver, vous pouvez utiliser PlaybackConfig pour définir licenseUrl si nécessaire.

L'extrait de code suivant montre comment définir des informations pour les demandes de licence telles que withCredentials:

const context = cast.framework.CastReceiverContext.getInstance();
const playbackConfig = new cast.framework.PlaybackConfig();
// Customize the license url for playback
playbackConfig.licenseUrl = 'http://widevine/yourLicenseServer';
playbackConfig.protectionSystem = cast.framework.ContentProtection.WIDEVINE;
playbackConfig.licenseRequestHandler = requestInfo => {
  requestInfo.withCredentials = true;
};
context.start({playbackConfig: playbackConfig});

// Update playback config licenseUrl according to provided value in load request.
context.getPlayerManager().setMediaPlaybackInfoHandler((loadRequest, playbackConfig) => {
  if (loadRequest.media.customData && loadRequest.media.customData.licenseUrl) {
    playbackConfig.licenseUrl = loadRequest.media.customData.licenseUrl;
  }
  return playbackConfig;
});

Si vous avez intégré l'Assistant Google, certaines informations DRM, telles que les identifiants nécessaires pour le contenu, peuvent être directement associées à votre compte Google via des mécanismes tels que OAuth/SSO. Dans ce cas, si le contenu multimédia est chargé par commande vocale ou provient du cloud, un setCredentials est appelé depuis le cloud vers l'appareil Cast qui fournit ces identifiants. Les applications qui créent une application Web Receiver peuvent ensuite utiliser les informations setCredentials pour exploiter la DRM, si nécessaire. Voici un exemple d'utilisation de l'identifiant pour construire le média.

Conseil: Consultez également la section Charger un contenu multimédia à l'aide de contentId, contentUrl et entity.

Gestion du canal audio

Lorsque le lecteur Cast charge des contenus multimédias, il configure un tampon source audio unique. En parallèle, elle sélectionne également un codec approprié à utiliser par le tampon, en fonction du type MIME de la piste principale. Un nouveau tampon et un nouveau codec sont configurés:

  • au démarrage de la lecture,
  • à chaque coupure publicitaire,
  • chaque fois que le contenu principal reprend.

Étant donné que le tampon utilise un seul codec et que le codec est choisi en fonction de la piste principale, il arrive que les pistes secondaires soient filtrées et ne soient pas entendues. Cela peut se produire lorsque la piste principale d'un programme multimédia est en son surround, mais que les pistes audio secondaires utilisent un son stéréo. Étant donné que les pistes secondaires sont fréquemment utilisées pour proposer du contenu dans d'autres langues, fournir des contenus multimédias contenant un nombre différent de pistes peut avoir un impact important, par exemple un grand nombre de spectateurs ne pouvant pas entendre le contenu dans leur langue maternelle.

Les scénarios suivants illustrent pourquoi il est important de proposer une programmation dont les pistes principales et secondaires contiennent le même nombre de canaux:

Scénario 1 – Le flux multimédia ne présente pas la parité des canaux entre les canaux principaux et secondaires:

  • anglais - AC-3 5.1 channel (primary)
  • suédois - AAC 2-canaux
  • français - AAC 2 canaux
  • allemand - AAC 2-canaux

Dans ce scénario, si la langue du lecteur n'est pas l'anglais, l'utilisateur n'entend pas le titre qu'il s'attend à entendre, car les pistes des deux canaux sont filtrées lors de la lecture. Le seul titre qui pourrait être lu serait le canal principal AC-3 5.1, puis uniquement lorsque la langue est définie sur l'anglais.

Scénario 2 – Flux multimédia avec parité des canaux entre les canaux principaux et secondaires:

  • anglais - AC-3 5.1 channel (primary)
  • suédois - chaîne AC-3 5.1
  • Français - AC-3 5.1 canal
  • allemand - AC-3 5.1 canal

Étant donné que tous les titres de cette diffusion sont associés au même nombre de chaînes, les spectateurs entendront un titre quelle que soit la langue sélectionnée.

Gestion des canaux audio Shaka

Par défaut, le lecteur Shaka (DASH) utilise un nombre de canaux préféré de deux, par mesure d'atténuation lorsque des contenus multimédias manquent de parité entre les pistes audio secondaires.

Si la piste principale n'est pas un son surround (par exemple, une piste stéréo à deux canaux), le lecteur Shaka utilise deux canaux par défaut et filtre automatiquement toutes les pistes multimédias secondaires comportant plus de deux canaux.

Le nombre de canaux audio préféré de Shaka peut également être configuré en définissant preferredAudioChannelCount dans la propriété shakaConfig sur cast.framework.PlaybackConfig.

Exemple :

shakaConfig = { "preferredAudioChannelCount": 6 };

Lorsque le paramètre preferredAudioChannelCount est défini sur 6, Shaka Player vérifie s'il est compatible avec les codecs de son surround (AC-3 ou EC-3) et filtre automatiquement toutes les pistes multimédias qui ne sont pas conformes au nombre de canaux souhaité.