Questions courantes sur Azure Media Services

Consultez le guide de mise hors service d’Azure Media Services

En voici la liste :

• Spécification OpenAPI (Swagger)
• Azure CLI
• .NET
• Java
• Python
• Node.JS
• Go

Nous vous déconseillons d’essayer d’inclure l’API REST pour Media Services dans un wrapper directement dans votre propre code de bibliothèque. Pour le faire correctement à des fins de production, vous devrez implémenter toute la logique de nouvelle tentative d’Azure Resource Manager et comprendre comment gérer les opérations de longue durée dans les API Resource Manager. Les Kits de développement logiciel (SDK) clients pour différents langages (par exemple, .NET, Java, TypeScript, Python et Ruby) gèrent automatiquement cette tâche pour vous, afin de réduire les risques de problèmes liés à la logique de nouvelle tentative ou à l’échec des appels d’API.

Consultez les pages d’exemples. Il existe des exemples pour les comptes, les ressources, le streaming en direct, le streaming VOD, la protection de contenu, l’encodage, l’analytique et l’utilisation de lecteurs.

Lors de l’utilisation de la pagination, vous devez toujours utiliser le lien suivant pour énumérer la collection et ne pas dépendre d’une taille de page particulière. Pour voir des détails et des exemples, consultez Entités de filtrage, de tri et de pagination.

Pour plus d’informations sur l’utilisation de l’interface CLI dans le but d’associer Media Services à Azure Key Vault pour chiffrer vos données, consultez le tutoriel Utiliser une clé de Key Vault pour chiffrer les données dans un compte Media Services.

Si vous souhaitez que Media Services accède à un compte de stockage lorsque celui-ci est configuré pour bloquer les demandes provenant d’adresses IP inconnues, suivez les étapes décrites dans Accéder à un stockage avec une identité managée Media Services.

Voir Déplacement d’un compte Media Services entre abonnements.

Voir Contrôle d'accès en fonction du rôle Azure (Azure RBAC) pour les comptes Media Services.

Media Services définit les rôles intégrés suivants :

• Administrateur de compte Media Services
• Opérateur de média Media Services
• Administrateur de stratégie Media Services
• Administrateur de points de terminaison de streaming Media Services
• Administrateur d’événement en direct Media Services

Ces rôles sont détaillés dans Contrôle d'accès en fonction du rôle Azure (Azure RBAC) pour les comptes Media Services.

Ces rôles peuvent être utilisés pour donner un accès précis à un compte Media Services. Pour autoriser tous les accès à un compte Media Services, le rôle « Propriétaire » ou « Contributeur » peut être utilisé. Media Services dispose d'une ancienne API en voie d'obsolescence qui ne prend pas en charge le contrôle d'accès précis. Les clients qui ont besoin d'un contrôle d'accès précis ne doivent pas sélectionner « Activer les API classiques » lorsqu'ils créent un compte Media Services à l'aide du portail (ou utiliser la version 2020-05-01 de l'API s'ils utilisent l'API pour créer des comptes).

La stratégie Azure Policy intégrée suivante peut être utilisée pour bloquer la création de comptes qui prennent en charge l'ancienne API : les comptes Azure Media Services qui permettent l'accès à l'API v2 héritée devraient être bloqués - Microsoft Azure

Un élément multimédia Media Services est un conteneur de compte Stockage Azure qui est utilisé pour chaque fichier vidéo que vous chargez. Elle possède un identificateur unique qui est utilisé avec les transformations et d’autres opérations. Voir Actifs multimédias dans Azure Media Service v3.

Chaque fois que vous souhaitez charger un fichier multimédia et effectuer une opération dessus, comme l’encodage ou la diffusion en continu, vous créez un élément multimédia pour y stocker le fichier multimédia et les fichiers associés. Les ressources sont automatiquement créées pour vous si vous utilisez le portail Azure. Si vous n’utilisez pas le portail pour charger des fichiers, vous devez d’abord créer un élément multimédia.

Les formats d’encodage courants sont disponibles avec l’encodeur standard de Media Services. Pour obtenir la liste de tous les formats, consultez Codecs et formats de l’encodeur standard.

