Protocolli di streaming del lettore web ricevitore

Attualmente l'SDK Web Submitr supporta tre tipi di protocolli di streaming:

DASH, HTTP Live Streaming e Streaming fluido.

In questo documento elenchiamo il nostro supporto per ciascuno dei protocolli di streaming. Tieni presente che la spiegazione dei tag supportati per ciascun protocollo è piuttosto abbreviata rispetto alle specifiche dettagliate del protocollo. L'obiettivo è fornire una rapida panoramica e comprendere come utilizzare ciascun protocollo e quali funzionalità sono supportate sui dispositivi compatibili con Google Cast per offrire le loro esperienze di streaming.

Streaming adattivo dinamico su HTTP (DASH)

specifica dettagliata di DASH ISO.

DASH è un protocollo di streaming con velocità in bit adattiva che consente lo streaming video di alta qualità tramite server HTTP(S). Un file manifest, composto in XML, contiene la maggior parte delle informazioni dei metadati su come inizializzare e scaricare i contenuti video. I concetti chiave supportati dal ricevitore 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 contenuto di streaming. I tag <Period> consentono di ordinare i diversi contenuti in streaming e vengono spesso utilizzati per separare i contenuti principali e la pubblicità o più contenuti video consecutivi.

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

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

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

Per un valore <SegmentTemplate>, indica come il segmento di inizializzazione e i segmenti multimediali possono essere rappresentati tramite i modelli. Nell'esempio seguente, $Number$ indica il numero del segmento come disponibile dalla CDN. Quindi si traduce in seg1.m4s, seg2.m4s e così via mentre la riproduzione 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>

Per un elemento <SegmentTemplate>, è prassi comune utilizzare il tag <SegmentTimeline> per indicare la durata di ogni segmento e quali si ripetono. Una timescale (unità che rappresentano un secondo) viene spesso inclusa negli 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> indica un tag di segmento, l'attributo d specifica la durata del segmento e l'attributo r specifica quanti segmenti della stessa durata si ripetono in modo da poter calcolare correttamente $Time$ per il download del segmento multimediale come specificato nell'attributo 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>

Per la rappresentazione utilizzando <SegmentList>, ecco un esempio:

<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 file con un singolo segmento, con le richieste di intervallo di byte viene spesso utilizzato <SegmentBase> per specificare quale parte di un file <BaseURL> contiene l'indice, mentre il resto può essere recuperato on demand durante la riproduzione o durante la ricerca. Qui l'intervallo Initialization specifica l'intervallo di metadati init e indexRange specifica l'indice per i 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 dalla rappresentazione utilizzata, se i flussi sono protetti, una sezione <ContentProtection> può apparire in <AdaptationSet>, dove schemeIdUri identifica in modo univoco il sistema DRM da utilizzare. Per la crittografia comune può essere incluso un ID chiave facoltativo.

<!-- 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 altri esempi e dettagli, fai riferimento alla specifica MPEG-DASH. Di seguito è riportato un elenco di attributi DASH aggiuntivi su tag non menzionati sopra, che attualmente supportiamo:

Nome attributo Funzione attributo
mediaPresentationDuration La durata dei contenuti video.
minimumUpdatePeriod Attributo del tag <MPD>; specifica la frequenza con cui dobbiamo ricaricare il manifest.
digita Attributo del tag <MPD>; "dinamico" per indicare che si tratta di un live streaming.
presentationTimeOffset Attributo del tag <SegmentBase>; specifica lo scarto per la rappresentazione dall'inizio del periodo.
startNumber Specifica il numero del primo segmento multimediale in una presentazione in un periodo. Questa opzione è spesso utilizzata nei live streaming.

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

Sebbene il nostro attuale ricevitore web supporti i principali casi d'uso di DASH, qui puoi trovare un elenco di attributi comuni che la nostra attuale implementazione di DASH ignora o non utilizza. Ciò significa che, a prescindere dalla presenza o meno nel file manifest, questi elementi non influiscono sull'esperienza di riproduzione dei contenuti.

  • availabilityStartTime
  • segmentAlignment

