Preguntas frecuentes de solución de problemas

Este documento describe las prácticas recomendadas y los consejos de solución de problemas para Amazon Interactive Video Service (IVS). Se pueden producir comportamientos inesperados o no deseados cuando use IVS. Estos comportamientos pueden ocurrir en varios puntos del proceso de transmisión, desde la transmisión hasta la reproducción del contenido:

Para obtener información sobre la asistencia y otros recursos de Amazon IVS, consulte Recursos y soporte.

Transmisión y codificación

En las preguntas de esta sección se hace referencia a la transmisión, la codificación y las condiciones de transmisión de primera milla a IVS. Estos comportamientos se producen antes de que el contenido llegue a los servidores de IVS.

Temas:

• ¿Qué es la transmisión en inanición?

• ¿Por qué la transmisión se detuvo de repente?

• ¿Qué ocurre cuando cambio de red mientras hago una transmisión?

• ¿Cómo puedo tener redundancia multirregional con IVS?

• ¿Cómo soluciono los problemas de una sesión del SDK de IVS de transmisión web?

• ¿Cómo utilizo las métricas internas de WebRTC de Google Chrome para evaluar una sesión del SDK de transmisión web de IVS?

¿Qué es la transmisión en inanición?

La “transmisión en inanición” es un retraso o una interrupción en la entrega de paquetes de contenido cuando se envía contenido a IVS, es decir, cuando IVS ingiere contenido. Si durante la ingesta, IVS no obtiene la cantidad esperada de bits que el dispositivo de codificación anunció que enviaría durante un periodo determinado, esto se considera un evento de inanición. A menudo, los eventos de inanición se deben al codificador de la emisora, a las condiciones de la red local o al tránsito a través de la Internet pública, entre el dispositivo de codificación e IVS.

Desde la perspectiva del espectador, los eventos de inanición pueden manifestarse como un video que se retrasa, se almacena en búfer o se congela. Los eventos de transmisión en inanición pueden ser breves (menos de 5 segundos) o largos (varios minutos), según la naturaleza del evento.

Para permitir el monitoreo de los eventos de inanición, IVS envía los eventos de inanición como EventBridge eventos de Amazon; consulte Examples: Stream Health Change in Using Amazon with EventBridge Amazon IVS. Se envían cuando una transmisión entra o sale de un estado de inanición. Según el caso de uso, puede tomar las medidas adecuadas, como notificar a la emisora y a los espectadores sobre las condiciones intermitentes de la transmisión.

Para obtener más herramientas de monitoreo de inanición, consulte Monitoring Amazon IVS Low-Latency Streaming, el punto final de la ListStreamsAPI IVS (filtrado por estado) y el GetStreampunto final IVS (para analizar una transmisión individual). Consulte también ¿Cómo superviso los eventos de transmisión en inanición?

¿Por qué la transmisión se detuvo de repente?

Las siguientes son las razones más comunes por las que una transmisión puede detenerse abruptamente (es decir, finalizar la sesión de transmisión):

• Faltan datos de ingesta: cuando la ingesta de una sesión de transmisión se detiene por completo (no hay ingesta de datos en IVS) durante 30 segundos, el servidor de ingesta de IVS finaliza la sesión de transmisión de IVS. El periodo de 30 segundos permite a la emisora volver a conectarse al servidor de ingesta. Sin embargo, en algunos casos (como el cambio de redes), quizá no sea posible volver a conectarse a la sesión de transmisión existente porque se ha interrumpido el protocolo de enlace TLS de RTMPS. Las causas de raíz más comunes de esto son los problemas de red (como la congestión entre el dispositivo de transmisión e IVS), la pérdida total de Internet en el dispositivo de transmisión o que el dispositivo de transmisión no produzca segmentos de contenido (etiquetas FLV).

  A menudo, la desconexión de la transmisión se alinea con un evento de transmisión en inanición; el evento de inanición se desencadena cuando se detiene la entrada de datos. Si se envía un evento de inicio de inanición y, a continuación, se envía un evento de fin de transmisión (sin un evento de fin de inanición), esto suele indicar que la transmisión finalizó porque no se enviaron datos a IVS.

