Preguntas frecuentes sobre Azure Media Services

Consulte la guía de retirada de Azure Media Services.

Aquí tiene una lista:

• Especificación OpenAPI (Swagger)
• CLI de Azure
• .NET
• Java
• Python
• Node.js
• Go

No se recomienda que intente encapsular la API REST de Media Services directamente en su propio código de biblioteca. Para hacerlo correctamente con fines de producción, será necesario implementar toda la lógica de reintento de Azure Resource Manager y entender cómo administrar las operaciones de larga duración de las API de Resource Manager. Los SDK de cliente de varios lenguajes, por ejemplo, .NET, Java, TypeScript, Python y Ruby, se encargan de ello automáticamente, a fin de reducir las posibilidades de problemas con la lógica de reintento o las llamadas API con error.

Consulte las páginas de ejemplos. Hay ejemplos para cuentas, activos, streaming en vivo, streaming deVOD, protección de contenido, codificación, análisis y uso de reproductores.

Al usar la paginación, siempre debe usar el vínculo siguiente para enumerar la colección y no tener que depender de un tamaño de página determinado. Para información detallada y ejemplos, consulte Filtrado, ordenación y paginación de entidades.

Para información sobre el uso de la CLI de Azure para emparejar Media Services con Azure Key Vault para cifrar los datos, consulte el tutorial Uso de una clave de Key Vault para cifrar los datos en una cuenta de Media Services.

Si quiere que Media Services acceda a una cuenta de almacenamiento cuando está configurada para bloquear las solicitudes de direcciones IP desconocidas, siga los pasos que se indican en Acceso al almacenamiento con una identidad administrada de Media Services.

Consulte Traslado de una cuenta de Media Services entre suscripciones.

Consulte Control de acceso basado en roles de Azure (RBAC de Azure) para cuentas de Media Services.

Media Services define los siguientes roles integrados:

• Administrador de cuenta de Media Services
• Operador multimedia de Media Services
• Administrador de directivas de Media Services
• Administrador de puntos de conexión de streaming de Media Services
• Administrador de eventos en directo de Media Services

Estos roles se detallan en Control de acceso basado en roles de Azure (Azure RBAC) para cuentas de Media Services.

Estos roles se pueden usar para otorgar acceso específico a una cuenta de Media Services. Para permitir el acceso total a una cuenta de Media Services, se puede usar el rol "Propietario" o "Colaborador". Media Services tiene una API anterior en la ruta de caída en desuso, que no admite el control de acceso específico. Los clientes que requieren un control de acceso específico no deben seleccionar "Habilitar API clásicas" al crear una cuenta de Media Services desde el portal (o usar la API versión 2020-05-01 si usan la API para crear cuentas).

Las siguientes instancias integradas de Azure Policy se pueden usar para bloquear la creación de cuentas que admitan la API antigua: las cuentas de Azure Media Services que permiten el acceso a la API v2 heredada tienen que bloquearse: Microsoft Azure

Un recurso de Media Services es un contenedor de cuentas de almacenamiento de Azure que se usa con los archivos de vídeo que se cargan. Tiene un identificador único que se usa con transformaciones y otras operaciones. Consulte Recursos de la versión 3 de Azure Media Services.

Cada vez que quiera cargar un archivo multimedia y utilizarlo en alguna tarea, como codificación o streaming, debe crear un recurso para almacenar el archivo multimedia y otros archivos asociados. Los recursos se crean automáticamente si usa Azure Portal. Si no usa el portal para cargar archivos, primero debe crear un recurso.

Los formatos de codificación comunes están disponibles con el codificador estándar de Media Services. Para obtener una lista de todos los formatos, consulte Códecs y formatos de codificador estándar.

Puede crear un trabajo en Azure Portal con la CLI de Azure, REST o cualquiera de los SDK. Consulte los ejemplos de Media Services del lenguaje que prefiera.

Sí. Consulte Codificación con una escala de velocidad de bits generada automáticamente.

Sí. Media Services puede realizar un análisis de dos pasadas en un vídeo. Luego, puede recomendar el mejor conjunto de velocidad de bits adaptable, la resolución y la configuración de codificación en función del contenido del vídeo.

