Protocoles de streaming du lecteur-récepteur Web

Le SDK Web Receiver accepte trois types des protocoles de streaming aujourd’hui:

DASH HTTP en direct Streaming <ph type="x-smartling-placeholder"></ph> Streaming fluide.

Dans ce document, nous indiquons les protocoles de streaming que nous prenons en charge. Remarque l'explication des balises prises en charge pour chaque protocole est assez abrégée par rapport à la spécification détaillée du protocole. L'objectif est de fournir une un aperçu et une compréhension rapide de l’utilisation de chaque protocole et des fonctionnalités du protocole sont compatibles avec les appareils compatibles Cast pour diffuser leur expériences de streaming.

Streaming adaptatif dynamique sur HTTP (DASH)

ISO spécification détaillée de DASH.

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

Un fichier manifeste DASH commence par une balise racine <MPD> et à l'intérieur inclut une ou autres tags <Period>, qui représentent un contenu en streaming. Les balises <Period> permettent de classer différents éléments de contenu en streaming. et sont souvent utilisés pour séparer le contenu principal de 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 de la vidéo, de l'audio ou des sous-titres. Les plus Les types MIME couramment acceptés sont "video/mp4", "audio/mp4" et "text/vtt". Une l'option <ContentComponent contentType="$TYPE$"> facultative peut être incluse moins de <AdaptationSet>.

À l'intérieur de chaque balise <AdaptationSet>, une liste de balises <Representation> doit et que le lecteur Web Receiver utilise les informations codecs pour initialiser le tampon source MSE et les informations bandwidth pour qui sélectionne automatiquement la représentation ou le débit à lire.

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

Pour un <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 auprès du CDN. Il est donc se traduit en seg1.m4s, seg2.m4s, etc. au fur et à mesure que la lecture se poursuit.

<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>

Avec <SegmentTemplate>, il est courant d'utiliser la balise <SegmentTimeline> pour : indiquer la durée de chaque segment et quels segments se répètent. Un timescale (unités représentant une seconde) est souvent incluse dans les attributs de <SegmentTemplate> afin que nous puissions calculer l'heure du segment en fonction cette unité. Dans l'exemple ci-dessous, la balise <S> correspond à une balise de segment, la L'attribut d indique la longueur de la section et l'attribut r spécifie le nombre de segments de même durée qui se répètent, de sorte que $Time$ peut être calculé correctement pour télécharger le segment multimédia, comme indiqué dans 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 de 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 seul fichier de segment, <SegmentBase> est souvent utilisé avec l'octet les requêtes de plage pour spécifier quelle partie d'un fichier <BaseURL> contient et le reste peut être récupéré à la demande au fur et à mesure que la lecture se poursuit se produit. Ici, la plage Initialization spécifie la plage de métadonnées init et indexRange spécifie l'index des segments multimédias. Notez que pour le moment, nous ne prenons en charge que les plages d'octets consécutifs.

<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, La 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, veuillez consulter 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:

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

Bien que notre lecteur Web Receiver Player actuel soit compatible avec les principaux cas d'utilisation de DASH, Il s'agit d'une liste d'attributs courants que notre mise en œuvre actuelle de DASH ignore ou n'utilise pas. Cela signifie que le fichier manifeste contient elles n'ont aucun impact sur l'expérience de lecture du contenu.

• availabilityStartTime
• segmentAlignment

Diffusion HTTP en direct (HLS)

Découvrez la présentation et les spécifications complètes de la diffusion HTTP en direct cliquez ici.

L'un des points forts du lecteur Web Receiver est sa capacité à prendre en charge lors de la lecture du HLS en MSE. À l'inverse de DASH, où un fichier manifeste est fourni fichier HLS, le HLS envoie la playlist principale contenant la liste de tous les flux de variantes par leur URL respective. La playlist de variantes est la playlist de contenus multimédias. Les deux les principaux tags HLS actuellement pris en charge par le lecteur Web Receiver dans le maître ; playlist sont:

Voici une liste des tags HLS actuellement compatibles avec le lecteur Web Receiver la playlist de contenus multimédias:

Pour les diffusions 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é. Si présent, le #EXT-X-PROGRAM-DATE-TIME est utilisé pour correspondre aux segments actualisés. Sinon, le numéro #EXT-X-MEDIA-SEQUENCE est utilisé. Notez que, conformément aux spécification HLS, la comparaison des noms de fichiers n'est pas utilisée pour la mise en correspondance.

Notre implémentation HLS permet de sélectionner un autre flux audio, tel que Son surround 5.1, comme lecture audio principale Pour ce faire, vous pouvez avec une balise #EXT-X-MEDIA avec les autres codecs et en fournissant le format de segment dans la configuration du flux ;

Le lecteur Web Receiver s'attend à un comportement spécifique selon les spécifications. Par exemple, après une #EXT-INF, nous attendons un URI. S'il ne s'agit pas d'un URI, par exemple, #EXT-X-DISCOUNTINUITY entraîne l'échec de l'analyse de 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 toutes les au nouveau segment. Chaque fois qu'une recherche est demandée, nous ne la recherchons que la plage de recherche. Pour les diffusions en direct, la recherche n'est autorisée qu'à partir du début du la plus récente jusqu'à une durée cible de trois à partir de la fin. Par exemple, Si vous avez une liste de 10 segments et que vous êtes sur le segment 6, vous pouvez uniquement rechercher à 7, mais pas à 8.

Compatibilité avec le format de segment

Le SDK CAF prend en charge la lecture de contenus diffusés dans plusieurs formats référencés dans HlsSegmentFormat pour l'audio et HlsVideoSegmentFormat pour les vidéos. Cela inclut la prise en charge audio empaqueté comme la lecture AAC et AC3, avec ou sans chiffrement. Champ obligatoire pour spécifier ces informations dans le MediaInformation de LoadRequestData pour décrire correctement votre contenu au lecteur. S'il n'est pas spécifié, le la configuration par défaut du lecteur tentera de lire le contenu en tant que Lire en streaming des contenus empaquetés 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 récepteur par le biais d'intercepteurs de messages.

Consulter l'exemple de code ci-dessous ou l'extrait Chargement de contenu multimédia à l'aide de contentId, contentUrl et entity pour obtenir plus d'informations sur la préparation du contenu dans 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 "Balise #EXT-X-KEY" ci-dessus, le SDK Cast est compatible avec SAMPLE-AES ou SAMPLE-AES-CTR, où un URI de la clé et 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, et l'URI contient un Informations DRM encodées en BASE64 XXXXXXX qui, une fois décodées, contiennent l'ID de la clé:

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

La version 1 définit les attributs suivants:

Attributs mis en correspondance avec la description de la présentation du média DASH:

Exemple de playlist HLS avec signalisation 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 tags HLS que nous n'utilisons pas actuellement ou de l'assistance. Leur présence ou leur absence n'ont aucune incidence sur 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 vidéo à la demande, mais actuellement Le lecteur Web Receiver ne s'appuie que sur l'existence de #EXT-X-ENDLIST pour déterminer la vidéo à la demande.

Streaming fluide

Le site officiel de Microsoft Spécification du streaming fluide.

La diffusion fluide fournit le protocole de streaming adaptatif et la spécification XML via HTTP (semblable à DASH). À l'inverse de DASH, la fonctionnalité de streaming fluide recommande et seulement le format MPEG-4 pour les segments de médias.

Voici un tableau des tags et attributs les plus courants dans Smooth Streaming qui compatible avec le lecteur Web Receiver. De nombreux concepts sont déjà expliqués la section DASH ci-dessus.

Protection du contenu

Pour encoder correctement les ID de système de protection, veuillez utiliser le mappage suivant:

• Grand angle : '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 avec des données encodées en base64. La les données décodées sont conformes au même format décodé que celui décrit dans 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 en direct avec une durée de durée du contenu:

<?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 ci-dessus concernant le flux vidéo, le modèle d'URL est le suivant:

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