• StopStream Punto final de IVS: durante una sesión de transmisión de IVS, si se realiza la llamada a la StopStreamAPI, la sesión de transmisión de IVS finalizará. El StopStream punto final desconecta la transmisión RTMPS entrante del servidor de ingesta de IVS. Según el software o hardware de codificación que se utilice, se puede intentar una nueva sesión de transmisión.

• Error de codificador: algunos codificadores de software o hardware desconectarán la sesión de transmisión cuando se produzca un error durante el proceso de codificación. Desde la perspectiva de IVS, estas desconexiones aparecen como desconexiones intencionadas por parte de la emisora. Sin embargo, en los registros de codificación, se puede determinar que la transmisión se desconectó debido a un error involuntario.

¿Qué ocurre cuando cambio de red mientras hago una transmisión?

Cuando una emisora cambia de red (por ejemplo, de red móvil), se WiFi desconecta una conexión RTMPS en curso. Si bien es probable que la conexión a Internet de la emisora se restablezca después de 3 o 4 segundos, la nueva conexión tiene una nueva dirección IP debido al conmutador de red, que genera una nueva conexión RTMPS. Durante este cambio, la conexión RTMPS anterior no se desconecta correctamente: el codificador no envía un mensaje de desconexión a IVS. Como resultado, IVS espera 30 segundos a que se vuelva a conectar la conexión RTMPS anterior, lo que impide que la nueva transmisión RTMPS de la nueva red se conecte a IVS.

Para permitir una conmutación más rápida entre redes, te recomendamos que utilices el StopStreamterminal IVS para cerrar la sesión de transmisión anterior cuando el dispositivo cambie de red. En este escenario, cuando el dispositivo de transmisión se conecte a la nueva red, el dispositivo de transmisión podría llamar al StopStream punto final para finalizar la transmisión ahora inactiva. Tras una StopStream llamada exitosa, el dispositivo de transmisión podría iniciar una nueva sesión de transmisión en la nueva red sin esperar 30 segundos.

¿Cómo puedo tener redundancia multirregional con IVS?

La redundancia en IVS se puede lograr de varias maneras; consulte Resiliencia en Seguridad en IVS.

IVS se divide en diferentes planos de red: control y datos.

• El plano de control es regional (se basa en las regiones de AWS) y almacena información sobre los recursos de IVS (canales, claves de transmisión, pares de claves de reproducción y configuraciones de grabación).

• El plano de datos no está restringido a una región de AWS y es la red que transporta los datos desde la ingesta hasta la salida. Incluso si se crea un canal en la región us-west-2 (por ejemplo), es posible que el video que se transmite a ese canal no pase por us-west-2.

También consulte Solución global, control regional. Pueden darse los siguientes escenarios:

• Si solo se utiliza una región del plano de control (por ejemplo, us-east-1): si una región de control de AWS en particular sufre una degradación o una interrupción, es posible que el plano de control de IVS experimente latencia o errores cuando se crea, lee, actualiza o elimina cualquiera de los siguientes elementos: canales, claves de transmisión, pares de claves de reproducción o configuraciones de grabación. Intentar iniciar una nueva transmisión durante una interrupción puede provocar más latencia o errores cuando se inicia una sesión de transmisión. Según la gravedad de la degradación, puede ser posible continuar transmitiendo a un canal con una transmisión ya en curso.

  Si la autorización de reproducción está habilitada, es probable que los espectadores actuales puedan continuar reproduciendo las transmisiones en curso, pero es posible que los nuevos espectadores no puedan empezar a verla si hay problemas con la autorización del par de claves de reproducción. Si la autorización de reproducción no está habilitada, tanto los espectadores actuales como los nuevos deberían poder ver la transmisión en curso.

  La función de grabación automática de IVS en S3 también puede interrumpirse en caso de interrupción.

  El plano de control de IVS no se conmuta automáticamente por error a otra región de AWS en caso de una interrupción regional.

