Llegué a casa de mi examen en la red de programación, y una de las preguntas que se nos pidió fue «Si usted va a transmitir vídeo, se debe utilizar el protocolo TCP o UDP? Dar una explicación tanto de vídeo almacenados y video en vivo-los arroyos». A esta pregunta simplemente espera de una respuesta corta de TCP para vídeo almacenados y UDP para video en vivo, pero pensé acerca de esto en mi camino a casa, y no es necesariamente mejor usar UDP para la transmisión de vídeo en directo? Quiero decir, si usted tiene el ancho de banda para él, y decir que está transmitiendo un partido de fútbol o un concierto para el que importa, lo que realmente necesita para utilizar UDP?

Digamos que mientras se está transmitiendo este concierto o lo que sea mediante TCP usted comienza a perder paquetes (algo malo ocurrió en red entre usted y el emisor), y por un minuto entero no recibe paquetes. El video-stream pausa, y después de los minutos se ha ido paquetes de empezar a obtener a través de nuevo (IP encontrado una nueva ruta para usted). Lo que luego sucederá es que TCP retransmite el minuto perdido y continuar con el envío de la transmisión en vivo. Como supuesto el ancho de banda es mayor que la tasa de bits en la secuencia, y el ping no es demasiado alto, por lo que en un corto período de tiempo, un minuto perdido de actuar como un amortiguador para el flujo para que, de esa manera, si de paquetes la pérdida ocurre de nuevo, usted no notará.

Ahora, no puedo pensar de algunos aparatos donde esta no sería una buena idea, como por ejemplo, video-conferencias, donde necesidad para estar siempre en el final de la secuencia, debido a que un retraso en un vídeo-chat es simplemente horrible, pero durante un fútbol-partido, o de un concierto, ¿qué importa si usted es un solo minuto por detrás del stream? Además, se le garantiza que usted obtenga todos los datos y que sería mejor guardar para su posterior visualización cuando se entra sin ningún tipo de errores.

Esto me lleva a mi pregunta. ¿Hay alguna desventaja que no conozco sobre el uso de TCP para live-streaming? O debe ser, que si tiene el ancho de banda para que usted debe ir para TCP, dado que es «mejor» a la red (control de flujo)?

  • No muy de acuerdo que es la tarea, en el pasado ahora que he terminado el curso, pero, bueno… 🙂
  • usted no puede utilizar TCP w/o cualquier elemento incorporado en el lag (que es algo que todos estén de acuerdo sobre), pero usted puede utilizar TCP+UDP para proporcionar una buena calidad si la sesión es grabada.
InformationsquelleAutor Alxandr | 2011-05-31

