Streaming-Protokolle des Web Receivers

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

DASH, HTTP-Livestreaming und Smooth Streaming

In diesem Dokument wird die Unterstützung für jedes Streamingprotokoll aufgeführt. Die Erläuterung der unterstützten Tags für jedes Protokoll wird im Vergleich zur detaillierten Protokollspezifikation ziemlich abgekürzt. Das Ziel ist, einen kurzen Überblick darüber zu geben, wie die einzelnen Protokolle verwendet werden können und welche Funktionen des Protokolls auf Streaming-fähigen Geräten für das Streaming unterstützt werden.

Dynamisches adaptives Streaming über HTTP (DASH)

Detaillierte DASH-Spezifikation von ISO

DASH ist ein adaptives Bitrate-Streaming-Protokoll, das Videostreaming in hoher Qualität über HTTP(S)-Server ermöglicht. Ein Manifest in XML enthält die meisten Metadaten zum Initialisieren und Herunterladen des Videocontents. Die wichtigsten Konzepte, 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 mindestens ein <Period>-Tag, das einen Streaminginhalt repräsentiert. <Period>-Tags ermöglichen die Anordnung verschiedener Streaminginhalte und werden häufig verwendet, um Hauptinhalte und Werbung oder mehrere aufeinanderfolgende Videoinhalte voneinander zu trennen.

Eine <AdaptationSet> unter <MPD> besteht aus einer Reihe von Darstellungen für einen Medienstream, in den meisten Fällen Video, Audio oder Untertitel. Die gängigsten MIME-Typen sind „video/mp4“, „audio/mp4“ und „text/vtt“. Unter <AdaptationSet> kann ein optionaler <ContentComponent contentType="$TYPE$"> eingefügt werden.

In jeder <AdaptationSet> sollte eine Liste von <Representation>-Tags vorhanden sein. Der Web Receiver Player verwendet die codecs-Informationen zum Initialisieren des MSE-Quellpuffers und die bandwidth-Informationen zur automatischen Auswahl der richtigen Darstellung/Bitrate.

Für jede <Representation> werden Mediensegmente entweder mit <BaseURL> für die Darstellung einzelner Segmente, mit <SegmentList> für eine Liste von Segmenten (ähnlich HLS) oder mit <SegmentTemplate> beschrieben.

Für <SegmentTemplate> gibt es an, wie das Initialisierungssegment und Mediensegmente durch Vorlagen dargestellt werden können. Im Beispiel unten steht $Number$ für die im CDN verfügbare Segmentnummer. Die Datei wird also im Verlauf der Wiedergabe in seg1.m4s, seg2.m4s usw. umgewandelt.

<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 mit dem Tag <SegmentTimeline> angegeben, wie lang jedes Segment ist und welche Segmente sich wiederholen. Ein timescale (Einheiten, die eine Sekunde darstellen) ist oft als Teil der Attribute von <SegmentTemplate> enthalten, damit wir die Zeit des Segments auf der Grundlage dieser Einheit berechnen können. Im folgenden Beispiel gibt das <S>-Tag ein Segment-Tag an, das d-Attribut gibt die Länge des Segments an und das r-Attribut gibt an, wie viele Segmente mit derselben Dauer sich wiederholen, damit $Time$ für das Herunterladen des Mediensegments wie im media-Attribut angegeben korrekt 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 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 ein <SegmentBase> häufig mit Bytebereichsanfragen verwendet, um anzugeben, welcher Teil einer <BaseURL>-Datei den Index enthält. Der Rest kann bei Bedarf abgerufen werden, wenn die Wiedergabe fortgesetzt wird oder eine Suche stattfindet. Hier gibt der Bereich Initialization den Metadaten- Initialisierungsbereich und der indexRange den Index für die Mediensegmente an. Hinweis: Derzeit werden nur aufeinanderfolgende Bytebereiche unterstützt.

<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, wenn geschützte Streams geschützt sind, ein <ContentProtection>Abschnitt unter <AdaptationSet> angezeigt werden, in dem 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. Nachstehend finden Sie eine Liste der zusätzlichen DASH-Attribute für Tags, die oben nicht aufgeführt sind und die wir derzeit unterstützen:

Attributname Attributfunktion
mediaPresentationDuration Die Dauer des Videocontents
min.UpdatePeriod Attribut des <MPD>-Tags. Gibt an, wie oft das Manifest neu geladen werden muss.
Typ Attribut des Tags <MPD>. „dynamisch“ bedeutet, dass dies ein Livestream ist.
PräsentationszeitOffset Attribut des Tags <SegmentBase>. Gibt den Zeitunterschied zur Darstellung vom Beginn des Zeitraums an.
startNumber (Startnummer) Gibt die Nummer des ersten Mediensegments in einer Präsentation in einem Zeitraum an. Dies wird oft im Livestream verwendet.

Wir unterstützen auch die Erkennung von EMSG-Box in MP4-Fragmenten für DASH und stellen Entwicklern eine EmsgEvent bereit.

Während unser aktueller Web Receiver-Player die wichtigsten DASH-Anwendungsfälle unterstützt, finden Sie hier eine Liste häufig verwendeter Attribute, die von unserer aktuellen DASH-Implementierung ignoriert oder nicht verwendet werden. Das bedeutet, dass sie unabhängig davon, ob sie im Manifest enthalten sind, keinen Einfluss auf die Wiedergabe der Inhalte haben.

  • VerfügbarkeitStartTime
  • Segmentausrichtung

HTTP Live Streaming (HLS)

Die Übersicht und die vollständige Spezifikation des HTTP-Livestreamings finden Sie hier.

Eine der wichtigsten Stärken des Web Receiver-Players ist die Unterstützung der Wiedergabe von HLS in MSE. Im Gegensatz zum DASH, bei dem ein Manifest in einer einzigen 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 wichtigsten HLS-Tags, die der Web Receiver-Player derzeit in der Masterplaylist unterstützt, sind:

Tag-Name Funktionen
#EXT-X-STREAM-INF. Gibt einen Bitraten-/Variantenstream an. Das Attribut BANDWIDTH ist erforderlich, um die Auswahl für das Streaming mit adaptiver Bitrate zu unterstützen. Das Attribut CODECS wird für die Initialisierung von MSE dringend empfohlen, z. B. "avc1.42c01e,mp4a.40.2". Wenn keine Angabe erfolgt, wird die Standardeinstellung für H264-Hauptprofil 3.0-Video und "mp4a.40.2" audiocodierte Inhalte festgelegt.
#EXT X-MEDIA Gibt zusätzliche Medienplaylist (im Attribut URI) für den Inhalt an. Dies sind in der Regel alternative Audiostreams in einem anderen Format (5.1-Surround-Sound) oder in einer anderen Sprache. Ein Attribut von TYPE, das entweder VIDEO, AUDIO, SUBTITLES oder CLOSED-CAPTIONS enthält, ist zulässig. Wenn du das Attribut DEFAULT auf YES setzt, wird dieser alternative Stream standardmäßig ausgewählt.

Hier ist eine Liste von 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 in der nächsten Zeile die URL des Segments.
#EXT-X-TARGETDURATION Die Dauer in Sekunden pro Segment. Damit wird auch festgelegt, wie oft das Playlist-Manifest für einen Livestream heruntergeladen/aktualisiert wird. Der Web Receiver-Player unterstützt keine kürzeren Zeiträume.
#EXT-X-MEDIA-SEQUENCE Die Sequenznummer (häufig für einen Livestream), die das erste Segment in dieser Playlist darstellt.
#EXT-X-SCHLÜSSEL DRM-Schlüsselinformationen. 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 eine Diskontinuität zwischen aufeinanderfolgenden Segmenten an. Dies ist häufig bei der serverseitigen Anzeigenbereitstellung zu sehen, bei der ein Anzeigensegment in der Mitte des Hauptstreams erscheint.
#EXT-X-PROGRAMM-DATE-TIME Absolute Zeit der ersten Stichprobe des nächsten Segments, z. B. „2016-09-21T23:23:52.066Z“.
#EXT-X-ENDLISTE Ob es sich um einen VOD- oder Livestream handelt.

Für Livestreams verwenden wir #EXT-X-PROGRAM-DATE-TIME und #EXT-X-MEDIA-SEQUENCE als wichtige Faktoren, um zu bestimmen, wie ein neu aktualisiertes Manifest zusammengeführt werden soll. Wenn 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 verwenden wir für den Abgleich keinen Dateinamenvergleich.

Unsere HLS-Implementierung unterstützt die Auswahl eines alternativen Audiostreams wie 5.1-Surround-Sound als Hauptaudiowiedergabe. 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 erwartet ein bestimmtes Spezifikationsverhalten. Nach einem #EXT-INF-Tag wird beispielsweise ein URI erwartet. Wenn es sich nicht um einen URI handelt, führt ein #EXT-X-DISCOUNTINUITY beispielsweise dazu, dass das Parsing für die Playlist fehlschlägt.

Alle #EXT-X-TARGETDURATION Sekunden wird die Playlist bzw. das Manifest aktualisiert, um neue Segmentlisten zu erhalten. Außerdem wird die neue interne Darstellung aller Segmente auf das neue Segment aktualisiert. Jedes Mal, wenn eine Suche angefordert wird, suchen wir nur innerhalb des durchsuchbaren Bereichs. Bei Livestreams dürfen Sie nur vom Anfang der neuesten Liste bis zu einer drei Zieldauer vom Ende aus suchen. Wenn Sie beispielsweise eine Liste mit 10 Segmenten haben und sich in Segment 6 befinden, können Sie nur bis zu 7, aber nicht 8 suchen.

Unterstützung für Segmentformate

Das CAF SDK unterstützt die Wiedergabe von Inhalten, die in mehreren Formaten bereitgestellt werden. Eine Beschreibung finden Sie unter HlsSegmentFormat für Audio und HlsVideoSegmentFormat für Videos. Dies umfasst die Unterstützung verschlüsselter Audiodateien wie AAC- und AC3-Wiedergabe, sowohl verschlüsselt als auch unverschlüsselt. Es ist erforderlich, dass du diese Informationen in den MediaInformation des LoadRequestData angibst, um dem Player deine Inhalte ordnungsgemäß zu beschreiben. Wenn diese nicht angegeben ist, versucht die Standard-Player-Konfiguration, die Inhalte als verpackte Transport Stream-Inhalte wiederzugeben. Dieses Attribut kann von allen Absendern in den Ladeanfragedaten (Android, iOS und Web) oder innerhalb des Empfängers über Nachrichtenabfangen festgelegt werden.

Weitere Informationen zur Vorbereitung von Inhalten auf dem Web Receiver finden Sie im Beispielcode-Snippet unten oder im Leitfaden Medien mit contentId, contentUrl und Entity laden.

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-Tag oben aufgeführt, unterstützt das Cast SDK SAMPLE-AES oder SAMPLE-AES-CTR, wobei ein URI zum Schlüssel ein Initialisierungsvektor angegeben werden kann:

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

KEYFORMAT wird jetzt von Widevine unterstützt. Der URI enthält die BASE64-codierten DRM-Informationen XXXXXXX. Diese entschlüsselt die Schlüssel-ID:

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

In Version 1 werden die folgenden Attribute definiert:

Attribut Beispiel Beschreibung
KEYFORMATVERSIONS "1" Dieses Angebot definiert die Schlüsselformatversion 1.
KEYFORMAT "urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed" Die UUID ist die Widevine-UUID von DASH IF IOP. Derselbe String wird auch in MPD-Dateien mit Widevine-verschlüsselten Streams 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üsselungsverschlüsselung an, die beim Verschlüsseln des Inhalts verwendet wird. SAMPLE-AES signalisiert, dass der Inhalt mit „cbcs“ verschlüsselt ist. SAMPLE-AES-CTR signalisiert, dass der Inhalt mit einem der AES-CTR-Schutzschemas verschlüsselt ist, nämlich „cenc“.

Attribute, die DASH-MPD zugeordnet sind:

Attribut Beschreibung
KEYFORMAT Das SchemaIdUri-Attribut des ContentProtection-Elements.
URI Der Inhalt des Elements „cenc:pssh“.
KEYID 16-Byte-Hexadezimalstring, der die Schlüssel-ID codiert, die dieselbe Rolle wie das Standard-Kid in MPEG-DASH hat. Wenn Sie ein hierarchisches Schlüsselschema verwenden, ist dies der Schlüssel „root“.

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

Im Folgenden finden Sie eine Liste der Features und Tags in HLS, die wir derzeit nicht verwenden oder nicht unterstützen. Ihr Vorhandensein oder ihr 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 nutzen wir DEFAULT=
  • #EXT-X-I-FRAME-STREAM-INF wird in der Masterplaylist 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 enthalten sein. Aktuell nutzt der Web Receiver aber nur #EXT-X-ENDLIST, um Live- oder VOD-Streams zu ermitteln.

Smooth Streaming

Die offizielle Smooth Streaming-Spezifikation von Microsoft.

Smooth Streaming bietet ein adaptives Streamingprotokoll und eine XML-Spezifikation über HTTP (ähnlich wie DASH). Anders als bei DASH empfiehlt Smooth Streaming für die Mediensegmente nur die MPEG-4-Paketerstellung.

Im Folgenden findest du eine Tabelle mit den gängigsten Tags und Attributen in Smooth Streaming, die der Web Receiver-Player derzeit unterstützt. Viele Konzepte werden bereits im Abschnitt „DASH“ oben erläutert.

Tag/Attribut Nutzung
<SmoothStreamingMedia> Haupt-Tag für das Manifest mit folgenden Attributen:
  • 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 Dauer von weniger als 0,1 Sekunden.
  • IsLive: Gibt an, ob das Manifest live ist.
<StreamIndex> Ein Stream-Satz, ähnlich wie das AdaptationSet von DASH. Der Typ ist in der Regel „Text“, „Video“ oder „Audio“. Das URL-Attribut enthält normalerweise eine Fragment-URL-Vorlage mit Informationen wie Bitrate oder Startzeit.
<Qualitätsstufe> Jedes QualityLevel-Tag gibt seine Bitrate und einen FourCC-Codec an. Häufig lautet der FourCC-Code „H264“, „AVC1“, „AACL“ usw. Bei Videos werden die Auflösungen über „MaxWidth“ und „MaxHeight“ angegeben. Für Audio wird die Frequenz (z. B. 44100) über die Abtastrate und die Anzahl der Kanäle angegeben.
<c> Element des Streamfragments. Enthält:
  • d: Dauer eines Fragments.
  • t: Medienzeit des Fragments.
<Schutz> Ein Tag mit dem optionalen SystemID-Attribut, das die ID des System-DRM enthält, das unter dem Tag <SmoothStreamingMedia> verwendet werden soll.
<ProtectionHeader> Unter <Protection> kann das Attribut von System-ID und benutzerdefinierten Daten enthalten sein, normalerweise Base64-codiert. 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 (Lizenzbenutzeroberflächen-URL) 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 dem decodierten Format, das oben in der DASH-Inhaltsschutzunterstützung beschrieben wurde.

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

Hier ein Beispiel für ein Smooth-Streaming-Manifest mit einer Dauer 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 Beispiel oben 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 2) haben die folgenden Werte, wobei die Anfangszeit aus t="80649401378125" unter dem Video StreamIndex und die Inkrementierung von 4 Sekunden * 10000000 pro Segment ermittelt werden:

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

Im Folgenden finden Sie eine Liste der Smooth Streaming-Attribute, die wir derzeit ignorieren und keine Auswirkungen auf die Streamingerfahrung haben, unabhängig davon, ob sie bereitgestellt werden:

  • CanSeek, CanPause im Tag <SmoothStreamingMedia>.
  • Chunks, QualityLevels im Tag <StreamIndex>. Stattdessen wird die Anzahl der Segmente und die Qualitätsstufen anhand der Informationen in <StreamIndex> berechnet, z. B. 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 Web Receiver-Geräts und zeigt sie an. Dazu werden die übergebenen Medienparameter validiert und ein boolescher Wert zurückgegeben. Alle Parameter bis auf die ersten sind optional. Je mehr Parameter Sie angeben, desto genauer wird die Prüfung.

Ihre Signatur ist canDisplayType(<em>mimeType</em>,<em>codecs</em>,<em>width</em>,<em>height</em>,<em>framerate</em>)

Beispiele:

Prüft, ob das Web Receiver-Gerät und das Display den Video-/MP4-MIME-Typ mit diesem bestimmten 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 4K-Videoformate für diesen Codec unterstützen. Dazu wird die Breite von 3.840 und eine Höhe von 2.160 angegeben:

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, die Abmessungen und die Framerate unterstützt:

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

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

Hinweis: Einer der Hauptvorteile der Verwendung des Web Receiver SDK ist, dass deine App MPL nicht mehr separat laden und die Medienwiedergabe separat verwalten muss.

