Protocolli di streaming del lettore web ricevitore

L'SDK WebRicevir supporta tre tipi dei protocolli di streaming attualmente disponibili:

DASH, HTTP Live Streaming e Streaming fluido.

In questo documento è elencato il supporto per ciascuno dei protocolli di streaming. Nota la spiegazione dei tag supportati per ogni protocollo è piuttosto abbreviata rispetto alle specifiche dettagliate di protocollo. L'obiettivo è fornire una una rapida panoramica e la comprensione di come utilizzare ciascun protocollo e di quali funzionalità del protocollo sono supportati sui dispositivi compatibili con Google Cast per offrire esperienze in streaming.

Dynamic Adaptive Streaming over HTTP (DASH)

ISO specifica dettagliata di DASH.

DASH è un protocollo di streaming con velocità in bit adattiva che consente video di alta qualità tramite i server HTTP(S). Un file manifest, composto in XML, contiene la maggior parte delle informazioni sui metadati per inizializzare e scaricare il video contenuti. I concetti chiave supportati dal player Web ricevitore sono <Period>, <AdaptationSet>, <Representation>, <SegmentTemplate> <SegmentList>, <BaseUrl> e <ContentProtection>.

Un manifest DASH inizia con un tag <MPD> principale e al suo interno include uno o più tag <Period>, che rappresentano un solo contenuto in streaming. I tag <Period> consentono di ordinare le diverse parti dei contenuti in streaming e sono spesso utilizzati per separare i contenuti principali dalla pubblicità o più contenuti video consecutivi.

Un <AdaptationSet> in <MPD> è un insieme di rappresentazioni per un tipo di stream multimediale, nella maggior parte dei casi video, audio o sottotitoli codificati. Il più i tipi MIME comunemente supportati sono "video/mp4", "audio/mp4" e "text/vtt". Un l'elemento facoltativo <ContentComponent contentType="$TYPE$"> può essere incluso sotto <AdaptationSet>.

All'interno di ogni <AdaptationSet> deve essere presente un elenco di <Representation> tag e il player Web Ricevitore utilizza le informazioni codecs per inizializza il buffer di origine MSE e le informazioni bandwidth in e scegliere automaticamente la giusta rappresentazione/velocità in bit da riprodurre.

Per ogni <Representation>, i segmenti multimediali vengono descritti utilizzando a <BaseURL> per la rappresentazione di un singolo segmento, <SegmentList> per elenco di segmenti (simile a HLS) o <SegmentTemplate>.

Per un valore <SegmentTemplate>, indica il modo in cui segmento di inizializzazione e i segmenti multimediali possono essere rappresentati tramite modelli. Nell'esempio riportato di seguito $Number$ indica il numero del segmento come disponibile dalla CDN. Quindi traduce in seg1.m4s, seg2.m4s ecc. durante la riproduzione.

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

Per un <SegmentTemplate>, è comune utilizzare il tag <SegmentTimeline> per indica la lunghezza di ogni segmento e i segmenti che si ripetono. Un timescale (unità di misura che rappresentano un secondo) sono spesso incluse come parte degli attributi di <SegmentTemplate> in modo da poter calcolare il tempo del segmento in base a questa unità. Nell'esempio riportato di seguito, il tag <S> rappresenta un tag di segmento, ovvero L'attributo d specifica la lunghezza del segmento e l'attributo r specifica quanti segmenti della stessa durata si ripetono affinché $Time$ possono essere calcolati correttamente per scaricare il segmento multimediale come specificato in 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>

Ecco un esempio per la rappresentazione che utilizza <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>

Per un singolo file di segmento, viene spesso utilizzato un <SegmentBase> con i byte per specificare quale parte di un file <BaseURL> contiene l'indice e il resto può essere recuperato on demand mentre la riproduzione continua o . In questo caso l'intervallo Initialization specifica l'intervallo di metadati init mentre indexRange specifica l'indice dei segmenti multimediali. Tieni presente che al momento supportiamo solo intervalli di byte consecutivi.

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

Indipendentemente da quale rappresentazione viene utilizzata, se i flussi sono protetti, La sezione <ContentProtection> può essere visualizzata in <AdaptationSet>, dove schemeIdUri identifica in modo univoco il sistema DRM da utilizzare. È possibile includere un ID chiave facoltativo per la crittografia comune.

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