Sí. Para obtener detalles y vínculos a una aplicación de ejemplo que muestra cómo cargar un archivo MP4 de velocidad de bits única codificado previamente y generar el manifiesto de servidor (.ism) y el manifiesto de cliente (.ismc), vea la respuesta a la pregunta "¿Puedo transmitir archivos MP4 existentes que están codificados previamente o codificados en otra solución?" en la sección sobre empaquetado y entrega. Esa respuesta también describe el impacto del rendimiento en el origen.

Esta opción no se recomienda. El contenido muy corto con una duración de uno o dos minutos no resulta conveniente para el streaming con velocidad de bits adaptable. Si piensa transmitir archivos con formato muy corto, se recomienda codificar previamente el contenido en un formato que se transmita fácilmente mediante una velocidad de bits única.

Dado que la mayoría de los reproductores con velocidad de bits adaptable necesitan tiempo para almacenar en el búfer varios segmentos de vídeo, así como tiempo para analizar el ancho de banda de red antes de "desplazarse" hacia arriba o hacia abajo en la escalera de velocidad de bits adaptable, a menudo resulta inútil proporcionar una gran cantidad de velocidades de bits para el contenido que tiene menos de 30 segundos de duración. En el momento en que el reproductor bloquea su algoritmo heurístico en la velocidad de bits correcta para funcionar según las condiciones de la red, se realiza el streaming del archivo.

Además, algunos reproductores tienen como valor predeterminado el almacenamiento en búfer de hasta tres segmentos de vídeo. Cada segmento puede tener entre dos y seis segundos de duración. En el caso de los vídeos de formato muy corto, es probable que el reproductor los almacene en el búfer y comience la reproducción de la primera velocidad de bits seleccionada del conjunto de velocidades de bits adaptables. Por este motivo, se recomienda usar un archivo MP4 de velocidad de bits única y cargarlo en un recurso si necesita la generación de manifiestos HLS o DASH. Para más información sobre cómo lograrlo, consulte la respuesta a la pregunta "¿Puedo transmitir archivos MP4 existentes codificados previamente o codificados en otra solución?" en la sección sobre empaquetado y entrega.

Es necesario entregar los archivos solo en formato HLS o DASH si quiere beneficiarse de las funcionalidades de esos protocolos. En lo que respecta a las secuencias con velocidades de bits únicas, todavía tienen mucho que ofrecer, como una búsqueda más rápida, compatibilidad con la administración de derechos digitales (DRM) y una mayor dificultad para la descarga a través de una URL (pero todavía posible) que un MP4 de descarga progresiva en el almacenamiento de blobs. La compatibilidad de subtítulos con VTT e IMSC1 también es otra ventaja. Además, la posibilidad de enlazar ejecuciones de audio adicionales o doblajes en idiomas alternativos hace que sea una opción valiosa para algunas situaciones.

Si buscas formas de usar un codificador de Media Services para hacer cosas como rotar un vídeo, subbclip de un vídeo, unir vídeos, crear miniaturas y sprites, tenemos una gran cantidad de ejemplos de código en la página Ejemplos de código. Los lenguajes de ejemplo disponibles incluyen Node.JS, Python, .NET y Java.

Un evento en directo de Media Services es el proceso de ingerir fuentes de vídeo en directo y difundirlas a través de un protocolo RTMPS o Smooth Streaming. Para más información, consulte Eventos en directo y salidas en directo en Media Services.

El primer paso es elegir un codificador local. Se han proporcionado ejemplos para crear un evento en directo con Wirecast y OBS. Si prefiere comenzar con una introducción a los eventos en directo de Media Services, consulte Tipos de eventos en directo.

Azure Media Services ofrece vídeo, audio y texto en diferentes protocolos. Cuando se publica el streaming en vivo mediante MPEG-DASH o HLS/CMAF, el servicio proporciona, junto con el vídeo y el audio, el texto transcrito en formato IMSC1.1 compatible con TTML. Para más información, consulte Transcripción en directo.

