Protocolos de streaming do player receptor da Web

O SDK do receptor da Web oferece suporte a três tipos de protocolos de streaming atuais:

DASH; HTTP Live Streaming e Smooth Streaming.

Neste documento, listamos nosso suporte para cada um dos protocolos de streaming. Observação a explicação das tags suportadas para cada protocolo está bem abreviada em comparação com a especificação detalhada do protocolo. O objetivo é fornecer visão geral e compreensão de como usar cada protocolo e de quais recursos do protocolo são compatíveis com dispositivos compatíveis com Cast para exibir as experiências de streaming.

Dynamic Adaptive Streaming over HTTP (DASH)

da ISO especificação detalhada do DASH (link em inglês).

O DASH é um protocolo de streaming com taxa de bits adaptável que permite vídeos de alta qualidade streaming por meio de servidores HTTP(S). Um manifesto, composto em XML, contém a maior parte das informações de metadados sobre como inicializar e baixar o vídeo conteúdo. Os principais conceitos compatíveis com o player do receptor da Web são <Period>, <AdaptationSet>, <Representation> e <SegmentTemplate>. <SegmentList>, <BaseUrl> e <ContentProtection>.

Um manifesto DASH começa com uma tag raiz <MPD> e, dentro dele, inclui uma ou mais tags <Period>, que representam um conteúdo de streaming. As tags <Period> permitem ordenar diferentes partes do conteúdo de streaming e são frequentemente usados para separar o conteúdo principal e a publicidade ou vários conteúdos de vídeo consecutivos.

Um <AdaptationSet> em <MPD> é um conjunto de representações para um tipo de stream de mídia, na maioria dos casos, vídeo, áudio ou legendas. A maior os tipos MIME comumente aceitos são "video/mp4", "audio/mp4" e "text/vtt". Um opcional <ContentComponent contentType="$TYPE$"> podem ser incluídos abaixo de <AdaptationSet>.

Dentro de cada <AdaptationSet>, deve haver uma lista de tags <Representation>. estar presente, e o player do receptor da Web usa as informações de codecs para inicializa o buffer de origem do MSE e as informações do bandwidth para escolher automaticamente a representação/taxa de bits certa para reproduzir.

Para cada <Representation>, os segmentos de mídia são descritos usando: <BaseURL> para representação de segmento único, <SegmentList> para lista de segmentos (semelhante a HLS) ou <SegmentTemplate>.

Para uma <SegmentTemplate>, ela indica como o segmento de inicialização e os segmentos de mídia podem ser representados por modelos. No exemplo abaixo $Number$ indica o número do segmento conforme disponível a partir da CDN. Então, é traduzido para seg1.m4s, seg2.m4s etc. à medida que a reprodução continua.

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

Para uma <SegmentTemplate>, é comum usar a tag <SegmentTimeline> para indicam quanto tempo cada segmento tem e quais segmentos se repetem. Uma timescale (unidades para representar um segundo) é frequentemente incluído como parte dos atributos do <SegmentTemplate> para que possamos calcular o tempo do segmento com base em nesta unidade. No exemplo abaixo, a tag <S> significa uma tag de segmento, a O atributo d especifica o comprimento do segmento e o atributo r especifica quantos segmentos da mesma duração se repetem para que $Time$ pode ser calculado corretamente para fazer o download do segmento de mídia conforme especificado no o atributo 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>

Confira um exemplo de representação usando <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>

Para um único arquivo de segmento, um <SegmentBase> é frequentemente usado com bytes para especificar qual parte de um arquivo <BaseURL> contém as índice, e o restante pode ser buscado sob demanda enquanto a reprodução continua ou uma busca acontece. Aqui, o intervalo Initialization especifica o intervalo de metadados init. e indexRange especifica o índice dos segmentos de mídia. Observe que no momento só aceitamos intervalos de bytes consecutivos.

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

Independentemente de qual representação for usada, se os streams estiverem protegidos, uma A seção <ContentProtection> pode aparecer em <AdaptationSet>, em que um schemeIdUri identifica exclusivamente o sistema de DRM a ser usado. Um ID de chave opcional pode ser incluído para criptografia comum.

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

