Tutorial: Livestreaming mit Media Services, Node.js und TypeScript

Media Services-Logo v3

Warnung

Azure Media Services wird am 30. Juni 2024 eingestellt. Weitere Informationen finden Sie im Leitfaden zur Einstellung von AMS.

In Azure Media Services sind Liveereignisse für die Verarbeitung von Livestreaminginhalten zuständig. Bei einem Liveereignis wird ein Eingabeendpunkt (Erfassungs-URL) bereitgestellt, den Sie dann für einen Liveencoder bereitstellen. Das Liveereignis empfängt Eingabestreams aus dem Liveencoder und stellt diese zum Streamen über einen oder mehrere Streamingendpunkte zur Verfügung. Zudem stellen Liveereignisse einen Vorschauendpunkt (Vorschau-URL) bereit, mit dem Sie eine Vorschau des Streams anzeigen und überprüfen können, bevor Sie ihn weiter verarbeiten und übermitteln.

In diesem Tutorial erfahren Sie, wie Sie unter Verwendung von Node.js und TypeScript ein Liveereignis vom Typ Passthrough erstellen und mit OBS Studio einen Livestream dafür übertragen.

In diesem Lernprogramm lernen Sie Folgendes:

  • Laden Sie den Beispielcode herunter.
  • Untersuchen des Codes zum Konfigurieren und Durchführen des Livestreamings
  • Sehen Sie sich das Ereignis mit Azure Media Player auf der Media Player Demowebsite an.
  • Bereinigen der Ressourcen

Hinweis

In diesem Tutorial werden Node.js-Beispiele verwendet. Die allgemeinen Schritte sind jedoch auch bei Verwendung der REST-API, der CLI oder anderer unterstützter SDKs gleich.

Voraussetzungen

Für dieses Tutorial benötigen Sie Folgendes:

Sie benötigen diese zusätzlichen Elemente für Livestreamingsoftware:

  • Eine Kamera oder ein Gerät (beispielsweise ein Laptop) zum Übertragen eines Ereignisses.

  • Einen lokalen Softwareencoder, der Ihren Kameradatenstrom codiert und über das Real-Time Messaging Protocol (RTMP) an den Media Services-Livestreamingdienst sendet. Weitere Informationen finden Sie unter Empfohlene lokale Liveencoder. Der Datenstrom muss das Format RTMP oder Smooth Streaming haben.

    In diesem Beispiel wird davon ausgegangen, dass Sie OBS Studio (Open Broadcaster Software) verwenden, um RTMP an den Erfassungsendpunkt zu übertragen. Installieren Sie OBS Studio.

    Verwenden Sie in OBS Studio die folgenden Codierungseinstellungen:

    • Encoder: NVIDIA NVENC (sofern verfügbar) oder x264
    • Ratensteuerung: CBR
    • Bitrate: 2.500 KBit/s (bzw. für Ihren Computer geeignete Rate)
    • Keyframe-Intervall: 2 Sekunden (oder 1 Sekunde für geringe Latenzzeit)
    • Voreinstellung: „Low-Latency Quality“ (Geringe Wartezeit: Qualität) oder „Low-Latency Performance“ (Geringe Wartezeit: Leistung) bei Verwendung von NVENC oder „veryfast“ (sehr schnell) bei Verwendung von x264
    • Profil: „high“ (hoch)
    • GPU: 0 (Auto)
    • Max. B-Frames: 2

Tipp

Lesen Sie Livestreaming mit Azure Media Services v3, bevor Sie mit diesem Tutorial fortfahren.

Herunterladen und Konfigurieren des Beispiels

Klonen Sie mit folgendem Befehl das GitHub-Repository auf Ihren Computer, welches das Beispiel für Livestreaming mit Node.js enthält:

git clone https://github.com/Azure-Samples/media-services-v3-node-tutorials.git

Das Livestreaming-Beispiel befindet sich im Ordner Live.

Kopieren Sie im Stammordner die Datei sample.env in eine neue Datei mit dem Namen .env, um die Einstellungen Ihrer Umgebungsvariablen zu speichern, die Sie im Artikel Mit Azure CLI auf Azure Media Services-API zugreifen gesammelt haben. Achten Sie darauf, dass der Dateiname den Punkt (.) vor „env“ enthält, damit das Codebeispiel ordnungsgemäß funktioniert.

