Compartir a través de

Terminología y cambios de entidad entre Media Services V2 y V3

  • Artículo

logotipo de la guía de migración

pasos de migración 2

Importante

Ya no es necesario migrar de Azure Media Service v2 a v3, ya que el desuso de la API V2 se alineará con la retirada de Azure Media Services. Consulte la guía de retirada de Azure Media Services para más información.

En este artículo se describen las diferencias de terminología entre Azure Media Services v2 y v3.

Cambios de terminología

  • Ahora, un localizador de se denomina localizador de streaming.
  • Una de canal de ahora se denomina Live Event.
  • Ahora programa de se denomina Live Output.
  • Ahora tarea se denomina jobOutput, que forma parte de un trabajo.

Cambios de entidad

de entidad de V2 de entidad V3 guía accesible para la V3 actualizado por el V3
AccessPolicy La entidad AccessPolicies no existe en la versión 3. No No
Asset Asset Sí Sí
AssetDeliveryPolicy StreamingPolicy Sí No
AssetFile La entidad AssetFiles no existe en la versión 3. Aunque los archivos (blobs de almacenamiento) que se cargan todavía se consideran archivos.

Use las API de Azure Storage para enumerar los blobs de un contenedor en su lugar. Hay dos maneras de aplicar una transformación a los archivos con un trabajo:

Archivos que ya se han cargado en el almacenamiento: el URI incluiría el identificador de recurso para que los trabajos se realicen en los recursos de una cuenta de almacenamiento.

Archivos que se van a cargar durante el proceso de transformación y trabajo: el recurso se crea en el almacenamiento, se devuelve una dirección URL de SAS, los archivos se cargan en el almacenamiento y, a continuación, la transformación se aplica a los archivos.		 No No
Channel LiveEvent Los eventos en directo reemplazan canales de la API v2. Llevan la mayoría de las características y tienen más características nuevas, como transcripciones en vivo, modo stand-by y compatibilidad con la ingesta de RTMPS.

Consulte evento en directo en de streaming en vivo basado en escenarios		 No No
ContentKey ContentKeys ya no es una entidad, ahora es una propiedad de un localizador de streaming.