Ainsi, les deux premiers segments (en supposant que nous sommes sur le niveau de qualité de l'index 2) seront la valeur suivante, l'heure initiale étant extraite de t="80649401378125" sous la section Video StreamIndex et par incrément de temps de 4 secondes x 1 000 000 par segment:

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

Voici une liste des attributs de flux fluides que nous ignorons actuellement et pour lesquels nous avons aucun effet sur les expériences de streaming, qu'elles soient fournies ou non:

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

Vérifier le type d'affichage

canDisplayType de vérification des capacités vidéo et audio du récepteur Web et afficher en validant les paramètres multimédias transmis et en renvoyant une valeur booléenne. Tout mais les premiers sont facultatifs. Plus vous incluez de paramètres, la vérification sera plus 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 la vidéo/mp4 type MIME avec le codec, les dimensions et la fréquence d'images spécifiques suivants:

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

Vérifie si l'appareil et l'écran Web Receiver 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'appareil et l'écran Web Receiver sont compatibles avec la technologie HDR10 pour ce codec, les dimensions et la 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, ses 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 les contenus multimédias dont la licence DRM (et l'URL de la clé) est stockée dans son fichier manifeste (DASH ou HLS), le SDK Cast gère ce cas pour vous. Un sous-ensemble de ce contenu nécessite 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 les informations de demande de licence requêtes 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 accéder au contenu peuvent être directement liés un compte Google par le biais de mécanismes comme OAuth/SSO. Dans ce cas, si le le contenu multimédia est chargé par commande vocale ou provient du cloud, setCredentials est appelé depuis le cloud vers l'appareil Cast, à condition que : identifiants de connexion. Les applications qui écrivent une application Web Receiver peuvent ensuite utiliser setCredentials pour exploiter DRM si nécessaire. Voici un exemple à l'aide des identifiants pour construire le média.

Conseil: Consultez également la section Charger des contenus multimédias à l'aide de contentId, contentUrl et entity.

Gestion du canal audio

Lorsque le lecteur Cast charge un contenu multimédia, il configure un seul tampon de source audio. À en même temps, il 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:

• lorsque la lecture commence,
• à chaque coupure publicitaire,
• chaque fois que le contenu principal reprend.

Parce que le tampon utilise un seul codec et que le codec est choisi en fonction du titre principal, il arrive que des canaux secondaires filtrées et ne sont pas entendues. Cela peut se produire lorsqu'un programme multimédia piste est en son surround, mais les pistes audio secondaires utilisent un son stéréo. Parce que les pistes secondaires sont souvent utilisées pour proposer du contenu dans des langues, le fait de proposer des contenus multimédias avec un nombre différent de pistes impact important, comme l'incapacité pour un grand nombre de spectateurs d'entendre dans leur langue maternelle.

Les scénarios suivants montrent pourquoi il est important de fournir des où les canaux principaux et secondaires contiennent le même nombre de chaînes:

Scénario 1 : aucun canal n'est disponible dans le flux multimédia Parité principale et secondaire:

• Anglais - Canal AC-3 5.1 (principal)
• suédois - AAC 2-channel
• Français - AAC 2 canaux
• allemand - AAC 2 canaux

Dans ce scénario, si la langue du lecteur est définie sur une autre langue que anglais, l'utilisateur n'entend pas le titre qu'il s'attend à entendre, car tous les pistes bicanaux sont filtrées lors de la lecture. Le seul titre serait le canal principal AC-3 5.1, et ce n'est que lorsque la langue est définie sur Anglais.

Scénario 2 : Flux multimédia avec chaîne Parité principale et secondaire:

• Anglais - Canal AC-3 5.1 (principal)
• suédois - AC-3 5.1 channel
• français - AC-3 canal 5.1
• allemand - Canal AC-3 5.1

Comme les titres de cette diffusion ont tous le même nombre de chaînes, une audience le son quelle que soit la langue sélectionnée.

Gestion du canal audio Shaka

Par défaut, le lecteur Shaka (DASH) utilise un nombre de canaux préféré de deux, comme mesure d'atténuation lorsqu'un contenu multimédia n'est pas assez semblable des pistes audio.

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

Vous pouvez aussi configurer le nombre de canaux audio préféré de Shaka preferredAudioChannelCount dans la propriété shakaConfig cast.framework.PlaybackConfig.

Exemple :

shakaConfig = { "preferredAudioChannelCount": 6 };

Lorsque preferredAudioChannelCount est défini sur 6, le lecteur Shaka vérifie si Il est compatible avec les codecs de son surround (AC-3 ou EC-3). filtre automatiquement toutes les pistes multimédias qui ne sont pas conformes le nombre de canaux.