Web Receiver-Streaming-Protokolle

Das Web Receiver SDK unterstützt drei Typen Streaming-Protokollen heute:

DASH HTTP Live Streaming und <ph type="x-smartling-placeholder"></ph> Zuverlässiges Streaming.

In diesem Dokument stellen wir unsere Unterstützung für jedes Streaming-Protokoll vor. Hinweis Die Erklärung der unterstützten Tags für die einzelnen Protokolle ist ziemlich abgekürzt im Vergleich zur detaillierten Protokollspezifikation. Ziel ist es, einen schnellen Überblick über die Verwendung der einzelnen Protokolle und die Funktionen, des Protokolls auf für Google Cast optimierten Geräten unterstützt werden, Streamingerlebnisse.

Dynamic Adaptive Streaming over HTTP (DASH)

ISOs detaillierte Spezifikation von DASH

DASH ist ein Streaming-Protokoll mit adaptiver Bitrate, das Videos in hoher Qualität ermöglicht. als Streaming über HTTP(S)-Server. Ein Manifest, das in XML erstellt wurde, enthält die meisten der Metadaten für die Initialisierung und das Herunterladen des Videos Inhalte. Die Schlüsselkonzepte, die der Web Receiver Player unterstützt, sind <Period>, <AdaptationSet>, <Representation>, <SegmentTemplate> <SegmentList>, <BaseUrl> und <ContentProtection>.

Ein DASH-Manifest beginnt mit einem Stamm-<MPD>-Tag und enthält ein oder mehrere <Period>-Tags, die einen Streaming-Inhalt darstellen <Period>-Tags ermöglichen das Sortieren verschiedener Streaminginhalte und werden häufig verwendet, um Hauptinhalte und Werbung voneinander zu trennen. aufeinanderfolgende Videoinhalte.

Ein <AdaptationSet> unter <MPD> ist eine Reihe von Darstellungen für eine Art von Medienstream, meist Video, Audio oder Untertitel. Die meisten Die häufig unterstützten MIME-Typen sind „video/mp4“, „audio/mp4“ und „text/vtt“. Eine <ContentComponent contentType="$TYPE$"> kann optional angegeben werden weniger als <AdaptationSet>.

In jedem <AdaptationSet> sollte eine Liste mit <Representation>-Tags enthalten sein. vorhanden sein und der Web Receiver Player die codecs-Informationen verwendet, um den MSE-Quellpuffer und die bandwidth-Informationen zu initialisieren, automatisch die richtige Darstellung/Bitrate für die Wiedergabe auswählen.

Für jeden <Representation> werden Mediasegmente folgendermaßen beschrieben: ein <BaseURL> für die Darstellung eines einzelnen Segments, <SegmentList> für Liste mit Segmenten (ähnlich HLS) oder <SegmentTemplate>.

Für ein <SegmentTemplate> gibt es an, wie das Initialisierungssegment und Mediensegmente können durch Vorlagen repräsentiert werden. Im Beispiel unten $Number$ gibt die Segmentnummer an, die über das CDN verfügbar ist. Es ist also wird während der Wiedergabe in seg1.m4s, seg2.m4s usw. übersetzt.

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

Bei einem <SegmentTemplate> ist es üblich, das <SegmentTimeline>-Tag für Folgendes zu verwenden: wie lang die einzelnen Segmente sind und welche sich wiederholen. timescale (Einheiten für eine Sekunde) wird oft als Teil der Attribute von <SegmentTemplate>, damit wir die Zeit des Segments basierend auf diese Einheit. Im Beispiel unten steht das Tag <S> für ein Segment-Tag, das Das d-Attribut gibt an, wie lang das Segment ist, und das r-Attribut gibt an, wie viele Segmente mit derselben Dauer sich wiederholen, sodass $Time$ für den Download des Mediensegments wie in den media-Attribut

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

Hier ein Beispiel für die Darstellung mit <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>