HTTP Live Streaming (HLS)

La panoramica e le specifiche complete relative al live streaming HTTP sono disponibili qui.

Uno dei principali punti di forza del web ricevitore è la capacità di supportare la riproduzione di HLS in MSE. A differenza di DASH, in cui un file manifest è incluso in un singolo file, HLS invia la playlist principale contenente un elenco di tutti gli stream delle varianti con il rispettivo URL. La playlist della variante è la playlist multimediale. I due tag HLS principali attualmente supportati dal player ricevitore web nella playlist principale sono:

Nome tag Funzionalità
#EXT-X-STREAM-INF Specifica una velocità in bit/stream di varianti. L'attributo BANDWIDTH è obbligatorio e supporta la selezione dello streaming con velocità in bit adattiva. L'attributo CODECS è vivamente consigliato per l'inizializzazione di MSE, ad esempio "avc1.42c01e,mp4a.40.2". Se non specificato, il caso predefinito è impostato su video H264 del profilo principale 3.0 e sui contenuti con codifica audio "mp4a.40.2".
#EXT-X-MEDIA Specifica una playlist multimediale aggiuntiva (nell'attributo URI) che rappresenta i contenuti. Di solito si tratta di stream audio alternativi in un altro formato (audio surround 5.1) o in una lingua. È consentito un attributo TYPE che contiene VIDEO, AUDIO, SUBTITLES o CLOSED-CAPTIONS. Se imposti l'attributo DEFAULT su YES, verrà indicato la scelta di questo stream alternativo per impostazione predefinita.

Di seguito è riportato un elenco dei tag HLS attualmente supportati dal ricevitore web nella playlist multimediale:

Nome tag Funzionalità
#EXTINF Informazioni sullo stream, di solito seguite dalla durata del segmento in secondi e nella riga successiva l'URL del segmento.
#EXT-X-TARGETDURATION La durata in secondi di ogni segmento. Questo determina anche la frequenza di download/aggiornamento del file manifest della playlist per un live streaming. Web ricevitore Player non supporta durate inferiori a 0,1 secondi.
#EXT-X-MEDIA-SEQUENCE Il numero di sequenza (spesso per un live streaming) rappresentato dal primo segmento di questa playlist.
#EXT-X-KEY Informazioni chiave DRM. L'attributo METHOD indica quale sistema chiavi utilizzare. Attualmente supportiamo AES-128 e SAMPLE-AES.
#EXT-X-BYTERANGE L'intervallo di byte da recuperare per l'URL di un segmento.
#EXT-X-DISCONTINUITY Specifica una discontinuità tra segmenti consecutivi. Questo problema si verifica spesso con l'inserimento di annunci lato server, in cui un segmento di annunci viene visualizzato al centro dello stream principale.
#EXT-X-PROGRAM-DATE-TIME Tempo assoluto del primo campione del segmento successivo, ad esempio "2016-09-21T23:23:52.066Z".
#EXT-X-ENDLIST Che si tratti di un VOD o di un live streaming.

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

La nostra implementazione HLS supporta la selezione di uno stream audio alternativo, ad esempio l'audio surround 5.1, come riproduzione audio principale. Questo può essere ottenuto avendo un tag #EXT-X-MEDIA con i codec alternativi, oltre a fornire il formato del segmento nella configurazione del flusso.

Il web ricevitore si aspetta un determinato comportamento in base alle specifiche. Ad esempio, dopo un tag #EXT-INF, ci aspettiamo un URI. Se non si tratta di un URI, ad esempio #EXT-X-DISCOUNTINUITY, l'analisi della playlist non andrà a buon fine.

Ogni #EXT-X-TARGETDURATION secondi, ricarichiamo la playlist/il manifest per ricevere nuovi elenchi di segmenti e aggiorniamo la nuova rappresentazione interna di tutti i segmenti con quella nuova. Ogni volta che viene richiesta una ricerca, la ricerca viene effettuata solo entro l'intervallo ricercabile. Per i contenuti pubblicati, consentiamo la ricerca solo dall'inizio dell'elenco più recente 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 fino a 7 segmenti, ma non 8.

