Web Receiver-Streaming-Protokolle

Das Web Receiver SDK unterstützt derzeit drei Arten von Streamingprotokollen:

DASH, HTTP Live Streaming und Smooth Streaming

In diesem Dokument ist unsere Unterstützung für jedes der Streaming-Protokolle aufgeführt. Die Beschreibung der unterstützten Tags für jedes Protokoll ist im Vergleich zur detaillierten Protokollspezifikation recht kurz. Ziel ist es, einen schnellen Überblick über die Verwendung der einzelnen Protokolle zu geben und zu verstehen, welche Funktionen des Protokolls auf für Google Cast optimierten Geräten für die Bereitstellung von Streaming-Inhalten unterstützt werden.

Dynamic Adaptive Streaming over HTTP (DASH)

Detaillierte Spezifikation von DASH in ISO

DASH ist ein Streamingprotokoll mit adaptiver Bitrate, das das Streaming von Videos in hoher Qualität über HTTP(S)-Server ermöglicht. Ein in XML verfasstes Manifest enthält die meisten Metadateninformationen zum Initialisieren und Herunterladen des Videoinhalts. 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 <MPD>-Stamm-Tag und enthält ein oder mehrere <Period>-Tags, die einen Streaminginhalt darstellen. <Period>-Tags ermöglichen die Sortierung verschiedener Streaminginhalte. Sie werden häufig verwendet, um Hauptinhalt und Werbung oder mehrere aufeinanderfolgende Videoinhalte voneinander zu trennen.

Ein <AdaptationSet> unter <MPD> ist ein Satz von Darstellungen für eine Art von Medienstream, in den meisten Fällen Video, Audio oder Untertitel. Die am häufigsten unterstützten MIME-Typen sind "video/mp4", "audio/mp4" und "text/vtt". Eine optionale <ContentComponent contentType="$TYPE$"> kann unter <AdaptationSet> eingeschlossen werden.

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

Für jeden <Representation> werden Mediasegmente entweder mit einem <BaseURL> für die Darstellung eines einzelnen Segments, mit <SegmentList> für eine Liste von Segmenten (ähnlich wie HLS) oder mit <SegmentTemplate> beschrieben.

Für ein <SegmentTemplate> gibt er an, wie Initialisierungssegment und Mediensegmente durch Vorlagen dargestellt werden können. Im folgenden Beispiel gibt $Number$ die vom CDN verfügbare Segmentnummer an. Im weiteren Verlauf der Wiedergabe wird es also zu 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> wird üblicherweise das <SegmentTimeline>-Tag verwendet, um anzugeben, wie lang jedes Segment ist und welche sich wiederholen. Ein timescale (Einheiten, die eine Sekunde darstellen) ist häufig in den Attributen von <SegmentTemplate> enthalten, sodass wir die Zeit des Segments auf der Grundlage dieser Einheit berechnen können. Im folgenden Beispiel bezeichnet das Tag <S> ein Segment-Tag, das Attribut d gibt die Länge des Segments an und das Attribut r gibt an, wie viele Segmente mit derselben Dauer wiederholt werden, damit $Time$ für das Herunterladen des Mediasegments wie im Attribut media festgelegt richtig berechnet werden kann.

<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 ist 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 häufig mit Bytebereichsanfragen ein <SegmentBase> verwendet, um anzugeben, welcher Teil einer <BaseURL>-Datei den Index enthält. Der Rest kann bei Bedarf abgerufen werden, wenn die Wiedergabe fortgesetzt oder eine Suche stattfindet. Hier gibt der Bereich Initialization den Init-Metadatenbereich und indexRange den Index für die Mediensegmente an. Beachten Sie, dass derzeit nur aufeinanderfolgende Bytebereiche unterstützt werden.

<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 kann bei geschützten Streams ein <ContentProtection>-Abschnitt unter <AdaptationSet> angezeigt werden, wobei ein schemeIdUri das zu verwendende DRM-System eindeutig identifiziert. Für die 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 unterstützt werden:

