Änderungen bei der Terminologie und bei Entitäten zwischen Media Services V2 und V3
Wichtig
Es ist nicht mehr erforderlich, von Azure Media Service v2 zu v3 zu migrieren, da die Veraltetkeit der V2-API mit der Einstellung von Azure Media Services übereinstimmt. Weitere Informationen finden Sie im Leitfaden zur Einstellung von Azure Media Services .
In diesem Artikel werden die Unterschiede bei der Terminologie zwischen Azure Media Services V2 und V3 beschrieben.
Terminologieänderungen
- Ein Locator wird jetzt als Streaminglocator bezeichnet.
- Ein Kanal wird jetzt als Liveereignis bezeichnet.
- Ein Programm wird jetzt als Liveausgabe bezeichnet.
- Eine Aufgabe wird jetzt als Auftragsausgabe bezeichnet und ist Teil eines Auftrags.
Entitätsänderungen
| V2-Entität | V3-Entität | Leitfaden | Zugänglich in V3 | Aktualisiert in V3 |
|---|---|---|---|---|
AccessPolicy |
Die Entität AccessPolicies ist in V3 nicht vorhanden. |
Nein | Nein | |
Asset |
Asset |
Ja | Yes | |
AssetDeliveryPolicy |
StreamingPolicy |
Ja | Nein | |
AssetFile |
Die Entität AssetFiles ist in V3 nicht vorhanden. Die hochgeladenen Dateien (Speicherblobs) werden weiterhin als Dateien angesehen.Verwenden Sie für das Durchlaufen der Blobs in einem Container stattdessen die Azure Storage-APIs. Es gibt zwei Möglichkeiten, mit einem Auftrag eine Transformation auf die Dateien anzuwenden: Dateien wurden bereits in den Speicher hochgeladen: Der URI enthält die Objekt-ID für Aufträge, die für Medienobjekte in einem Speicherkonto ausgeführt werden sollen. Dateien werden während der Transformations- und Auftragsverarbeitung hochgeladen: Das Medienobjekt wird im Speicher erstellt, eine SAS-URL wird zurückgegeben, Dateien werden in den Speicher hochgeladen, und anschließend wird die Transformation auf die Dateien angewandt. |
Nein | Nein | |
Channel |
LiveEvent |
Liveereignisse ersetzen Kanäle aus der V2-API. Sie übernehmen die meisten Funktionen und verfügen über mehr neue Features wie Livetranskriptionen, Standbymodus und Unterstützung für die RTMPS-Erfassung. Siehe Liveereignis im szenariobasierten Livestreaming |
Nein | Nein |
ContentKey |
ContentKeys ist jetzt keine Entität mehr, sondern eine Eigenschaft des Streaminglocators.In V3 sind die Daten für symmetrische Schlüssel dem StreamingLocator (bei der Ausgabeverschlüsselung) oder dem Medienobjekt selbst (bei der clientseitigen Speicherverschlüsselung) zugeordnet. |
Ja | Nein | |
ContentKeyAuthorizationPolicy |
ContentKeyPolicy |
Ja | Nein | |
ContentKeyAuthorizationPolicyOption |
ContentKeyPolicyOptions sind in der ContentKeyPolicy enthalten. |
Ja | Nein | |
IngestManifest |
Die Entität IngestManifests ist in V3 nicht vorhanden. Für das Hochladen von Dateien wird in V3 die Azure Storage-API verwendet. Zuerst werden Medienobjekte erstellt, und anschließend werden Dateien in den zugeordneten Speichercontainer hochgeladen. Es gibt viele alternative Möglichkeiten, Daten in einen Azure Storage-Container zu übertragen. JobInputHttp bietet auch eine Möglichkeit, die Auftragseingabe bei Bedarf von einer bestimmten URL herunterzuladen. |
Nein | Nein | |
IngestManifestAsset |
Es gibt viele alternative Möglichkeiten, Daten in einen Azure Storage-Container zu übertragen. JobInputHttp bietet auch eine Möglichkeit, die Auftragseingabe bei Bedarf von einer bestimmten URL herunterzuladen. |
Nein | Nein | |
IngestManifestFile |
Es gibt viele alternative Möglichkeiten, Daten in einen Azure Storage-Container zu übertragen. JobInputHttp bietet auch eine Möglichkeit, die Auftragseingabe bei Bedarf von einer bestimmten URL herunterzuladen. |
Nein | Nein | |
Job |
Job |
Erstellen Sie zunächst eine Transform und erst dann einen Job. |
Nein | Nein |
JobTemplate |
Transform |
Verwenden Sie stattdessen einen Transform. Eine Transformation ist eine vom Auftrag unabhängige und wiederverwendbare Entität. |
Nein | Nein |
Locator |
StreamingLocator |
Ja | Nein | |
MediaProcessor |
Verwenden Sie beim Definieren einer Transformation die gewünschte Voreinstellung, anstatt den MediaProcessor anhand seines Namens zu verwenden. Mit der verwendeten Voreinstellung wird der vom Auftragssystem verwendete Medienprozessor bestimmt. Weitere Informationen finden Sie unter den Codierungsthemen in Szenariobasierte Codierung. |
Nein | Nicht verfügbar (in V2 schreibgeschützt) | |
NotificationEndPoint |
Benachrichtigungen werden in V3 über Azure Event Grid verarbeitet. Der NotificationEndpoint wird durch die Registrierung des Event Grid-Abonnements ersetzt, die auch die Konfiguration für die zu empfangenden Benachrichtigungstypen einschließt (wurde in V2 von der JobNotificationSubscription des Auftrags, der TaskNotificationSubscription der Aufgabe und der ComponentMonitoringSetting für Telemetriedaten behandelt). Die V2-Telemetriedaten wurden zwischen Azure Event Grid und Azure Monitor aufgeteilt, um sie an die Verbesserungen des größeren Azure-Ökosystems anzupassen. |
Nein | Nein | |
Program |
LiveOutput |
Liveausgaben ersetzen in der V3-API Programme. | Nein | Nein |
StreamingEndpoint |
StreamingEndpoint |
Streamingendpunkte bleiben größtenteils unverändert. Sie werden für die dynamische Paketerstellung, Verschlüsselung und Übermittlung von HLS- und DASH-Inhalten für das Live- und On-Demand-Streaming entweder direkt an der Quelle oder über das CDN verwendet. Zu den neuen Features gehören die Unterstützung einer verbesserten Azure Monitor-Integration und die Diagrammerstellung. | Ja | Ja |
Task |
JobOutput |
Ersetzt durch JobOutput (in der API nun keine separate Entität mehr). Weitere Informationen finden Sie unter den Codierungsthemen in Szenariobasierte Codierung. |
Nein | Nein |
TaskTemplate |
TransformOutput |
Ersetzt durch TransformOutput (in der API nun keine separate Entität mehr). Weitere Informationen finden Sie unter den Codierungsthemen in Szenariobasierte Codierung. |
Nein | Nein |
Inputs |
Inputs |
Eingaben und Ausgaben befinden sich jetzt auf der Auftragsebene. Weitere Informationen finden Sie unter den Codierungsthemen in Szenariobasierte Codierung. | Nein | Nein |
Outputs |
Outputs |
Eingaben und Ausgaben befinden sich jetzt auf der Auftragsebene. In V3 wurde das Metadatenformat von XML in JSON geändert. Liveausgaben werden bei der Erstellung gestartet und beim Löschen beendet. Weitere Informationen finden Sie unter den Codierungsthemen in Szenariobasierte Codierung. | Nein | Nein |
| Weitere Änderungen | Version 2 | Version 3 |
|---|---|---|
| Storage | ||
| Speicher | Die V3-SDKs sind jetzt vom Storage SDK entkoppelt, sodass sich eine bessere Kontrolle über die zu verwendende Version des Storage SDK ergibt und Versionsprobleme vermieden werden. | |
| Codierung | ||
| Bitraten für die Codierung | Bitraten, gemessen in KBit/s, z. B.: 128 (KBit/s) | Bits pro Sekunde (Bit/s), z. B.: 128000 (Bit/s) |
| Codierung von DRM mit FairPlay | In Media Services V2 konnte der Initialisierungsvektor (IV) angegeben werden. | In Media Services V3 kann FairPlay IV nicht angegeben werden. |
| Premium-Encoder | Premium-Encoder und ältere Indexer | Der Zugriff auf den Premium-Encoder und die älteren Media Analytics-Prozessoren (Azure Media Services Indexer 2 Preview, Face Redactor usw.) ist über V3 nicht möglich. Im Media Encoder Standard wurde Unterstützung für die Audiokanalzuordnung hinzugefügt. Weitere Informationen finden Sie in der Dokumentation zu Audiodaten bei der Media Services-Codierung mit Swagger. Weitere Informationen finden Sie unter den Codierungsthemen in Szenariobasierte Codierung. |
| Transformationen und Aufträge | ||
| Auftragsbasierte Verarbeitung von HTTPS | Für dateibasierte Auftragsverarbeitung können Sie als Eingabe eine HTTPS-URL verwenden. Sie müssen noch keine Inhalte in Azure gespeichert haben und müssen auch keine Medienobjekte erstellen. | |
| ARM-Vorlagen für Aufträge | ARM-Vorlagen waren in V2 noch nicht vorhanden. | Eine Transformation kann verwendet werden, um wiederverwendbare Konfigurationen und Azure Resource Manager-Vorlagen zu erstellen, und um Verarbeitungseinstellungen zwischen mehreren Kunden oder Mandanten zu isolieren. |
| Liveereignisse | ||
| Streamingendpunkt | Ein Streamingendpunkt stellt einen Streamingdienst dar, der Inhalte zur weiteren Verteilung direkt in einer Clientwiedergabeanwendung oder einem Content Delivery Network (CDN) bereitstellen kann. | Streamingendpunkte bleiben größtenteils unverändert. Sie werden für die dynamische Paketerstellung, Verschlüsselung und Übermittlung von HLS- und DASH-Inhalten für das Live- und On-Demand-Streaming entweder direkt an der Quelle oder über das CDN verwendet. Zu den neuen Features gehören die Unterstützung einer verbesserten Azure Monitor-Integration und die Diagrammerstellung. |
| Liveereigniskanäle | Kanäle sind für die Verarbeitung von Livestreaminginhalten zuständig. Ein Kanal stellt einen Eingabeendpunkt (Erfassungs-URL) bereit, den Sie dann einem Live-Transcoder vorlegen. Der Kanal empfängt Liveeingabestreams vom Livetranscoder und stellt diese zum Streamen durch Streamingendpunkte zur Verfügung. Zudem bieten Kanäle einen Vorschauendpunkt (Vorschau-URL), mit dem Sie eine Vorschau des Streams anzeigen und überprüfen können, bevor Sie diesen weiter verarbeiten und übermitteln. | Liveereignisse ersetzen Kanäle aus der V2-API. Sie übernehmen die meisten Funktionen und verfügen über mehr neue Features wie Livetranskriptionen, Standbymodus und Unterstützung für die RTMPS-Erfassung. |
| Liveereignisprogramme | Mit einem Programm können Sie die Veröffentlichung und Speicherung von Segmenten in einem Livestream steuern. Kanäle verwalten Programme. Die Beziehung zwischen Kanal und Programm ähnelt herkömmlichen Medien, bei denen ein Kanal einen konstanten Stream von Inhalten aufweist und ein Programm auf ein zeitlich festgelegtes Ereignis in diesem Kanal ausgerichtet ist. Sie können in Stunden angeben, wie lange der aufgezeichnete Inhalt für das Programm beibehalten werden soll. Legen Sie dazu die ArchiveWindowLength-Eigenschaft fest. Dieser Wert kann von mindestens 5 Minuten bis zu einem Höchstwert von 25 Stunden eingestellt werden. |
Liveausgaben ersetzen in der V3-API Programme. |
| Länge von Liveereignissen | Wenn Media Services zum Transcodieren eines Beitragsfeeds mit Einzelbitrate in einen Ausgabestream mit mehreren Bitraten verwendet wird, können Sie Liveereignisse streamen, die bis zu 24/7 Stunden lang sind. | |
| Latenz von Liveereignissen | Neue Unterstützung für Livestreaming mit niedriger Latenz für Liveereignisse. | |
| Vorschau für Liveereignisse | Die Vorschau von Liveereignissen unterstützt die dynamische Paketerstellung und dynamische Verschlüsselung. Dadurch wird in der Vorschau der Inhaltsschutz sowie auch die Paketerstellung für DASH und HLS ermöglicht. | |
| RTMPS für Liveereignisse | Verbesserte RTMPS-Unterstützung mit höherer Stabilität und besserer Unterstützung für Quellcodierer. | |
| Sichere RTMPS-Erfassung für Liveereignisse | Bei der Erstellung eines Liveereignisses erhalten Sie vier Erfassungs-URLs. Die vier Erfassungs-URLs sind nahezu identisch und verfügen über das gleiche Streamingtoken (AppId). Nur der Portnummernteil unterscheidet sich. Zwei der URLs dienen als primäre URL und Backup-URL für RTMPS. |
|
| Transkription von Liveereignissen | Azure Media Service übermittelt Video, Audio und Text in unterschiedlichen Protokollen. Wenn Sie Ihren Livestream mittels MPEG-DASH oder HLS/CMAF veröffentlichen, stellt unser Dienst neben den Video- und Audiospuren auch den transkribierten Text im IMSC1.1-kompatiblen TTML-Format bereit. | |
| Standbymodus bei Liveereignissen | In V2 war kein Standbymodus verfügbar. | Der Standbymodus ist ein neues V3-Feature, das bei der Verwaltung von Pools der heißen Ebene für Liveereignisse hilfreich ist. Kunden können jetzt ein Liveereignis zu niedrigeren Kosten im Standbymodus starten, bevor sie es in den Ausführungszustand versetzen. Dies verbessert die Startzeiten des Kanals und senkt die Kosten für den Betrieb von Pools auf heißer Ebene für schnellere Starts. |
| Abrechnung von Liveereignissen | Die Abrechnung von Liveereignissen basiert auf Livekanal-Verbrauchseinheiten. | |
| Liveausgaben | Programme mussten nach der Erstellung gestartet werden. | Liveausgaben werden bei der Erstellung gestartet und beim Löschen beendet. |
Anfordern von Hilfe und Support
Sie können Media Services mit Fragen kontaktieren oder unsere Updates mit einer der folgenden Methoden verfolgen:
- Q & A
- Stack Overflow. Markieren Sie Fragen mit
azure-media-services. - @MSFTAzureMedia oder verwenden Sie @AzureSupport , um Support anzufordern.
- Öffnen Sie ein Supportticket über die Azure-Portal.