Für eine einzelne Segmentdatei wird <SegmentBase> häufig mit Byte Bereichsanfragen, um anzugeben, welcher Teil einer <BaseURL>-Datei die Der Rest kann bei Fortsetzung der Wiedergabe oder einer Suche abgerufen werden. passiert. Hier gibt der Bereich Initialization den Init-Metadatenbereich an und mit indexRange der Index für die Mediensegmente angegeben wird. Beachten Sie, dass unterstützen wir derzeit nur aufeinanderfolgende Bytebereiche.

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

Unabhängig von der verwendeten Darstellung gilt: Wenn die Streams geschützt sind, Der Bereich „<ContentProtection>“ kann unter „<AdaptationSet>“ angezeigt werden, Dabei wird das zu verwendende DRM-System durch einen schemeIdUri eindeutig identifiziert. Für eine allgemeine Verschlüsselung kann eine optionale Schlüssel-ID angegeben werden.

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

Weitere Beispiele und Details finden Sie in der MPEG-DASH-Spezifikation. Nachfolgend finden Sie eine Liste zusätzlicher DASH-Attribute für Tags, die oben nicht aufgeführt sind die wir derzeit unterstützen:

Wir unterstützen auch die Erkennung des EMSG-Feldes in MP4-Fragmenten für DASH und eine EmsgEvent für Entwickelnde.

Unser aktueller Web Receiver Player unterstützt zwar die wichtigsten DASH-Anwendungsfälle, hier ist eine Liste allgemeiner Attribute, die bei der aktuellen DASH-Implementierung ignoriert oder nicht verwendet. Das heißt, unabhängig davon, ob das Manifest haben sie keinen Einfluss auf die Wiedergabe der Inhalte.

• availabilityStartTime
• segmentAlignment

HTTP Live Streaming (HLS)

Eine Übersicht und die vollständigen Spezifikationen von HTTP-Livestreaming findest du unter hier.

Eine der größten Stärken des Web Receiver Player ist seine Fähigkeit, Wiedergabe von HLS in MSE. Im Gegensatz zu DASH, bei dem ein Manifest sendet HLS die Masterplaylist mit einer Liste aller Variantenstreams. durch die entsprechende URL. Die Variantenplaylist ist die Mediaplaylist. Die beiden wichtige HLS-Tags, die der Web Receiver Player derzeit im Master unterstützt Playlist:

Hier ist eine Liste der HLS-Tags, die der Web Receiver Player derzeit in der Medienplaylist:

Für Livestreams verwenden wir #EXT-X-PROGRAM-DATE-TIME und #EXT-X-MEDIA-SEQUENCE als Schlüsselfaktoren, um zu bestimmen, wie ein neu aktualisiertes Manifest zusammengeführt werden soll. Wenn vorhanden ist, wird #EXT-X-PROGRAM-DATE-TIME verwendet, um die aktualisierten Segmente abzugleichen. Andernfalls wird die #EXT-X-MEDIA-SEQUENCE-Nummer verwendet. Beachten Sie, dass gemäß der HLS-Spezifikation ist, verwenden wir für den Abgleich keinen Dateinamensvergleich.

Unsere HLS-Implementierung unterstützt die Auswahl eines alternativen Audiostreams, z. B. 5.1-Surround-Sound zur Hauptwiedergabe Dies kann erreicht werden, indem ein #EXT-X-MEDIA-Tag mit den alternativen Codecs und die Bereitstellung Das Segmentformat in der Streamkonfiguration.

Der Web Receiver Player erwartet ein bestimmtes Verhalten pro Spezifikation. Beispiel: Nach einem #EXT-INF-Tag enthält, wird ein URI erwartet. Wenn es sich nicht um einen URI handelt, z. B. einen #EXT-X-DISCOUNTINUITY führt dazu, dass das Parsen der Playlist fehlschlägt.