Attributname Attributfunktion
mediaPresentationDuration Die Länge des Videoinhalts.
minimumUpdatePeriod Attribut des <MPD>-Tags. Gibt an, wie oft das Manifest neu geladen werden muss.
eingeben Attribut des <MPD>-Tags. „Dynamisch“ gibt an, dass es sich um einen Livestream handelt.
presentationTimeOffset Attribut des <SegmentBase>-Tags. Gibt den Zeitversatz für die Darstellung vom Beginn des Zeitraums an.
startNumber Gibt die Nummer des ersten Mediensegments in einer Präsentation in einem Zeitraum an. Diese Option wird häufig bei Livestreams verwendet.

Wir unterstützen auch die Erkennung des EMSG-Feldes in MP4-Fragmenten für DASH und stellen Entwicklern eine EmsgEvent zur Verfügung.

Unser aktueller Web Receiver Player unterstützt zwar die wichtigsten DASH-Anwendungsfälle, im Folgenden finden Sie jedoch eine Liste allgemeiner Attribute, die bei unserer aktuellen DASH-Implementierung ignoriert oder nicht verwendet werden. Unabhängig davon, ob das Manifest sie enthält, haben sie also keine Auswirkungen auf die Wiedergabe des Inhalts.

  • availabilityStartTime
  • segmentAlignment

HTTP Live Streaming (HLS)

Die Übersicht und die vollständigen Spezifikationen von HTTP-Livestreams findest du hier.

Eine der größten Stärken des Web Receiver Players ist die Unterstützung der HLS-Wiedergabe in MSE. Im Gegensatz zu DASH, bei der ein Manifest in einer einzelnen Datei enthalten ist, sendet HLS die Masterplaylist, die eine Liste aller Variantenstreams mit der entsprechenden URL enthält. Die Variantenplaylist ist die Mediaplaylist. Die beiden Haupt-HLS-Tags, die der Web Receiver Player derzeit in der Masterplaylist unterstützt, sind:

Tag-Name Funktionen
#EXT-X-STREAM-INF Gibt eine Bitrate/Varianten-Stream an. Das Attribut BANDWIDTH ist erforderlich, um die Auswahl des adaptiven Bitratenstreamings zu unterstützen. Für die Initialisierung von MSE, z. B. "avc1.42c01e,mp4a.40.2", wird dringend das Attribut CODECS empfohlen. Wenn nichts angegeben ist, wird die Standard Groß-/Kleinschreibung standardmäßig auf H264-Video des Hauptprofils 3.0 und als "mp4a.40.2"-audiocodierter Inhalt festgelegt.
#EXT-X-MEDIA Gibt eine zusätzliche Medienplaylist (im Attribut URI) an, die den Inhalt darstellt. Dabei handelt es sich in der Regel um alternative Audiostreams in einem anderen Format (5.1-Surround-Sound) oder einer anderen Sprache. Ein Attribut von TYPE, das entweder VIDEO, AUDIO, SUBTITLES oder CLOSED-CAPTIONS enthält, ist zulässig. Wenn das Attribut DEFAULT auf YES gesetzt ist, wird standardmäßig dieser alternative Stream ausgewählt.

Hier ist eine Liste der HLS-Tags, die der Web Receiver Player derzeit in der Mediaplaylist unterstützt:

Tag-Name Funktionen
#EXTINF Streaminformationen, normalerweise gefolgt von der Dauer des Segments in Sekunden und der URL des Segments in der nächsten Zeile.
#EXT-X-TARGETDURATION Die Länge der einzelnen Segmente in Sekunden. Dadurch wird auch festgelegt, wie oft das Playlist-Manifest für einen Livestream heruntergeladen/aktualisiert wird. Der Web Receiver Player unterstützt keine Zeitspannen unter 0,1 Sekunden.
#EXT-X-MEDIA-SEQUENCE Die Sequenznummer (häufig bei einem Livestream), die das erste Segment in dieser Playlist repräsentiert.
#EXT-X-KEY Informationen zum DRM-Schlüssel. Das Attribut METHOD gibt an, welches Schlüsselsystem verwendet werden soll. Heute unterstützen wir AES-128 und SAMPLE-AES.
#EXT-X-BYTERANGE Der Bytebereich, der für eine Segment-URL abgerufen werden soll.
#EXT-X-DISCONTINUITY Gibt einen Diskontinuitätsgrad zwischen aufeinanderfolgenden Segmenten an. Dies ist häufig bei der serverseitigen Anzeigenbereitstellung der Fall, bei der ein Anzeigensegment in der Mitte des Hauptstreams erscheint.
#EXT-X-PROGRAM-DATE-TIME Absolute Zeit der ersten Stichprobe des nächsten Segments, z. B. "2016-09-21T23:23:52.066Z".
#EXT-X-ENDLIST Ob es sich um einen VOD oder Livestream handelt.

Für Livestreams bestimmen wir anhand von #EXT-X-PROGRAM-DATE-TIME und #EXT-X-MEDIA-SEQUENCE, wie ein neu aktualisiertes Manifest zusammengeführt wird. Falls vorhanden, wird #EXT-X-PROGRAM-DATE-TIME verwendet, um die aktualisierten Segmente abzugleichen. Andernfalls wird die #EXT-X-MEDIA-SEQUENCE-Nummer verwendet. Gemäß der HLS-Spezifikation wird kein Dateinamenvergleich für den Abgleich verwendet.

Unsere HLS-Implementierung unterstützt die Auswahl eines alternativen Audiostreams, z. B. 5.1-Surround-Sound, als primäre Audiowiedergabe. Dazu können Sie ein #EXT-X-MEDIA-Tag mit den alternativen Codecs verwenden und in der Streamkonfiguration das Segmentformat angeben.

Der Web Receiver Player setzt ein bestimmtes Spezifikationsverhalten voraus. Nach einem #EXT-INF-Tag erwarten wir beispielsweise einen URI. Wenn es sich nicht um einen URI handelt (z. B. durch #EXT-X-DISCOUNTINUITY), schlägt das Parsen für die Playlist fehl.

Alle #EXT-X-TARGETDURATION Sekunden laden wir die Playlist bzw. das Manifest neu, um neue Segmentlisten abzurufen, und aktualisieren die neue interne Darstellung aller Segmente auf die neue. Jedes Mal, wenn eine Suche angefordert wird, suchen wir nur innerhalb des suchbaren Bereichs. Bei Livestreams ist nur eine Suche ab dem Anfang der neuesten Liste bis zu einer Dauer von drei Zielen vom Ende möglich. Wenn Sie also beispielsweise eine Liste mit 10 Segmenten haben und sich in Segment 6 befinden, können Sie nur bis 7, aber nicht 8 suchen.

Unterstützung von Segmentformaten

Das CAF SDK unterstützt die Wiedergabe von Inhalten, die in mehreren Formaten bereitgestellt werden, wie in HlsSegmentFormat für Audio und HlsVideoSegmentFormat für Videos angegeben. Dies umfasst die Unterstützung von gepackten Audioinhalten wie AAC- und AC3-Wiedergabe sowohl verschlüsselt als auch unverschlüsselt. Du musst diese Informationen im MediaInformation des LoadRequestData angeben, damit deine Inhalte für den Player richtig beschrieben werden können. Wenn nicht angegeben, versucht die Standard-Player-Konfiguration, den Inhalt als gepackten Transport Stream-Inhalt wiederzugeben. Dieses Attribut kann von einem der Absender in den Ladeanfragedaten (Android, iOS und Web) oder innerhalb des Empfängers durch Nachrichtenabfangen festgelegt werden.

Weitere Informationen zum Vorbereiten von Inhalten im Web Receiver finden Sie im folgenden Beispielcode-Snippet oder im Leitfaden Loading media using contentId, contentUrl and entity.

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 im Abschnitt #EXT-X-KEY oben aufgeführt, unterstützt das Cast SDK SAMPLE-AES oder SAMPLE-AES-CTR, wobei ein URI für den Schlüssel eines Initialisierungsvektors angegeben werden kann:

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

