Microsoft Azure

Artikel
05/05/2015

Microsoft Azure Media Services

Laden Sie die Codebeispiele herunter

Microsoft hat über Jahre hinweg geholfen, die umfangreiche Livestream-Videobereitstellung zu entwerfen und zu unterstützen. Ein Paradebeispiel hierfür war die 2014 stattfindende Winterolympiade in Sotschi. Hierfür waren umfangreiche technologische Ressourcen, einschließlich Hardwareserver, Quellvideostreams, Codierung, Serverredundanz (duale Rechenzentren), ausgabeadaptive Videostreams, Netzwerke für die Inhaltsübermittlung (Content Delivery Networks, CDNs), Partnerunternehmen und natürlich Microsoft-Personal erforderlich.

All diese Ressourcen – zusammen mit der Kundensoftwareentwicklung – sind erforderlich, um sicherzustellen, dass die durchgängige Videoveranstaltung mit nur wenigen oder ohne Zwischenfälle ausgeführt wird. Die Kosten der Orchestrierung dieser Ressourcen spiegeln sich auf der Skala der Livestreamveranstaltung wider. Es ist ein hoher Kapitalaufwand zum Erwerben der erforderlichen Server, Switches und der zugehörigen Technologie vonnöten. Dies führt zu offensichtlichen Risiken und den folgenden Fragen:

Wurde genug oder zu viel Hardware erworben, um der Liveveranstaltung gerecht zu werden?
Was machen Sie mit besagter Hardware bis zur nächsten Veranstaltung?
Wie lange wird die erworbene Technologie relevant bleiben?
Wurden die richtigen Technologiepartner involviert, um die fehlerfreie Orchestrierung der Veranstaltung zu gewährleisten?

Unter Berücksichtigung von Microsofts Beteiligung, Know-how und Erfolg bei Livevideoveranstaltungen hat das Microsoft Azure Media Services-Team Livestreams entwickelt, um diese Risiken zu vermeiden. Das Team hat globale Videofeeds der 2014 stattfindenden Winterolympiade in Sotschi auf Grundlage von Microsoft Azure Media Services live gestreamt. Obwohl dies eine äußerst große Veranstaltung war, bietet Microsoft Azure eine bedarfsgesteuerte Hardware, die auf die Skalierbarkeit abzielt.

In Abhängigkeit der Größe der Livevideoveranstaltung erstellt eine Anforderung zu Azure Media Services möglicherweise eine Skalaeinheit (klein, mittel oder groß), um Hunderttausenden oder auch nur Hunderten von Betrachtern den Livevideostream bereitzustellen. Die Preisgestaltung ermöglicht Modelle auf Nutzungsbasis zum Beschaffen, Verwenden und Veröffentlichen der Livestreamdienste, vorausgesetzt, die Kosten sind vor einer Veranstaltung bekannt. Die Hardware und Infrastruktur wird regelmäßig aufgerüstet und aktualisiert. Microsoft hält außerdem strategische Beziehungen aufrecht, die für das Bereitstellen von Livestreamlösungen relevant sind.

In diesem Artikel konzentriere ich mich auf ein Beispielszenario, welches das neue Livestreaming des Microsoft Azure Media Services-Teams (zurzeit in der privaten Vorschau) verwendet, auf oben genannte Risiken abzielt und die Beziehung des Livestreamangebots zum vorhandenen Video-on-Demand-Dienst (VOD) erörtert.

Konzepte und Begrifflichkeiten

Es ist wichtig, einige allgemeine Konzepte und Begrifflichkeiten in Bezug auf Azure Media Services zu verstehen. Der Begriff "Kanal" ist aus Entwicklersicht der durchgängige Pfad, den ein Livevideostream über Azure Media Services durchläuft. Ein Kanal kann verschiedene Status aufweisen, wobei der angehaltene und laufende Status die beiden wichtigsten darstellen. Ein Kanal umfasst die folgenden Komponenten, die die Videostreams durch das System koordinieren:

Erfassungs-URI: Stellt einen Zugangspunkt dar, an dem der Kanal mindestens einen Videobitratenstream für die Bereitstellung empfängt.
Vorschau-URI: Stellt einen Austrittspunkt des Livestreams, wie er durch den Kanal empfangen wird, dar, der nur für Überwachungszwecke verwendet werden sollte.
Programm: Ist mit einem Kanal verknüpft und stellt eine Teilmenge des im Blob-Speicher als Asset bleibenden Livestreams dar. Mindestens ein Programm sollte in einem Kanal erstellt werden und in einem ausführbaren Status sein, um einen Livevideostream zu ermöglichen. Das Programm wird das Video aktiv erfassen, während es sich in einem ausführbaren Status befindet.
Asset: Mit einem Programm verknüpft – stellt im Blob-Speicher gespeicherte Daten dar. Ein Asset enthält möglicherweise eine oder mehrere Dateien, dazu zählen auch Videos, Audio, Bilder, Miniaturansichtssammlungen und ein Manifest. Das Asset ist möglicherweise weiterhin vorhanden, nachdem ein Programm gelöscht wurde.
Locator: Mit dem Asset und einem Ursprung verknüpft. Ein Locator stellt einen URI bereit, der als Austrittspunkt des Liveprogrammstreams verwendet wird.
Ursprung: Mit einem Locator verknüpft. Dieser repräsentiert den skalierbaren Austrittspunkt für die Bereitstellung des Videostreams aus der Locator-URI eines Assets in Mehrfachbitraten-Formaten (Multiple Bitrate, MBR) wie Smooth, HLS (https Live Streaming) und Dynamic Adaptive Streaming over https (DASH).

Azure Media Services gewährleistet, dass die entsprechende Redundanz erstellt wird und für die zuverlässige Bereitstellung von Videos im entsprechenden Maßstab verfügbar ist. Diese Bereitstellung könnte viele Geräte umfassen, die variierende Streamingformate wie Smooth, HLS und DASH verwenden. Abbildung 1 zeigt den Aufbau eines Kanals.

Abbildung 1 – ein Übermittlungskanal ist der vollständige durchgängige Pfad eines Livevideostreams

Es ist wichtig, die Beziehung zwischen einem Kanal und mindestens einem im Kanal erstellten Programm zu verstehen. In Abbildung 2 wurde eine Livevideoveranstaltung auf einer Kanaldarstellung zugeordnet, die zwischen 17 Uhr und 2 Uhr einen ausführbaren Status aufweist. Es ist wichtig zu beachten, dass die Übergangszeit des Kanals von einem angehaltenen zu einem ausführbaren Status 10–20 Minuten in Anspruch nehmen kann. Die Intervallmarkierungen – "Concert1", "Vip1", "Act1", "Act2" und "Vip2" – stellen Programme und ihre geplanten Start- und Stoppzeiten dar. Abschließend stellen die Intervallmarkierungen namens "Transition" (Übergang) die Zeit zwischen dem aktuellen Programm und dem nächsten Programm dar, in der ein Programm gestoppt und das andere gestartet wird.

Abbildung 2 – eine Livevideoveranstaltung, die so zugeordnet ist, dass sie 17 Uhr gestartet und 2 Uhr angehalten wird

Dies ist ein Beispiel, wie eine Zeitvorgabe einem Kanal mit Programmen zugeordnet werden kann. Wie in Abbildung 2 definiert, gibt es ein Programm, das die gesamte Veranstaltung umspannt.

"Concert1" befindet sich zwischen 17:15 Uhr und 2 Uhr in einem ausführbaren Status, und zwar mit einem gleitenden Videopuffer von 10 Minuten. Die Pufferung ermöglicht Benutzern das Zurückspulen, während sie einen Media Player zum Anschauen verwenden. Das Programm "Concert1" stellt den primären Livevideostream der gesamten Veranstaltung bereit. Die CDNs werden mit URIs zwecks Zuordnung vor der Veranstaltung bereitgestellt.

Die verbleibenden Programme – "Vip1", "Act1", "Act2" und "Vip2" – sollten während der definierten Start- und Stoppzeiten in einem ausführbaren Status sein, und zwar mit einer zulässigen Abweichung für Übergänge. Ein Programm wird weder unmittelbar gestartet noch angehalten. Sie müssen Übergänge beim Planen einer Liveveranstaltung in Erwägung ziehen. Sie können gleichzeitig über mehrere Programme in einem ausführbaren Status verfügen, die allesamt Video aufzeichnen. "Concert1" und ein anderes Programm werden während der Veranstaltung gestartet und angehalten. Um Ihnen zu zeigen, wie Sie einen Übergang verwenden können, könnten Sie eine Programmstartanforderung für "Vip2" um 18:45 Uhr ausstellen, anschließend eine Programmstoppanforderung für "Vip1" um 19 Uhr, wobei eine 15-minütige Übergangszeit gegeben sein muss. Daher könnten während dieses 15-minütigen Übergangs drei Programme einen ausführbaren Status aufweisen.

Nach der Beschreibung der generellen Konzepte und Begrifflichkeiten konzentriere ich mich auf die Verwendung des Veranstaltungszeitplans (siehe Abbildung 2), der einem Benutzerszenario zugeordnet wurde, um mithilfe der Azure Media Services-API Codierungsbeispiele zu entwickeln.

Das Design: Contoso's Blues Bar

Als ein namhafter Veranstaltungsort in den Vereinigten Staaten für aufstrebende Musiker hat die Contoso’s Blues Bar enge Fristen zum Koordinieren eines bevorstehenden Livekonzerts für eine bekannte europäische Band namens "Contoso and the Shock Wallets". Die Fangemeinde der Band ist hauptsächlich in Europa angesiedelt. Die Show im Contoso’s ist das Debüt der Band in den Vereinigten Staaten. Daher müssen die Showmanager das Konzert live streamen, sodass die europäische Fangemeinde das Konzert auf den jeweiligen Computern und Mobilgeräten anschauen kann.

Der CIO der Contoso’s Blues Bar setzt eine Besprechung an und bittet sein Technologieteam darum, nach einer Lösung zu suchen bzw. eine zu empfehlen, die die folgenden Anforderungen erfüllt:

Sie muss einfach implementierbar sein.
Sie muss das Streamen von Videos für eine Vielzahl unterschiedlicher Gerätekonfigurationen ermöglichen.
Sie muss unbekannte Skalierbarkeitsanforderungen erfüllen.
Die Kosten basieren während der Veranstaltung auf einer Nutzungsbasis.

Sprint eins

Das Veranstaltungsplanungsteam der Contoso’s Blues Bar verbringt die nächsten paar Tage damit, ihre User Storys festzulegen. Diese User Storys sind die Grundlage für die Sprint-Planung, um das Videostreaming des Livekonzerts bereitzustellen. Im Meeting definiert das Team einige Wissenslücken, die während Sprint eins einige Unannehmlichkeiten – oder Fragen, die eine Lösung erfordern – erzwingen. Das Team definiert zudem die folgende Liste größerer User Storys, die für gewöhnlich als Epics bezeichnet werden und folgendes standardmäßiges Format aufweisen: "Als ein … möchte ich, … um …":

Als ein Fan von Contoso and the Shock Wallets möchte ich das Livekonzert auf meinem Gerät mit der nach Möglichkeit höchsten Videoqualität ansehen, um Ihr Debüt in den Vereinigten Staaten genießen zu können.

Als ein Fan von Contoso and the Shock Wallets möchte ich später ein Video des Konzerts auf meinem Gerät mit der nach Möglichkeit höchsten Videoqualität ansehen, um Ihr die Veranstaltung in meiner Freizeit ansehen zu können.

Als ein Vertreter der Contoso’s Blues Bar möchte ich eine Liveübertragung unserer Konzerte bereitstellen und den Aufwand der Livestreamvideo-Bereitstellung von unserem Veranstaltungsort reduzieren, um weitere Musiker und Kunden bei gleichzeitiger Kosteneinsparung für uns zu gewinnen.

Die User Storys und zugehörigen Spike-Ermittlungen umfassen:

User Story 1.1: Als ein Angestellter der Veranstaltungsproduktion möchte ich mindestens eine Kamera, um das Livekonzert aufzuzeichnen.

Spike 1.1.1: Welcher Kameratyp wird verwendet, und wie lautet der Ausgabevideostream?

Die Produktionsmitarbeiter erfahren, wie sie hochqualitative Videokameras erwerben können, um einen HD-Video-/-Audiostream über eine serielle, digitale Schnittstelle (Serial Digital Interface, SDI) zu produzieren.

User Story 1.2: Als ein Mitarbeiter der Veranstaltungsproduktion möchte ich das Livevideo zum Internet streamen, um Fans zu ermöglichen, ein Konzert anzuschauen.

Spike 1.2.1: Wie wird der Kameravideofeed zur Produktionsstation übermittelt?

Das Produktionsteam erfährt, dass Contoso Switch Company einen HD-SDI-zu-Glasfaser-Videoswitch produziert. Es kann diesen Switch mit bis zu vier Kameras verwenden.

Spike 1.2.2: Wie wird dieser Videofeed zur IT-Abteilung übermittelt?

Das Produktionsteam erfährt, dass der Glasfaser-Videoswitch einen HD-SDI-Video-/-Audiostream ausgibt, der mit einem Audio-/Video-Switcher verbunden werden kann. Es kann anschließend über eine Übertragungskonsole kontrollieren, welches Kamerasignal aktiv ist. Der Livevideofeed wird von der Übertragungskonsole schließlich durch eine HD-SDI-Verbindung gesendet.

User Story 1.3: Als ein Mitarbeiter der IT-Abteilung möchte ich den Videostream auf Windows-, iOS- und Android-Geräten bereitstellen, um die maximale Geräteunterstützung für das Konzertvideo anzubieten.

Spike 1.3.1: Welchen Videofeedtyp empfange ich, um Video zum Internet zu übermitteln?

Der HD-SDI-Videofeed wird an die IT-Abteilung gesendet.

Spike 1.3.2: Welcher Typ der Videofeeds ist für die Zielgeräte erforderlich?

Die Mitarbeiter der IT-Abteilung ermitteln, dass sie die folgenden adaptiven Videoprotokolle verwenden können, um Videos auf jedem der folgenden Zielgeräte bereitzustellen:

Smooth Streaming: Windows 8 und Windows Phone 8
HLS: iOS und Android
DASH: Windows 8.1, Windows Phone 8 und Xbox One

Spike 1.3.3: Wie übermittle ich dieses Video zum Internet in einer skalierbaren Weise?

Die Mitarbeiter der IT-Abteilung erfahren, dass Microsoft ein neues Feature auf Azure angekündigt hat, welches speziell auf das Streamen von Livevideos über das Internet abzielt. Nach ein wenig Recherche findet das Team heraus, dass Azure Media Services als Zwischenschicht zwischen ihrem Veranstaltungsort und den Zielgeräten fungiert. Am wichtigsten ist jedoch, dass sie die folgenden Details über Azure Media Services erfahren:

Sobald Sie sich für ein Azure-Konto registriert haben und ein Medienkonto hinzufügen, können Sie einen Livestreamingkanal erstellen. Ein Livekanal wird als Synonym zu einem TV-Kanal verwendet. Sämtliche zugeordneten Serverressourcen sind für diesen Kanal vorgesehen, um Ihre Programme zu übermitteln. Ein Kanal verfügt möglicherweise über viele Programme. Ein Programm ist die Definition eines Zeitfensters und des zugehörigen Assets. Ein Asset ist ein Speicherort des gestreamten Videos in Azure Media Services.
Die Serverzuordnung gewährleistet, dass die Redundanz in den Videopfad ohne eine einzelne Fehlerquelle integriert ist.
Ein Livevideostream kann als RTMP oder MPEG TS durch Azure Media Services über einen Erfassungs-URI empfangen werden.
Geräte können einen Videostream anfordern, der systemeigen unterstützt wird. Microsoft Azure Media Services gewährleistet auf Basis eines gerätespezifischen URI, dass das Video im entsprechenden Format gepackt ist.
Die Unterstützung ist in den Livestreaming-Ursprungsservern für den sicheren Zugriff durch einen CDN-Anbieter wie Akamai Technologies integriert.

Zusätzliche Ergebnisse der Spikes 1.3.1 und 1.3.2: Die Mitarbeiter der IT-Abteilung wählen einen Encoder aus, der einen HD-SDI-Video-/Audiostream empfangen kann. Diese Encoder kann die HD-SDI-Streams verwenden, um MBR-Streams dynamisch für die Übermittlung zu Azure Media Services zu generieren, die einen eingehenden URI bereitstellen, der RTMP oder MPEG TS als eine Eingabeformat akzeptiert.

Sprint zwei

Nach den Kaffee am Morgen beginnen die Entwickler mit dem Entwickeln von Code, der die Livestreamingveranstaltung ermöglicht.

User Story 1.4.1: Als ein Entwickler möchte ich die entsprechenden Azure-Konten erstellen, um mit dem Schreiben von Code zum Streamen eines Videos beginnen zu können.