• Si se utilizan dos regiones del plano de control (por ejemplo, us-east-1 y us-west-2), y la segunda región se usa como conmutación por error si la región principal no está disponible: IVS no admite de forma nativa la conmutación por error del plano de control regional; por lo tanto, si una región del plano de control tiene problemas, es posible que las nuevas transmisiones que se inicien o las llamadas al plano de control experimenten problemas. Sin embargo, es probable que el plano de datos no se vea afectado, por lo que las transmisiones en curso para la región del plano de control continuarían sin problemas. El traslado del plano de control a una región secundaria (conmutación por error) se tendría que realizar desde la aplicación. Puede escribir una lógica de implementación personalizada para gestionar la conmutación por error del plano de control. No tenemos instrucciones oficiales sobre cómo gestionar una conmutación por error de un canal regional.

  Cuando se separa el plano de datos de video y el plano de control regional, la arquitectura de IVS adquiere resiliencia: las transmisiones en directo en curso deberían tener poca o ninguna interrupción en caso de que se produzca una falla en el plano de control regional. IVS mantiene un SLA del 99,9 % de tiempo de actividad y se compromete a garantizar la estabilidad de la infraestructura para sus clientes (consulte nuestro SLA).

¿Cómo soluciono los problemas de una sesión del SDK de IVS de transmisión web?

El SDK de transmisión web de IVS funciona un tanto diferente a una sesión de ingesta de IVS RTMPS normal. El SDK de transmisión web aprovecha el protocolo WebRTC para transmitir a un punto de conexión de IVS. Una vez que el contenido entra en el punto de conexión de IVS, se procesa y se remezcla o transcodifica en la salida HLS para su visualización.

Debido a la naturaleza del SDK de transmisión web, tenga en cuenta estos consejos para solucionar problemas de comportamiento de codificación:

• Cierre todas las pestañas o programas del dispositivo de transmisión que no deban estar abiertos durante la sesión de transmisión. Las pestañas o programas superfluos pueden utilizar recursos informáticos (como la CPU, la RAM y las redes), lo que puede provocar un rendimiento deficiente de la aplicación de transmisión. En el caso de las pestañas o programas que no se puedan cerrar, asegúrese de que no utilicen cantidades innecesarias de recursos informáticos.

• Asegúrese de que la velocidad de carga del dispositivo supere los 200 Kbps. (Esto se indica en uno de los Problemas conocidos del SDK de transmisión web). Para evaluar la velocidad de carga, abre el Administrador de tareas del dispositivo de transmisión para analizar la red disponible durante la transmisión. Si la velocidad de carga o de bits es inferior a lo que espera o desea, evalúe otras pestañas o procesos que puedan estar consumiendo ancho de banda. Además, observe otras máquinas de la red local que puedan estar consumiendo grandes cantidades de ancho de banda.

• Si hay picos aleatorios en el uso de la CPU, consulte el Administrador de tareas de la máquina para comprender qué procesos pueden estar consumiendo la CPU. Un servicio común que provoca el uso aleatorio de la CPU es el software antivirus que ejecuta escaneos periódicos en la máquina.

• Intente transmitir a través de https://stream.ivs.rocks/ para ayudar a aislar los entornos y asegurarse de que la lógica de la aplicación no esté causando el comportamiento no deseado. Este sitio está gestionado por IVS y es un entorno de pruebas sólido para evaluar si alguna parte de la integración con el SDK de transmisión web es la causa principal del comportamiento no deseado.

• Intente utilizar los componentes internos de WebRTC de Google Chrome (consulte más abajo).

¿Cómo utilizo las métricas internas de WebRTC de Google Chrome para evaluar una sesión del SDK de transmisión web de IVS?