13 Comentarios

  1. 73

    Inconvenientes de la utilización de TCP para video en vivo:

    1. Normalmente en vivo de streaming de vídeo electrodomésticos no están diseñados con TCP streaming en mente. Si utiliza TCP, el sistema operativo debe búfer de la no reconocida segmentos para cada cliente. Esto no es deseable, especialmente en el caso de los eventos en vivo; presumiblemente su lista de clientes simultáneos es largo debido a la singularidad del evento. Vídeo Pre-grabadas-proyecta normalmente no tienen mucho de un problema con esto, porque los espectadores escalonar su actividad de reproducción; por lo tanto TCP es más apropiado para la reproducción de un video-on-demand.
    2. De multidifusión IP reduce significativamente el ancho de banda de vídeo de los requisitos para el gran público; TCP impide el uso de la multidifusión IP, pero UDP es muy adecuado para la multidifusión IP.
    3. Vídeo en directo es normalmente una constante secuencia de ancho de banda grabar una cámara; pre-grabadas flujos de vídeo de salir de una disco. La pérdida de interrupción de la dinámica de TCP hacer más difícil para servir de video en vivo cuando los flujos fuente están en un ancho de banda constante (como sucedería en el caso de un evento). Si el búfer a disco de una cámara, asegúrese de tener suficiente amortiguación para impredecibles eventos de la red y de la variable de envío TCP/retroceso de las tasas. UDP te da mucho más control para esta aplicación ya que UDP no se preocupa de la red de transporte la capa de gotas.

    Para su INFORMACIÓN, le rogamos que no utilice la palabra «paquetes» al describir las redes. Redes enviar «paquetes».

    • Lo siento, voy a cambiarlo. Una pregunta, sin embargo, no IPv6 (sí, lo sé, puede no ser compatible con todo) soporte de multidifusión en el auto, así que no debería TCP a través de IPv6?
    • Oh, y también, el video grabado a través de un evento en vivo es probablemente guardan en el disco de todos modos, tener que retransmitir una pequeña parte de eso, ¿sería realmente mal por mal?
    • Yo no estoy familiarizado con nada en IPv6 que hace que TCP multidifusión más fácil. ¿Qué característica de IPv6 qué tienes en mente?
    • tcpipguide.com/free/t_IPv6MulticastandAnycastAddressing.htm
    • incluso si utiliza direcciones Anycast, no resuelve el problema fundamental con el servicio de multidifusión a través de TCP… TCP identifica sockets como un quad-tupla de (src ip, puerto orig, dst ip, horario de verano puerto). Si todos los clientes utilizan la misma ip fuente, debe de alguna manera la ruta de los paquetes IPv6, basadas en el src puerto y mantener la pérdida de estado entre todos los clientes. Esta derrota el propósito de multidifusión, que fue enviar un copia de los paquetes para cada receptor
    • Lo que yo veo. Gracias por la respuesta :). Tenía curiosidad en cuanto a esto, así que he pensado que me gustaría ver lo que los pueblos pensado en esto. Y parece que los mundos de fútbol, los aficionados y la propia internet es contra mí, así que me imagino que es mi pérdida ^_^
    • Yo no conseguirlo, ¿cómo se puede transmitir con UDP cuando su Dgram base? ¿Cómo hacer eso, la única manera que he encontrado para enviar cosas más grande que un Paquete es dividir con bucles For y similares.
    • suena como usted, sólo pensaba en una base de paquete UDP streaming algoritmo… ¿tiene que ser duro? FYI, legado UDP streaming con VLC

  2. 25

    pero durante un fútbol-partido, o un
    concierto ¿qué importa si son
    un solo minuto por detrás del stream?

    A algunos aficionados al fútbol, bastante. Se ha comentado que los retrasos de unos pocos segundos presente en las transmisiones de vídeo digitales debido a la codificación (o lo que sea) puede ser muy molesto cuando, durante los eventos de alto perfil, tales como partidos de la copa mundial, se puede escuchar los gritos y gemidos de los chicos de al lado (que están viendo un undelyed programa analógico) antes de llegar a ver el juego de movimientos que les causó.

    Creo que para alguien que cuida mucho acerca de los deportes (y esos son el mayor grupo de clientes de pago de la TELEVISIÓN digital, al menos aquí en Alemania), siendo de un minuto por detrás en una secuencia de vídeo en directo sería completamente inaceptable (Como en, no iban a cambiar a su competidor donde esto no sucede).

    • Recuerdo a la gente quejarse de que en Suiza también.
  3. 17

    Generalmente de una secuencia de vídeo es un poco tolerante a fallos. Así que si algunos de los paquetes se pierden (debido a algunos router a lo largo de la manera de ser sobrecargado, por ejemplo), entonces todavía será capaz de mostrar el contenido, pero con menor calidad.

    Si su transmisión en vivo fue el uso de TCP/IP, entonces sería forzado a la espera para aquellos que cayó paquetes antes de podría continuar con el procesamiento de datos más recientes.

    Eso es doblemente malo:

    • los datos antiguos se re-transmitida (que probablemente sea un marco que ya fue mostrado y por lo tanto sin valor) y
    • nuevos datos no pueden llegar hasta después de los datos antiguos se re-transmitida

    Si su objetivo es mostrar como la actualizada información posible (y para un live-stream usualmente quiere ser actualizada, incluso si los marcos se vea un poco peor), TCP trabajar en contra de usted.

    Para un flujo de grabación de la situación es ligeramente diferente: usted probablemente va a ser el almacenamiento en búfer mucho más (posiblemente varios minutos!) y no habría de datos re-transmitida que tienen algunos artefactos debidos a la pérdida de paquetes. En este caso TCP es un buen partido (esto todavía podría ser implementado en la UDP, por supuesto, pero TCP no tiene tanta inconvenientes como para la transmisión en vivo de los casos).

    • Pero como he explicado, muchos de los «vivos» de los arroyos que utilizamos hoy en día, probablemente no habría ningún problema con ser la mitad de un minuto de retraso, y por lo tanto usted recibirá automáticamente un buffer, por lo que no tienes que ver los paquetes que se pierden en todos. No esta probablemente preferible si se va a guardar los datos?
    • en el caso de que usted está suavizando la definición de un «vivo» stream, no 😉
    • Sí, lo sé, pero yo trato de explicar que en la pregunta demasiado. Aunque parece que el principal problema sería con el almacenamiento de datos antiguos (para retransmitir), y la multidifusión (al menos con IPv4)
    • En cualquier caso, usted no desea que los paquetes descartados va a causar artefactos visuales que se propagan en varios fotogramas. Solución adecuada es soltar todos los marcos y UDP es definitivamente no es la solución para la congestión de la red en la reproducción de vídeo.
    • Por defecto, una secuencia de vídeo es no tolerante a fallos
  4. 7

    Hay algunos casos de uso adecuado de transporte UDP y otros adecuados para el transporte TCP.

    El caso de uso también se dicta en la configuración de codificación del vídeo. Cuando radiodifusión partido de fútbol foco está en la calidad y por video conferencia foco está en la latencia.

    Cuando el uso de la multidifusión para entregar el vídeo a sus clientes, a continuación, UDP se utiliza.

    Requisito para la multidifusión es costoso hardware de red entre la radiodifusión servidor y el cliente. En la práctica esto significa que si su empresa es propietaria de la infraestructura de red puede utilizar multidifusión y UDP para la transmisión de video en directo. Incluso entonces, la calidad de servicio también se implementa para marcar los paquetes de vídeo y dar prioridad a ellos así que no hay pérdida de paquetes sucede.

    De multidifusión simplificará la radiodifusión de software debido a que el hardware de red manejará la distribución de los paquetes a los clientes. Los clientes se suscriben a la multidifusión y los canales de la red se vuelva a configurar para enrutar paquetes a los nuevos suscriptores. Por defecto, todos los canales están disponibles para todos los clientes y puede ser de forma óptima a enrutar.

    Este flujo de trabajo lugares dificultad en el proceso de autorización. Hardware de red no diferenciar a los usuarios suscritos de otros usuarios. Solución para la autorización en el cifrado de contenido de vídeo y la habilitación de descifrado en el software del reproductor cuando la suscripción es válida.

    De unidifusión (TCP) de flujo de trabajo permite servidor para comprobar las credenciales del cliente y sólo permitir suscripciones válidas. Incluso permitir que sólo cierto número de conexiones simultáneas.

    De multidifusión no está habilitado a través de internet.

    Para la entrega de video a través de internet TCP debe ser utilizado. Cuando UDP se utiliza desarrolladores acaban de re-implementación de paquetes de re-transmisión, por ejemplo. Bittorrent p2p vivir protocolo.

    «Si utiliza TCP, el sistema operativo debe búfer de la no reconocida segmentos para cada cliente. Esto no es deseable, especialmente en el caso de los eventos en vivo».

    Este buffer debe existir en alguna forma. Mismo es cierto para el buffer de jitter en el lado del jugador. Se llama zócalo «buffer» y el software del servidor puede saber cuando este buffer se llena y descarte adecuado de fotogramas de vídeo para la transmisión de secuencias en directo. Es mejor utilizar unicast/TCP método debido a que el software de servidor puede implementar un adecuado marco de abandonar la lógica. Al azar paquetes que faltan en la UDP caso de que se acaba de crear mala experiencia de usuario. como en este video: http://tinypic.com/r/2qn89xz/9

    «De multidifusión IP reduce significativamente el ancho de banda de vídeo de los requisitos para el gran público»

    Esto es cierto para las redes privadas, Multidifusión no está habilitado a través de internet.

    «Tenga en cuenta que si TCP pierde demasiados paquetes, la conexión se muere; por lo tanto, UDP te da mucho más control para esta aplicación ya que UDP no se preocupa de la red de transporte la capa de gotas».

    UDP también no le importa acerca de la eliminación de fotogramas completos o grupo de fotogramas por lo que no dan más control sobre la experiencia del usuario.

    «Normalmente una secuencia de vídeo es un poco tolerante a fallos»

    Vídeo codificado es no tolerante a fallos. Cuando se transmite más fiable de transporte, a continuación, corrección de errores hacia adelante se añade al contenedor de vídeo. Buen ejemplo es MPEG-TS contenedor que se utiliza en el satélite de emisión de vídeo que llevan varios audio, vídeo, EPG, etc. los arroyos. Esto es necesario ya que el enlace de satélite no es la comunicación bidireccional, lo que significa el receptor no puede solicitar que se vuelva a la transmisión de paquetes perdidos.

    Cuando usted tiene la comunicación dúplex disponible siempre es mejor re-transmisión de datos sólo para los clientes de pérdida de paquetes, a continuación, incluir una sobrecarga de adelante-corrección de errores en la secuencia enviado a todos los clientes.

    En cualquier caso, la pérdida de paquetes son inaceptables. Tramas están bien, en casos excepcionales, cuando el ancho de banda se ve obstaculizada.

    El resultado de los paquetes que faltan son artefactos como este: TCP vs UDP en el flujo de vídeo

    Algunos decodificadores pueden romper en flujos de paquetes que faltan en lugares críticos.

    • -1 para la multidifusión no está habilitado a través de internet. No en todas partes, pero algunos compañeros ofrecemos servicio de multicast. Un ejemplo es SeattleIX quien activa de multidifusión en el 2009
    • Pennington: algunos proveedores de servicios no están «internet», así que mi afirmación sigue siendo cierta. Usted se acaba de señalar al subconjunto muy pequeño de la infraestructura y con la esperanza de que otros se unan a esta práctica. Por favor, limítese a los hechos.
    • Cuando usted encuentra un punto a debatir cuánto multidifusión pasa a través de la internet por favor, hágamelo saber
  5. 4

    Recomiendo que mires de nuevo en directo p2p protocolo Bittorrent Live.

    Como para el streaming es mejor usar UDP, primero porque reduce la carga en los servidores, pero sobre todo porque usted puede enviar paquetes de multidifusión, es más fácil que enviar a cada cliente conectado.

  6. 3

    Depende. ¿Cuánta importancia tiene el contenido que se está transmitiendo? Si uso crítico de TCP. Esto puede causar problemas en el ancho de banda, calidad de vídeo (puede que tenga que utilizar una menor calidad para lidiar con la latencia), y la latencia. Pero si usted necesita el contenido garantizado llegar allí, uso de él.

    De otro modo UDP debe estar bien si la secuencia no es crítico y se prefieren debido a que UDP tiende a tener menos gastos generales.

  7. 2

    Uno de los mayores problemas con el suministro de eventos en directo por Internet, es la de ‘escala’, y TCP no escala bien. Por ejemplo, cuando la transmisión se realiza en directo un partido de fútbol -frente a una demanda de la reproducción de la película – el número de personas mirando fácilmente puede ser 1000 veces más. En un escenario de uso de TCP es una sentencia de muerte para el Cdn (content delivery networks).

    Hay un par de razones principales por las que TCP no escala bien:

    1. Una de las más grandes ventajas del TCP es la variabilidad de rendimiento alcanzable entre el emisor y el receptor. Durante el streaming de vídeo a través de Internet el vídeo de los paquetes debe atravesar varios routers a través de Internet, cada uno de estos routers se conectan con diferentes conexiones de velocidad. El TCP algoritmo comienza con la ventana de TCP pequeñas, luego crece hasta que la pérdida de paquetes es detectado, la pérdida de paquetes se considera un signo de congestión de TCP y responde al reducir drásticamente el tamaño de la ventana para evitar la congestión. Así que a su vez reduce el rendimiento efectivo de inmediato. Ahora imagina una red con TCP de transmisión el uso de 6-7 router de lúpulo para el cliente (muy habitual), si alguno de los intermedios router pierde ningún paquete, el protocolo TCP de enlace que va a reducir la tasa de transmisión. En realidad, El flujo de tráfico entre los routers de seguir un reloj de arena tipo de una forma; siempre gong arriba y abajo entre uno de los enrutadores intermedios. La representación efectiva a través de poner mucho menor en comparación con el mejor esfuerzo de la UDP.

    2. Como usted puede saber ya que TCP es un reconocimiento basado en el protocolo. Permite por ejemplo decir que el remitente es 50ms de distancia (es decir, la latencia entre dos puntos). Esto significaría que el tiempo que tarda un paquete para ser enviado a un receptor y el receptor para enviar un acuse de recibo sería 100ms; por lo tanto el máximo rendimiento posible en comparación a la UDP basado en la transmisión ya está a la mitad.

    3. El TCP no admiten la multidifusión o el nuevo estándar emergente de la multidifusión de AMT. Lo que significa que la Cdn no tiene la oportunidad de reducir el tráfico de red mediante la replicación de los paquetes-cuando muchos clientes están viendo el mismo contenido. Eso sí es un gran motivo suficiente para que los Cdn (como Akamai o Level3) para no ir con TCP para transmisiones en vivo.

  8. 1

    Para la transmisión de vídeo de ancho de banda es probable que la restricción en el sistema. El uso de la multidifusión puede reducir considerablemente la cantidad de ancho de banda de subida utilizado. Con UDP, usted puede fácilmente sus paquetes de multidifusión a todos los terminales conectados.
    También se puede utilizar un protocolo de multidifusión fiable, uno se llama Pragmática General de Multidifusión (PGM), yo no sé nada acerca de él y creo que no está muy extendida en su uso.

  9. 1

    Mientras que la lectura de la TCP UDP debate me di cuenta de un error lógico. Un paquete TCP pérdida causando un minuto de retraso que se convierten en un minuto buffer no puede ser correlacionada a la UDP soltando un minuto completo, mientras que experimentan la misma pérdida. Una más justa la comparación es la siguiente.

    TCP experimenta una pérdida de paquetes. El vídeo se detiene mientras TCP reenviar los paquetes en un intento de transmitir matemáticamente perfecta paquetes. El vídeo se retrasa durante un minuto y comienza donde lo dejó después de que falta el paquete hace su destino. Todos esperamos, pero sabemos que no te pierdas ni un solo píxel.

    UDP experimenta una pérdida de paquetes. Por un segundo durante la secuencia de vídeo en una esquina de la pantalla se pone un poco borrosa. Que nadie se de cuenta y el show continúa sin mirar para los paquetes perdidos.

    Nada que transmite las ganancias de la mayoría de los beneficios de la UDP. La pérdida de paquetes causando un minuto de retraso para TCP no causar un minuto de retraso a la UDP. Teniendo en cuenta que la mayoría de los sistemas de uso múltiple de la resolución de flujos de hacer que las cosas van paralizados cuando de hambre para los paquetes, que hace aún más sentido utilizar UDP.

    UDP FTW cuando streaming.

    • Estás olvidando que la mayoría de los códecs de vídeo tienen por lo menos un poco de redundancia mediante el uso de códigos de corrección de errores. Un solo paquete perdido puede ser ignorada porque de todos modos los datos ya disponibles, y el decodificador ni siquiera lo note.
  10. 1

    Si el ancho de banda es mucho mayor que la tasa de bits, yo recomendaría TCP para unicast streaming de vídeo en vivo.

    Caso 1: Consecutivo se pierden paquetes para una duración de varios segundos. => vivir de vídeo se detendrá en el lado del cliente sea cual sea la capa de transporte es (TCP o UDP). Cuando la red se recupera:
    – si se utiliza TCP, cliente reproductor de vídeo puede elegir reiniciar la secuencia en la primera pérdida de paquetes (timeshift) O a la caída de todos los finales de paquetes y para reiniciar la secuencia de vídeo sin timeshift.
    – si UDP se utiliza, no hay ninguna opción en el lado del cliente, video reiniciar vivir sin ningún tipo de timeshift.
    => TCP igual o mejor.

    Caso 2: algunos paquetes al azar y a menudo se pierde en la red.
    – si se utiliza TCP, estos paquetes serán inmediatamente retransmitidos y con una correcta del buffer de jitter, no habrá ningún impacto en el flujo de vídeo de calidad/latencia.
    – si UDP se utiliza, la calidad del vídeo será pobre.
    => TCP mucho mejor

  11. 1

    Todo el «uso de UDP respuestas de asumir una red abierta y «cosas tanto como usted puede’ enfoque. Bien de estilo antiguo cerrado jardín dedicado de audio/vídeo de redes, que son un tipo de fuga.

    En el mundo real, su transmisión va a ir a través de firewalls (que caerá de multidifusión y a veces udp), la red es compartida con otros más importantes ($$$) de aplicaciones, por lo que quiere para castigar a los abusadores con el escalado de la ventana.

  12. 1

    Además de todas las otras razones, UDP puede utilizar la multidifusión. Apoyo a 1000 de los TCP que todos los usuarios de la transmisión de los mismos datos desechos de ancho de banda.
    Sin embargo, hay otra razón importante para el uso de TCP.

    TCP puede mucho más fácil pasar a través de firewalls y Nat. Dependiendo de su NAT y el operador, que puede incluso no ser capaz de recibir un flujo UDP debido a problemas con la UDP de perforación del agujero.

  13. 0

    Esta es la cosa, es más una cuestión de contenido de lo que es un problema de tiempo. El protocolo TCP requiere que un paquete que no fue entregada debe ser cheque, verificado y entregados. UDP no hace uso de este requisito. Así que si usted envía un archivo que contiene millones de paquetes usando UDP, como un video, si algunos de los paquetes que faltan el momento de la entrega, lo más probable es que vaya unmissed.

Dejar respuesta

Please enter your comment!
Please enter your name here