Terminologie und Entitätsänderungen zwischen Media Services V2 und V3
Wichtig
Es ist nicht mehr erforderlich, von Azure Media Service v2 zu v3 zu migrieren, da die V2-API veraltet ist, mit der Einstellung von Azure Media Services übereinstimmt. Weitere Informationen finden Sie im Azure Media Services-Einstellungsleitfaden.
In diesem Artikel werden die Terminologieunterschiede zwischen Azure Media Services v2 und v3 beschrieben.
Terminologieänderungen
- Ein Locator- wird jetzt als Streaming Locator-bezeichnet.
- Ein Channel- wird jetzt als Live Event-bezeichnet.
- Ein Programm- wird jetzt als Live Outputbezeichnet.
- Ein Task- wird jetzt als JobOutput-bezeichnet, der Teil eines Auftrags ist.
Entitätsänderungen
V2-Entitäts- | V3 Entity | Anleitungen | Barrierefrei für V3- | aktualisiert von V3 |
---|---|---|---|---|
AccessPolicy |
Die Entität AccessPolicies ist in V3 nicht vorhanden. |
Nein | Nein | |
Asset |
Asset |
Ja | Ja | |
AssetDeliveryPolicy |
StreamingPolicy |
Ja | Nein | |
AssetFile |
Die Entität AssetFiles ist in V3 nicht vorhanden. Obwohl Dateien (Speicher-Blobs), die Sie hochladen, weiterhin als Dateien betrachtet werden.Verwenden Sie die Azure Storage-APIs, um stattdessen die Blobs in einem Container aufzählen zu können. Es gibt zwei Möglichkeiten, eine Transformation auf die Dateien mit einem Auftrag anzuwenden: Dateien, die bereits in den Speicher hochgeladen wurden: Der URI enthält die Objekt-ID, damit Aufträge für Ressourcen innerhalb eines Speicherkontos ausgeführt werden können. Dateien, die während des Transformations- und Auftragsvorgangs hochgeladen werden sollen: Die Ressource wird im Speicher erstellt, eine SAS-URL wird zurückgegeben, Dateien werden in den Speicher hochgeladen, und dann wird die Transformation auf die Dateien angewendet. |
Nein | Nein | |
Channel |
LiveEvent |
Liveereignisse ersetzen Kanäle aus der v2-API. Sie übernehmen die meisten Features und verfügen über weitere neue Features wie Livetranskriptionen, Stand-by-Modus und Unterstützung für RTMPS-Aufnahme. Anzeigen Liveereignisses im szenariobasierten Livestreaming- |
Nein | Nein |
ContentKey |
ContentKeys keine Entität mehr ist, ist sie jetzt eine Eigenschaft eines Streaminglocators.In v3 sind die Inhaltsschlüsseldaten entweder dem StreamingLocator (für die Ausgabeverschlüsselung) oder dem Objekt selbst (für die clientseitige Speicherverschlüsselung) zugeordnet. |
Ja | Nein | |
ContentKeyAuthorizationPolicy |
ContentKeyPolicy |
Ja | Nein | |
ContentKeyAuthorizationPolicyOption
|
ContentKeyPolicyOptions sind im ContentKeyPolicy enthalten. |
Ja | Nein | |
IngestManifest |
Die Entität IngestManifests ist in V3 nicht vorhanden. Das Hochladen von Dateien in V3 umfasst die Azure-Speicher-API. Objekte werden zuerst erstellt und dann dateien in den zugehörigen Speichercontainer hochgeladen. Es gibt viele Möglichkeiten zum Abrufen von Daten in einen Azure Storage-Container, der stattdessen verwendet werden kann.
JobInputHttp bietet auch eine Möglichkeit, bei Bedarf eine Auftragseingabe aus einer bestimmten URL herunterzuladen. |
Nein | Nein | |
IngestManifestAsset |
Es gibt viele Möglichkeiten zum Abrufen von Daten in einen Azure Storage-Container, der stattdessen verwendet werden kann.
JobInputHttp bietet auch eine Möglichkeit, bei Bedarf eine Auftragseingabe aus einer bestimmten URL herunterzuladen. |
Nein | Nein | |
IngestManifestFile |
Es gibt viele Möglichkeiten zum Abrufen von Daten in einen Azure Storage-Container, der stattdessen verwendet werden kann.
JobInputHttp bietet auch eine Möglichkeit, bei Bedarf eine Auftragseingabe aus einer bestimmten URL herunterzuladen. |
Nein | Nein | |
Job |
Job |
Erstellen Sie eine Transform , bevor Sie eine Job erstellen. |
Nein | Nein |
JobTemplate |
Transform |
Verwenden Sie stattdessen eine Transform . Eine Transformation ist eine separate Entität von einem Auftrag und kann wiederverwendet werden. |
Nein | Nein |
Locator |
StreamingLocator |
Ja | Nein | |
MediaProcessor |
Anstatt die MediaProcessor nach Namen zu suchen, verwenden Sie beim Definieren einer Transformation die gewünschte Voreinstellung. Die verwendete Voreinstellung bestimmt den vom Auftragssystem verwendeten Medienprozessor. Siehe Codierungsthemen in szenariobasierten Codierungs-. |
Nein | NA (schreibgeschützt in V2) | |
NotificationEndPoint |
Benachrichtigungen in v3 werden über Azure Event Grid behandelt. Die NotificationEndpoint wird durch die Registrierung des Ereignisrasterabonnements ersetzt, die auch die Konfiguration für die empfangenden Benachrichtigungstypen kapselt (die in v2 vom JobNotificationSubscription des Auftrags, der TaskNotificationSubscription der Aufgabe und der Telemetrie-ComponentMonitoringSetting behandelt wurde). Die v2-Telemetrie wurde zwischen Azure Event Grid und Azure Monitor aufgeteilt, um in die Verbesserungen des größeren Azure-Ökosystems einzupassen. |
Nein | Nein | |
Program |
LiveOutput |
Live-Ausgaben ersetzen jetzt Programme in der v3-API. | Nein | Nein |
StreamingEndpoint |
StreamingEndpoint |
Streamingendpunkte bleiben in erster Linie gleich. Sie werden für dynamische Verpackungen, Verschlüsselung und Übermittlung von HLS- und DASH-Inhalten sowohl für Live- als auch on-Demand-Streaming entweder direkt vom Ursprung oder über das CDN verwendet. Zu den neuen Features gehören Unterstützung für eine bessere Integration und Diagrammerstellung in Azure Monitor. | Ja | Ja |
Task |
JobOutput |
Ersetzt durch JobOutput (die keine separate Entität mehr in der API ist). Siehe Codierungsthemen in szenariobasierten Codierungs-. |
Nein | Nein |
TaskTemplate |
TransformOutput |
Ersetzt durch TransformOutput (die keine separate Entität mehr in der API ist). Siehe Codierungsthemen in szenariobasierten Codierungs-. |
Nein | Nein |
Inputs |
Inputs |
Eingaben und Ausgaben befinden sich jetzt auf Auftragsebene. Siehe Codierungsthemen in szenariobasierten Codierungs- | Nein | Nein |
Outputs |
Outputs |
Eingaben und Ausgaben befinden sich jetzt auf Auftragsebene. In V3 wurde das Metadatenformat von XML zu JSON geändert. Live-Ausgaben beginnen beim Erstellen und Beenden beim Löschen. Siehe Codierungsthemen in szenariobasierten Codierungs- | Nein | Nein |
Andere Änderungen | V2- | V3- |
---|---|---|
Speicher | Die V3-SDKs werden jetzt vom Storage SDK entkoppelt. Dadurch erhalten Sie mehr Kontrolle über die Version des Storage SDK, die Sie verwenden möchten, und vermeiden Sie Versionsverwaltungsprobleme. | |
Codierung | ||
Codieren von Bitraten | Bitraten in KBit/s ab: 128 (KBit/s) | Bits pro Sekunde ex: 128000 (Bits/Sekunde) |
Codieren von DRM FairPlay- | In Media Services V2 kann der Initialisierungsvektor (IV) angegeben werden. | In Media Services V3 kann die FairPlay IV nicht angegeben werden. |
Premium-Encoder | Premium-Encoder und Legacyindexer | Auf die Premium Encoder und die älteren Media Analytics-Prozessoren (Azure Media Services Indexer 2 Preview, Face Redactor usw.) kann nicht über V3 zugegriffen werden. Wir haben Unterstützung für die Audiokanalzuordnung zum Standard-Encoder hinzugefügt. Siehe Audio in der Media Services Encoding Swagger-Dokumentation. Siehe Codierungsthemen in szenariobasierten Codierungs- |
Transformationen und Aufträge | ||
Auftragsbasierte Verarbeitung von HTTPS- | Für die dateibasierte Auftragsverarbeitung können Sie eine HTTPS-URL als Eingabe verwenden. Sie müssen inhalte nicht bereits in Azure gespeichert haben, noch müssen Sie Ressourcen erstellen. | |
ARM-Vorlagen für Aufträge | ARM-Vorlagen waren in V2 nicht vorhanden. | Eine Transformation kann verwendet werden, um wiederverwendbare Konfigurationen zu erstellen, Azure Resource Manager-Vorlagen zu erstellen und Verarbeitungseinstellungen zwischen mehreren Kunden oder Mandanten zu isolieren. |
Liveereignisse | ||
Streamingendpunkt | Ein Streamingendpunkt stellt einen Streamingdienst dar, der Inhalte direkt an eine Clientplayeranwendung oder an ein Content Delivery Network (CDN) zur weiteren Verteilung liefern kann. | Streamingendpunkte bleiben in erster Linie gleich. Sie werden für dynamische Verpackungen, Verschlüsselung und Übermittlung von HLS- und DASH-Inhalten sowohl für Live- als auch on-Demand-Streaming entweder direkt vom Ursprung oder über das CDN verwendet. Zu den neuen Features gehören Unterstützung für eine bessere Integration und Diagrammerstellung in Azure Monitor. |
Liveereigniskanäle | Kanäle sind für die Verarbeitung von Livestreaminginhalten verantwortlich. Ein Kanal stellt einen Eingabeendpunkt (Aufnahme-URL) bereit, den Sie dann für einen Livetranscoder bereitstellen. Der Kanal empfängt Live-Eingabestreams vom Livetranscoder und stellt ihn für das Streaming über einen oder mehrere Streaming-Endpunkte zur Verfügung. Kanäle stellen auch einen Vorschauendpunkt (Vorschau-URL) bereit, den Sie zum Anzeigen und Überprüfen Ihres Datenstroms vor der weiteren Verarbeitung und Übermittlung verwenden. | Liveereignisse ersetzen Kanäle aus der v2-API. Sie übernehmen die meisten Features und verfügen über weitere neue Features wie Livetranskriptionen, Stand-by-Modus und Unterstützung für RTMPS-Aufnahme. |
Liveereignisprogramme | Mit einem Programm können Sie die Veröffentlichung und Speicherung von Segmenten in einem Livestream steuern. Kanäle verwalten Programme. Die Kanal- und Programmbeziehung ähnelt herkömmlichen Medien, bei denen ein Kanal einen konstanten Inhaltsstrom aufweist und ein Programm auf ein bestimmtes zeitgesteuertes Ereignis in diesem Kanal festgelegt ist. Sie können die Anzahl der Stunden angeben, die Sie den aufgezeichneten Inhalt für das Programm beibehalten möchten, indem Sie die eigenschaft ArchiveWindowLength festlegen. Dieser Wert kann zwischen mindestens 5 Minuten und maximal 25 Stunden festgelegt werden. |
Live-Ausgaben ersetzen jetzt Programme in der v3-API. |
Länge des Liveereignisses | Sie können Liveereignisse 24/7 streamen, wenn Sie Media Services zum Transcodieren eines einzelnen Bitrate-Beitragsfeeds in einen Ausgabedatenstrom mit mehreren Bitraten verwenden. | |
Latenz bei Liveereignissen | Neue Unterstützung für Livestreaming mit geringer Latenz für Liveereignisse. | |
Live-Ereignisvorschau | Live Event Preview unterstützt dynamische Verpackungen und dynamische Verschlüsselung. Dies ermöglicht den Inhaltsschutz für Vorschau sowie DASH- und HLS-Verpackungen. | |
RTMPS- des Liveereignisses | Verbesserte RTMPS-Unterstützung mit erhöhter Stabilität und mehr Quell-Encoderunterstützung. | |
RTMPS-Sichere Erfassung von Liveereignissen | Wenn Sie ein Liveereignis erstellen, erhalten Sie vier Aufnahme-URLs. Die vier Aufnahme-URLs sind fast identisch, weisen das gleiche Streamingtoken AppId auf, nur der Portnummernteil ist unterschiedlich. Zwei der URLs sind primär und sichern für RTMPS. |
|
Transkription von Liveereignissen | Azure Media Service liefert Video, Audio und Text in verschiedenen Protokollen. Wenn Sie Ihren Livestream mit MPEG-DASH oder HLS/CMAF veröffentlichen, liefert unser Dienst zusammen mit Video und Audio den transkribierten Text in IMSC1.1 kompatiblem TTML. | |
Standbymodus für Liveereignisse | Es gab keinen Standbymodus für V2. | Der Stand-by-Modus ist ein neues v3-Feature, mit dem Hot Pools von Liveereignissen verwaltet werden können. Kunden können jetzt ein Liveereignis im Stand-by-Modus zu niedrigeren Kosten starten, bevor sie in den laufenden Zustand übergehen. Dies verbessert die Startzeiten des Kanals und reduziert die Kosten des Betriebs von Hot Pools für schnellere Start-Ups. |
Abrechnung von Liveereignissen | Die Abrechnung von Liveereignissen basiert auf Live-Kanalzählern. | |
Liveausgabe | Programme mussten nach der Erstellung gestartet werden. | Live-Ausgaben beginnen beim Erstellen und Beenden beim Löschen. |
Hilfe und Support erhalten
Sie können media Services mit Fragen kontaktieren oder unsere Updates mit einer der folgenden Methoden befolgen:
- Q & A
-
Stack Overflow. Markieren Sie Fragen mit
azure-media-services
. - @MSFTAzureMedia oder verwenden Sie @AzureSupport, um Support anzufordern.
- Öffnen Sie ein Supportticket über das Azure-Portal.