Al transmitir por medio del SDK de transmisión web de IVS, pueden producirse varios comportamientos durante la codificación y el envío de la transmisión. Siga estos pasos para solucionar problemas o recopilar información sobre la sesión en el dispositivo de transmisión:

1. En Google Chrome, abra la página web de transmisión.

2. Abra una nueva pestaña de Chrome y diríjase a chrome://webrtc-internals/ (copie exactamente esto).

3. En la pestaña de la página web de transmisión original, inicie la sesión del SDK de transmisión web y deje que la sesión se ejecute hasta que se observe el comportamiento.

4. Cuando observe este comportamiento, cambie a la pestaña chrome://webrtc-internals/ (no finalice la sesión de transmisión) y asegúrese de que se muestra la página web correcta:

   

5. Abra la sección expandible Crear volcado en la parte superior de la pantalla.

6. Selecciona Descargar las PeerConnection actualizaciones y los datos estadísticos en la parte superior de la pantalla (justo debajo de Crear volcado) para descargar el .txt archivo de la sesión correspondiente.

7. Una vez descargado, el archivo mostrará una vista histórica de la conexión WebRTC. Puede verlo en varias herramientas o enviarlo al equipo de AWS Support para que lo analice más a fondo.

Supervisión y eventos

En las preguntas de esta sección se hace referencia a la supervisión, las métricas y los eventos de IVS.

Temas:

• ¿Cómo superviso los eventos de transmisión en inanición?

• ¿Cómo utilizo Amazon CloudWatch para monitorizar las cuotas de servicio de IVS?

• ¿Cómo puedo diagnosticar la inestabilidad de la transmisión mediante el estado de la transmisión de IVS?

¿Cómo superviso los eventos de transmisión en inanición?

Recomendamos los siguientes métodos de supervisión de los eventos de transmisión en inanición:

• Amazon EventBridge con Amazon IVS: cuando comienza o termina un evento de inanición de arroyos, IVS produce un EventBridge evento de cambio en la salud del arroyo. Con EventBridge los objetivos y las reglas de Amazon, puedes usar estos eventos de inanición de arroyos para recibir alertas cuando se produzca una falta de arroyos. Para obtener más información sobre los objetivos y las normas, consulta la Guía del EventBridge usuario de Amazon.

• Monitoreo de transmisión de baja latencia de Amazon IVS: durante una sesión de transmisión en vivo, los datos se graban para luego incluirse en los análisis del estado de la transmisión de IVS. Esto incluye información sobre la configuración del codificador, las métricas de ingesta y los eventos de la sesión de transmisión. Esto es beneficioso cuando se supervisa una transmisión en curso o se evalúa retroactivamente una transmisión. Puede utilizar la consola o la API de IVS para identificar las transmisiones que experimentaron inanición. Los datos de las sesiones de transmisión están disponibles durante 60 días, incluso después de que se haya eliminado un canal, por lo que pueden resultar útiles para identificar transmisiones pasadas con eventos de inanición.

• Filtrado de transmisiones por estado: con la consola de IVS o el punto final de la ListStreamsAPI de IVS, puede usar el health filtro para buscar sesiones de transmisión que estén en un STARVING estado. Además, la CloudWatch métrica IVS ConcurrentStreams incluye una Health dimensión que puede utilizar para recopilar un recuento total de las transmisiones que se encuentran en estado de escasez de transmisiones. Consulte Monitoreo de transmisión de baja latencia de Amazon IVS.

• Puede utilizar el GetStreampunto final del IVS para analizar una transmisión individual.

Consulte también ¿Qué es la transmisión en inanición?

¿Cómo utilizo Amazon CloudWatch para monitorizar las cuotas de servicio de IVS?

Puedes usar Amazon CloudWatch para monitorizar/gestionar de forma proactiva las cuotas de servicio de IVS. Consulte Service Quotas de Amazon IVS. Esta documentación incluye información sobre la creación de CloudWatch alarmas para las métricas de uso.

Recomendamos que configure un tema de SNS adecuado para notificar a las personas o grupos adecuados cuando se active una alarma. Si se activa la alarma y la cuota es ajustable, debe solicitar un aumento de la service quota con un nuevo valor. Consulte Service Quotas de IVS para obtener información sobre cómo solicitar un aumento.

¿Cómo puedo diagnosticar la inestabilidad de la transmisión mediante el estado de la transmisión de IVS?

Recomendamos que evalúe la inestabilidad de la transmisión mediante el panel de control del estado de la transmisión de IVS. Las instrucciones se encuentran en Monitoreo de transmisión de baja latencia de Amazon IVS.

El panel de control contiene gráficos de series temporales para la tasa de bits de video, la velocidad de fotogramas y la tasa de bits de audio. A continuación, se muestran algunos ejemplos. Además, puedes hacer clic en Ver en CloudWatch para ver los datos en Amazon CloudWatch.

A continuación, se analizan varios escenarios.

Ancho de banda reducido o congestión de Internet

En este caso, la transmisión es relativamente inestable, incluso cuando se reducen las tasas de bits. O no hay suficiente ancho de banda entre la emisora y el ISP o entre el ISP e IVS, o hay algún problema en la ruta de red a IVS. Para resolver este problema, compruebe que ningún otro proceso de red utilice ancho de banda o póngase en contacto con el ISP para obtener un diagnóstico de la red.

Panel de control del estado de la transmisión de IVS:

CloudWatch:

Tasa de bits excesiva

Una tasa de bits más alta no supone necesariamente una mejor calidad; en este caso, la tasa de bits alta provoca inestabilidad. En muchos casos, debido a la congestión de la red, las tasas de bits altas provocan inestabilidad durante toda la transmisión. Respete las tasas de bits máximas que figuran en Resolución/Velocidaddebits/FPS.

Panel de control del estado de la transmisión de IVS:

CloudWatch:

Problemas de red o hardware

La codificación de video consume muchos recursos computacionales y, a veces, la máquina que realiza la codificación de video no puede soportar la carga. En este caso, verifique que la máquina no esté sobrecargada (ejecutando demasiadas cosas a la vez) y que el codificador esté actualizado. Considere la posibilidad de cambiar a un ajuste preestablecido de codificación que utilice menos CPU.

Panel de control del estado de la transmisión de IVS:

CloudWatch:

Picos y caídas de la tasa de bits

A veces, los codificadores de streaming intentan ser demasiado inteligentes y optimizar la tasa de bits, a menudo en función de la complejidad del fotograma que se está comprimiendo. Si la tasa de bits fluctúa rápidamente, es posible que los espectadores experimenten un almacenamiento en búfer cuando intentan cargar demasiados datos. Asegúrese de que la tasa de bits constante (CBR) esté habilitada, ya que mantiene una tasa de bits uniforme en toda la transmisión, independientemente de la complejidad de los fotogramas. Tenga en cuenta que también pueden producirse caídas; esto puede ser una señal de que su máquina no tiene suficiente potencia de CPU para que el codificador comprima el video.

Panel de control del estado de la transmisión de IVS:

CloudWatch:

Desconexión de Internet

Cuando un dispositivo de transmisión experimenta un problema con Internet, los servidores de IVS entran en un periodo de 30 segundos en el que evalúan si se restablece la misma conexión. Si no se restablece la misma conexión, el servidor de IVS finaliza la sesión de transmisión. Algunos codificadores intentarán volver a conectarse a la sesión de transmisión si se pierde la conexión a Internet, en cuyo caso se puede iniciar una nueva sesión de transmisión una vez finalizada la transmisión inicial.

Panel de control del estado de la transmisión de IVS:

CloudWatch:

Reproducción de la transmisión

