Ontwikkelen met Media Services v3-API’s

media services logo v3


Zoekt u Media Services v2-documentatie?

Als ontwikkelaar kunt u clientbibliotheken gebruiken voor (.NET, Python, Node.js, Java, Go en Ruby REST API) waarmee u eenvoudig aangepaste mediawerkstromen kunt maken, beheren en onderhouden. De Media Services v3-API is gebaseerd op de OpenAPI-specificatie (voorheen bekend als een Swagger).

In dit artikel worden regels besproken die van toepassing zijn op entiteiten en API's wanneer u ontwikkelt met Media Services v3.

Waarschuwing

Het is niet raadzaam om de REST API voor Media Services rechtstreeks in uw eigen bibliotheekcode te verpakken. Als u dit voor productiedoeleinden goed doet, moet u de volledige logica voor opnieuw proberen van Azure Resource Management implementeren en inzicht krijgen in het beheren van langlopende bewerkingen in Azure Resource Management-API's. Dit wordt automatisch afgehandeld door de client-SDK's voor verschillende talen ( .NET, Java, TypeScript, Python, Ruby, enzovoort) en vermindert de kans dat u problemen hebt met rety-logica of mislukte API-aanroepen. De client-SDK's verwerken dit allemaal al voor u. De Postman-verzameling wordt meer aangeboden als een onderwijshulpprogramma en om u te laten zien wat de client-SDK's daadwerkelijk op de kabel doen tijdens de ontwikkeling met de verschillende client-SDK's.

Toegang tot de API van Azure Media Services

Om te worden geautoriseerd voor toegang tot Media Services-resources en de API van Media Services, moet u eerst worden geverifieerd. Media Services biedt ondersteuning voor verificatie op basis van Azure AD (Azure Active Directory). Twee algemene verificatieopties zijn:

  • Verificatie van service-principal: Wordt gebruikt om een service te verifiëren (bijvoorbeeld: web-apps, functie-apps, logische apps, API en microservices). Toepassingen die meestal gebruikmaken van deze verificatiemethode, zijn apps waarmee daemonservices, services uit de middelste laag, of geplande taken worden uitgevoerd. Voor web-apps moet er bijvoorbeeld altijd een middenlaag zijn die verbinding maakt met Media Services met een service-principal.
  • Gebruikersverificatie: Wordt gebruikt om een persoon te verifiëren die de app gebruikt om te communiceren met Media Services-resources. De interactieve app moet de gebruiker eerst vragen om zijn/haar referenties. Een voorbeeld is een beheerconsole-app die door geautoriseerde gebruikers wordt gebruikt om coderingstaken of livestreams te bewaken.

Voor de API van Media Services is vereist dat de gebruiker of app die de REST API-aanvragen doet, toegang heeft tot het Media Services-account en beschikt over de rol Inzender of Eigenaar. Toegang tot de API met de rol Lezer is ook mogelijk, maar dan zijn alleen Get- of List-bewerkingen beschikbaar.Zie Op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC)voor Media Services accounts voor meer informatie.

In plaats van een service-principal te maken, kunt u overwegen beheerde identiteiten te gebruiken voor Azure-resources, om via Azure Resource Manager toegang te krijgen tot de API van Media Services. Zie Wat zijn beheerde identiteiten voor Azure-resources voor meer informatie over beheerde identiteiten voor Azure-resources.

Azure AD-service-principal

De Azure AD-app en service-principal moeten zich in dezelfde tenant. Nadat u de app hebt aangemaakt, geeft u de app-rol Inzender of Eigenaar toegang tot het Media Services account.

Zie Vereiste machtigingen als u niet zeker weet of u machtigingen hebt om een Azure AD-app te maken.

In de volgende afbeelding vertegenwoordigen de getallen de stroom van de aanvragen in chronologische volgorde:

App-verificatie in de middelste laag met AAD van een web-API

  1. Een app in de middelste laag vraagt een Azure AD-toegangs token aan met de volgende parameters:

    • Azure AD-tenant-eindpunt.
    • Media Services resource-URI.
    • Resource-URI voor REST Media Services.
    • Waarden voor Azure AD-apps: de client-id en het clientgeheim.

    Zie Access Azure Media Services API voor alle benodigde waarden.

  2. Het Azure AD-toegangsken wordt verzonden naar de middelste laag.

  3. De middelste laag verzendt een aanvraag naar de Azure Media REST API met het Azure AD-token.

  4. De middelste laag haalt de gegevens terug uit Media Services.

Voorbeelden

Zie de volgende voorbeelden die laten zien hoe u verbinding maakt met de Azure AD-service-principal:

Naamconventies

Namen van Azure Media Services v3-resources (bijvoorbeeld activa, taken, transformaties) zijn onderhevig aan de naamgevingsbeperkingen van Azure Resource Manager. In overeenstemming met Azure Resource Manager zijn de resourcenamen altijd uniek. U kunt dus alle unieke id-strings (bijvoorbeeld GUID's) gebruiken voor uw resourcenamen.

Media Services resourcenamen kunnen niet bestaan uit: '<', '>', '%', '&', ':', '\', '?', '/', '*', '+', '.', het enkele aan te geven teken of een besturingselementteken. Alle andere tekens zijn toegestaan. De maximale lengte van een resourcenaam is 260 tekens.

Zie Naming requirements and Naming conventions(Naamgevingsvereisten en Naamconventen) voor meer informatie over Azure Resource Manager naamgeving.

Namen van bestanden/blobs binnen een asset

De namen van bestanden/blobs in een asset moeten voldoen aan zowel de vereisten voor de blobnaam als de NTFS-naamvereisten. De reden voor deze vereisten is dat de bestanden kunnen worden gekopieerd van blobopslag naar een lokale NTFS-schijf voor verwerking.

Langlopende bewerkingen

De bewerkingen die zijn gemarkeerd x-ms-long-running-operation met in Azure Media Services swagger-bestanden zijn langdurige bewerkingen.

Zie Asynchrone bewerkingen voor meer informatie over het bijhouden van asynchrone Azure-bewerkingen.

Media Services heeft de volgende langlopende bewerkingen:

Wanneer een lange bewerking is ingediend, ontvangt u een '201 Gemaakt' en moet u een poll uitvoeren voor voltooiing van de bewerking met behulp van de geretourneerde bewerkings-id.

In het artikel Asynchrone Azure-bewerkingen volgen wordt uitvoerig beschreven hoe de status van asynchrone Azure-bewerkingen wordt gevolgd aan de hand van waarden die zijn geretourneerd in het antwoord.

Slechts één langlopende bewerking wordt ondersteund voor een bepaalde livegebeurtenis of een van de bijbehorende live-uitvoer. Zodra de bewerking is gestart, moet een langdurige bewerking worden voltooid voordat een volgende langlopende bewerking op dezelfde LiveEvent of alle bijbehorende live-uitvoer wordt gestart. Voor livegebeurtenissen met meerdere live-uitvoer moet u wachten op de voltooiing van een langdurige bewerking op de ene live-uitvoer voordat u een langdurige bewerking op een andere live-uitvoer activeert.

SDK's

Notitie

De Azure Media Services v3 SDK's zijn niet gegarandeerd thread-veilig. Wanneer u een app met meerdere threads ontwikkelt, moet u uw eigen threadsynchronisatielogica toevoegen om de client te beveiligen of een nieuw AzureMediaServicesClient-object per thread te gebruiken. U moet ook voorzichtig zijn met problemen met meerdere threads die worden geïntroduceerd door optionele objecten die door uw code aan de client worden geleverd (zoals een HttpClient-exemplaar in .NET).

SDK Referentie
.NET SDK .NET-ref
Java SDK Java-ref
Python SDK Python-ref
Node.js SDK Node.js-ref
Go-SDK Go-ref
Ruby SDK

Zie ook

Azure Media Services Explorer

Azure Media Services Explorer (AMSE) is een hulpprogramma beschikbaar voor Windows-klanten die kennis willen maken met Media Services. AMSE is een Winforms/C#-toepassing voor het uploaden, downloaden, coderen en streamen van VOD en live-inhoud met Media Services. Het AMSE-hulpprogramma is voor clients die Media Services willen testen zonder code te schrijven. De AMSE-code wordt geleverd als een bron voor klanten die willen ontwikkelen met Media Services.

AMSE is een Open-Source-project, en dus wordt er ondersteuning geboden door de community (problemen kunnen worden gemeld aan https://github.com/Azure/Azure-Media-Services-Explorer/issues). Op dit project is de Microsoft Open Source Code of Conduct (Microsoft Open Source-gedragscode) van toepassing. Zie de Veelgestelde vragen over de gedragscode voor meer informatie of neem contact op met andere vragen of opencode@microsoft.com opmerkingen.

Filteren, orden, pagineren van Media Services entiteiten

Zie Filteren, orden, pagineren van Azure Media Services entiteiten.

Vragen stellen, feedback geven, updates ophalen

Ga naar het artikel van de Azure Media Services-community voor verschillende manieren om vragen te stellen, feedback te geven en updates voor Media Services op te halen.

Zie ook

Zie Access Azure Media Services API voor alle benodigde waarden.

Volgende stappen