Wechseln Sie zur Azure-Website (azure.microsoft.com), klicken Sie auf die Schaltfläche "Kostenlose Testversion", und befolgen Sie die Schritte. Unter bit.ly/1mfacft erfahren Sie mehr über das Einrichten eines Kontos. Während des Registrierungsvorgangs können Sie ein Windows-Konto erstellen, das als Administratoranmeldedaten verwendet wird. Zum Erstellen eines Azure Media Services-Kontos müssen Sie zunächst ein Azure Storage-Konto erstellen, da die Videoassets für eine Liveveranstaltung im Blob-Speicher gespeichert werden. In der Azure Media Services-Dokumentation wird auch empfohlen, dass Sie das Speicherkonto im selben Rechenzentrum erstellen, von dem aus Sie das Azure Media Services-Konto beziehen. Erstellen Sie beispielsweise ein Speicherkonto und ein Medienkonto im Rechenzentrum "US-WEST".

User Story 1.4.2: Als Entwickler möchte ich Code zum Verwalten eines Kanals schreiben, um eine Livestreamingveranstaltung bereitzustellen.

Erstellen Sie mit Visual Studio 2012 ein Basisprojekt. Installieren Sie als Nächstes die NuGet-Pakete für Azure Media Services. Erstellen Sie eine Funktion namens "CreateContosLiveEvent", und beginnen Sie mit einem "CloudMediaContext"-Objekt, das immer zum Verwalten Ihrer Livestreams verwendet wird:

private void CreateContosLiveEvent()
{
  string liveAccount = "yourAzureMediaAccount";
  string liveKey = "yourAzureMediaAccountKey";
  CloudMediaContext LiveServices = new CloudMediaContext(
    liveAccount,  // URI created earlier
    liveKey );    // Account name

Notieren Sie sich den Code, um sicherzustellen, dass ein Ursprungsdienst ausgeführt wird. Der Ursprungsdienst übermittelt die Livestreams an die CDN-Anbieter (siehe Abbildung 3).

Abbildung 3 – ein Ursprungsdienst übermittelt Livevideostreams an CDN-Anbieter

string originName = "abcdefg";
IOrigin origin = LiveServices.FindOrigin(originName);
if (origin == null)
{
  Task<IOrigin> originTask = 
    LiveServices.Origins.CreateAsync(originName, 2);
  originTask.Wait();
  origin = originTask.Result;
}
if (origin.State == OriginState.Stopped)
{
  origin.StartAsync().Wait();
}

Anschließend müssen Sie Code schreiben, um einen Kanal zu erstellen (siehe Abbildung 4). Für einen Kanal muss eine Sicherheit konfiguriert sein, um die Authentifizierung der eingehenden Videostreamquelle zu ermöglichen. Die Quelle ist für gewöhnlich ein IP-konfigurierter Encoder, der ein HDI-SDI-Signal in die erforderlichen MBR-Videostreams umwandelt.

Abbildung 4 – Erstellen eines Kanals für Ihren Videofeed

string channelName = "ContsoBluesChannel";
IChannel channel = LiveServices.FindChannel(channelName);
if (channel != null)
{
  Debug.WriteLine("Channel already exists!");
  return;
}
ChannelSettings settings = new ChannelSettings();
Ipv4 ipv4 = new Ipv4();
// Currently setting IP to 0.0.0.0/0 allows all connections
//  Don't do this for production events
ipv4.IP = "0.0.0.0/0";
ipv4.Name = "Allow all connections";
// Protect the ingest URI
settings.Ingest = new IngestEndpointSettings();
settings.Ingest.Security = new SecuritySettings();
settings.Ingest.Security.IPv4AllowList = new List<Ipv4>();
settings.Ingest.Security.IPv4AllowList.Add(ipv4);
// Protect the preview URI
settings.Preview = new PreviewEndpointSettings();
settings.Preview.Security = new SecuritySettings();
settings.Preview.Security.IPv4AllowList = new List<Ipv4>();
settings.Preview.Security.IPv4AllowList.Add(ipv4);
// Create the channel
Task<IChannel> taskChannel = LiveServices.Channels.CreateAsync(
  channelName, "video streaming", ChannelSize.Large, settings);
taskChannel.Wait();
channel = taskChannel. Result;

Der Beispielcode konfiguriert die Erfassung und Vorschau der URIs mit einer auf "0.0.0.0/0" festgelegten CIDR-formatierten (Classless Inter-Domain Routing, klassenloses domänenübergreifendes Routing) IP-Adresse. Dadurch können alle IP-Adressen auf die Erfassungs- und Vorschau-URIs zugreifen. Für Produktionskanäle empfiehlt es sich, dass Sie den Zugriff beschränken, indem Sie bekannte Werte wie die IP-Adresse Ihres Encoders oder Ihrer Authentifizierungstoken verwenden. Verwenden Sie einen eindeutigen Kanalnamen. Es wird eine Ausnahme ausgelöst, wenn bereits ein Kanal mit demselben Namen vorhanden ist.

Schreiben Sie en Code, der die Programme, zugehörige Assets und Locators erstellt (siehe Abbildung 5). Die für die Namen und Zeitfenster verwendeten Werte stehen im Zusammenhang mit den Werten aus Abbildung 2. Die Kennzeichnung "enableArchive" ist während der Programmerstellung für alles mit Ausnahme von "Concert1" auf "true" festgelegt. Der Wert "true" zeigt an, dass ein Livevideostream, während sich das Programm in einem ausführbaren Status befindet, aufgezeichnet wird und dauerhaft im zugehörigen Asset für die spätere Verwendung als VOD verbleibt. In der Manifestdatei des Assets wird der Locator mit einer Zugriffsrichtlinie von 30 Tagen erstellt. Dadurch wird ein URL für das Streamingvideo bereitgestellt.

Abbildung 5 – Erstellen des während der Ausführung Ihres Feeds laufenden Programms

// Define the program name, DVR window and estimated duration in minutes.
// NOTE: DVR window value most likely will be removed when service 
// reaches public preview.
Tuple<string, int, int>[] programSettings = new Tuple<string, int, int>[]
{
  new Tuple<string,int,int>( "Concert1", 60, 60 ),
  new Tuple<string,int,int>( "Vip1", 75, 75 ),
  new Tuple<string,int,int>( "Act1", 90, 90 ),
  new Tuple<string,int,int>( "Act2", 165, 165 ),
  new Tuple<string,int,int>( "Vip2", 120, 120 ),
};
foreach (Tuple<string, int, int> programSetting in programSettings)
{
  IAsset asset = null;
  // To persist specific program's asset for Video on Demand (VOD) this
  // code tests if the DVR window and Event duration equal in length.
  // If true it sets the enable archive flag to true, which tells the
  // system a program's asset should not be deleted automatically.
  bool enableArchive = programSetting.Item2 == programSetting.Item3;
  try
  {
    // Create the asset that is used to persist the video streamed
    // while the program is running and VOD.
    asset = LiveServices.Assets.Create(programSetting.Item1 + "_asset",
      AssetCreationOptions.None);
    Task<IProgram> taskProgram = channel.Programs.CreateAsync(
      programSetting.Item1,
      "program description",
      // Enable archive note forcing to true for now
      true, // enableArchive,
    // NOTE: DVR window value most likely will be removed
    // This is not used
    TimeSpan.FromMinutes(programSetting.Item2),
    // Estimated duration time
    TimeSpan.FromMinutes(programSetting.Item3),
      asset.Id);
    taskProgram.Wait();
    LiveServices.CreateLocators(asset, TimeSpan.FromDays(30));
  }
  catch (Exception exp)
  {
    Debug.WriteLine(exp.Message);
  }
}

Sie können einen Ursprungs-URI von einem Locator abrufen, und zwar wie mit einem Azure Media Services-VOD-Asset Anschließend würden Sie diesen dem CDN-Anbieter Ihrer Wahl bereitstellen. Da die Kennzeichnung "enableArchive" festgelegt wurde, können Sie, sobald ein Programm angehalten wurde, denselben URI zum Übermitteln des Livestreams als ein VOD-Asset verwenden.

Die verbleibende Aufgabe besteht darin, den zum Starten eines Kanals und der Programme ggf. erforderlichen Code zu schreiben. Die Anforderung, einen Kanal zu starten, signalisiert Azure Media Services mit dem Zuordnen von Ressourcen für die eingehenden Dienste, Redundanz und den Lastenausgleich zu beginnen. Beim Start eines Kanals kann die Zeit zwischen dem Starten und Ausführen von Status zwischen 10 und 20 Minuten dauern.

Sie sollten den Kanals rechtzeitig vor der Veranstaltung starten, um nicht die Möglichkeit der Anzeige des Livevideostreams zu beeinträchtigen. Es ist zudem wichtig zu beachten, dass die Berechnung der Gebühren akkumuliert wird, sobald Ihr Kanals gestartet wird. Wenn Sie nicht planen, einen Livekanal rund um die Uhr laufen zu lassen, sollten Sie den Kanal und die zugehörigen Programme anhalten, wenn sie nicht verwendet werden. Der zum Starten eines Kanals tatsächlich erforderliche Code ist ziemlich einfach:

// Start channel
Task start = channel.StartAsync();
start.Wait();

Gleiches gilt für den zum Start des Programms benötigten Code:

start = program.StartAsync();
start.Wait();

Eine Hauptanforderung für die Veranstaltung ist die Fähigkeit, den Zeitpunkt zu steuern, wann jedes Programm gestartet und angehalten werden soll. Daher ist das nächste Element vor der Entwicklung eine einfache Benutzeroberfläche, welche die Veranstaltung in ihrer Gesamtheit erstellt, indem die Methode "CreateContosLiveEvent" aufgerufen wird. Dadurch wird das Starten und Anhalten des Kanals und jedes zugehörigen Programms bei Bedarf zugelassen.

Zur Realisierung des Szenarios waren die anderen Teammitglieder mit dem Einrichten der Kameras, dem Verlegen von Kabeln, dem Installieren eines Videoencoders und dem Konfigurieren von CDNs beschäftigt, während Sie die Anwendung mithilfe von Azure Media Services entwickelt haben. Abschließend führen die Mitarbeiter eine Reihe von Tests aus, um zu gewährleisten, dass das durchgängige Szenario funktioniert.

Sobald das tatsächliche Konzert stattfindet, wird ein Livevideostream gestartet, und unterschiedliche Benutzergeräte, Desktopcomputer und Tablets stellen eine Verbindung zu Azure Media Services her, um die Livevideostreams anzuschauen. Bei Testläufen werden immer einige wenige Probleme aufgedeckt, die Mitarbeiter arbeiten jedoch daran, die Macken zu beseitigen, und die gesamte harte Arbeit erfolgt rechtzeitig, um das Livevideostreaming des Konzerts zu zeigen.

Die Vereinfachung einer anspruchsvollen Aufgabe

Das Hosten von Livevideoveranstaltungen kann in der Realität eine anspruchsvolle Aufgabe sein. Bevor Lösungen wie Azure Media Services Livestreamingvideos bereitstellen können, sind oftmals erhebliche Investitionen für die Infrastrukturausstattung erforderlich. Andere kritische Entscheidungen umfassen die Anzahl der Systeme, die zum Unterstützen unterschiedlicher Veranstaltungen, die in puncto Größe und Maßstäbe variieren, erforderlich sind. Solche Einkäufe erfolgen oftmals entweder mit einer zu großen oder einer zu geringen Bereitstellung. Microsoft Azure Media Services reagiert auf diese Komplexität und Kosten. Das Live-Angebot baut auf dem Azure Media Services-VOD-Featuresatz auf. Es bietet eine einzelne, vereinheitlichte Plattform und APIs, um der Industrie sowohl Live- als auch VOD-Inhalte im entsprechenden Maßstab bereitzustellen.

Gregory Prentice ist ein erfahrener Softwarearchitekt mit einer über 25-jährigen Erfahrung in Bezug auf das Entwerfen und Erstellen von Anwendungen für verschiedene Start-up-Unternehmen. Er begann für Microsoft mit der Entwicklung der folgenden Projekte zu arbeiten: Locadio, Microsoft Hohm und Microsoft Utility Rates Service. Zuletzt unterstützte er die Microsoft Azure Media Services- und Delta Tre-Teams bei der Bereitstellung des Livevideostreams für die 2014 stattfindende Winterolympiade in Sotschi. Zurzeit fungiert er als ein Experte in der Gruppe "Developer and Platform Evangelism" bei Microsoft. Lesen Sie seinen Blog unter blogs.msdn.com/b/greg-prentice.

Unser Dank gilt den folgenden technischen Experten von Microsoft für die Durchsicht dieses Artikels: Steven Goulet, Principal PM, Live Services: und Jason Suess, Live Services für die letzten Olympischen Spiele