Alle #EXT-X-TARGETDURATION Sekunden laden wir die Playlist/das Manifest neu, Segmentlisten erstellen und die interne Darstellung aller in das neue Segment. Bei jeder Anforderung einer Suche erfolgt eine Suche nur innerhalb von den suchbaren Bereich. Bei Livestreams ist nur die Suche ab dem Anfang des neueste Liste bis zu einer Zieldauer von drei nach dem Ende. Nehmen wir z. B. Wenn Sie eine Liste mit zehn Segmenten haben und sich in Segment 6 befinden, können Sie auf 7, aber nicht auf 8.

Unterstützung für Segmentformate

Das CAF SDK unterstützt die Wiedergabe von Inhalten, die in verschiedenen Formaten wie angegeben in HlsSegmentFormat für Audio und HlsVideoSegmentFormat für Videos. Dazu gehört auch die Unterstützung voller Audio wie die verschlüsselte und unverschlüsselte AAC- und AC3-Wiedergabe. Dies ist ein Pflichtfeld. , um diese Informationen im MediaInformation der LoadRequestData anzugeben um deine Inhalte für den Player richtig zu beschreiben. Wenn keine Angabe erfolgt, wird der In der Standard-Player-Konfiguration wird versucht, den Inhalt als Transportmittel abzuspielen Gepackte Inhalte streamen. Dieses Attribut kann von jedem Absender im Daten der Ladeanfrage (Android, iOS und Web) oder im Empfänger über Nachrichten-Abfangenden.

Beispielcode ansehen Snippet unter oder das Feld Medien mit contentId, contentUrl und Entität laden für weitere Informationen zum Vorbereiten von Inhalten auf 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;
    });

Inhaltsschutz

Wie oben im Abschnitt zum #EXT-X-KEY-Tag aufgeführt, unterstützt das Cast SDK SAMPLE-AES oder SAMPLE-AES-CTR, wobei ein URI zum Schlüssel eines Initialisierungsvektors angegeben werden:

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

Die KEYFORMAT, die wir jetzt unterstützen, ist Widevine und der URI enthält einen BASE64-codierte DRM-Informationen XXXXXXX, die nach der Decodierung die Schlüssel-ID enthalten:

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

In Version 1 werden die folgenden Attribute definiert:

Der DASH-MPD zugeordnete Attribute:

Beispiel für eine HLS-Playlist mit V2-Signalen:

#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

Nachfolgend finden Sie eine Liste von Funktionen und Tags in HLS, die wir derzeit nicht verwenden. Support. Ihr Vorhandensein oder Fehlen hat keinen Einfluss auf das Streamingverhalten.

• Das Attribut RESOLUTION= in #EXT-X-STREAM-INF wird ignoriert.
• Das Attribut AUTOSELECT= in #EXT-X-MEDIA wird nicht verwendet. Stattdessen verlassen wir uns DEFAULT=
• #EXT-X-I-FRAME-STREAM-INF in der Masterplaylist wird ignoriert.
• #EXT-X-DISCONTINUITY-SEQUENCE wird ignoriert
• #EXT-X-PLAYLIST-TYPE:EVENT kann in einem Livestream anwesend sein und #EXT-X-PLAYLIST-TYPE:VOD kann in einem VOD-Stream verwendet werden. Der Web Receiver Player benötigt #EXT-X-ENDLIST, um Live- und VOD.

Zuverlässiges Streaming

Offiziell von Microsoft Spezifikation für flüssiges Streaming:

Smooth Streaming bietet adaptives Streamingprotokoll und XML-Spezifikation (ähnlich wie DASH). Im Gegensatz zu DASH empfiehlt Smooth Streaming MPEG-4-Paketerstellung für die Mediensegmente.

Hier ist eine Tabelle mit den häufigsten Tags und Attributen beim Smooth Streaming, die der derzeit vom Web Receiver Player unterstützt wird. Viele Konzepte werden bereits in im Abschnitt „DASH“ oben.

Inhaltsschutz

Verwenden Sie die folgende Zuordnung, um die Schutzsystem-IDs richtig zu codieren:

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