En la versión 3, los datos de clave de contenido están asociados al StreamingLocator (para el cifrado de salida) o al propio recurso (para el cifrado de almacenamiento del lado cliente).		 Sí No
ContentKeyAuthorizationPolicy ContentKeyPolicy Sí No
ContentKeyAuthorizationPolicyOption ContentKeyPolicyOptions se incluyen en el ContentKeyPolicy. Sí No
IngestManifest La entidad IngestManifests no existe en la versión 3. La carga de archivos en V3 implica la API de Azure Storage. Los recursos se crean primero y, a continuación, los archivos se cargan en el contenedor de almacenamiento asociado. Hay muchas maneras de obtener datos en un contenedor de Azure Storage que se puede usar en su lugar. JobInputHttp también proporciona una manera de descargar una entrada de trabajo desde una dirección URL determinada si lo desea. No No
IngestManifestAsset Hay muchas maneras de obtener datos en un contenedor de Azure Storage que se puede usar en su lugar. JobInputHttp también proporciona una manera de descargar una entrada de trabajo desde una dirección URL determinada si lo desea. No No
IngestManifestFile Hay muchas maneras de obtener datos en un contenedor de Azure Storage que se puede usar en su lugar. JobInputHttp también proporciona una manera de descargar una entrada de trabajo desde una dirección URL determinada si lo desea. No No
Job Job Cree un Transform antes de crear un Job. No No
JobTemplate Transform Use un Transform en su lugar. Una transformación es una entidad independiente de un trabajo y se puede reutilizar. No No
Locator StreamingLocator Sí No
MediaProcessor En lugar de buscar el MediaProcessor que se va a usar por nombre, use el valor preestablecido deseado al definir una transformación. El valor preestablecido usado determinará el procesador multimedia utilizado por el sistema de trabajo. Consulte los temas de codificación en escenario basado en codificación. No NA (readonly en V2)
NotificationEndPoint Las notificaciones de la versión 3 se controlan a través de Azure Event Grid. El NotificationEndpoint se reemplaza por el registro de suscripción de Event Grid que también encapsula la configuración de los tipos de notificaciones que se van a recibir (que en la versión 2 se controló mediante el JobNotificationSubscription del trabajo, el TaskNotificationSubscription de la tarea y la telemetría ComponentMonitoringSetting). La telemetría v2 se dividió entre Azure Event Grid y Azure Monitor para adaptarse a las mejoras del ecosistema de Azure más grande. No No
Program LiveOutput Ahora, las salidas en directo reemplazan los programas de la API v3. No No
StreamingEndpoint StreamingEndpoint Los puntos de conexión de streaming permanecen principalmente iguales. Se usan para el empaquetado dinámico, el cifrado y la entrega de contenido HLS y DASH para streaming en vivo y a petición, ya sea directo desde el origen o a través de la red CDN. Las nuevas características incluyen compatibilidad con una mejor integración y gráficos de Azure Monitor. Sí Sí
Task JobOutput Reemplazado por JobOutput (que ya no es una entidad independiente en la API). Consulte los temas de codificación en escenario basado en codificación. No No
TaskTemplate TransformOutput Reemplazado por TransformOutput (que ya no es una entidad independiente en la API). Consulte los temas de codificación en escenario basado en codificación. No No
Inputs Inputs Las entradas y salidas ahora están en el nivel de trabajo. Consulte los temas de codificación en escenario basado en codificación No No
Outputs Outputs Las entradas y salidas ahora están en el nivel de trabajo. En V3, el formato de metadatos cambió de XML a JSON. Las salidas dinámicas comienzan a crearse y se detienen cuando se eliminan. Consulte los temas de codificación en escenario basado en codificación No No
Otros cambios V2 V3 de V3
de almacenamiento de
de almacenamiento Los SDK V3 ahora están desacoplados del SDK de Storage, lo que proporciona más control sobre la versión del SDK de Storage que desea usar y evita problemas de control de versiones.
de codificación
Codificación de velocidades de bits velocidades de bits medida en kbps por ejemplo: 128 (kbps) bits por segundo, por ejemplo: 128000 (bits/segundo)
Codificación de drm FairPlay En Media Services V2, se puede especificar el vector de inicialización (IV). En Media Services V3, no se puede especificar FairPlay IV.
del codificador Premium Codificador Premium y Indexador heredado El Premium Encoder y los procesadores de análisis multimedia heredados (Versión preliminar de Azure Media Services Indexer 2, Face Redactor, etcetera).) no son accesibles a través de V3. Se ha agregado compatibilidad con la asignación de canales de audio al codificador Estándar. Consulte Audio en la documentación de Swagger de codificación de Media Services.
Consulte los temas de codificación en escenario basado en codificación
Transformaciones y trabajos
Procesamiento basado en trabajos https Para el procesamiento del trabajo basado en archivos, puede usar una dirección URL HTTPS como entrada. No es necesario que el contenido ya esté almacenado en Azure ni que tenga que crear recursos.
Plantillas de ARM para trabajos Las plantillas de ARM no existían en la versión 2. Se puede usar una transformación para crear configuraciones reutilizables, crear plantillas de Azure Resource Manager y aislar la configuración de procesamiento entre varios clientes o inquilinos.
eventos en directo
de punto de conexión de streaming Un punto de conexión de streaming representa un servicio de streaming que puede entregar contenido directamente a una aplicación de reproductor cliente o a una red de entrega de contenido (CDN) para su posterior distribución. Los puntos de conexión de streaming permanecen principalmente iguales. Se usan para el empaquetado dinámico, el cifrado y la entrega de contenido HLS y DASH para streaming en vivo y a petición, ya sea directo desde el origen o a través de la red CDN. Las nuevas características incluyen compatibilidad con una mejor integración y gráficos de Azure Monitor.
Canales de eventos en directo Los canales son responsables del procesamiento de contenido de streaming en vivo. Un canal proporciona un punto de conexión de entrada (dirección URL de ingesta) que luego se proporciona a un transcodificador en directo. El canal recibe transmisiones de entrada en vivo del transcodificador en vivo y hace que esté disponible para el streaming a través de uno o varios puntos de conexión de streaming. Los canales también proporcionan un punto de conexión de versión preliminar (dirección URL de vista previa) que se usa para obtener una vista previa y validar la secuencia antes de su posterior procesamiento y entrega. Los eventos en directo reemplazan canales de la API v2. Llevan la mayoría de las características y tienen más características nuevas, como transcripciones en vivo, modo stand-by y compatibilidad con la ingesta de RTMPS.
programas de eventos en directo Un programa le permite controlar la publicación y el almacenamiento de segmentos en una secuencia en directo. Los canales administran programas. La relación Canal y Programa es similar a los medios tradicionales en los que un canal tiene una secuencia constante de contenido y un programa tiene como ámbito algún evento de tiempo en ese canal. Puede especificar el número de horas que desea conservar el contenido grabado para el programa estableciendo la propiedad ArchiveWindowLength. Este valor se puede establecer de un mínimo de 5 minutos a un máximo de 25 horas. Ahora, las salidas en directo reemplazan los programas de la API v3.
de longitud del evento en directo Puede transmitir eventos en directo 24/7 al usar Media Services para transcodificación de una sola fuente de contribución de velocidad de bits en un flujo de salida que tenga varias velocidades de bits.
de latencia de eventos en directo Nueva compatibilidad con streaming en vivo de baja latencia en eventos en directo.
de vista previa de eventos en directo Live Event Preview admite empaquetado dinámico y cifrado dinámico. Esto habilita la protección de contenido en la versión preliminar, así como el empaquetado DASH y HLS.
rtMPS de eventos en directo Se ha mejorado la compatibilidad con RTMPS con mayor estabilidad y más compatibilidad con el codificador de origen.
Ingesta segura de RTMPS de eventos en directo Al crear un evento en directo, obtendrá 4 direcciones URL de ingesta. Las 4 direcciones URL de ingesta son casi idénticas, tienen el mismo token de streaming AppId, solo la parte del número de puerto es diferente. Dos de las direcciones URL son principales y copias de seguridad para RTMPS.
de transcripción de eventos en directo Azure Media Service ofrece vídeo, audio y texto en distintos protocolos. Al publicar la transmisión en vivo con MPEG-DASH o HLS/CMAF, después, junto con el vídeo y el audio, nuestro servicio entrega el texto transcrito en IMSC1.1 compatible con TTML.
en modo de espera de eventos en directo No había ningún modo de espera para V2. El modo stand-by es una nueva característica v3 que ayuda a administrar grupos de acceso frecuente de eventos en directo. Los clientes ahora pueden iniciar un evento en directo en modo stand-by a un costo menor antes de realizar la transición al estado en ejecución. Esto mejora las horas de inicio del canal y reduce los costos de los grupos activos operativos para inicios más rápidos.
de facturación de eventos en directo La facturación de eventos en directo se basa en medidores de canal en directo.
de salidas dinámicas Los programas tenían que iniciarse después de la creación. Las salidas dinámicas comienzan a crearse y se detienen cuando se eliminan.

Obtener ayuda y soporte técnico

Puede ponerse en contacto con Media Services con preguntas o seguir nuestras actualizaciones mediante uno de los métodos siguientes: