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:
Attributname | Attributfunktion |
---|---|
mediaPresentationDuration | Die Länge des Videoinhalts. |
minimumUpdatePeriod | Attribut des <MPD> -Tags; gibt an, wie oft wir
um das Manifest neu zu laden. |
Typ | Attribut des <MPD> -Tags; „dynamisch“ um anzuzeigen, dass
Das ist ein Livestream. |
presentationTimeOffset | Attribut des <SegmentBase> -Tags; gibt die
Zeitversatz der Präsentation am Anfang des Zeitraums. |
startNumber | Gibt die Nummer des ersten Mediensegments in einer Präsentation in einem Punkt. Dies wird häufig bei Livestreams verwendet. |
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:
Tag-Name | Funktionen |
---|---|
#EXT-X-STREAM-INF | Gibt einen Bitrate-/Variantenstream an. Das Attribut BANDWIDTH ist
erforderlich, das adaptive Bitraten-Streaming-Auswahl unterstützt. Die
Das Attribut CODECS wird für die Initialisierung von MSE dringend empfohlen, z. B.
als "avc1.42c01e,mp4a.40.2" . Wenn keine Angabe erfolgt, wird die standardmäßige Groß- und Kleinschreibung verwendet.
auf H264-Hauptprofil 3.0-Video und "mp4a.40.2" -Audio codiert festgelegt
Inhalte. |
#EXT-X-MEDIA | Gibt im Attribut URI zusätzliche Medienplaylist an, die
für den Inhalt steht. Das sind normalerweise alternative Audiostreams in anderen
Format (5.1-Surround-Sound) oder Sprache. Ein Attribut von TYPE
die entweder VIDEO , AUDIO ,
SUBTITLES oder CLOSED-CAPTIONS sind zulässig. Einstellung
Das Attribut DEFAULT auf YES zeigt an, dass Sie
in diesem alternativen Stream. |
Hier ist eine Liste der HLS-Tags, die der Web Receiver Player derzeit in der Medienplaylist:
Tag-Name | Funktionen |
---|---|
#EXTINF | Streaminformationen, gefolgt von der Dauer des Segments Sekunden und in der nächsten Zeile die URL des Segments. |
#EXT-X-TARGETDURATION | Die Länge in Sekunden jedes Segments. Dadurch wird auch festgelegt, Playlist-Manifest für einen Livestream herunterladen/aktualisieren Web Receiver Der Player unterstützt keine Videolängen unter 0,1 Sek. |
#EXT-X-MEDIA-SEQUENCE | Die Sequenznummer (häufig bei Livestreams), die das erste Segment in die diese Playlist repräsentiert. |
#EXT-X-KEY | Wichtige Informationen zur digitalen Rechteverwaltung Das Attribut METHOD gibt an,
zu verwenden. Heute unterstützen wir AES-128 und SAMPLE-AES
. |
#EXT-X-BYTERANGE | Byte-Bereich, der für eine Segment-URL abgerufen werden soll |
#EXT-X-DISCONTINUITY | Gibt eine Diskontinuität zwischen aufeinanderfolgenden Segmenten an. Das kommt häufig vor, mit serverseitiger Anzeigenbereitstellung, bei der ein Anzeigensegment in der Mitte des Hauptstream. |
#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 ein VOD oder einen Livestream handelt |
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:
Attribut | Beispiel | Beschreibung |
---|---|---|
KEYFORMATVERSIONS |
"1" |
In diesem Angebot wird Version 1 des Schlüsselversionsformats definiert |
KEYFORMAT |
"urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed" |
Die UUID ist die Widevine-UUID aus DASH IF IOP. Derselbe String wird in MPD mit 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 bei der Verschlüsselung des Inhalts verwendete Verschlüsselungschiffre an. Mit SAMPLE-AES wird signalisiert, dass der Inhalt mit „cbcs“ verschlüsselt wird. Mit SAMPLE-AES-CTR wird angegeben, dass der Inhalt mit einem der AES-CTR-Schutzschemas verschlüsselt wird, nämlich „cenc“. |
Der DASH-MPD zugeordnete Attribute:
Attribut | Beschreibung |
---|---|
KEYFORMAT |
Das SchemaIdUri-Attribut des ContentProtection-Elements. |
URI |
Der Inhalt des Elements „cenc:pssh“. |
KEYID |
Hexadezimalwert mit 16 Byte für die Schlüssel-ID, die dieselbe Rolle wie „default_kid“ in MPEG DASH hat. Bei Verwendung eines hierarchischen Schlüsselschemas wäre dies das Stammschema. . |
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 unsDEFAULT=
#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.
Tag/Attribut | Nutzung |
---|---|
<SmoothStreamingMedia> | Das Haupt-Tag für das Manifest enthält folgende Attribute:
<ph type="x-smartling-placeholder">
|
<StreamIndex> | Ein Stream-Satz, ähnlich wie AdaptationSet von DASH. Der Typ ist normalerweise „Text“, „Video“ oder „Audio“. Das URL-Attribut enthält normalerweise eine Fragment-URL mithilfe von Informationen wie Bitrate oder Startzeit. |
<QualityLevel> | Jedes QualityLevel-Tag gibt seine Bitrate und einen FourCC-Codec an. The FourCC häufig „H264“, „AVC1“, „AACL“ usw. Auflösungen über MaxWidth und MaxHeight ändern. Für Audio gibt er seine Häufigkeit (z. B. 44100) anhand von Abtastrate und Anzahl der Channels. |
<c> | Stream-Fragment-Element. Enthält:
<ph type="x-smartling-placeholder">
|
<Protection> | Ein Tag mit dem optionalen SystemID-Attribut, das die ID des Systems auflistet DRM zur Verwendung unter <SmoothStreamingMedia> Tag. |
<ProtectionHeader> | Unter <Protection> kann das Attribut „SystemID“ und „Benutzerdefiniert“ enthalten sein. normalerweise Base64-codiert. Für Widevine enthält er die Schlüssel-ID, den Schlüssel Länge, die Algorithmus-ID, z. B. AESCTR, die LA_URL (License Acquisition URL), LUI_URL (URL der Lizenzbenutzeroberfläche) und DS_ID (Domain-Service-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 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ächlichenQualityLevel
-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.