In der ENV-Datei befinden sich Azure Active Directory-Anwendungsschlüssel (Azure AD) und -geheimnis. Sie enthält zudem Kontonamen und Abonnementinformationen, die zum Authentifizieren des SDK-Zugriffs auf Ihr Media Services-Konto erforderlich sind. Die Datei .gitignore ist bereits konfiguriert, um das Veröffentlichen dieser Datei auf Ihr geforktes Repository zu verhindern. Achten Sie auf die Sicherheit dieser Anmeldeinformationen, da diese wichtige Geheimnisse Ihres Kontos sind.

Wichtig

In diesem Beispiel wird für jede Ressourcen ein eindeutiges Suffix verwendet. Wenn Sie das Debuggen abbrechen oder die App beenden, ohne das Beispiel vollständig zu durchlaufen, werden in Ihrem Konto mehrere Liveereignisse generiert.

Stellen Sie sicher, dass Sie die ausgeführten Liveereignisse beenden. Andernfalls fallen für die Ereignisse Kosten an! Am Ende der Programmausführung werden die Ressourcen automatisch bereinigt. Falls Programm bzw. Debugger vorzeitig beendet werden und dadurch die Programmausführung abgebrochen wird, vergewissern Sie sich im Portal, dass keine Liveereignisse im Ausführungs- oder Standby-Zustand vorhanden sind, um unerwünschte Abrechnungsgebühren zu vermeiden.

Untersuchen des TypeScript-Codes für Livestreaming

In diesem Abschnitt werden die in der Datei index.ts des Projekts Live/Standard_Passthrough_Live_Event definierten Funktionen untersucht.

Das Beispiel erstellt für jede Ressource ein eindeutiges Suffix, damit keine Namenskonflikte auftreten, wenn Sie das Beispiel ohne Bereinigung der Ressourcen mehrmals ausführen.

Erste Schritte mit dem Media Services SDK für Node.js mit TypeScript

Um Media Services-APIs mit Node.js verwenden zu können, muss zunächst das SDK-Modul @azure/arm-mediaservices mithilfe des npm-Paket-Managers hinzugefügt werden.

npm install @azure/arm-mediaservices

In der Datei package.json ist dies bereits für Sie konfiguriert. Sie müssen nur npm install ausführen, um die Module und Abhängigkeiten zu laden:

  1. Installieren Sie die Pakete, die in der Datei packages.json verwendet werden.

    npm install

  2. Öffnen Sie Visual Studio Code über den Stammordner. (Dies ist erforderlich, damit das Starten aus dem Ordner erfolgt, in dem sich der Ordner .vscode und die tsconfig.json-Dateien befinden.)

    code .

Öffnen Sie den Ordner für Live/Standard_Passthrough_Live_Event, und öffnen Sie die Datei index.ts im Visual Studio Code-Editor.

Drücken Sie in der Datei index.ts die Taste F5, um den Debugger zu öffnen.

Festlegen von longRunningOperationUpdateIntervalMs

Um das Abrufen zeitintensiver Vorgänge vom Standardwert von 30 Sekunden auf wenige Sekunden zu beschleunigen, müssen Sie longRunningOperationUpdateIntervalMs festlegen und diesen Wert bei Verwendung von liveEvents an die Eigenschaft updateIntervaleInMs des options-Parameters für Vorgänge vom Typ „createAndWait()“ übergeben. Dies ist im gesamten Beispiel zu sehen. In diesem Beispiel wird ein Wert von 2.000 ms (2 Sekunden) verwendet. Diese Änderung reduziert die Zeit, die benötigt wird, um den Status eines Vorgangs mit langer Ausführungsdauer auf dem Azure Resource Manager-Endpunkt abzufragen. Es verkürzt die Zeit zum Abschließen wichtiger Vorgänge wie das Erstellen von Liveereignissen, das Starten und Beenden, bei denen es sich um asynchrone Aufrufe handelt. Für die meisten zeitkritischen Szenarien wird ein Wert von 2 Sekunden empfohlen.


// Long running operation polling interval in milliseconds
const longRunningOperationUpdateIntervalMs = 2000;

Erstellen eines Liveereignisses

In diesem Abschnitt wird das Erstellen eines Liveereignisses vom Typ Passthrough der SKU „Standard“ (LiveEventEncodingType auf PassthroughStandard festgelegt) beschrieben. Weitere Informationen zu den verfügbaren Typen finden Sie unter Liveereignistypen. Neben Passthrough der SKU „Basic“ oder „Standard“ können Sie ein Livecodierungsereignis für eine Cloudcodierung mit adaptiver Bitrate (720p oder 1080p) verwenden. Beispiele für diese Ereignistypen finden Sie im Ordner Live des Beispielrepositorys. Darüber hinaus ist ein Beispiel enthalten, das zeigt, wie Sie über Event Hubs auf Event Grid-Ereignisse lauschen.