Vous pouvez créer un travail dans le portail Azure en utilisant Azure CLI, REST ou l’un des Kits de développement logiciel (SDK). Consultez les exemples de Media Services pour le langage de votre choix.

Oui. Voir Encoder avec une échelle de débit générée automatiquement.

Oui. Media Services peut effectuer une analyse en deux passes sur une vidéo. Il peut ensuite recommander le meilleur ensemble de débit binaire adaptatif, les meilleures résolutions et les meilleurs paramètres d’encodage en fonction du contenu de la vidéo.

Oui. Pour obtenir des détails et des liens vers un exemple d’application montrant comment charger un fichier MP4 à débit unique pré-encodé et générer le manifeste du serveur (.ism) et le manifeste du client (.ismc), consultez la réponse à la question « Puis-je diffuser en continu des fichiers MP4 existants qui sont préencodés ou encodés dans une autre solution ? » Cette réponse décrit également l’impact sur les performances de l’origine.

Nous ne le recommandons pas. Les contenus très courts, d’une durée inférieure à une ou deux minutes, ne sont pas idéaux pour le streaming à débit adaptatif. Si vous envisagez de diffuser en continu des fichiers de format très court, nous vous recommandons de préencoder le contenu dans un format qui est facilement diffusé en continu à débit unique.

Étant donné que la plupart des lecteurs à débit adaptatif ont besoin de temps pour mettre en mémoire tampon plusieurs segments de la vidéo, ainsi que pour l’analyse de la bande passante réseau avant d’adapter le réglage vers le haut ou vers le bas sur l’échelle à débit adaptatif, il est souvent inutile de fournir un débit élevé pour les contenus inférieurs à 30 secondes. Le temps que le lecteur verrouille son algorithme heuristique sur le débit approprié pour la lecture en fonction des conditions du réseau, le streaming du fichier est terminé.

En outre, certains lecteurs disposent par défaut d’une mise en mémoire tampon allant jusqu’à trois segments de vidéo. Chaque segment peut avoir une longueur de deux à six secondes. Pour les formats vidéo très courts, le lecteur est susceptible de mettre en mémoire tampon et de commencer la lecture du premier débit sélectionné de l’ensemble de débit adaptatif. C’est pourquoi nous vous recommandons d’utiliser un fichier MP4 à débit unique et de le charger sur un élément multimédia si vous avez besoin de la génération de manifeste HLS ou DASH. Pour plus d’informations sur la façon de procéder, consultez la réponse à la question « Puis-je diffuser en continu des fichiers MP4 existants qui sont préencodés ou encodés dans une autre solution ? » dans la section concernant l’emballage et la livraison.

Les fichiers doivent être livrés au format HLS ou DASH uniquement si vous souhaitez tirer parti des capacités de ces protocoles. Pour les flux à débit unique, ils peuvent encore offrir de nombreux avantages, comme une recherche plus rapide, la prise en charge de la gestion des droits numériques (DRM) et une plus grande difficulté à télécharger via une URL (mais possible) qu’un MP4 à téléchargement progressif dans un stockage blob. La prise en charge des sous-titres pour VTT et IMSC1 constitue un autre avantage. En outre, la possibilité de lier tardivement des rendus audio supplémentaires, ou des doublages dans d’autres langues, en fait un choix judicieux dans certaines situations.

Si vous recherchez des façons d’utiliser un encodeur Media Services pour effectuer des opérations telles que faire pivoter une vidéo, sous-découper une vidéo, assembler des vidéos, créer des miniatures et des sprites, nous disposons d’une multitude d’exemples de code sur la page Exemples de code. Les exemples de langages disponibles incluent Node.JS, Python, .NET et Java.

Un événement en direct Media Services est le processus qui consiste à ingérer des flux vidéo en direct et à les diffuser via un protocole RTMPS ou Smooth Streaming. Pour plus d’informations, consultez Événements en direct et sorties en direct dans Media Services.

La première étape consiste à choisir un encodeur local. Nous avons fourni des exemples de création d’un événement en direct avec Wirecast et OBS. Si vous préférez commencer par une présentation des événements en direct Media Services, consultez Types d’événements en direct.

