Stream - Cuestionario 4. Distribución en Directo (T7)
|
|
Título del Test:
![]() Stream - Cuestionario 4. Distribución en Directo (T7) Descripción: - suerte! |



| Comentarios |
|---|
NO HAY REGISTROS |
|
Cuando hablamos de contenido en directo, nos referimos a: Contenido que se transmite a medida que ocurren los eventos, en tiempo real o con poco retardo. Contenido emitido seleccionado a criterio del servidor, el cliente sólo elige verlo o no, pero no qué ver. Contenido pre-producido que el servidor envía en el stream LIVE. Todas las otras opciones pueden ser contenido en directo. La latencia de los contenidos en directo: No es importante para este tipo de contenidos. Suele ser preferible baja latencia, sobre todo si hay interactividad. Siempre es mejor una mayor latencia, ya que da tiempo a cortar trozos no deseados en producción. Sólo depende del tráfico de Internet en cada momento, por lo que escapa de nuestro control. El protocolo RTMP: Permite transmisión en baja latencia ya que está basado en UDP. Permite transmisión en baja latencia ya que utiliza chunks o fragmentación. Está basado en el formato de vídeo MP4. Todas las otras respuestas son correctas. Sobre la tecnología WebRTC: Es muy útil para aplicaciones de vídeo interactivas. Es transparente para routers y aprovecha las ventajas de caché en CDNs. Utiliza fragmentación de vídeo sobre el protocolo TCP. Todas las demás respuestas son correctas. En streaming HTTP en directo o LIVE: No puede ser adaptativo porque no da tiempo a cambiar de calidad. Ni DASH ni HLS soportan streaming en directo. El estándar DASH soporta streaming en directo pero HLS no. Ninguna de las demás respuestas es correcta. La segmentación de contenidos en HTTP streaming en directo: Se realiza exactamente de la misma manera que en HTTP streaming de vídeo bajo demanda. El manifiesto se mantiene igual pero el contenido se separa en archivos para cada segmento. Hay cambios en el manifiesto y los contenidos se dividen en archivos, uno para cada segmento. Ninguna de las demás opciones es correcta. En HTTP streaming de baja latencia: El servidor de streaming empuja fragmentos al cliente aunque el segmento no esté completo. El servidor de streaming es un servidor web estándar. No se produce rebuffering en el cliente cuando se usa HTTP streaming de baja latencia adaptativo. Todas las respuestas son correctas. Si usamos DASH para streaming en directo: El archivo MPD se debe ir actualizando periódicamente mientras dure la transmisión. El listado de segmentos en la MPD es ineficiente si no usamos el mecanismo Segment Template. En el archivo MPD no aparece la duración total del contenido. Todas las respuestas son correctas. |