Beim Erstellen des Liveereignisses können Sie beispielsweise Folgendes angeben:

  • Erfassungsprotokoll für das Liveereignis: Derzeit werden die Protokolle RTMP, RTMPS und Smooth Streaming unterstützt. Die Protokolloption kann nicht geändert werden, während das Liveereignis oder die zugehörigen Liveausgaben aktiv sind. Sollten Sie verschiedene Protokolle benötigen, erstellen Sie für jedes Streamingprotokoll ein separates Liveereignis.

  • IP-Einschränkungen für Erfassung und Vorschau: Sie können die IP-Adressen definieren, die ein Video für dieses Liveereignis erfassen dürfen. Zulässige IP-Adressen können als eine der folgenden Optionen angegeben werden:

    • Einzelne IP-Adresse (z. B. 10.0.0.1)
    • Ein IP-Adressbereich, für den eine IP-Adresse und eine CIDR-Subnetzmaske (Classless Inter-Domain Routing) verwendet werden (z. B. 10.0.0.1/22)
    • Ein IP-Adressbereich, für den eine IP-Adresse und Subnetzmaske in Dezimalschreibweise mit Punkten (z. B. 10.0.0.1(255.255.252.0)) verwendet werden

    Wenn keine IP-Adressen angegeben sind und es keine Regeldefinition gibt, sind keine IP-Adressen zulässig. Erstellen Sie eine Regel, und geben Sie 0.0.0.0/0 an, um alle IP-Adressen zuzulassen. Die IP-Adressen müssen in einem der folgenden Formate vorliegen: IPv4- oder IPv6-Adressen mit vier Zahlen oder einem CIDR-Adressbereich. Weitere Informationen zur Verwendung von IPv4 oder IPv6 finden Sie unter Einschränken des Zugriffs auf DIE DRM-Lizenz und der Übermittlung von AES-Schlüsseln mithilfe von IP-Zulassungslisten.

  • Autostart für ein Ereignis, während Sie es erstellen: Wenn für den automatischen Start true festgelegt ist, wird das Liveereignis nach der Erstellung gestartet. Dies bedeutet, dass die Abrechnung beginnt, sobald die Ausführung des Liveereignisses startet. Sie müssen für die Liveereignisressource explizit Stop auswählen, damit keine weiteren Gebühren anfallen. Weitere Informationen finden Sie unter Zustandswerte von Liveereignissen und Abrechnung.

    Standbymodi sind verfügbar, um das Liveereignis in einem kostengünstigeren „zugeordneten“ Zustand zu starten, der den Wechsel in einen Ausführungszustand beschleunigt. Dies ist etwa im Falle von Pools der heißen Ebene hilfreich, die schnell Kanäle für Streamer bereitstellen müssen.

  • Ein statischer Hostname und eine eindeutige GUID: Legen Sie die Eigenschaft useStaticHostname auf true fest, um eine vorhersagbare Erfassungs-URL zu erhalten, die zudem einfacher in einem hardwarebasierten Liveencoder verwaltet werden kann. Verwenden Sie für accessToken eine benutzerdefinierte, eindeutige GUID. Ausführliche Informationen finden Sie unter Erfassungs-URLs für Liveereignisse.


// Creating the LiveEvent - the primary object for live streaming in AMS. 
// See the overview - https://docs.microsoft.com/azure/media-services/latest/live-streaming-overview

// Create the LiveEvent

// Understand the concepts of what a live event and a live output is in AMS first!
// Read the following - https://docs.microsoft.com/azure/media-services/latest/live-events-outputs-concept
// 1) Understand the billing implications for the various states
// 2) Understand the different live event types, pass-through and encoding
// 3) Understand how to use long-running async operations 
// 4) Understand the available Standby mode and how it differs from the Running Mode. 
// 5) Understand the differences between a LiveOutput and the Asset that it records to.  They are two different concepts.
//    A live output can be considered as the "tape recorder" and the Asset is the tape that is inserted into it for recording.
// 6) Understand the advanced options such as low latency, and live transcription/captioning support. 
//    Live Transcription - https://docs.microsoft.com/en-us/azure/media-services/latest/live-transcription
//    Low Latency - https://docs.microsoft.com/en-us/azure/media-services/latest/live-event-latency

// When broadcasting to a live event, please use one of the verified on-premises live streaming encoders.
// While operating this tutorial, it is recommended to start out using OBS Studio before moving to another encoder. 