Azure Media Services diffuse de la vidéo, de l’audio et du texte dans différents protocoles. Lorsque vous publiez votre stream en direct en MPEG-DASH ou HLS/CMAF, le service diffuse le texte transcrit en IMSC1.1 compatible TTML avec la vidéo et l’audio. Pour en savoir plus, consultez Transcription en direct.

Vous pouvez surveiller les événements en direct en vous abonnant à Azure Event Grid. Pour plus d’informations, consultez le schéma d’événement Event Grid. Vous pouvez :

• vous abonner aux événements Microsoft.Media.LiveEventEncoderDisconnected au niveau du flux et surveiller qu’aucune reconnexion ne survient pendant un certain temps pour arrêter et supprimer votre événement en direct ;
• vous abonner aux événements de pulsation au niveau de la piste. Si toutes les pistes ont une vitesse de transmission entrante de 0 ou si le dernier timestamp n’augmente plus, vous pouvez arrêter en toute sécurité l’événement en direct. Les événements de pulsation sont générés toutes les 20 secondes pour chaque piste, ce qui peut être un peu trop détaillé.

Non, vous ne pouvez pas facilement utiliser la même URL de diffusion en continu si vous arrêtez et redémarrez un événement en direct. Chaque fois que vous créez et publiez une nouvelle sortie en direct (et un nouvel élément multimédia), une nouvelle URL de diffusion en continu (GUID) sera utilisée pour le nouveau localisateur. De cette façon, vous êtes sûr qu’il n’y aura pas de conflit de cache dans le point de terminaison de streaming et le réseau de distribution de contenu (CDN). Vous pouvez préparer (et connaître) les URL de diffusion en continu à l’avance, car vous pouvez imposer un GUID spécifique pour le localisateur de streaming, puis décider du nom du manifeste à utiliser pour la sortie en direct.

Supposons que vous décidiez d’utiliser le GUID 1a7ed69e-a361-433d-8a56-29c61872744f pour la sortie en direct que vous créerez demain. Le jour venu, vous démarrez l’événement en direct et créez une sortie en direct. Vous pouvez décider d’utiliser « conference1 » pour le manifeste et imposer le GUID pour le localisateur.

L’URL de streaming est prévisible : il s’agit de http://<youraccountname>-<azureregion>.streaming.media.azure.net/1a7ed69e-a361-433d-8a56-29c61872744f/conference1.ism/manifest.

Vous ne pouvez pas réutiliser la même sortie en direct ou le même élément multimédia plusieurs fois. Imaginez la combinaison de la sortie en direct et de l’élément multimédia comme un enregistrement sur bande. Une fois que la sortie en direct a été enregistrée dans l’élément multimédia, vous ne pouvez plus la réutiliser pour un autre enregistrement. Il y aura un conflit de blobs ou des remplacements si vous le faites à nouveau. À moins que vous ne prévoyiez de vider complètement les blobs présents dans le compte de stockage et de vider complètement le CDN, il y aura des problèmes. Il y aura probablement encore des problèmes, car les fragments sont déjà mis en cache en aval au niveau du CDN ou dans les caches des appareils clients (par exemple, le cache du navigateur).

L’une des raisons les plus courantes est que le point de terminaison de streaming à partir duquel vous essayez de lire la vidéo n’est pas en état de fonctionnement.

Dans Media Services, un point de terminaison de streaming représente un empaquetage dynamique (juste-à-temps) et un service d’origine qui permet de transmettre votre contenu en direct et à la demande directement à une application de lecteur cliente en utilisant l’un des protocoles de streaming multimédia courants (HLS ou DASH). En outre, le point de terminaison de streaming offre un chiffrement dynamique (juste-à-temps) aux systèmes DRM de pointe. Pour plus d’informations, consultez Points de terminaison de streaming (origine) dans Azure Media Services.

Pour rendre les vidéos disponibles en lecture pour les clients, vous devez créer un localisateur de streaming, puis générer des URL de diffusion en continu. Les localisateurs de streaming sont également utilisés pour appliquer des stratégies de diffusion en continu qui contiennent des règles sur la façon dont les fichiers multimédias sont consommés.