Per ulteriori esempi e dettagli, fai riferimento alla specifica MPEG-DASH. Di seguito è riportato un elenco di altri attributi DASH relativi ai tag non menzionati sopra attualmente supportati:

Supportiamo anche il riconoscimento della casella EMSG all'interno dei frammenti MP4 per DASH e offrono un EmsgEvent: agli sviluppatori.

Sebbene l'attuale Web receiver del nostro player supporti i principali casi d'uso di DASH, qui un elenco di attributi comuni che la nostra attuale implementazione di DASH ignora o non utilizza. Ciò significa che il file manifest contiene non incidono in alcun modo sull'esperienza di riproduzione dei contenuti.

• availabilityStartTime
• segmentAlignment

HTTP Live Streaming (HLS)

Puoi consultare la panoramica e le specifiche complete del live streaming HTTP qui

Uno dei principali punti di forza del player Web receiver è la sua capacità di supportare la riproduzione di file HLS in MSE. A differenza di DASH, dove un manifest è disponibile in un unico , HLS invia la playlist principale contenente un elenco di tutti gli stream delle varianti con il rispettivo URL. La playlist delle varianti è la playlist multimediale. I due i tag HLS principali attualmente supportati dal Web ricevitore Player playlist sono:

Ecco un elenco dei tag HLS che il player Web ricevitore attualmente supporta in la playlist multimediale:

Per il live streaming, utilizziamo #EXT-X-PROGRAM-DATE-TIME e #EXT-X-MEDIA-SEQUENCE come fattori chiave per determinare come unire un manifest aggiornato di recente. Se presente, #EXT-X-PROGRAM-DATE-TIME viene utilizzato per abbinare i segmenti aggiornati. In caso contrario, verrà utilizzato il numero #EXT-X-MEDIA-SEQUENCE. Tieni presente che, in base alle specifica HLS, non utilizziamo il confronto dei nomi file per la corrispondenza.

La nostra implementazione HLS supporta la selezione di uno stream audio alternativo, come Audio surround 5.1, come riproduzione audio principale. A questo scopo avere un tag #EXT-X-MEDIA con codec alternativi, oltre a fornire il formato del segmento nella configurazione dello stream.

Il player del ricevitore web si aspetta un determinato comportamento in base alla specifica. Ad esempio, dopo un #EXT-INF, è previsto un URI. Se non è un URI, ad esempio un #EXT-X-DISCOUNTINUITY causerà l'esito negativo dell'analisi della playlist.

Ogni #EXT-X-TARGETDURATION secondi ricarichiamo la playlist/il manifest per ricevere nuovi elenchi di segmenti e aggiorniamo la nuova rappresentazione interna di tutti segmenti al nuovo. Ogni volta che viene richiesta una ricerca, cerchiamo solo l'intervallo cercabile. Per i live streaming, consentiamo la ricerca solo all'inizio del fino a una durata target di tre dalla fine. Ad esempio, se hai un elenco di 10 segmenti e ti trovi nel segmento 6, puoi cercare solo a 7, ma non a 8.

Supporto del formato dei segmenti

L'SDK CAF supporta la riproduzione di contenuti pubblicati in più formati come riferimento tra HlsSegmentFormat per audio e HlsVideoSegmentFormat per i video. È compresa l'assistenza per un pacchetto audio come AAC e AC3, criptati e non criptati. Obbligatorio per specificare queste informazioni nel MediaInformation di LoadRequestData per descrivere correttamente i tuoi contenuti al player. Se non specificato, il parametro la configurazione predefinita del player tenterà di riprodurre i contenuti come trasporto Riprodurre in streaming contenuti in pacchetti. Questa proprietà può essere impostata da qualsiasi mittente in dei dati delle richieste di caricamento (Android, iOS e web) o all'interno del destinatario tramite intercettatori di messaggi.

Guarda il codice campione riportato di seguito o Caricamento di contenuti multimediali utilizzando contentId, contentUrl ed entità per ulteriori informazioni sulla preparazione dei contenuti sul ricevitore web.

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;
    });

Protezione dei contenuti

Come indicato nella precedente sezione relativa ai tag #EXT-X-KEY, l'SDK Cast supporta SAMPLE-AES o SAMPLE-AES-CTR, dove un URI della chiave è un vettore di inizializzazione che è possibile specificare:

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