Para mais exemplos e detalhes, consulte a especificação MPEG-DASH. Veja abaixo uma lista de atributos DASH adicionais em tags não mencionadas acima atualmente compatíveis:

Também aceitamos o reconhecimento da caixa EMSG dentro de fragmentos MP4 para DASH e fornecem um EmsgEvent aos desenvolvedores.

Embora nosso player de receptor da Web atual ofereça suporte aos principais casos de uso de DASH, aqui é uma lista de atributos comuns que nossa implementação atual de DASH ignora ou não usa. Isso significa que, independentemente de o manifesto conter ou não elas não afetam a experiência de reprodução do conteúdo.

• availabilityStartTime
• segmentAlignment

HTTP Live Streaming (HLS)

A visão geral e as especificações completas da transmissão HTTP ao vivo estão disponíveis aqui.

Um dos pontos fortes do player do receptor da Web é sua capacidade de dar suporte reprodução de HLS em MSE. Diferente do DASH, em que um manifesto vem em um único o HLS envia a playlist master com uma lista de todos os streams de variantes pelos respectivos URLs. A playlist de variantes é a de mídia. Os dois as principais tags HLS compatíveis com o player do receptor da Web no playlist são:

Veja uma lista de tags HLS atualmente compatíveis com o Web Receiver Player a playlist de mídia:

Para a transmissão ao vivo, usamos #EXT-X-PROGRAM-DATE-TIME e #EXT-X-MEDIA-SEQUENCE. como os principais fatores para determinar como mesclar um manifesto recém-atualizado. Se presente, o #EXT-X-PROGRAM-DATE-TIME é usado para corresponder aos segmentos atualizados. Caso contrário, o número #EXT-X-MEDIA-SEQUENCE será usado. De acordo com o especificação HLS, não usamos a comparação de nomes de arquivos para correspondência.

Nossa implementação de HLS permite selecionar um stream de áudio alternativo, como Som surround 5.1, como a reprodução de áudio principal. Para isso, uma tag #EXT-X-MEDIA com os codecs alternativos, além de fornecer o formato do segmento na configuração do stream

O player do receptor da Web espera determinado comportamento de acordo com a especificação. Por exemplo, depois que um #EXT-INF, esperamos um URI. Se não for um URI, por exemplo, um #EXT-X-DISCOUNTINUITY vai causar uma falha na análise da playlist.

A cada #EXT-X-TARGETDURATION segundos, recarregamos a playlist/manifesto para novas listas de segmentos e atualizaremos a nova representação interna de todos os para o novo. Sempre que uma busca é solicitada, buscamos apenas dentro de o intervalo pesquisável. Para transmissões ao vivo, permitimos a busca somente a partir do início do lista mais recente até uma duração de três metas do final. Por exemplo, se você tiver uma lista de 10 segmentos e estiver no segmento 6, poderá buscar somente como 7, mas não 8.

Suporte ao formato do segmento

O SDK do CAF oferece suporte à reprodução de conteúdo enviado em vários formatos, conforme mencionado. em HlsSegmentFormat para áudio e HlsVideoSegmentFormat para vídeo. Isso inclui suporte para pacote de áudio como reprodução AAC e AC3, com ou sem criptografia. É obrigatório para especificar essas informações no MediaInformation do LoadRequestData para descrever corretamente seu conteúdo ao player. Se não for especificado, o configuração padrão do player tentará reproduzir o conteúdo como Transport Transmitir conteúdo empacotado. Essa propriedade pode ser definida por qualquer um dos remetentes no dados de solicitação de carregamento (Android, iOS e Web) ou dentro do destinatário por interceptadores de mensagens.

Conferir o exemplo de código snippet abaixo ou Como carregar mídia usando contentId, contentUrl e entity para mais informações sobre como preparar conteúdo no receptor da 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;
    });

Proteção de conteúdo

Conforme listado na seção de tag #EXT-X-KEY acima, o SDK do Cast é compatível com SAMPLE-AES ou SAMPLE-AES-CTR, em que um URI para a chave um vetor de inicialização podem ser especificadas:

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