Supporto del formato dei segmenti

L'SDK CAF supporta la riproduzione di contenuti pubblicati in più formati, come indicato in HlsSegmentFormat per l'audio e HlsVideoSegmentFormat per i video. Ciò include il supporto per audio in pacchetti, come la riproduzione AAC e AC3, sia criptati che non criptati. È necessario specificare queste informazioni nel MediaInformation dell'LoadRequestData per descrivere correttamente i tuoi contenuti al player. Se non specificato, la configurazione predefinita del player tenterà di riprodurre i contenuti come contenuti in pacchetto Transport Stream. Questa proprietà può essere impostata da qualsiasi mittente nei dati della richiesta di caricamento (Android, iOS e Web) o all'interno del destinatario tramite intercettatori dei messaggi.

Consulta lo snippet di codice di esempio riportato di seguito o la guida Caricamento di contenuti multimediali con contentId, contentUrl ed entità per ulteriori informazioni su come preparare i 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 sopra nella sezione relativa ai tag #EXT-X-KEY, l'SDK Cast supporta SAMPLE-AES o SAMPLE-AES-CTR in cui è possibile specificare un URI della chiave e un vettore di inizializzazione:

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

Il KEYFORMAT che ora supportiamo è Widevine e l'URI contiene un'informazione DRM codificata BASE64 XXXXXXX che, quando decodificata, contiene l'ID chiave:

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

La versione 1 definisce i seguenti attributi:

Attributo Esempio Descrizione
KEYFORMATVERSIONS "1" Questa proposta definisce la versione 1 del formato della chiave
KEYFORMAT "urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed" L'UUID è l'UUID di Widevine di DASH IF IOP. Con gli stream criptati di Widevine viene utilizzata la stessa stringa esatta in MPD.
URI "data:text/plain;base64, <base64 encoded PSSH box>" URI del flusso contenente il tipo di dati e la casella PSSH.
METHOD SAMPLE-AES-CTR Indica la crittografia utilizzata durante la crittografia dei contenuti. EXAMPLE-AES indica che i contenuti sono criptati utilizzando "cbcs". EXAMPLE-AES-CTR indica che i contenuti sono criptati utilizzando uno degli schemi di protezione AES-CTR, ovvero "cenc".

Attributi mappati a MPD DASH:

Attributo Descrizione
KEYFORMAT Attributo schemaIdUri dell'elemento ContentProtection.
URI Il contenuto dell'elemento cenc:pssh.
KEYID Stringa esadecimale a 16 byte che codifica l'ID della chiave che ha lo stesso ruolo di default_kid in MPEG DASH. Se utilizzi uno schema di chiavi gerarchico, questa sarà la chiave "principale".

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 attualmente non utilizziamo o non supportiamo. 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 è stato utilizzato. Ci affidiamo invece a: DEFAULT=
  • #EXT-X-I-FRAME-STREAM-INF nella playlist principale viene ignorato.
  • Ignora #EXT-X-DISCONTINUITY-SEQUENCE
  • #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 il nostro web ricevitore si basa solo sull'esistenza di #EXT-X-ENDLIST per determinare il confronto tra live e VOD.

Streaming senza interruzioni

Le specifiche per lo streaming fluido ufficiali di Microsoft.

Lo streaming fluido offre protocollo di streaming adattivo e specifica XML su HTTP (in modo simile a DASH). Diversa da DASH, Streaming fluido consiglia solo pacchetti MPEG-4 per i segmenti multimediali.

Di seguito è riportata una tabella dei tag e degli attributi più comuni per lo streaming fluido attualmente supportati dal ricevitore web ricevitore. Molti concetti sono già spiegati nella sezione DASH sopra.