Unten sehen Sie für <ProtectionHeader> ein Beispiel mit Base64-codierten Daten. Die decodierten Daten dasselbe decodierte Format wie in den Support für den DASH-Inhaltsschutz oben.

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

Unten sehen Sie ein Beispiel für ein Manifest für flüssiges Livestreaming mit einer Dauer von 3.000 Sekunden Dauer des Inhalts:

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

Im obigen Beispiel für den Videostream lautet die URL-Vorlage:

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

Die ersten beiden Segmente (sofern wir uns auf der Qualitätsebene von Index 2 befinden) werden die folgende, mit anfänglicher Zeit, die aus t="80649401378125" extrahiert wurde im Bereich Video-StreamIndex und die Zeitintervalle von 4 Sekunden * 1.000.000 pro Segment:

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

Hier ist eine Liste der Attribute für flüssiges Streaming, die wir derzeit ignorieren und keine Auswirkungen auf Streamingerlebnisse, unabhängig davon, ob sie bereitgestellt werden:

• CanSeek und CanPause im Tag <SmoothStreamingMedia>
• Chunks und QualityLevels im <StreamIndex>-Tag. Stattdessen berechnen wir Anzahl der Segmente und Qualitätsstufen basierend auf Informationen <StreamIndex> wie dem tatsächlichen QualityLevel-Tag und dem <c>-Tags.
• BitsPerSample und PacketSize in <QualityLevel> werden nicht verwendet.

Displaytyp prüfen

Die canDisplayType Methodenprüfung auf Video- und Audiofunktionen des Web Receiver-Geräts und durch Validieren der übergebenen Medienparameter und Rückgabe eines booleschen Werts. Alle Die ersten Parameter sind optional. Je mehr Parameter Sie angeben, damit die Prüfung präziser sein wird.

Die Signatur lautet canDisplayType(<em>mimeType</em>,<em>codecs</em>,<em>width</em>,<em>height</em>,<em>framerate</em>).

Beispiele:

Prüft, ob WebReceiver und Display das Video/MP4 unterstützen MIME-Typ mit diesem Codec, diesen Dimensionen und dieser Framerate:

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

Prüft, ob Web Receiver-Gerät und -Display 4K-Videoformat für Codec hinzu, indem Sie die Breite von 3840 und die Höhe von 2160 angeben:

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

Prüft, ob Web Receiver und Display HDR10 für diesen Codec unterstützen, Dimensionen und Framerate:

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

Prüft, ob der Webempfänger und das Display Dolby Vision (DV) für diesem Codec, den Abmessungen und der Framerate:

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

DRM

Einige Medieninhalte erfordern die digitale Rechteverwaltung (Digital Rights Management, DRM). Für Medieninhalte dessen DRM-Lizenz (und die Schlüssel-URL) im Manifest (DASH oder HLS) gespeichert ist, das Cast SDK übernimmt diesen Fall für Sie. Für einen Teil dieser Inhalte ist ein licenseUrl das zum Abrufen des Entschlüsselungsschlüssels erforderlich ist. Im Web Receiver können Sie Folgendes verwenden: PlaybackConfig, um licenseUrl nach Bedarf festzulegen.

Das folgende Code-Snippet zeigt, wie Sie Anfrageinformationen für eine Lizenz Anfragen wie 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;
});

Wenn Sie Google Assistant integriert haben, werden einige DRM-Informationen wie können die für die Inhalte erforderlichen Anmeldedaten direkt mit Ihrem Google-Konto über Mechanismen wie OAuth/SSO verwenden. Wenn in diesen Fällen werden Medieninhalte per Spracheingabe geladen oder stammen aus der Cloud, setCredentials wird über die Cloud auf dem Übertragungsgerät aufgerufen, sofern Folgendes zutrifft: Anmeldedaten. Anwendungen, die eine Web Receiver-Anwendung schreiben, können dann den setCredentials Informationen für den Betrieb der digitalen Rechteverwaltung bei Bedarf. Hier ist ein Beispiel für beim Erstellen der Medien anhand der Anmeldedaten.