Puede supervisar eventos en directo si se suscribe a eventos de Azure Event Grid. Para más información, consulte el esquema de eventos de Event Grid. Puede:

• Suscribirse a los eventos Microsoft.Media.LiveEventEncoderDisconnected de nivel de flujo y supervisar que no se produzca ninguna reconexión durante un tiempo para detener y eliminar el evento en directo.
• Suscribirse a los eventos de latido de nivel de pista. Si todas las pistas tienen una velocidad de bits de entrada que cae a 0, o bien si la última marca de tiempo ya no aumenta, puede apagar el evento en directo de manera segura. Los eventos de latido ocurren cada 20 segundos por cada pista, por lo que podría haber un cierto nivel de detalle.

No, no es fácil que pueda usar la misma dirección URL de streaming si detiene e inicia un evento en directo. Cada vez que cree y publique una nueva salida en directo (y un recurso), se usará una nueva dirección URL de streaming (GUID) con el nuevo localizador. De este modo, está seguro de que no habrá ningún conflicto de caché en el punto de conexión de streaming y la red de entrega de contenido (CDN). Puede preparar (y conocer) las direcciones URL de streaming por anticipado porque puede forzar un GUID específico para el localizador de streaming y, luego, decidir el nombre del manifiesto que se usará para la salida en directo.

Supongamos que decide usar el GUID 1a7ed69e-a361-433d-8a56-29c61872744f para la salida en directo que creará mañana. Cuando llega el día, inicia el evento en directo y crea una salida en directo. Puede decidir usar "conference1" para el manifiesto y forzar el GUID del localizador.

La dirección URL de streaming es predecible y es http://<youraccountname>-<azureregion>.streaming.media.azure.net/1a7ed69e-a361-433d-8a56-29c61872744f/conference1.ism/manifest.

No se puede volver a usar la misma salida en directo o recurso varias veces. Piense en la combinación de la salida en directo y el recurso como una grabación en cinta. Una vez que la salida en directo se haya registrado en el recurso, no se puede volver a usar en otra grabación. Si lo hace de nuevo, habrá conflictos de blobs o sobrescrituras. A menos que planee purgar en su totalidad los blobs de la cuenta de almacenamiento y purgar el CDN por completo, habrá problemas. Es probable que siga habiendo problemas porque los fragmentos ya están almacenados en caché de bajada en la CDN o en las cachés de los dispositivos cliente (por ejemplo, la caché del explorador).

Uno de los motivos más habituales es que el punto de conexión de streaming desde el que intenta reproducirlo no está en estado de ejecución.

En Media Services, un punto de conexión de streaming representa un empaquetado dinámico (Just-In-Time) y el servicio de origen que puede entregar directamente el contenido en directo y a petición a una aplicación de reproducción de cliente, mediante uno de los protocolos de streaming de multimedia (HLS o DASH). Además, el punto de conexión de streaming proporciona cifrado dinámico (Just-In-Time) a sistemas de administración de derechos digitales líderes del sector. Para más información, consulte Puntos de conexión de streaming (origen) en Azure Media Services.

Para que los vídeos estén disponibles y que los clientes los puedan reproducir, debe crear un localizador de streaming y, después, compilar direcciones URL de streaming. Los localizadores de streaming también se usan para aplicar directivas de streaming que contienen reglas sobre cómo se consumen los archivos multimedia.

Para compilar una dirección URL de streaming, primero debe crear un localizador de streaming. A continuación, debe concatenar el nombre de host del punto de conexión de streaming y la ruta de acceso del localizador de streaming.

Las directivas de streaming permiten definir los protocolos de streaming y las opciones de cifrado de los localizadores de streaming. Media Services v3 incluye algunas directivas de streaming predefinidas. Para más información, consulte Directivas de streaming.

Para ver una lista de directivas predefinidas que puede usar para empezar, consulte Directivas de streaming.

Asegúrese de que tiene (format=m3u8-cmaf) al final de la ruta de acceso (después de la parte /manifest de la dirección URL) para indicar al servidor de origen de streaming que devuelva el contenido de HLS para su consumo en dispositivos Apple iOS nativos. Para más información, consulte Entrega de contenido.