Tag/Attributo Utilizzo
<SmoothStreamingMedia> Tag principale per il manifest, contiene attributi di:
  • Scala temporale: numero di unità che rappresentano un secondo, in genere con un incremento di 10.000.000.
  • Durata: la lunghezza dei contenuti in scala temporale. Web ricevir player non supporta durate inferiori a 0,1 secondi.
  • IsLive: indica se il manifest è un elemento multimediale live.
<StreamIndex> Un insieme di stream, simile all'AdattamentoSet di DASH. Di solito il tipo è "text", "video" o "audio". L'attributo URL di solito contiene un URL con frammento basato su modelli che utilizza informazioni come la velocità in bit o l'ora di inizio.
<QualityLevel> Ogni tag QualityLevel specifica la velocità in bit e un codec FourCC. Il codice FourCC è spesso "H264", "AVC1", "AACL" e così via. Per i video, specifica le risoluzioni tramite Maxwidth e MaxHeight. Per l'audio, specifica la sua frequenza (ad esempio 44100) tramite SamplingRate e il numero di canali.
<c> Elemento frammento di flusso. Contiene:
  • d: durata di un frammento.
  • t: ora multimediale del frammento.
<Protezione> Un tag con l'attributo facoltativo SystemID che elenca l'ID del DRM di sistema da utilizzare nel tag < smoothStreamingMedia>.
<ProtectionHeader> In <Protection>, può contenere un attributo SystemID e dati personalizzati, di solito con codifica Base64. Per Widevine, conterrà l'ID chiave, la lunghezza della chiave, l'ID dell'algoritmo, ad esempio AESCTR, LA_URL (URL di acquisizione licenza), LUI_URL (url interfaccia utente licenza) e DS_ID (ID servizio di dominio).

Protezione dei contenuti

Per codificare correttamente gli ID sistema di protezione, utilizza la mappatura riportata di seguito:

  • WIDEVINE: 'EDEF8BA9-79D6-4ACE-A3C8-27DCD51D21ED',
  • CHIAVE: '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. Quando decodificati, i dati sono conformi allo stesso formato decodificato descritto nel 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 file manifest in live streaming in streaming con contenuti di 3000 secondi:

<?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 precedente per il video stream, il modello di URL è:

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

Quindi i primi due segmenti (supponendo che il livello qualitativo sia l'indice 2) saranno i seguenti, con il tempo iniziale estratto da t="80649401378125" sotto il video StreamIndex 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 che non hanno alcun effetto sulle esperienze di streaming, a prescindere dal fatto che vengano forniti o meno:

  • CanSeek, CanPause nel tag <SmoothStreamingMedia>.
  • Chunks, QualitàLevels nel tag <StreamIndex>. Calcoliamo invece il numero di segmenti e il numero di livelli qualitativi in base alle informazioni fornite all'interno di <StreamIndex>, come il tag QualityLevel effettivo e i tag <c>.
  • BitsPerSample, PacketSize in <QualityLevel> non vengono utilizzati.

Controlla il tipo di visualizzazione

Il metodo canDisplayType verifica le funzionalità video e audio del dispositivo e della visualizzazione web del ricevitore web convalidando i parametri multimediali trasmessi e restituendo un valore booleano. Tutti i parametri, tranne i primi, sono facoltativi: più parametri includi, più preciso sarà il controllo.

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

Esempi:

Verifica se il dispositivo ricevitore web e il display supportano il tipo MIME video/mp4 con i seguenti codec, dimensioni e frequenza fotogrammi:

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

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

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

Verifica se il dispositivo e il display del ricevitore web supportano la tecnologia HDR10 per i seguenti codec, dimensioni e frequenza fotogrammi:

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

Verifica se il dispositivo ricevitore web e il display supportano il formato Dolby Vision (DV) per questi codec, dimensioni e frequenza fotogrammi:

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

DRM

Alcuni contenuti multimediali richiedono la tecnologia DRM (Digital Rights Management). Per i contenuti multimediali con licenza DRM (e URL della chiave) memorizzati nel file manifest (DASH o HLS), questo caso viene gestito dall'SDK Cast per te. Un sottoinsieme di questi contenuti richiede un elemento licenseUrl, necessario per ottenere la chiave di decriptazione. Nel ricevitore web, puoi usare PlaybackConfig per impostare licenseUrl in base alle tue esigenze.

Il seguente snippet di codice mostra come impostare le informazioni sulle richieste di 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 disponi di un'integrazione con l'Assistente Google, alcune informazioni DRM, come le credenziali necessarie per i contenuti, potrebbero essere collegate direttamente al tuo Account Google tramite meccanismi come OAuth/SSO. In questi casi, se i contenuti multimediali vengono caricati tramite comandi vocali o provengono dal cloud, viene richiamato un elemento setCredentials dal cloud al dispositivo di trasmissione fornendo le credenziali. Le applicazioni che scrivono un'app ricevitore web possono quindi usare le informazioni setCredentials per gestire DRM secondo necessità. Ecco un esempio di utilizzo della credenziale per creare i contenuti multimediali.

Suggerimento: vedi anche Caricamento di contenuti multimediali utilizzando contentId, contentUrl ed entity.

Gestione dei canali audio

Quando il player di trasmissione carica i contenuti multimediali, imposta un buffer della sorgente audio singolo. Allo stesso tempo, seleziona anche un codec appropriato che deve essere utilizzato dal buffer, in base al tipo MIME della traccia principale. Sono stati impostati un nuovo buffer e un nuovo codec:

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

Poiché il buffer utilizza un singolo codec e quest'ultimo viene scelto in base alla traccia principale, in alcune situazioni le tracce secondarie potrebbero essere filtrate e non udibili. Questo può accadere quando la traccia principale di un programma multimediale utilizza l'audio surround, mentre le tracce audio secondarie utilizzano il suono stereo. Poiché le tracce secondarie vengono spesso utilizzate per offrire contenuti in lingue alternative, fornire contenuti multimediali contenenti un numero diverso di tracce può avere un impatto significativo, ad esempio un numero elevato di spettatori non riesce a sentire i contenuti nella propria lingua madre.

I seguenti scenari illustrano perché è importante fornire una programmazione in cui i canali principali e secondari contengono lo stesso numero di canali:

Scenario 1 - Lo stream multimediale non ha la parità di canali tra le tracce principali e secondarie:

  • italiano - Canale AC-3 5.1 (principale)
  • svedese - AAC a due canali
  • francese - AAC a due canali
  • tedesco - AAC 2-channel

In questo scenario, se la lingua del player è impostata su una lingua diversa dall'inglese, l'utente non sente la traccia che si aspetta di sentire, perché tutte le tracce a due canali vengono omesse durante la riproduzione. L'unica traccia che potrebbe essere riprodotta sarebbe quella del canale AC-3 5.1 principale e solo quando la lingua è impostata sull'inglese.

Scenario 2 - stream multimediale con parità di canali tra le tracce principali e secondarie:

  • italiano - Canale AC-3 5.1 (principale)
  • Svedese: AC-3 5.1 canali
  • francese - AC-3 5.1 canali
  • tedesco - AC-3 5.1 channel

Poiché tutte le tracce di questo stream hanno lo stesso numero di canali, il pubblico ascolta una traccia indipendentemente dalla lingua selezionata.

Gestione del canale audio Shaka

Per impostazione predefinita, il player Shaka (DASH) mostra un numero preferito di canali pari a due, come misura di mitigazione quando si incontrano contenuti multimediali che non hanno la parità tra le tracce audio secondarie.

Se la traccia principale non è un audio surround (ad esempio, una traccia stereo a due canali), per impostazione predefinita il player Shaka sceglierà due canali ed escluderà automaticamente tutte le tracce multimediali secondarie che hanno più di due canali.

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

Ad esempio:

shakaConfig = { "preferredAudioChannelCount": 6 };

Con preferredAudioChannelCount impostato su 6, Shaka Player controlla se può supportare i codec audio surround (AC-3 o EC-3) e filtra automaticamente tutte le tracce multimediali non conformi al numero di canali preferito.