O KEYFORMAT com suporte agora é Widevine, e o URI contém um Informações de DRM codificadas em BASE64 XXXXXXX que, quando decodificadas, contêm o ID da chave:

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

A versão 1 define os seguintes atributos:

Atributos mapeados para DASH MPD:

Exemplo de playlist HLS com sinalização 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

Confira abaixo uma lista de recursos e tags em HLS que não usamos ou suporte. A presença ou ausência deles não afeta o comportamento do streaming.

• O atributo RESOLUTION= em #EXT-X-STREAM-INF é ignorado.
• O atributo AUTOSELECT= em #EXT-X-MEDIA não é usado. Em vez disso, contamos com DEFAULT=
• #EXT-X-I-FRAME-STREAM-INF na playlist master foi ignorado.
• #EXT-X-DISCONTINUITY-SEQUENCE foi ignorado
• #EXT-X-PLAYLIST-TYPE:EVENT pode estar presente em uma transmissão ao vivo e #EXT-X-PLAYLIST-TYPE:VOD podem estar presentes em um stream de VOD, mas atualmente nosso O player do receptor da Web depende apenas da existência de #EXT-X-ENDLIST para determinar transmissões ao vivo x VOD.

Streaming sem falhas

Oficial da Microsoft Especificações de Smooth Streaming.

O streaming suave fornece protocolo de streaming adaptável e especificação XML por HTTP (semelhante ao DASH). Diferente do DASH, o Smooth Streaming recomenda apenas pacotes MPEG-4 para os segmentos de mídia.

Esta é uma tabela das tags e dos atributos mais comuns no Smooth Streaming que que o Web Receiver Player suporta atualmente. Muitos conceitos já foram explicados na seção DASH acima.

Proteção de conteúdo

Para codificar corretamente os IDs do sistema de proteção, use o mapeamento abaixo:

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

Para <ProtectionHeader>, confira abaixo um exemplo com dados codificados em Base64. A os dados, quando decodificados, estão em conformidade com o mesmo formato decodificado, conforme descrito nas Suporte à proteção de conteúdo do DASH acima.

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

Confira abaixo um exemplo de manifesto de transmissão ao vivo Smooth com 3.000 segundos duração do conteúdo:

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

No exemplo de stream de vídeo acima, o modelo de URL é:

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

Assim, os dois primeiros segmentos (supondo que estejamos no nível de qualidade do índice 2) serão a seguir, com tempo inicial extraído de t="80649401378125" na seção StreamIndex de vídeo e o incremento de tempo de 4 segundos * 10.000.000 por segmento:

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

Aqui está uma lista dos atributos de Smooth Streaming que ignoramos e temos atualmente. nenhum efeito nas experiências de streaming, independentemente de serem fornecidas:

• CanSeek e CanPause na tag <SmoothStreamingMedia>.
• Chunks e QualityLevels na tag <StreamIndex>. Em vez disso, calculamos o número de segmentos e o número de níveis de qualidade com base em informações fornecidos no <StreamIndex>, como a tag QualityLevel real e o <c>.
• BitsPerSample e PacketSize em <QualityLevel> não são usados.

Verificar o tipo de visor

O canDisplayType verifica os recursos de vídeo e áudio do dispositivo receptor da Web e exibição validando os parâmetros de mídia passados, retornando um booleano. Todos , mas o primeiro é opcional. Quanto mais parâmetros incluir, mais precisa será a verificação.

Sua assinatura é canDisplayType(<em>mimeType</em>,<em>codecs</em>,<em>width</em>,<em>height</em>,<em>framerate</em>)

Exemplos:

Verifica se o dispositivo receptor da Web e a tela são compatíveis com arquivos de vídeo/mp4 mimetype com este codec, dimensões e frame rate específicos:

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

Verifica se o dispositivo receptor da Web e a tela oferecem suporte ao formato de vídeo 4K para este codec especificando a largura de 3840 e a altura de 2160:

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

Verifica se o dispositivo receptor da Web e a tela oferecem suporte a HDR10 para o codec e frame rate:

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

Verifica se o dispositivo e a tela receptores da Web oferecem suporte a Dolby Vision (DV) para codec, dimensões e frame rate:

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

DRM