La mayor parte de la información en esta sección es específica del SDK de reproductor de IVS y puede que no se aplique a otros reproductores. Para obtener más información, consulte Amazon IVS Player (Reproductor de Amazon IVS).

Temas:

• ¿Cómo puedo depurar los comportamientos del reproductor de IVS?

• ¿Por qué se congeló o se detuvo la reproducción para todos los espectadores?

• ¿Qué provoca que el reproductor de IVS almacene en búfer?

¿Cómo puedo depurar los comportamientos del reproductor de IVS?

Para habilitar el registro detallado para ayudar a depurar el reproductor de IVS, utilice el método setLogLevel del reproductor. Modifique el nivel de registro del reproductor para usar el argumento DEBUG. A continuación, el reproductor de IVS generará un registro detallado sobre el estado y la lógica que se producen en el reproductor de IVS.

Para realizar pruebas rápidas con el reproductor de IVS, con o sin los registros DEBUG habilitados, utilice el sitio de pruebas https://debug.ivsdemos.com/. Si los registros DEBUG están habilitados a través del menú de configuración, puede verlos en la vista de la consola del navegador.

¿Por qué se congeló o se detuvo la reproducción para todos los espectadores?

Si la reproducción se bloquea o se detiene para todos los espectadores al mismo tiempo en el contenido, probablemente se deba a un comportamiento ascendente. A menudo, la causa principal es el codificador de transmisión.

La transmisión en inanición o los comportamientos adversos de los codificadores de transmisión pueden afectar a todos los espectadores al mismo tiempo. Si la codificación de transmisión se desconecta y se inicia una nueva sesión de transmisión, todos los espectadores dejan de recibir contenido simultáneamente. Recomendamos que evalúe la sesión de transmisión mediante el Monitoreo de transmisión de baja latencia de Amazon IVS cuando analice este comportamiento.

¿Qué provoca que el reproductor de IVS almacene en búfer?

En el contexto de la transmisión de video y audio en vivo, el “almacenamiento en búfer” implica que el dispositivo de reproducción no puede descargar el contenido antes de que este se reproduzca. El almacenamiento en búfer puede manifestarse de varias formas: el contenido puede detenerse y comenzar de forma aleatoria (lo que también se conoce como inestabilidad), el contenido puede detenerse durante periodos prolongados (también conocido como congelación) o el reproductor puede entrar en un estado de BUFFERING.

Hay muchas causas del almacenamiento en búfer, las cuales podemos organizar en tres categorías principales:

• El almacenamiento en búfer del lado del espectador suele ocurrir cuando un evento de almacenamiento en búfer afecta a un solo espectador o a un grupo pequeño de espectadores. La causa principal de estos eventos de almacenamiento en búfer suele deberse a un problema en la red local (LAN) o del dispositivo de reproducción. En el caso de un problema de lentitud de la red local o del dispositivo, el almacenamiento en búfer se puede resolver asegurándose de que la reproducción con tasa de bits adaptable (ABR) esté habilitada, mediante la selección manual de una calidad inferior o la reducción del ancho de banda que utilizan otros programas y dispositivos.

• Almacenamiento en búfer en cuanto a la red: pueden producirse problemas entre la red local y el servidor de distribución de IVS, también conocido como el nivel del ISP. Los comportamientos de almacenamiento en búfer que surgen a nivel del ISP pueden ser difíciles de solucionar, ya que tener una visibilidad total del ISP podría ser imposible. Comportamientos como la latencia y la sobrecarga de la red (por ejemplo, el ISP no puede administrar el tráfico total de entrada y salida) pueden provocar retrasos en el suministro de contenido al espectador.

• Almacenamiento en búfer del lado de la transmisión: los problemas de transmisión de la sesión de transmisión en directo pueden provocar problemas de almacenamiento en búfer a gran escala para los espectadores. Por ejemplo, si un dispositivo de transmisión deja de enviar datos a IVS, este no tiene contenido para entregar al reproductor y el reproductor de IVS entra en un estado de almacenamiento en búfer cuando no se descarga ningún contenido. En muchos casos, un evento de almacenamiento en búfer de la transmisión hace que la mayoría de los espectadores, si no todos, se vean afectados simultáneamente.