Für einige Medieninhalte ist die digitale Rechteverwaltung (Digital Rights Management, DRM) erforderlich. Bei Medieninhalten, in deren Manifest (DASH oder HLS) die DRM-Lizenz und die Schlüssel-URL gespeichert sind, übernimmt das Cast SDK dies für Sie. Für einen Teil dieses Inhalts ist ein licenseUrl erforderlich, der zum Abrufen des Entschlüsselungsschlüssels erforderlich ist. Im Webempfänger können Sie PlaybackConfig verwenden, um den licenseUrl nach Bedarf festzulegen.

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 Sie eine Google Assistant-Integration haben, können einige DRM-Informationen wie die für den Inhalt erforderlichen Anmeldedaten direkt über Mechanismen wie OAuth/SSO mit Ihrem Google-Konto verknüpft werden. Wenn die Medieninhalte in diesen Fällen per Sprachbefehl geladen werden oder aus der Cloud stammen, wird ein setCredentials aus der Cloud an das Cast-Gerät aufgerufen, das diese Anmeldedaten bereitstellt. Anwendungen, die eine Web Receiver-App schreiben, können dann die setCredentials-Informationen verwenden, um DRM nach Bedarf auszuführen. Hier ein Beispiel für die Verwendung der Anmeldedaten zum Erstellen der Medien.

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

Umgang mit Audiokanälen

Wenn der Cast-Player Medien lädt, wird ein einzelner Audioquellenpuffer eingerichtet. Gleichzeitig wird anhand des MIME-Typs des primären Tracks der geeignete Codec für die Verwendung durch den Zwischenspeicher ausgewählt. Ein neuer Puffer und ein neuer Codec sind eingerichtet:

  • wenn die Wiedergabe beginnt,
  • in jeder Werbeunterbrechung
  • wenn der Hauptinhalt fortgesetzt wird.

Da der Puffer einen einzelnen Codec verwendet und auf der Grundlage des primären Tracks ausgewählt wird, kann es vorkommen, dass sekundäre Tracks herausgefiltert und nicht gehört werden. Das kann passieren, wenn der primäre Titel eines Medienprogramms Surround-Sound ist, aber sekundäre Audiotracks Stereo-Sound verwenden. Da sekundäre Titel häufig verwendet werden, um Inhalte in verschiedenen Sprachen anzubieten, kann die Bereitstellung von Medien mit unterschiedlicher Anzahl von Titeln erhebliche Auswirkungen haben, z. B. dass viele Zuschauer Inhalte in ihrer Muttersprache nicht hören können.

Die folgenden Szenarien veranschaulichen, warum es wichtig ist, eine Programmgestaltung bereitzustellen, bei der primäre und sekundäre Tracks dieselbe Anzahl an Kanälen enthalten:

Szenario 1 – Medienstream ohne gleichwertige Kanäle für primäre und sekundäre Titel:

  • english - AC-3 5.1 channel (primary)
  • Schwedisch - AAC 2-Kanal
  • Französisch – AAC 2-Kanal
  • Deutsch – AAC 2-Kanal

Wenn die Sprache des Players auf eine andere Sprache als Englisch eingestellt ist, hört der Nutzer nicht den erwarteten Titel, da alle zweikanaligen Tracks während der Wiedergabe herausgefiltert werden. Der einzige Titel, der abgespielt werden kann, ist der primäre AC-3-5.1-Kanal. Erst wenn die Sprache auf Englisch eingestellt wird,

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

  • english - AC-3 5.1 channel (primary)
  • 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 dieselbe Anzahl an Kanälen haben, wird ein Titel unabhängig von der ausgewählten Sprache abgespielt.

Umgang mit Shaka-Audiokanälen

Der Shaka-Player (DASH) verwendet standardmäßig eine bevorzugte Kanalanzahl von zwei, um das Problem zu beheben, wenn Medien erkannt werden, die in den sekundären Audiotracks nicht einheitlich sind.

Wenn der primäre Track kein Surround-Sound ist (z. B. ein Stereokanal mit zwei Kanälen), wird im Shaka-Player standardmäßig zwei Kanäle verwendet. Alle sekundären Medien-Tracks mit mehr als zwei Kanälen werden automatisch herausgefiltert.

Shakas bevorzugte Anzahl von Audiokanälen kann auch konfiguriert werden. Dazu wird preferredAudioChannelCount im Attribut shakaConfig von cast.framework.PlaybackConfig festgelegt.

Beispiel:

shakaConfig = { "preferredAudioChannelCount": 6 };

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