// Note: When creating a LiveEvent, you can specify allowed IP addresses in one of the following formats:                 
//      To allow all IPv4 addresses and block all IPv6 addresses, set the IP allow list to [ "0.0.0.0/0" ]
//      IpV4 address with 4 numbers
//      CIDR address range

let allowAllIPv4InputRange: IPRange = {
    name: "Allow all IPv4 addresses",
    address: "0.0.0.0",
    subnetPrefixLength: 0
};

// IpV6 addresses or ranges
//  For this example, the following request from the following addresses will be accepted:
//      •	IPv6 addresses between 2001:1234:1234:0000:0000:0000:0000:4567 and 2001:1234:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF,
//      •	IPv6 address 2001:1235:0000:0000:0000:0000:0000:0000
//  Additional examples:
//      •	To allow requests from any IP address, set the “defaultAction” of the “accessControl” block to “Allow” (and do not specify an “ipAllowList)
//      •	To allow all IPv6 addresses and block all IPv6 addresses, set the IP allow list to [ "::/0" ]

let allowAllIPv6InputRange: IPRange = {
    name: "Allow all IPv6 addresses",
    address: "::",
    subnetPrefixLength: 0
};

// Create the LiveEvent input IP access control object
// this will control the IP that the encoder is running on and restrict access to only that encoder IP range.
let liveEventInputAccess: LiveEventInputAccessControl = {
    ip: {
        allow: [
            // re-use the same range here for the sample, but in production you can lock this
            // down to the ip range for your on-premises live encoder, laptop, or device that is sending
            // the live stream
            allowAllIPv4InputRange,
            allowAllIPv6InputRange
        ]
    }
};

// Create the LiveEvent Preview IP access control object. 
// This will restrict which clients can view the preview endpoint
let liveEventPreview: LiveEventPreview = {
    accessControl: {
        ip: {
            allow: [
                // re-use the same range here for the sample, but in production you can lock this to the IPs of your 
                // devices that would be monitoring the live preview. 
                allowAllIPv4InputRange,
                allowAllIPv6InputRange
            ]
        }
    }
}

// To get the same ingest URL for the same LiveEvent name every single time...
// 1. Set useStaticHostname  to true so you have ingest like: 
//        rtmps://liveevent-hevc12-eventgridmediaservice-usw22.channel.media.azure.net:2935/live/522f9b27dd2d4b26aeb9ef8ab96c5c77           
// 2. Set accessToken to a desired GUID string (with or without hyphen)

// See REST API documentation for details on each setting value
// https://docs.microsoft.com/rest/api/media/liveevents/create 

let liveEventCreate: LiveEvent = {
    location: mediaAccount.location,
    description: "Sample Live Event from Node.js SDK sample",
    // Set useStaticHostname to true to make the ingest and preview URL host name the same. 
    // This can slow things down a bit. 
    useStaticHostname: true,
    //hostnamePrefix: "somethingstatic", /// When using Static host name true, you can control the host prefix name here if desired 
    // 1) Set up the input settings for the Live event...
    input: {
        streamingProtocol: KnownLiveEventInputProtocol.Rtmp, // options are RTMP or Smooth Streaming ingest format.
        accessControl: liveEventInputAccess,  // controls the IP restriction for the source encoder. 
        // keyFrameIntervalDuration: "PT2S",  // Set this to match the ingest encoder's settings. This should not be used for encoding live events  
        accessToken: "9eb1f703b149417c8448771867f48501" // Use this value when you want to make sure the ingest URL is static and always the same. If omitted, the service will generate a random GUID value.
    },

    // 2) Set the live event to use pass-through or cloud encoding modes...
    encoding: {
        // Set this to Basic pass-through, Standard pass-through, Standard or Premium1080P to use the cloud live encoder.
        // See https://go.microsoft.com/fwlink/?linkid=2095101 for more information
        // Otherwise, leave as "None" to use pass-through mode
        encodingType: KnownLiveEventEncodingType.PassthroughStandard,
        // OPTIONS for encoding type you can use:
        // encodingType: KnownLiveEventEncodingType.PassthroughBasic, // Basic pass-through mode - the cheapest option!
        // encodingType: KnownLiveEventEncodingType.PassthroughStandard, // also known as standard pass-through mode (formerly "none")
        // encodingType: KnownLiveEventEncodingType.Premium1080p,// live transcoding up to 1080P 30fps with adaptive bitrate set
        // encodingType: KnownLiveEventEncodingType.Standard,// use live transcoding in the cloud for 720P 30fps with adaptive bitrate set
        //
        // OPTIONS using live cloud encoding type:
        // keyFrameInterval: "PT2S", //If this value is not set for an encoding live event, the fragment duration defaults to 2 seconds. The value cannot be set for pass-through live events.
        // presetName: null, // only used for custom defined presets. 
        //stretchMode: KnownStretchMode.None // can be used to determine stretch on encoder mode
    },
    // 3) Set up the Preview endpoint for monitoring based on the settings above we already set. 
    preview: liveEventPreview,

    // 4) Set up more advanced options on the live event. Low Latency is the most common one. 
    streamOptions: [
        "LowLatency"
    ],

    // 5) Optionally enable live transcriptions if desired. 
    // WARNING : This is extra cost ($$$), so please check pricing before enabling. Transcriptions are not supported on PassthroughBasic.
    //           switch this sample to use encodingType: "PassthroughStandard" first before un-commenting the transcriptions object below. 

    /* transcriptions : [
        {
            inputTrackSelection: [], // chose which track to transcribe on the source input.
            // The value should be in BCP-47 format (e.g: 'en-US'). See https://go.microsoft.com/fwlink/?linkid=2133742
            language: "en-us", 
            outputTranscriptionTrack: {
                trackName : "English" // set the name you want to appear in the output manifest
            }
        }
    ]
    */
}