Pour générer une URL de diffusion en continu, vous devez d’abord créer un localisateur de streaming. Ensuite, vous concaténez le nom d’hôte du point de terminaison de streaming et le chemin du localisateur de streaming.

Les stratégies de diffusion en continu vous permettent de définir les protocoles de diffusion en continu et les options de chiffrement de vos localisateurs de streaming. Media Services v3 fournit quelques stratégies de diffusion en continu prédéfinies. Pour plus d’informations, consultez Stratégies de diffusion en continu.

Pour obtenir une liste de stratégies prédéfinies que vous pouvez utiliser pour commencer, consultez Stratégies de diffusion en continu.

Vérifiez que (format=m3u8-cmaf) est présent à la fin du chemin (après la partie /manifest de l’URL) pour indiquer au serveur d’origine de la diffusion en continu qu’il doit renvoyer le contenu HLS utilisable sur des appareils Apple iOS natifs. Pour plus d’informations, consultez Distribution de contenu.

Oui, le serveur d’origine Media Services (point de terminaison de streaming) prend en charge l’empaquetage dynamique des fichiers MP4 au format de streaming HLS ou DASH. Toutefois, le contenu doit être encodé au format GOP fermé, avec des GOP courts dans la plage de durée de deux à six secondes. Nous recommandons les paramètres suivants : GOP de deux secondes, distance maximale et minimale de deux secondes entre les images clés, encodage à vitesse de transmission constante (mode CBR). La plupart des contenus dans ce format qui sont encodés avec le codec vidéo H.264 ou HEVC, ainsi que le format audio AAC, peuvent être pris en charge. D’autres formats audio préencodés peuvent également être pris en charge, comme Dolby DD+.

Pour que cela fonctionne, vous devez créer un élément multimédia, charger les éléments multimédias préencodés dans le conteneur de l’élément multimédia à l’aide des Kits de développement logiciel (SDK) clients de Stockage Blob Azure, puis générer les fichiers de manifeste du serveur (.ism) et du client requis. Pour plus d’informations, consultez l’exemple de projet .NET dans Diffuser en continu des fichiers MP4 existants.

Gardez à l’esprit que cette approche a des répercussions sur les performances, car l’encodeur intégré dans Media Services génère également des index binaires (fichiers .mpi) qui améliorent le temps d’accès aux fichiers MP4. Sans ces fichiers, le serveur peut utiliser un peu plus de ressources de l’UC en cas de charge élevée. Pour plus d’informations, consultez Diffusion en continu d’un fichier MP4 à débit unique existant avec HLS ou DASH.

Lorsque vous effectuez un scale-up avec cette approche, vous devez surveiller la charge de l’UC du point de terminaison de streaming. Si vous envisagez de passer en production avec une grande bibliothèque de fichiers MP4 préencodés en dehors de Media Services, envoyez un ticket de support pour que votre architecture soit examinée et pour vous renseigner sur les moyens d’améliorer les performances du serveur d’origine pour le contenu MP4 préencodé.

Les localisateurs de streaming créés avec l’API v2 continueront de fonctionner une fois que l’API v2 sera désactivée. Une fois les données du localisateur de streaming créées dans la base de données du back-end Media Services, il n’existe aucune dépendance sur l’API REST v2 pour le streaming. Nous ne supprimerons pas les enregistrements spécifiques à la v2 de la base de données lorsque la v2 sera désactivée en février 2024.

Certaines propriétés des ressources et des localisateurs créés avec la v2 ne sont pas accessibles ou sont mises à jour avec la nouvelle API v3. Par exemple, la v2 expose une API Fichiers de ressources qui n’a pas de fonctionnalité équivalente dans l’API v3. Ce n’est souvent pas un problème pour la plupart de nos clients, car il ne s’agit pas d’une fonctionnalité largement utilisée, et vous pouvez toujours streamer d’anciens localisateurs et les supprimer quand ils ne sont plus nécessaires.

Après la migration, vous devez éviter d’effectuer des appels à l’API v2 pour modifier les localisateurs de streaming ou des ressources.