Sí, el servidor de origen de Media Services (punto de conexión de streaming) admite el empaquetado dinámico de archivos MP4 en formato de streaming HLS o DASH. Sin embargo, el contenido debe codificarse en formato GOP cerrado, con grupos de imágenes cortos en el intervalo de dos a seis segundos. Se recomienda la siguiente configuración: GOP de dos segundos, distancia máxima y mínima del fotograma clave de dos segundos, codificación de velocidad de bits constante (modo CBR). Se puede admitir la mayoría del contenido en este formato codificado mediante el códec de vídeo H264 o HEVC junto con el formato de audio AAC. También se podrían admitir formatos de audio adicionales que estén codificados previamente, como Dolby DD+.

La clave para que funcione esta posibilidad es crear un recurso, cargar los recursos codificados previamente en el contenedor del recurso mediante los SDK de cliente de Blob Storage y, luego, generar los archivos de manifiesto de servidor (.ism) y de manifiesto de cliente necesarios. Para más información, consulte el proyecto de ejemplo de .NET en Transmisión de archivos MP4 existentes.

Tenga en cuenta que el uso de este enfoque tiene consecuencias para el rendimiento, ya que el codificador integrado en Media Services también genera índices binarios (archivos .mpi) que mejoran el tiempo de acceso a los archivos MP4. Sin estos archivos, el servidor puede usar un poco más de CPU con una carga elevada. Para más información, consulte Streaming de un archivo MP4 de velocidad de bits única existente con HLS o Dash.

Al realizar el escalado vertical con este enfoque, debe supervisar la carga de CPU del punto de conexión de streaming. Si planea pasar a producción con una gran biblioteca de archivos MP4 que están codificados previamente fuera de Media Services, abra una incidencia de soporte técnico para que se revise la arquitectura y consulte las formas de mejorar el rendimiento del servidor de origen del contenido MP4 codificado previamente.

Los localizadores de streaming creados con la API v2 seguirán funcionando después de desactivar la API v2. Una vez creados los datos del localizador de streaming en la base de datos de back-end de Media Services, no hay ninguna dependencia en la API REST v2 para el streaming. No quitaremos registros específicos de v2 de la base de datos cuando v2 esté desactivada en febrero de 2024.

Hay algunas propiedades de recursos y localizadores creados con v2 a los que no se puede acceder ni actualizar mediante la nueva API v3. Por ejemplo, v2 expone una API Asset Files que no tiene una característica equivalente en la API v3. Esto no suele ser un problema para la mayoría de nuestros clientes, ya que no es una característica de uso general y todavía puede transmitir localizadores antiguos y eliminarlos cuando ya no sean necesarios.

Después de la migración, debe evitar realizar llamadas a la API v2 para modificar los localizadores de streaming o los recursos.

El cifrado dinámico protege su contenido multimedia desde el momento en que este deja el equipo hasta el almacenamiento, el procesamiento y la entrega. Con Media Services puede entregar el contenido cifrado de forma dinámica en directo y a petición con el Estándar de cifrado avanzado (AES-128) o cualquiera de los tres sistemas de administración de derechos digitales principales: Microsoft PlayReady, Google Widevine y Apple FairPlay. Para más información, consulte Protección del contenido mediante el cifrado dinámico de Media Services.

Los clientes suelen preguntarse si deben usar el cifrado de AES o un sistema de DRM. La diferencia principal entre los dos sistemas es que, con el cifrado de AES, la clave de contenido se transmite al cliente a través de TLS. La clave se cifra en tránsito sin cifrado adicional ("sin cifrar"). Como resultado, la clave que se usa para descifrar el contenido está accesible en el reproductor del cliente y se puede ver en un seguimiento de la red en el cliente en texto sin formato. La clave sin cifrado AES-128 es adecuada para los casos de uso en los que el destinatario es una entidad de confianza (p. ej., cifrado de vídeos corporativos distribuidos dentro de una empresa para su visualización por parte de los empleados).