console.log("Creating the LiveEvent, please be patient as this can take time to complete async.")
console.log("Live Event creation is an async operation in Azure and timing can depend on resources available.")
console.log();

let timeStart = process.hrtime();
// When autostart is set to true, the Live Event will be started after creation. 
// That means, the billing starts as soon as the Live Event starts running. 
// You must explicitly call Stop on the Live Event resource to halt further billing.
// The following operation can sometimes take awhile. Be patient.
// On optional workflow is to first call allocate() instead of create. 
// https://docs.microsoft.com/en-us/rest/api/media/liveevents/allocate 
// This allows you to allocate the resources and place the live event into a "Standby" mode until 
// you are ready to transition to "Running". This is useful when you want to pool resources in a warm "Standby" state at a reduced cost.
// The transition from Standby to "Running" is much faster than cold creation to "Running" using the autostart property.
// Returns a long running operation polling object that can be used to poll until completion.
await mediaServicesClient.liveEvents.beginCreateAndWait(
    resourceGroup,
    accountName,
    liveEventName,
    liveEventCreate,
    // When autostart is set to true, you should "await" this method operation to complete. 
    // The Live Event will be started after creation. 
    // You may choose not to do this, but create the object, and then start it using the standby state to 
    // keep the resources "warm" and billing at a lower cost until you are ready to go live. 
    // That increases the speed of startup when you are ready to go live. 
    {
        autoStart: false,
        updateIntervalInMs: longRunningOperationUpdateIntervalMs // This sets the polling interval for the long running ARM operation (LRO)
    }
).then((liveEvent) => {
    let timeEnd = process.hrtime(timeStart);
    console.info(`Live Event Created - long running operation complete! Name: ${liveEvent.name}`)
    console.info(`Execution time for create LiveEvent: %ds %dms`, timeEnd[0], timeEnd[1] / 1000000);
    console.log();
}).catch((reason) => {
    if (reason.error && reason.error.message) {
        console.info(`Live Event creation failed: ${reason.message}`);
    }
})

Erstellen eines Assets zum Aufzeichnen und Archivieren des Liveereignisses

Im folgenden Codeblock wird ein leeres Asset als „Videokassette“ zum Aufzeichnen Ihres Liveereignisarchivs erstellt.

Beim Lernen dieser Konzepte ist es hilfreich, wenn Sie sich dieses Medienobjekt als „Videokassette“ vorstellen, wie sie früher einmal in einen Videorekorder eingelegt wurde. Die Liveausgabe fungiert hierbei als „Videorekorder“. Das Liveereignis ist das vom Computer ausgegebene „Videosignal“.

Das Medienobjekt (die „Videokassette“) kann zu einem beliebigen Zeitpunkt erstellt werden. Sie werden das leere Objekt an das Liveausgabeobjekt, den „Videorekorder“ in dieser Analogie, übertragen.


// Create an Asset for the LiveOutput to use. Think of this as the "tape" that will be recorded to. 
// The asset entity points to a folder/container in your Azure Storage account. 
console.log(`Creating an asset named: ${assetName}`);
console.log();
let asset = await mediaServicesClient.assets.createOrUpdate(resourceGroup, accountName, assetName, {});

// Create the Live Output - think of this as the "tape recorder for the live event". 
// Live outputs are optional, but are required if you want to archive the event to storage,
// use the asset for on-demand playback later, or if you want to enable cloud DVR time-shifting.
// We will use the asset created above for the "tape" to record to. 
let manifestName: string = "output";
console.log(`Creating a live output named: ${liveOutputName}`);
console.log();

// See the REST API for details on each of the settings on Live Output
// https://docs.microsoft.com/rest/api/media/liveoutputs/create

Erstellen der Liveausgabe

In diesem Abschnitt wird eine Liveausgabe erstellt, die den Medienobjektnamen als Eingabe verwendet, um anzugeben, wo das Liveereignis aufgezeichnet werden soll. Darüber hinaus wird das Timeshift-Fenster (DVR) für die Aufzeichnung eingerichtet.

Im Beispielcode wird die Einrichtung eines Timeshift-Fensters von 1 Stunde gezeigt. Dadurch können Clients die letzte Stunde des Ereignisses ab einer beliebigen Stelle wiedergeben. Darüber hinaus wird nur die letzte Stunde des Liveereignisses im Archiv gespeichert. Dieser Wert kann auf bis zu 25 Stunden erhöht werden. Beachten Sie auch, dass Sie die Benennung der Ausgabemanifeste steuern können, welche die Manifeste für HTTP LIVE STREAMING (HLS) und das dynamische adaptive Streaming per HTTP (Dynamic Adaptive Streaming over HTTP, DASH) bei der Veröffentlichung in Ihren URL-Pfaden verwenden.

Die Liveausgabe (in dieser Analogie der „Videorekorder“) kann ebenfalls zu einem beliebigen Zeitpunkt erstellt werden. Sie können also eine Liveausgabe vor oder nach dem Starten der Signalübertragung erstellen. Wenn es schnell gehen muss, empfiehlt es sich häufig, die Ausgabe vor dem Starten der Signalübertragung zu erstellen.

Liveausgaben beginnen, wenn sie erstellt werden, und werden beim Löschen angehalten. Wenn Sie die Liveausgabe löschen, bleiben das zugrunde liegende Medienobjekt und dessen Inhalt erhalten. Stellen Sie sich dies als Auswerfen des „Bands“ vor. Das Medienobjekt mit der Aufzeichnung bleibt so lange gespeichert, wie Sie möchten. Wenn es ausgeworfen wird (Löschen der Liveausgabe), ist es sofort für die bedarfsgesteuerte Anzeige verfügbar.

let liveOutputCreate: LiveOutput;
if (asset.name) {
    liveOutputCreate = {
        description: "Optional description when using more than one live output",
        assetName: asset.name,
        manifestName: manifestName, // The HLS and DASH manifest file name. This is recommended to set if you want a deterministic manifest path up front.
        archiveWindowLength: "PT30M", // sets the asset archive window to 30 minutes. Uses ISO 8601 format string.
        rewindWindowLength: "PT30M", // sets the time-shit(DVR) window to 30 minutes. Uses ISO 8601 format string.
        hls: {
            fragmentsPerTsSegment: 1 // Advanced setting when using HLS TS output only.
        },
    }

    // Create and await the live output
    await mediaServicesClient.liveOutputs.beginCreateAndWait(
        resourceGroup,
        accountName,
        liveEventName,
        liveOutputName,
        liveOutputCreate,
        {
            updateIntervalInMs: longRunningOperationUpdateIntervalMs // Setting this adjusts the polling interval of the long running operation. 
        })
        .then((liveOutput) => {
            console.log(`Live Output Created: ${liveOutput.name}`);
            let timeEnd = process.hrtime(timeStart);
            console.info(`Execution time for create Live Output: %ds %dms`, timeEnd[0], timeEnd[1] / 1000000);
            console.log();
        })
        .catch((reason) => {
            if (reason.error && reason.error.message) {
                console.info(`Live Output creation failed: ${reason.message}`);
            }
        });


}

Abrufen von Erfassungs-URLs

Sobald das Liveereignis erstellt wurde, können Sie Erfassungs-URLs abrufen, die Sie dem Liveencoder bereitstellen. Der Encoder gibt mit diesen URLs einen Livestream per RTMP-Protokoll ein.


// Get the RTMP ingest URL to configure in OBS Studio. 
// The endpoints is a collection of RTMP primary and secondary, and RTMPS primary and secondary URLs. 
// to get the primary secure RTMPS, it is usually going to be index 3, but you could add a  loop here to confirm...
if (liveEvent.input?.endpoints) {
    let ingestUrl = liveEvent.input.endpoints[0].url;
    console.log(`The RTMP ingest URL to enter into OBS Studio is:`);
    console.log(`RTMP ingest : ${ingestUrl}`);
    console.log(`Make sure to enter a Stream Key into the OBS studio settings. It can be any value or you can repeat the accessToken used in the ingest URL path.`);
    console.log();
}