Le chiffrement dynamique consiste à sécuriser votre contenu multimédia du moment où il quitte votre ordinateur jusqu’à sa livraison, en passant par le stockage et le traitement. Media Services vous permet de transmettre votre contenu en direct ou à la demande chiffré dynamiquement avec la norme Advanced Encryption Standard (AES-128) ou l’un des trois principaux systèmes DRM : Microsoft PlayReady, Google Widevine et Apple FairPlay. Pour plus d’informations, consultez Protéger votre contenu à l’aide du chiffrement dynamique de Media Services.

Les clients se demandent souvent s’ils devraient utiliser un chiffrement AES ou un système DRM. La principale différence entre les deux systèmes est qu’avec le chiffrement AES, la clé de contenu est transmise au client via TLS. La clé est chiffrée en transit sans chiffrement supplémentaire (« en clair »). Par conséquent, la clé utilisée pour déchiffrer le contenu peut être lue par le lecteur client et affichée dans la trace réseau du client, en texte en clair. Le chiffrement avec une clé en clair AES-128 convient à des cas d’utilisation dans lesquels l’observateur est fiable (par exemple, le chiffrement de vidéos d’entreprise distribuées dans une société et destinées aux employés).

Par rapport à la clé en clair AES-128, les systèmes DRM comme PlayReady, Widevine et FairPlay fournissent un niveau supplémentaire de chiffrement sur la clé utilisée pour déchiffrer le contenu. La clé de contenu est chiffrée à l’aide d’une clé protégée par le runtime DRM, en plus de tout chiffrement au niveau du transport fourni par TLS. Le déchiffrement est pris en charge dans un environnement sécurisé au niveau du système d’exploitation, où il est plus difficile pour un utilisateur malintentionné de commettre une attaque. Nous recommandons l’utilisation de la technologie DRM dans des cas d’utilisation où l’observateur n’est pas nécessairement fiable et où un niveau de sécurité supérieur est requis.

Vous n’êtes pas obligé d’utiliser un fournisseur de jetons spécifique tel qu’Azure Active Directory (Azure AD). Vous pouvez créer votre propre fournisseur JWT (appelé service d’émission de jeton de sécurité ou STS) en utilisant un chiffrement à clé asymétrique. Dans votre STS personnalisé, vous pouvez ajouter des revendications en fonction de votre logique métier.

Assurez-vous que l’émetteur, l’audience et les revendications correspondent exactement entre ce qui se trouve dans JWT et la valeur ContentKeyPolicyRestriction utilisée dans ContentKeyPolicy.

Pour plus d’informations, consultez Protéger votre contenu à l’aide du chiffrement dynamique de Media Services.

Pour un environnement de production, vous devez disposer d’un service d’émission de jeton de sécurité (STS, Secure Token Service), c’est-à-dire un service web, qui émet un jeton JWT en réponse à une requête HTTPS. Dans le cas d’un environnement de test, vous pouvez utiliser le code figurant dans la méthode GetTokenAsync définie dans Program.cs.

Après l’authentification d’un utilisateur, le lecteur adresse une requête au STS afin d’obtenir ce jeton et l’attribuer comme valeur de jeton. Vous pouvez utiliser l’API Lecteur multimédia Azure.

Pour un exemple d’exécution de STS avec une clé symétrique ou asymétrique, consultez Outil JWT. Pour obtenir un exemple de lecteur basé sur Lecteur multimédia Azure qui utilise un tel jeton JWT, consultez Outil de test multimédia Azure. (développez le lien player_settings pour voir l’entrée du jeton).

L’approche correcte consiste à utiliser STS. Dans le STS, en fonction du profil utilisateur, ajoutez différentes revendications (par exemple, « Utilisateur Premium », « Utilisateur De base » ou « Utilisateur de la version d’évaluation gratuite »). La définition de différentes revendications dans un jeton JWT permet à l’utilisateur de visualiser des contenus distincts. Pour différents contenus ou ressources, ContentKeyPolicyRestriction aura la valeur RequiredClaims correspondante.

Utilisez l’API Azure Media Services pour la configuration de la livraison de licences/clés et pour le chiffrement de vos éléments multimédias (comme indiqué dans cet exemple).