Los sistemas de administración de derechos digitales como PlayReady, Widevine y FairPlay proporcionan un nivel adicional de cifrado en la clave que se usa para descifrar el contenido en comparación con una clave sin cifrado AES-128. La clave de contenido se cifra en una clave protegida por el entorno de ejecución de administración de derechos digitales, además del cifrado de nivel de transporte que proporciona TLS. Asimismo, el descifrado se controla en un entorno seguro a nivel del sistema operativo donde a un usuario malintencionado le resulta más difícil atacar. Se recomienda DRM para los casos de uso en los que es posible que el destinatario no sea una entidad de confianza y se requiera el nivel de seguridad más alto.

No tiene que usar ningún proveedor de token específico como Azure Active Directory (Azure AD). Puede crear su propio proveedor JWT (denominado servicio de token de seguridad o STS) mediante el cifrado de claves asimétricas. En el STS personalizado, puede agregar notificaciones basadas en la lógica de negocios.

Asegúrese de que el emisor, el público y las notificaciones coincidan exactamente entre lo que hay en JWT y el valor de ContentKeyPolicyRestriction que se usa en ContentKeyPolicy.

Para más información, consulte Protección del contenido mediante el cifrado dinámico de Media Services.

Para entornos de producción, deberá tener un servicio de token seguro (que es un servicio web), que emite un token JWT tras una solicitud HTTPS. Para la prueba, puede usar el código que se muestra en el método GetTokenAsync definido en Program.cs.

Una vez que se autentica un usuario, el reproductor solicita a STS dicho token y lo asigna como valor del token. Puede usar la API de Azure Media Player.

Para un ejemplo de cómo ejecutar STS, ya sea con un clave simétrica o asimétrica, consulte la herramienta JWT. Para ver un ejemplo de un reproductor basado en Azure Media Player que usa dicho token JWT, consulte la herramienta de prueba multimedia de Azure. (Expanda el vínculo player_settings para ver la entrada de token).

El enfoque correcto consiste en usar el servicio de token seguro. En STS, según el perfil de usuario, agregue notificaciones distintas (por ejemplo, "Usuario prémium", "Usuario básico", "Usuario de evaluación gratuita"). Con notificaciones distintas en un token JWT, el usuario puede ver diferentes contenidos. Para los distintos contenidos o activos, ContentKeyPolicyRestriction tendrá el valor de RequiredClaims correspondiente.

Use las API de Azure Media Services para configurar la entrega de claves o licencias y cifrar los recursos (como se muestra en este ejemplo).

Este comportamiento parece deberse al diseño de la aplicación de ejemplo. Cuando existe una pista de audio alternativa (como es el caso de HLS) durante el modo sin conexión, tanto iOS 10 como iOS 11 la usan de manera predeterminada. Para compensar este comportamiento en el modo sin conexión de FPS, quite la pista de audio alternativa de la secuencia. Para hacer esto en Media Services, agregue el filtro de manifiesto dinámico audio-only=false. En otras palabras, una dirección URL de HLS finaliza con .ism/manifest(format=m3u8-aapl,audio-only=false) .

Según cómo esté diseñada la clave de caché para la red de entrega de contenido, es posible que el contenido se almacene en la memoria caché. Debe purgar la caché.

La estructura del archivo descargado en un dispositivo iOS es similar a la captura de pantalla siguiente. La carpeta _keys almacena las licencias de FPS descargadas, donde hay un archivo de almacén por cada host de servicio de licencia. La carpeta .movpkg almacena el contenido de audio y vídeo.

La primera carpeta, cuyo nombre finaliza con un guion seguido de un número, contiene datos de vídeo. El valor numérico es el ancho de banda máximo de la reproducción de vídeo. La segunda carpeta, cuyo nombre finaliza con un guion seguido de un 0, contiene datos de audio. La tercera carpeta, denominada Data contiene la lista de reproducción maestra del contenido de FPS. Por último, boot.xml proporciona una descripción completa del contenido de la carpeta .movpkg.

Este es archivo boot.xml de ejemplo:

<?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>

Dado que Media Services v3 permite que un recurso tenga varias instancias de StreamingLocator, puede tener:

• Una instancia de ContentKeyPolicy con license_type = "persistent", ContentKeyPolicyRestriction con una notificación en "persistent" y su instancia de StreamingLocator.
• Otra instancia de ContentKeyPolicy con license_type="nonpersistent", ContentKeyPolicyRestriction con una notificación en "nonpersistent" y su instancia de StreamingLocator.
• Dos instancias de StreamingLocator que tengan diferentes valores de ContentKey.

Dependiendo de la lógica de negocio de la STS personalizada, se emiten diferentes notificaciones en el token de JWT. Con el token, solo se puede obtener la licencia correspondiente y solo se puede reproducir la dirección URL correspondiente.

En el documento Información general de la arquitectura de DRM de Widevine de Google se definen tres niveles de seguridad. Sin embargo, la documentación de Azure Media Services en la plantilla de licencias de Widevine describe cinco niveles de seguridad (requisitos de solidez del cliente para la reproducción).

Google Widevine define ambos conjuntos de niveles de seguridad. La diferencia radica en el nivel de uso: arquitectura o API. Los niveles de cinco seguridad se utilizan en la API de Widevine. El servicio de licencia Widevine de Azure Media Services deserializa el objeto content_key_specs, que contiene security_level, y lo pasa al servicio de entrega global de Widevine. En la tabla siguiente se muestra la asignación entre los dos conjuntos de niveles de seguridad.

Use Azure Monitor para realizar un seguimiento de lo que sucede con sus recursos de Media Services. Para obtener más información, consulte Supervisar Media Services. Al final de la página se muestran las guías de procedimientos.

Use Azure Event Grid para supervisar el evento en directo sin un servicio de sondeo. Consulte Creación y supervisión de eventos de Media Services con Event Grid mediante el Azure Portal.

Media Services funciona con muchos reproductores. Consulte la lista de reproductores multimedia compatibles o pruebe los ejemplos de reproductores de terceros.

Para más información sobre Media Services y alta disponibilidad, consulte Alta disponibilidad con Media Services y vídeo bajo demanda (VOD).

Se ha creado una guía completa para la migración de v2 a v3. Sería interesante conocer su experiencia y necesidades acerca de la migración, por lo que no dude en enviar comentarios a través de una incidencia de GitHub o una incidencia de soporte técnico.

Se han documentado los códigos de error en las siguientes referencias: códigos de error de punto de conexión de streaming, códigos de error de eventos en directo, códigos de error de trabajo. Si no encuentra la respuesta a su pregunta, cree una incidencia de soporte técnico.

Puede restablecer las credenciales de su cuenta con la CLI de Azure.

Consulte la Guía de precios de Media Services.

Consulte Cuotas y límites de Media Services.

Los clientes asocian sus propias cuentas de almacenamiento a sus cuentas de Azure Media Services. Todos los datos de los recursos se almacenan en estas cuentas de almacenamiento asociadas y el cliente controla la ubicación y el tipo de replicación de este almacenamiento.

Los datos adicionales asociados con la cuenta de Media Services (incluidas las claves de cifrado de contenido, las claves de comprobación de tokens, las direcciones URL de JobInputHttp y otros metadatos de entidad) se almacenan en el almacenamiento propiedad de Microsoft dentro de la región seleccionada para la cuenta de Media Services.

Debido a los requisitos de residencia de datos del Sur de Brasil y el Sudeste Asiático, los datos adicionales de la cuenta se almacenan con redundancia de zona y están contenidos en una sola región. En el caso del Sudeste Asiático, todos los datos adicionales de la cuenta se almacenan en Singapur. En el caso del Sur de Brasil, se almacenan en Brasil. En regiones distintas del Sur de Brasil y el Sudeste Asiático, los datos adicionales de la cuenta también se pueden almacenar en un almacenamiento propiedad de Microsoft en la región emparejada.

Azure Media Services es un servicio regional y no proporciona alta disponibilidad ni replicación de datos. Animamos a los clientes que necesitan estas características a crear una solución mediante cuentas de Media Services en varias regiones. Como guía, dispone de un ejemplo que muestra cómo crear una solución de alta disponibilidad con vídeo bajo demanda de Media Services.