Das KEYFORMAT, das jetzt unterstützt wird, ist Widevine und der URI enthält eine BASE64-codierte DRM-Info XXXXXXX, die bei Decodierung die Schlüssel-ID enthält:

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

In Version 1 sind die folgenden Attribute definiert:

Attribut Beispiel Beschreibung
KEYFORMATVERSIONS "1" In diesem Vorschlag wird das Schlüsselformat Version 1 definiert.
KEYFORMAT "urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed" Die UUID ist die Widevine-UUID aus DASH IF IOP. In MPD-Dateien mit Widevine-verschlüsselten Streams wird genau derselbe String verwendet.
URI "data:text/plain;base64, <base64 encoded PSSH box>" URI des Streams, der den Datentyp und das PSSH-Feld enthält.
METHOD SAMPLE-AES-CTR Gibt die Verschlüsselungschiffre an, die beim Verschlüsseln des Inhalts verwendet wird. EXAMPLE-AES signalisiert, dass der Inhalt mit „cbcs“ verschlüsselt ist. SAMPLE-AES-CTR signalisiert, dass der Inhalt mit einem der AES-CTR-Schutzschemas, nämlich „cenc“, verschlüsselt wird.

Attribute, die der DASH-MPD zugeordnet sind:

Attribut Beschreibung
KEYFORMAT SchemaIdUri-Attribut des ContentProtection-Elements.
URI Der Inhalt des Elements cenc:pssh.
KEYID 16-Byte-Hexadezimalstring zur Codierung der Schlüssel-ID, die dieselbe Rolle wie „default_kid“ in MPEG DASH hat. Bei Verwendung eines hierarchischen Schlüsselschemas wäre dies der Stammschlüssel.

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

#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 der Funktionen und Tags in HLS, die derzeit weder verwendet noch unterstützt werden. Das Vorhandensein oder Fehlen dieser Elemente 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 auf 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 und #EXT-X-PLAYLIST-TYPE:VOD in einem VOD-Stream vorhanden sein. Derzeit wird unser Web Receiver Player jedoch nur auf das Vorhandensein von #EXT-X-ENDLIST angewiesen, um Live- und VOD-Inhalte zu bestimmen.

Zuverlässiges Streaming

Die offizielle Smooth Streaming-Spezifikation von Microsoft.

Smooth Streaming bietet ein adaptives Streamingprotokoll und eine XML-Spezifikation über HTTP (ähnlich wie DASH). Im Gegensatz zu DASH wird bei Smooth Streaming für Mediensegmente nur die MPEG-4-Paketerstellung empfohlen.

Hier ist eine Tabelle mit den gängigsten Tags und Attributen in Smooth Streaming, die derzeit vom Web Receiver Player unterstützt werden. Viele Konzepte wurden bereits oben im DASH-Abschnitt erläutert.

Tag/Attribut Nutzung
<SmoothStreamingMedia> Das Haupt-Tag für das Manifest enthält folgende Attribute:
  • TimeScale: Anzahl der Einheiten für eine Sekunde, in der Regel 10.000.000.
  • Dauer: Länge des Inhalts in der Zeitskala. Der Web Receiver Player unterstützt keine Zeitspannen unter 0,1 Sekunden.
  • IsLive: Gibt an, ob das Manifest ein Livemedium ist.
<StreamIndex> Ein Stream-Satz, ähnlich dem AdaptationSet von DASH. Der Typ ist normalerweise "Text", "Video" oder "Audio". Das URL-Attribut enthält normalerweise eine Vorlage für eine Fragment-URL mit Informationen wie Bitrate oder Startzeit.
<QualityLevel> Jedes QualityLevel-Tag gibt seine Bitrate und einen FourCC-Codec an. Der FourCC-Code lautet häufig „H264“, „AVC1“, „AACL“ usw. Bei Videos werden die Auflösungen über „MaxWidth“ und „MaxHeight“ angegeben. Für Audio wird die Frequenz (z. B. 44.100) über die Abtastrate und die Anzahl der Kanäle angegeben.
<c> Streamfragment-Element. Enthält:
  • d: Dauer eines Fragments
  • t: Medienzeit des Fragments.