Ce comportement semble être conçu tel quel dans l’application en exemple. Lorsqu’une autre piste audio est présente (ce qui est le cas pour HLS) en mode hors connexion, iOS 10 et iOS 11 utilisent par défaut l’autre piste audio. Pour compenser ce comportement en mode hors connexion FPS, supprimez l’autre piste audio du flux. Pour effectuer cette opération sur Media Services, ajoutez le filtre de manifeste dynamique audio-only=false. En d’autres termes, une URL HLS se termine par .ism/manifest(format=m3u8-aapl,audio-only=false) .

Selon la conception de la clé de cache pour le réseau de distribution de contenu, le contenu peut être mis en cache. Videz le cache.

La structure du fichier téléchargé sur un appareil iOS ressemble à la capture d’écran suivante. Le dossier _keys stocke les licences FPS téléchargées, avec un fichier stocké pour chaque hôte de service de licence. Le dossier .movpkg stocke le contenu audio et vidéo.

Le premier dossier dont le nom se termine par un tiret suivi par un nombre comprend du contenu vidéo. La valeur numérique est la bande passante maximale des rendus de vidéo. Le deuxième dossier dont le nom se termine par un tiret suivi de 0 contient un contenu audio. Le troisième dossier nommé Données contient la liste de lecture principale du contenu FPS. Enfin, boot.xml fournit une description complète du contenu du dossier .movpkg.

Voici un exemple de fichier Boot. xml :

<?xml version="1.0" encoding="UTF-8"?>
<HLSMoviePackage xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns="http://apple.com/IMG/Schemas/HLSMoviePackage" xsi:schemaLocation="http://apple.com/IMG/Schemas/HLSMoviePackage /System/Library/Schemas/HLSMoviePackage.xsd">
  <Version>1.0</Version>
  <HLSMoviePackageType>PersistedStore</HLSMoviePackageType>
  <Streams>
    <Stream ID="1-4DTFY3A3VDRCNZ53YZ3RJ2NPG2AJHNBD-0" Path="1-4DTFY3A3VDRCNZ53YZ3RJ2NPG2AJHNBD-0" NetworkURL="https://example.streaming.mediaservices.windows.net/e7c76dbb-8e38-44b3-be8c-5c78890c4bb4/MicrosoftElite01.ism/QualityLevels(127000)/Manifest(aac_eng_2_127,format=m3u8-aapl)">
      <Complete>YES</Complete>
    </Stream>
    <Stream ID="0-HC6H5GWC5IU62P4VHE7NWNGO2SZGPKUJ-310656" Path="0-HC6H5GWC5IU62P4VHE7NWNGO2SZGPKUJ-310656" NetworkURL="https://example.streaming.mediaservices.windows.net/e7c76dbb-8e38-44b3-be8c-5c78890c4bb4/MicrosoftElite01.ism/QualityLevels(161000)/Manifest(video,format=m3u8-aapl)">
      <Complete>YES</Complete>
    </Stream>
  </Streams>
  <MasterPlaylist>
    <NetworkURL>https://example.streaming.mediaservices.windows.net/e7c76dbb-8e38-44b3-be8c-5c78890c4bb4/MicrosoftElite01.ism/manifest(format=m3u8-aapl,audio-only=false)</NetworkURL>
  </MasterPlaylist>
  <DataItems Directory="Data">
    <DataItem>
      <ID>CB50F631-8227-477A-BCEC-365BBF12BCC0</ID>
      <Category>Playlist</Category>
      <Name>master.m3u8</Name>
      <DataPath>Playlist-master.m3u8-CB50F631-8227-477A-BCEC-365BBF12BCC0.data</DataPath>
      <Role>Master</Role>
    </DataItem>
  </DataItems>
</HLSMoviePackage>

Étant donné que Media Services v3 permet qu’un élément multimédia ait plusieurs instances StreamingLocator, vous pouvez avoir :