Il KEYFORMAT che supportiamo ora è Widevine e l'URI contiene un Informazioni DRM codificate in BASE64 XXXXXXX che, una volta decodificate, contengono l'ID chiave:

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

La versione 1 definisce i seguenti attributi:

Attributi mappati a DASH MPD:

Esempio di playlist HLS con segnalazione 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

Di seguito è riportato un elenco di funzionalità e tag in HLS che al momento non utilizziamo o assistenza in tempo reale. La loro presenza o assenza non influisce sul comportamento dello streaming.

• L'attributo RESOLUTION= in #EXT-X-STREAM-INF viene ignorato.
• L'attributo AUTOSELECT= in #EXT-X-MEDIA non è utilizzato. Ci affidiamo invece DEFAULT=
• #EXT-X-I-FRAME-STREAM-INF nella playlist principale viene ignorato.
• #EXT-X-DISCONTINUITY-SEQUENCE viene ignorato
• #EXT-X-PLAYLIST-TYPE:EVENT può essere presente in un live streaming e #EXT-X-PLAYLIST-TYPE:VOD può essere presente in uno stream VOD, ma al momento le nostre Il player del ricevitore web si basa solo sull'esistenza di #EXT-X-ENDLIST per determinare le differenze tra i live streaming VOD

Streaming fluido

Il team di assistenza Microsoft Specifiche per Streaming fluido.

Streaming fluido fornisce un protocollo di streaming adattivo e specifiche XML su HTTP (simile a DASH). A differenza di DASH, lo streaming fluido consiglia solo pacchetti MPEG-4 per i segmenti multimediali.

Di seguito è riportata una tabella dei tag e degli attributi più comuni in Streaming fluido supportato al momento dal player WebRicevitore. Molti concetti sono già spiegati in nella sezione DASH sopra riportata.

Protezione dei contenuti

Per codificare correttamente gli ID del sistema di protezione, utilizza la seguente mappatura:

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

Per <ProtectionHeader>, di seguito è riportato un esempio con dati codificati in Base64. La quando vengono decodificati, siano conformi allo stesso formato decodificato descritto Supporto della protezione dei contenuti DASH sopra.

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

Di seguito è riportato un esempio di manifest di un live streaming fluido con una durata di 3000 secondi durata dei contenuti:

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

Nell'esempio riportato sopra per lo stream video, il modello di URL è:

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

Quindi i primi due segmenti (supponendo di essere al livello qualitativo dell'indice 2) saranno Quella seguente, con il tempo iniziale estratto da t="80649401378125" nel StreamIndex per video e l'incremento di tempo di 4 secondi * 10000000 per segmento:

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

Di seguito è riportato un elenco di attributi di streaming fluido che al momento ignoriamo e di cui disponiamo senza alcun effetto sulle esperienze di streaming, indipendentemente dal fatto che vengano fornite o meno:

• CanSeek, CanPause nel tag <SmoothStreamingMedia>.
• Chunks, QualityLevels nel tag <StreamIndex>. Calcoliamo invece il numero di segmenti e il numero di livelli qualitativi in base alle informazioni forniti all'interno di <StreamIndex>, come il tag QualityLevel effettivo e <c>.
• BitsPerSample, PacketSize in <QualityLevel> non è utilizzato.

Controlla il tipo di visualizzazione

La canDisplayType verifica le funzionalità video e audio del dispositivo Web Ricevitore e convalidando i parametri multimediali trasmessi, restituendo un valore booleano. Tutti ma i primi sono facoltativi: più parametri includi, il controllo sarà più preciso.

La sua firma è canDisplayType(<em>mimeType</em>,<em>codecs</em>,<em>width</em>,<em>height</em>,<em>framerate</em>)

Esempi:

Controlla se il dispositivo e il display del ricevitore web supportano video/mp4 MIME con questo codec, dimensioni e frequenza fotogrammi specifici:

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

Controlla se il display e il dispositivo ricevitore web supportano il formato video 4K per specificando questo codec specificando la larghezza di 3840 e l'altezza di 2160:

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

Controlla se il display e il dispositivo ricevitore web supportano HDR10 per questo codec, dimensioni e frequenza fotogrammi:

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

Controlla se il dispositivo e il display Web Ricevitore supportano il formato Dolby Vision (DV) per codec, dimensioni e frequenza fotogrammi:

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

DRM

Alcuni contenuti multimediali richiedono il sistema DRM (Digital Rights Management). Per contenuti multimediali la cui licenza DRM (e l'URL della chiave) è archiviata nel file manifest (DASH o HLS), l'SDK Cast si occupa di questo caso. Un sottoinsieme di questi contenuti richiede licenseUrl necessario per ottenere la chiave di decrittografia. Nel ricevitore web, puoi utilizzare PlaybackConfig per impostare licenseUrl in base alle tue esigenze.

Il seguente snippet di codice mostra come impostare le informazioni di richiesta per la licenza come 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;
});