<Schutz> Ein Tag mit dem optionalen SystemID-Attribut, das die ID der System-DRM auflistet, die unter dem <SmoothStreamingMedia>-Tag verwendet werden soll.
<ProtectionHeader> Unter <Protection> kann ein Attribut mit SystemID und benutzerdefinierten Daten, normalerweise Base64-codiert, enthalten sein. Für Widevine enthält sie die Schlüssel-ID, die Schlüssellänge, die Algorithmus-ID, z. B. AESCTR, die LA_URL (Lizenzerfassungs-URL), LUI_URL (URL der Benutzeroberfläche für die Lizenz) und DS_ID (Domaindienst-ID).

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 ein Beispiel für <ProtectionHeader> mit Base64-codierten Daten. Die decodierten Daten entsprechen demselben decodierten Format, das oben in der DASH-Inhaltsschutzunterstützung beschrieben wurde.

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

Im Folgenden findest du ein Beispiel für ein Smooth Streaming-Live-Manifest mit einer Inhaltsdauer von 3.000 Sekunden:

<?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 (vorausgesetzt, wir befinden uns auf der Qualitätsstufe von Index 2) sind also die folgenden, wobei die Anfangszeit aus t="80649401378125" unter dem Video StreamIndex und das Zeitintervall von 4 Sekunden * 10.000.000 pro Segment extrahiert wird:

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

Hier ist eine Liste der Smooth Streaming-Attribute, die wir derzeit ignorieren und die keine Auswirkungen auf Streaming-Erlebnisse haben, unabhängig davon, ob sie bereitgestellt werden:

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

Anzeigetyp prüfen

Die Methode canDisplayType prüft die Video- und Audiofunktionen des Webempfangsgeräts und der Anzeige, indem die übergebenen Medienparameter validiert und ein boolescher Wert zurückgegeben wird. Alle Parameter außer dem ersten sind optional. Je mehr Parameter Sie angeben, desto genauer ist die Prüfung.

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

Beispiele:

Überprüft, ob das Web-Receiver-Gerät und die Anzeige den Video-/MP4-MIME-Typ mit folgendem Codec, diesen Abmessungen und dieser Framerate unterstützen:

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

Überprüft, ob das Web Receiver-Gerät und das Display das 4K-Videoformat für diesen Codec unterstützen, indem die Breite von 3.840 und die Höhe von 2.160 angegeben werden:

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

Überprüft, ob das Web Receiver-Gerät und das Display HDR10 für diesen Codec, diese Abmessungen und diese Framerate unterstützen:

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

Überprüft, ob das Web-Receiver-Gerät und das Display Dolby Vision (DV) für diesen Codec, die Abmessungen und die Framerate unterstützen:

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

DRM

Für einige Medieninhalte ist eine digitale Rechteverwaltung (Digital Rights Management, DRM) erforderlich. Bei Medieninhalten, deren DRM-Lizenz und Schlüssel-URL im Manifest gespeichert sind (DASH oder HLS), übernimmt das Cast SDK diesen Fall. Für einen Teil dieses Inhalts ist ein licenseUrl erforderlich, das zum Abrufen des Entschlüsselungsschlüssels erforderlich ist. Im Web Receiver können Sie licenseUrl nach Bedarf mit PlaybackConfig festlegen.