• Une instance ContentKeyPolicy avec license_type = "persistent", ContentKeyPolicyRestriction avec une revendication sur "persistent", et son instance StreamingLocator.
• Une autre instance ContentKeyPolicy avec license_type="nonpersistent", ContentKeyPolicyRestriction avec une revendication sur "nonpersistent, et son instance StreamingLocator.
• Deux instances de StreamingLocator dont les valeurs ContentKey diffèrent.

En fonction de la logique métier du service d’émission de jeton de sécurité personnalisé, différentes revendications peuvent être émises dans le jeton JWT. Avec le jeton, seule la licence correspondante peut être obtenue et seule l’URL correspondante peut être lue.

Le document Widevine DRM Architecture Overview (Vue d’ensemble de l’architecture DRM Widevine) de Google définit trois niveaux de sécurité. Toutefois, la Documentation Azure Media Services sur le modèle de licence Widevine fait état de cinq niveaux de sécurité (exigences de robustesse du client pour la lecture).

Google Widevine définit les deux ensembles de niveaux de sécurité. La différence réside dans le niveau d’utilisation : architecture ou API. Les cinq niveaux de sécurité sont utilisés dans l’API Widevine. Le service de licence Azure Media Services Widevine désérialise l’objet content_key_specs, qui contient security_level, et le transmet au service de livraison globale de Widevine. Le tableau ci-après montre le mappage entre les deux ensembles de niveaux de sécurité.

Utilisez Azure Monitor pour effectuer le suivi de ce qui se passe avec vos ressources Media Services. Pour plus d’informations, consultez Surveiller Media Services. Les guides pratiques sont répertoriés à la fin de la page.

Utilisez Azure Event Grid pour surveiller votre événement en direct sans service d’interrogation. Consultez Créer et surveiller des événements Media Services avec Event Grid à l’aide de la Portail Azure.

Media Services fonctionne avec de nombreux joueurs. Consultez la liste des lecteurs multimédias compatibles ou essayez les exemples de lecteur de tiers.

Pour plus d’informations sur Media Services et la haute disponibilité, consultez Haute disponibilité avec Media Services et VOD (vidéo à la demande).

Nous avons créé un guide complet pour la migration de la version 2 à la version 3. Nous sommes très intéressés par votre expérience et vos besoins en matière de migration. N’hésitez pas à nous faire part de vos commentaires par le biais d’un problème GitHub ou d’un ticket de support.

Nous avons documenté les codes d’erreur dans les références suivantes : Codes d’erreur du point de terminaison de streaming, Codes d’erreur des événements en direct et Codes d’erreur des tâches. Si vous ne trouvez pas de réponses sur cette page, créez un ticket de support.

Vous pouvez réinitialiser les informations d’identification de votre compte à l’aide d’Azure CLI.

Voir le guide de tarification de Media Services.

Voir Quotas et limites de Media Services.

Les clients associent leurs propres comptes de stockage à leurs comptes Azure Media Services. Toutes les données relatives aux éléments multimédias sont stockées dans ces comptes de stockage associés, et le client détermine l’emplacement et le type de réplication de ce stockage.

Les autres données associées à un compte Media Services (notamment les clés de chiffrement du contenu, les clés de vérification des jetons, les URL JobInputHttp et d’autres métadonnées d’entité) sont stockées sur un espace de stockage appartenant à Microsoft dans la région sélectionnée pour le compte Media Services.

En raison des exigences relatives à la résidence des données dans les régions Brésil Sud et Asie Sud-Est, les autres données de compte sont stockées en mode redondant interzone et contenues au sein d’une même région. Pour la région Asie Sud-Est, toutes les autres données de compte sont stockées à Singapour. Pour la région Brésil Sud, les données sont stockées au Brésil. Dans les régions autres que Brésil Sud et Asie Sud-Est, les autres données de compte peuvent également être stockées sur l’espace de stockage appartenant à Microsoft dans la région jumelée.

Azure Media Services est un service régional qui ne fournit ni haute disponibilité ni réplication de données. Nous encourageons les clients qui ont besoin de ces fonctionnalités à créer une solution en utilisant des comptes Media Services dans plusieurs régions. Un exemple montrant comment créer une solution de haute disponibilité avec vidéo à la demande Media Services est disponible à titre de guide.