Grabación automática en Amazon S3

Para obtener más información, consulte Auto-Record to Amazon S3 (Grabación automática en Amazon S3).

Temas:

• ¿Por qué falta parte del contenido de grabación?

• ¿Se puede utilizar el cifrado KMS-S3 con la grabación automática en S3?

¿Por qué falta parte del contenido de grabación?

Hay varias razones por las que puede faltar el contenido de grabación. Recomendamos los siguientes pasos para solucionar problemas con el contenido faltante:

1. Asegúrese de que la grabación automática en S3 esté habilitada para el canal de IVS deseado:

   1. Consola: en la página de información del canal correspondiente, en la sección General configuration (Configuración general), asegúrese de que la grabación automática en S3 esté Enabled. Si está habilitada, compruebe la Recording configuration (Configuración de grabación) para asegurarse de que tanto el Storage (Prefijo de almacenamiento) como el Recording prefix (Prefijo de grabación) sean correctos.

   2. CLI: ejecute el código get-channel y pase el ARN del canal de IVS deseado:

      aws ivs get-channel --arn "arn:aws:ivs:us-west-2:123456789012:channel/abcdABCDefgh"

      Compruebe si se devuelve el código recordingConfigurationArn.

2. Busca en el depósito S3 designado el contenido de grabación de la sesión de transmisión específica (consulta el prefijo S3). El prefijo clave S3 de una sesión grabada se encuentra en el evento Amazon EventBridge Recording State Change. Nota: Si la característica de fusión de transmisiones fragmentadas está habilitada, es posible que parte del contenido sea otra sesión grabada.

3. Si la duración total de la transmisión fue inferior a 10 segundos o faltó el contenido de la transmisión (es decir, se produjo una transmisión en inanición), es posible que falte el contenido grabado porque no se generó nada.

¿Se puede utilizar el cifrado KMS-S3 con la grabación automática en S3?

La función de grabación automática de IVS en Amazon S3 no admite el cifrado KMS-S3. Al intentar utilizar el cifrado KMS-S3, se produce un error al iniciar la grabación y se produce un error al iniciar la grabación. EventBridge La solución alternativa recomendada es utilizar el cifrado SSE-S3 compatible, que está habilitado de forma predeterminada en todos los objetos cargados en Amazon S3.

Temas varios

En las preguntas de esta sección se hace referencia a temas que no se pueden clasificar en ningún otro lugar.

Temas:

• ¿Qué significa el error “pendiente de verificación”?

• ¿Puedo estimar el costo por el uso de IVS?

¿Qué significa el error “pendiente de verificación”?

Cuando use IVS, puede aparecer un error que diga: “Su cuenta se encuentra pendiente de verificación”. Hasta que el proceso de verificación se complete, es posible que no pueda realizar solicitudes con esta cuenta. Si tiene alguna pregunta, póngase en contacto con AWS Support”.

Esto indica que la cuenta de AWS que está utilizando debe verificarse con AWS antes de que pueda usar IVS. (Si bien su cuenta puede funcionar con otros servicios de AWS, IVS utiliza un método de verificación mejorado).

Para verificar su cuenta de AWS, póngase en contacto con AWS Account Support (con el mensaje de error que está recibiendo) desde el Centro de AWS Support: https://support.console.aws.amazon.com/support/home?#/

¿Puedo estimar el costo por el uso de IVS?

Si bien el costo exacto por el uso de IVS no se puede determinar antes de una sesión de transmisión, hay un estimador de costos aproximados en: https://ivs.rocks/calculator. Puede encontrar información adicional sobre los precios en: https://aws.amazon.com/ivs/pricing/.