Tipp: Weitere Informationen finden Sie unter Medien mithilfe von „contentId“, „contentUrl“ und „entity“ laden.

Umgang mit Audiokanälen

Wenn der Cast-Player Medien lädt, wird ein einzelner Zwischenspeicher für die Audioquelle eingerichtet. Bei und wählt einen passenden Codec für den Zwischenspeicher aus. basierend auf dem MIME-Typ des primären Tracks. Ein neuer Puffer und Codec werden eingerichtet:

• wann die Wiedergabe beginnt,
• bei jeder Werbeunterbrechung
• wenn der Hauptinhalt wieder aktiviert wird.

Da der Zwischenspeicher nur einen Codec verwendet und der basierend auf dem primären Track, kann es Situationen geben, in denen sekundäre Tracks herausgefiltert und nicht gehört. Das kann passieren, wenn der primäre Surround-Sound vorhanden ist, bei sekundären Audiotracks wird Stereo-Sound verwendet. Weil sekundäre Titel häufig verwendet werden, um Inhalte in alternativen Versionen anzubieten und Medien mit einer unterschiedlichen Anzahl von Titeln haben, erhebliche Auswirkungen, z. B. wenn viele Zuschauer nichts hören können in ihrer Muttersprache.

Die folgenden Szenarien veranschaulichen, warum es wichtig ist, Programmierung zur Verfügung zu stellen. wobei der primäre und der sekundäre Titel die gleiche Anzahl an Kanälen enthalten:

Szenario 1 – Medienstream ohne Kanal Gleichheit im primären und sekundären Track:

• Englisch - AC-3 5.1-Kanal (primär)
• Schwedisch – AAC 2-Channel
• Französisch – AAC 2-Kanal
• Deutsch – AAC 2-Kanal

Ist in diesem Szenario die Sprache des Spielers auf eine andere Sprache als nicht den gewünschten Titel hören, Titel mit zwei Kanälen werden während der Wiedergabe herausgefiltert. Der einzige Track, der gespielt werden könnte, wäre der primäre AC-3-5.1-Kanal und nur dann, wenn der Sprache auf Englisch eingestellt ist.

Szenario 2 – Mediastream mit Kanal Gleichheit im primären und sekundären Track:

• Englisch - AC-3 5.1-Kanal (primär)
• Schwedisch - AC-3 5.1 Kanal
• Französisch – AC-3 5.1 Kanal
• Deutsch – AC-3 5.1-Kanal

Da die Titel dieses Streams alle die gleiche Anzahl an Kanälen haben, hören Sie einen Titel, unabhängig von der ausgewählten Sprache.

Umgang mit Shaka-Audiokanälen

Der Shaka-Player (DASH) ist standardmäßig auf 2 eingestellt, da Abhilfemaßnahmen, wenn es um Medien stößt, die im Vergleich zu sekundären Audiotracks.

Wenn es sich beim primären Titel nicht um Surround-Sound handelt (z. B. bei einer Zweikanal-Stereoanlage aktiviert, setzt der Shaka-Player standardmäßig zwei Kanäle ein. alle sekundären Media-Tracks mit mehr als zwei Kanäle.

Die bevorzugte Anzahl der Audiokanäle von Shaka kann auch konfiguriert werden, indem Sie die preferredAudioChannelCount in der Eigenschaft shakaConfig auf cast.framework.PlaybackConfig.

Beispiel:

shakaConfig = { "preferredAudioChannelCount": 6 };

Ist preferredAudioChannelCount auf 6 gesetzt, prüft Shaka Player, ob Es unterstützt die Surround-Sound-Codecs (AC-3 oder EC-3) und filtert automatisch alle Medien-Tracks heraus, die nicht den bevorzugten die Anzahl der Kanäle.