Abrufen der Vorschau-URL

Rufen Sie mit previewEndpoint die Vorschau-URL ab, und überprüfen Sie, ob die Eingabe des Encoders empfangen wird.

Wichtig

Vergewissern Sie sich vor dem Fortfahren, dass das Video an die Vorschau-URL übertragen wird.

if (liveEvent.preview?.endpoints) {
    // Use the previewEndpoint to preview and verify
    // that the input from the encoder is actually being received
    // The preview endpoint URL also support the addition of various format strings for HLS (format=m3u8-cmaf) and DASH (format=mpd-time-cmaf) for example.
    // The default manifest is Smooth. 
    let previewEndpoint = liveEvent.preview.endpoints[0].url;
    console.log("The preview url is:");
    console.log(previewEndpoint);
    console.log();
    console.log("Open the live preview in your browser and use any DASH or HLS player to monitor the preview playback:");
    console.log(`https://ampdemo.azureedge.net/?url=${previewEndpoint}(format=mpd-time-cmaf)&heuristicprofile=lowlatency`);
    console.log("You will need to refresh the player page SEVERAL times until enough data has arrived to allow for manifest creation.");
    console.log("In a production player, the player can inspect the manifest to see if it contains enough content for the player to load and auto reload.");
    console.log();
}

console.log("Start the live stream now, sending the input to the ingest url and verify that it is arriving with the preview url.");
console.log("IMPORTANT TIP!: Make CERTAIN that the video is flowing to the Preview URL before continuing!");

Erstellen und Verwalten von Liveereignissen und Liveausgaben

Sobald der Stream bei Ihrem Liveereignis eingeht, können Sie das Streamingereignis starten, indem Sie einen Streaminglocator für Ihre Clientplayer veröffentlichen. Dadurch wird er über den Streamingendpunkt für die Zuschauer verfügbar gemacht.

Erstellen Sie zunächst das Signal, indem Sie das Liveereignis erstellen. Das Signal wird erst übertragen, wenn Sie dieses Liveereignis starten und Ihren Encoder mit der Eingabe verbinden.

Um die „Videoaufnahme“ zu beenden, rufen Sie delete bei LiveOutput auf. Durch diese Aktion wird der Inhalt Ihres Archivs auf dem „Video“ (Asset) nicht gelöscht. Es wird nur der „Videorekorder“ gelöscht und die Archivierung beendet. Das Medienobjekt bleibt mit dem archivierten Videoinhalt erhalten, bis Sie explizit delete für das Medienobjekt aufrufen. Nach dem Löschen von LiveOutput kann der aufgezeichnete Inhalt des Medienobjekts weiterhin über alle bereits veröffentlichten Streaminglocator-URLs wiedergegeben werden.

Wenn Sie verhindern möchten, dass ein Client die archivierten Inhalte abspielen kann, müssen Sie zunächst alle Locatoren vom Asset entfernen. Leeren Sie auch den CDN-Cache (Content Delivery Network) im URL-Pfad, wenn Sie ein CDN für die Übermittlung verwenden. Andernfalls bleibt der Inhalt im CDN-Cache erhalten für den Zeitraum, der im CDN als Standardgültigkeitsdauer festgelegt ist (bis zu 72 Stunden).

Erstellen eines Streaminglocators zum Veröffentlichen von HLS- und DASH-Manifesten

Hinweis

Beim Erstellen Ihres Media Services-Kontos wird dem Konto ein Standard-Streamingendpunkt im Zustand „Beendet“ hinzugefügt. Um mit dem Streamen Ihrer Inhalte zu beginnen und die dynamische Paketerstellung und dynamische Verschlüsselung zu nutzen, muss sich der Streamingendpunkt, von dem Sie Inhalte streamen möchten, im Zustand „Wird ausgeführt“ befinden.

Wenn Sie das Medienobjekt mit einem Streaminglocator veröffentlichen, kann das Liveereignis (maximal bis zur DVR-Fensterlänge) bis zum Ablaufen oder Löschen des Streaminglocators (je nachdem, was zuerst eintritt) weiterhin angezeigt werden. Auf diese Weise können Sie die virtuelle Aufzeichnung so verfügbar machen, dass sie von Ihrer Zielgruppe live und „On-Demand“ angesehen werden kann. Mit der gleichen URL kann das Liveereignis, das DVR-Fenster oder das On-Demand-Medienobjekt angesehen werden, wenn die Aufzeichnung abgeschlossen ist (nach dem Löschen der Liveausgabe).

async function createStreamingLocator(assetName: string, locatorName: string) {
    let streamingLocator = {
        assetName: assetName,
        streamingPolicyName: "Predefined_ClearStreamingOnly"  // no DRM or AES128 encryption protection on this asset. Clear means un-encrypted.
    };

    let locator = await mediaServicesClient.streamingLocators.create(
        resourceGroup,
        accountName,
        locatorName,
        streamingLocator);

    return locator;
}

Erstellen der Pfade zu den HLS- und DASH-Manifesten

Die Methode BuildManifestPaths im Beispiel zeigt die deterministische Erstellung der Streamingpfade für die HLS- oder DASH-Übermittlung an verschiedene Clients und Playerframeworks.


// This method builds the manifest URL from the static values used during creation of the Live Output.
// This allows you to have a deterministic manifest path. <streaming endpoint hostname>/<streaming locator ID>/manifestName.ism/manifest(<format string>)
async function buildManifestPaths(scheme: string, hostname: string | undefined, streamingLocatorId: string | undefined, manifestName: string) {
    const hlsFormat: string = "format=m3u8-cmaf";
    const dashFormat: string = "format=mpd-time-cmaf";

    let manifestBase = `${scheme}://${hostname}/${streamingLocatorId}/${manifestName}.ism/manifest`
    let hlsManifest = `${manifestBase}(${hlsFormat})`;
    console.log(`The HLS (MP4) manifest URL is : ${hlsManifest}`);
    console.log("Open the following URL to playback the live stream in an HLS compliant player (HLS.js, Shaka, ExoPlayer) or directly in an iOS device");
    console.log(`${hlsManifest}`);
    console.log();

    let dashManifest = `${manifestBase}(${dashFormat})`;
    console.log(`The DASH manifest URL is : ${dashManifest}`);
    console.log("Open the following URL to playback the live stream from the LiveOutput in the Azure Media Player");
    console.log(`https://ampdemo.azureedge.net/?url=${dashManifest}&heuristicprofile=lowlatency`);
    console.log();
}

Ansehen des Ereignisses

Kopieren Sie zum Wiedergeben des Ereignisses die Streaming-URL, die Sie beim Ausführen des Codes unter „Erstellen eines Streaminglocators“ erhalten haben. Sie können einen Medienplayer Ihrer Wahl verwenden. Azure Media Player ist verfügbar, um Ihren Datenstrom auf der Media Player-Demowebsite zu testen.

Für ein Liveereignis werden Ereignisse bei der Beendigung automatisch in On-Demand-Inhalte konvertiert. Auch nach dem Beenden und Löschen des Ereignisses können die Benutzer archivierte Inhalte als Video auf Abruf streamen, solange Sie das Medienobjekt nicht löschen. Ein Medienobjekt kann nicht gelöscht werden, wenn es ein Ereignis verwendet. Zuerst muss das betreffende Ereignis gelöscht werden.

Bereinigen von Ressourcen in Ihrem Media Services-Konto

Wenn Sie die Anwendung bis zum Ende ausführen, werden in der Funktion cleanUpResources automatisch alle verwendeten Ressourcen bereinigt. Stellen Sie sicher, dass die Anwendung bzw. der Debugger bis zum Ende ausgeführt wird. Andernfalls kommt es möglicherweise zu einem Ressourcenleck sowie zu aktiven Liveereignissen in Ihrem Konto. Vergewissern Sie sich im Azure-Portal, dass alle Ressourcen in Ihrem Media Services-Konto bereinigt wurden.

Sehen Sie sich im Beispielcode die Methode cleanUpResources an, um weitere Details zu erhalten.

Wichtig

Wenn Sie das Liveereignis nicht beenden, fallen weiter Kosten dafür an. Beachten Sie, dass das Liveereignis möglicherweise im Abrechnungszustand verbleibt, wenn das Projekt oder Programm nicht mehr reagiert oder aufgrund eines anderen Problems geschlossen wird.

Fragen stellen, Feedback geben, Updates abrufen

Im Artikel Azure Media Services-Community finden Sie verschiedene Möglichkeiten, Fragen zu stellen, Feedback zu geben und Updates zu Media Services zu bekommen.

Weitere Entwicklerdokumentation für Node.js in Azure

Anfordern von Hilfe und Support

Sie können Media Services mit Fragen kontaktieren oder unsere Updates mit einer der folgenden Methoden verfolgen:

  • Last updated on