Das folgende Code-Snippet zeigt, wie Sie Anfrageinformationen für Lizenzanfragen wie withCredentials festlegen können:

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 du Google Assistant integriert hast, können einige der DRM-Informationen wie die für die Inhalte erforderlichen Anmeldedaten über Mechanismen wie OAuth/SSO direkt mit deinem Google-Konto verknüpft sein. Wenn in diesen Fällen die Medieninhalte per Sprachbefehl geladen werden oder aus der Cloud stammen, wird ein setCredentials von der Cloud aus auf das Übertragungsgerät aufgerufen und stellt diese Anmeldedaten bereit. Anwendungen, die eine Web Receiver-App schreiben, können dann die setCredentials-Informationen verwenden, um die digitale Rechteverwaltung nach Bedarf auszuführen. Hier ist ein Beispiel für die Verwendung des Berechtigungsnachweises zum Erstellen des Mediums.

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

Umgang mit Audiokanälen

Wenn der Cast-Player Medien lädt, richtet er einen einzelnen Audioquellenpuffer ein. Gleichzeitig wird basierend auf dem MIME-Typ des primären Tracks auch ein entsprechender Codec ausgewählt, der vom Zwischenspeicher verwendet werden soll. Ein neuer Puffer und Codec werden eingerichtet:

  • wenn die Wiedergabe beginnt,
  • bei jeder Werbeunterbrechung und
  • wenn die Hauptinhalte fortgesetzt werden.

Da der Puffer einen einzelnen Codec verwendet und der Codec basierend auf dem primären Track ausgewählt wird, gibt es Situationen, in denen sekundäre Tracks herausgefiltert und nicht gehört werden. Dies kann passieren, wenn der primäre Track eines Medienprogramms in Surround-Sound ist, sekundäre Audiotracks aber Stereo-Sound verwenden. Da Inhalte in anderen Sprachen häufig auf sekundären Tracks angeboten werden, kann die Bereitstellung von Medien mit einer unterschiedlichen Anzahl von Titeln erhebliche Auswirkungen haben, z. B. wenn eine große Anzahl von Zuschauern Inhalte in ihrer Muttersprache nicht hören kann.

Die folgenden Szenarien verdeutlichen, warum es wichtig ist, Programmgestaltung anzubieten, bei der primäre und sekundäre Tracks die gleiche Anzahl von Kanälen enthalten:

Szenario 1 – Medienstream ohne Kanalparität zwischen primären und sekundären Tracks:

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

Wenn die Sprache des Players in diesem Szenario auf eine andere Sprache als Englisch eingestellt ist, hört der Nutzer den erwarteten Titel nicht, da alle zweikanaligen Titel während der Wiedergabe herausgefiltert werden. Der einzige Titel, der gespielt werden könnte, ist der primäre AC-3 5.1-Kanal und dann nur, wenn als Sprache Englisch eingestellt ist.

Szenario 2 – Medienstream mit Kanalparität zwischen primären und sekundären Tracks:

  • Deutsch – 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 Zuschauer den Titel unabhängig von der ausgewählten Sprache.

Umgang mit Shaka-Audiokanälen

Für den Shaka-Player (DASH) wird standardmäßig die Anzahl der bevorzugten Kanäle von zwei festgelegt. Dies dient als Maßnahme zur Risikominimierung, wenn Medien erkannt werden, die keine Gleichheit zwischen sekundären Audiospuren haben.

Wenn der primäre Titel kein Surround-Sound ist (z. B. eine zweikanalige Stereospur), verwendet der Shaka-Player standardmäßig zwei Kanäle und filtert automatisch alle sekundären Medienspuren mit mehr als zwei Kanälen heraus.

Shakas bevorzugte Anzahl von Audiokanälen kann auch konfiguriert werden, indem preferredAudioChannelCount im Attribut shakaConfig für cast.framework.PlaybackConfig festgelegt wird.

Beispiel:

shakaConfig = { "preferredAudioChannelCount": 6 };

Wenn preferredAudioChannelCount auf 6 gesetzt ist, prüft Shaka Player, ob der Surround-Sound-Codecs (AC-3 oder EC-3) unterstützt wird, und filtert automatisch alle Medienspuren heraus, die nicht der bevorzugten Anzahl von Kanälen entsprechen.