Se hai un'integrazione con l'Assistente Google, alcune informazioni DRM, ad esempio le credenziali necessarie per i contenuti potrebbero essere collegate direttamente al tuo un Account Google tramite meccanismi come OAuth/SSO. In questi casi, se i contenuti multimediali vengono caricati tramite comandi vocali o provengono dal cloud, setCredentials viene richiamato dal cloud al dispositivo di trasmissione, a condizione che e credenziali. Le applicazioni che scrivono un'app di ricezione web possono quindi utilizzare setCredentials per utilizzare DRM in base alle esigenze. Ecco un esempio di usando la credenziale per costruire il supporto.

Suggerimento: consulta anche Caricamento di contenuti multimediali utilizzando contentId, contentUrl ed entità.

Gestione del canale audio

Quando il player di trasmissione carica i contenuti multimediali, configura un singolo buffer della sorgente audio. Alle ore Allo stesso tempo, seleziona anche un codec appropriato da usare dal buffer, in base al tipo MIME della traccia principale. Sono stati configurati un nuovo buffer e codec:

• all'avvio della riproduzione,
• a ogni interruzione pubblicitaria
• ogni volta che riprendono i contenuti principali.

Poiché il buffer utilizza un singolo codec e poiché il codec viene scelto in base al percorso principale, esistono delle situazioni in cui i canali secondari ed è stato filtrato e non ascoltato. Questo può accadere quando il principale la traccia è con audio surround, mentre le tracce audio secondarie utilizzano l'audio stereo. Perché le tracce secondarie vengono spesso utilizzate per offrire contenuti in lingue diverse, fornire contenuti multimediali contenenti un numero diverso di tracce può avere un impatto significativo, ad esempio un numero elevato di spettatori che non riesce a sentire contenuti nella propria lingua madre.

I seguenti scenari spiegano perché è importante fornire funzionalità di programmazione in cui le tracce principali e secondarie contengono lo stesso numero di canali:

Scenario 1: mancanza di canale nello stream di contenuti multimediali parità tra i canali primari e secondari:

• inglese - AC-3 5.1 canale (principale)
• svedese - AAC a 2 canali
• francese - AAC a 2 canali
• tedesco - AAC a 2 canali

In questo scenario, se la lingua del player è diversa da inglese, l'utente non sente la traccia che si aspetta di ascoltare, perché le tracce a due canali vengono escluse durante la riproduzione. L'unica traccia sarebbe il principale AC-3 5.1-channel, e poi solo quando sia impostata su Inglese.

Scenario 2: stream multimediale con canale parità tra i canali primari e secondari:

• inglese - AC-3 5.1 canale (principale)
• svedese - AC-3 5.1 canale
• francese - AC-3 5.1 canali
• tedesco - AC-3 5.1 canale

Poiché le tracce di questo stream hanno tutte lo stesso numero di canali, un pubblico sentirà la traccia indipendentemente dalla lingua selezionata.

Gestione del canale audio Shaka

Per impostazione predefinita, il player Shaka (DASH) sceglie due canali preferiti, come misura di mitigazione nel caso in cui si incontrino media che non dispongono di parità tra tracce audio.

Se la traccia principale non è audio surround (ad esempio, uno stereo a due canali ), il player Shaka mostrerà per impostazione predefinita due canali e filtra automaticamente tutte le tracce multimediali secondarie che ne hanno più di due canali.

Il numero preferito di canali audio di Shaka può essere configurato anche impostando preferredAudioChannelCount nella proprietà shakaConfig su cast.framework.PlaybackConfig.

Ad esempio:

shakaConfig = { "preferredAudioChannelCount": 6 };

Con il preferredAudioChannelCount impostato su 6, il giocatore Shaka controlla se può supportare i codec audio surround (AC-3 o EC-3) e filtra automaticamente eventuali tracce multimediali non conformi all'opzione preferita. numero di canali.