Alguns conteúdos de mídia exigem o Gerenciamento de direitos digitais (DRM). Para conteúdo de mídia com a licença de DRM (e o URL da chave) armazenada no manifesto (DASH ou HLS), o SDK do Cast lida com esse caso para você. Um subconjunto desse conteúdo requer uma licenseUrl que é necessária para conseguir a chave de descriptografia. No receptor da Web, é possível usar PlaybackConfig para definir o licenseUrl conforme necessário.

O snippet de código a seguir mostra como definir informações de solicitação de licença solicitações, como 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 você tiver uma integração com o Google Assistente, algumas das informações de DRM, como as credenciais necessárias para o conteúdo podem estar vinculadas diretamente ao seu Conta do Google por mecanismos como OAuth/SSO. Nesses casos, se o conteúdo de mídia é carregado por voz ou vem da nuvem, setCredentials é invocado da nuvem para o dispositivo de transmissão, desde que esse credenciais. Os aplicativos que escrevem um aplicativo receptor da Web podem usar o setCredentials para operar o DRM conforme necessário. Aqui está um exemplo usando a credencial para criar a mídia.

Dica: consulte também Como carregar mídia usando contentId, contentUrl e entity.

Gerenciamento de canais de áudio

Quando o player de transmissão carrega mídia, ele configura um único buffer de origem de áudio. Em ao mesmo tempo, ele também seleciona um codec apropriado para ser usado pelo buffer com base no tipo MIME da faixa principal. Um novo buffer e codec novos são configurados:

• quando a reprodução começar,
• em cada intervalo de anúncio, e
• sempre que o conteúdo principal for retomado.

Como o buffer usa um único codec e o codec é escolhido com base na faixa principal, há situações em que faixas secundárias podem ser filtradas e não ouvidas. Isso pode acontecer quando o sistema principal a faixa está em som surround, mas as secundárias usam som estéreo. Como as faixas secundárias costumam ser usadas para oferecer conteúdo em versões idiomas, fornecer mídia com diferentes números de faixas pode ter um impacto substancial, como um grande número de espectadores não conseguir ouvir conteúdo no idioma nativo deles.

Os cenários a seguir ilustram por que é importante fornecer recursos em que as faixas primária e secundária contêm o mesmo número de canais:

Cenário 1: fluxo de mídia sem canal paridade entre faixas primárias e secundárias:

• Inglês: canal AC-3 5.1 (principal)
• sueco - AAC 2 canais
• francês - AAC 2 canais
• alemão - AAC 2 canais

Nesse caso, se o idioma do player estiver definido como algo diferente em inglês, o usuário não ouve a faixa que espera ouvir, porque todas as faixas de dois canais são filtradas durante a reprodução. A única faixa que poderia ser reproduzida seria o canal 5.1 AC-3 principal e somente quando o está definido como inglês.

Cenário 2: stream de mídia com canal paridade entre faixas primárias e secundárias:

• Inglês: canal AC-3 5.1 (principal)
• sueco - canal AC-3 5.1
• francês - AC-3 5.1 canal
• alemão - canal AC-3 5.1

Como todas as faixas desta transmissão têm o mesmo número de canais, o público ouvirá uma faixa independentemente do idioma selecionado.

Processamento de canais de áudio Shaka

O player Shaka (DASH) tem como padrão uma contagem de canais preferencial de dois, como de mitigação ao encontrar mídia que não tem paridade em todo o conteúdo faixas de áudio.

Se a faixa principal não for som surround (por exemplo, um som estéreo de dois canais faixa), o player Shaka usará dois canais como padrão e filtrar automaticamente quaisquer faixas de mídia secundárias que tenham mais de duas canais.

O número preferido de canais de áudio da Shaka também pode ser definido definindo o preferredAudioChannelCount na propriedade shakaConfig em cast.framework.PlaybackConfig.

Exemplo:

shakaConfig = { "preferredAudioChannelCount": 6 };

Com preferredAudioChannelCount definido como 6, o Shaka Player verifica se Ele é compatível com os codecs de som surround (AC-3 ou EC-3) e filtra automaticamente todas as faixas de mídia que não estão em conformidade com as número de canais.