¿La transmisión utiliza la misma cantidad de ancho de banda que la descarga?


75

Suponiendo que el contenido es de la misma calidad (ceteris paribus), ¿los medios de transmisión (es decir, video, audio) usan la misma cantidad de ancho de banda que la descarga?

Digamos que debía descargar una película HD de Amazon o transmitirla, ¿sería el uso equivalente de ancho de banda?


2
Depende del protocolo y el códec: por ejemplo, descarga a través de http y transmisión a través de rtmp, o h264 vs vp6. En mi opinión, esta pregunta es demasiado amplia dada la cantidad de métodos de compresión y transmisión de datos para comparar.
zamnuts

Solo para aclarar tu pregunta. Por ancho de banda, ¿se refiere a la velocidad de datos, no al tamaño del archivo (película)?
Matt H

Una ventaja de descargar sobre la transmisión (que técnicamente se está descargando pero solo para un solo uso) es que puede consumir el material tantas veces como desee sin tener que gastar su ancho de banda cada vez. Algunos reproductores multimedia incluso pueden reproducir videos que está descargando actualmente (no descargados por completo), lo que brinda la "sensación" de transmisión con la ventaja de descargarlos.
ADTC

3
Sí, me estoy refiriendo a la velocidad de datos. La razón por la que pregunté fue por un desacuerdo con mi hermana y cuando busco en línea, todo lo que pude encontrar fueron respuestas vagas de las respuestas de Yahoo. Me doy cuenta de que hay muchas variables de las que depende, pero pensé que al menos valía la pena preguntar.
stemie

2
"En redes informáticas y ciencias de la computación, el ancho de banda, el ancho de banda de red, el ancho de banda de datos o el ancho de banda digital es una medida de la tasa de bits de los recursos de comunicación de datos disponibles o consumidos expresados ​​en bits por segundo o múltiplos de la misma (bit / s, kbit / s , Mbit / s, Gbit / s, etc.) - wikipedia.org/wiki/Bandwidth_(computing) "
publicado el

Respuestas:


43

A menudo no es equivalente.

Los proveedores de streaming utilizan protocolos, como DASH , para ajustar dinámicamente la calidad de la película a la disponibilidad de ancho de banda de los usuarios y los deseos de calidad. Luego, los servidores pueden limitar su velocidad de conexión para que pueda almacenar una cierta cantidad de almacenamiento intermedio (algo así como 10 segundos, tal vez 30 o un minuto completo) y luego solo obtiene la cantidad de ancho de banda requerida para obtener el contenido en tiempo real. Esta es una optimización obvia desde el punto de vista del proveedor, ya que distribuye el ancho de banda de manera más equitativa entre los usuarios y además evita que los datos se transfieran en vano (por ejemplo, cuando el usuario ve una película de 480p durante 10 minutos, sin limitación de imagen y con un enlace descendente común, es probable que se descargue mucho más que eso, pero luego se desperdicia si los usuarios dejan de ver el video).

La cantidad de datos transferidos es la misma. Pero puede llevar más tiempo con la transmisión, porque el proveedor puede limitar la velocidad de transferencia de datos a la velocidad requerida para entregar el contenido en una calidad determinada en tiempo real.

Dailymotion es uno de los proveedores que limitan las conexiones. Desde un servidor con al menos una conexión simétrica de 100 Mbit / s, vemos el siguiente comportamiento:

youtube-dl http://www.dailymotion.com/video/xhc3zz_long-distance-calling-into-the-black-wide-open_music
[dailymotion] xhc3zz: Downloading webpage 
[dailymotion] xhc3zz: Extracting information 
[dailymotion] xhc3zz: Downloading embed page 
[download] Destination: LONG DISTANCE CALLING - ' Into The Black Wide Open '-xhc3zz.mp4 
[download]   5.8% of 51.99MiB at 203.89KiB/s ETA 04:06

La tasa está muy por debajo de lo que sería posible (y se logra con otros proveedores). Además, si prueba material diferente, encontrará que la velocidad depende en gran medida del video individual: un video fullhd se descarga fácilmente con> 1 MiB / s, mientras que un video musical como este permanece alrededor de 200 KiB / s .

Para resumirlo todo y aclarar algunos posibles malentendidos: Algunos proveedores pueden limitar su descarga durante la transmisión, a través de su aplicación cliente (por ejemplo, youtube con su html5 o reproductor de video flash) o por medio del servidor. Si no le limitan la velocidad por medio del servidor, la descarga consumirá más ancho de banda, porque la limitación de velocidad que posiblemente aplica la aplicación del cliente durante la transmisión no tiene lugar. Este es el caso principal cuando el ancho de banda consumido es diferente con respecto a la pregunta original.


  1. Soy consciente de que esto es una especie de evidencia anectodal; sin embargo, he observado este comportamiento de manera consistente.

3
@Psycogeek Youtube es uno de los ejemplos que usan DASH (si este comentario no tiene sentido para usted, lea la parte introductoria del artículo que vinculé). Esto implica que el reproductor que el cliente está usando debe solicitar los fragmentos secuenciales de video de todos modos. Dar el paso desde allí para dejar de solicitar más fragmentos si el jugador no está corriendo es algo natural. Descargadores, como youtube-dlse acaba de seguir solicitando más trozos hasta que el vídeo está completamente descargado. Por lo tanto, la transmisión con DASH conlleva un poco más de gastos generales, pero probablemente valga la pena (tanto para el usuario como para el proveedor) y descuidada.
Jonas Schäfer

1
Suponiendo que la misma codificación de datos y se utilizan y definición (ver comentario psychogeek) la descarga se utilice más ancho de banda total. Es casi seguro que la descarga del video se realizará con TCP, mientras que la transmisión será UDP o un enfoque de entrega no garantizado similar. Por lo tanto, el TCP tendrá más acks enviados como mínimo, y dado que probablemente perderá o corromperá al menos algunos paquetes, el enfoque tcp también será más descargable (ya que también buscará los paquetes perdidos). Aunque la diferencia es muy pequeña en comparación con el tamaño de la descarga, esto es principalmente académico.
dsollen

2
@dsollen: a menos que un remitente UDP simplemente permita que los paquetes fluyan sin importar si el destinatario aún existe, tanto UDP como TCP requerirán acuses de recibo periódicos; En cualquier caso, los acuses de recibo representarán una porción muy pequeña del tráfico total. Además, formatear los datos de tal manera que cada paquete se pueda entender incluso si el paquete anterior no se recibe generalmente implica una sobrecarga de nivel más allá de lo que se requeriría para TCP.
supercat

77
Votaría en contra esta respuesta si tuviera suficiente representante: no responde la pregunta, la frase clave es "misma calidad". Cuando un proveedor pierde calidad, esto no es ceteris paribus .
zamnuts

1
@zamnuts, luego publica uno mejor y deja que la comunidad decida. FWIW, son un poco manzanas y naranjas cuando consideras que el proveedor decidió salsas de calidad, pero no creo que la respuesta estaría completa sin ella.
paqogomez

19

Suponiendo que estamos hablando de la misma calidad (es decir, sin aceleración, saltos de trama o transmisiones de menor calidad), entonces, en el mejor de los casos, las transmisiones tomarán la misma cantidad de ancho de banda que una descarga, aunque podría hacerse a un tiempo / velocidad Más conveniente para el proveedor. También podría tomar más ancho de banda dependiendo de cómo se comprima el video: la mayoría de las veces no se envía la imagen completa, sino solo el cambio (o delta) entre los cuadros. Esto significa que cuanto más historial haya (es decir, usar ese tono de azul del píxel X en el cuadro Y), menos habrá que enviar. Esto normalmente no aparece mucho, pero cuando una secuencia se detiene / interrumpe por cualquier razón, este "historial" se pierde y deberá volver a transmitirse, lo que aumenta el ancho de banda, mientras que con una descarga, se puede reanudar en el "descanso", y asumió que el receptor ya tiene esta información. Lo mismo puede usarse para audio, especialmente cuando no hay una tasa fija (es decir, FLAC en lugar de mp3)

Saltar (saltar, rebobinar, etc.) también podría afectar el uso: avanzar más allá del búfer reduciría la cantidad de ancho de banda utilizado por una secuencia, pero cualquier rebobinado lo aumentaría. También habría una interrupción, lo que provocaría un mayor uso (ver arriba), y cualquier tipo de "vista previa en miniatura" como el uso de YouTube y Netflix también aumentaría ligeramente el ancho de banda.

Última nota: compresión: esto podría hacerse para descargas, pero no tanto para transmisiones, la advertencia es que la mayoría de los videos ya están comprimidos, por lo que no se ganaría mucho aquí (aunque podría haber margen para ganancias en el ultra- departamento de alta resolución / calidad).


7

La transmisión utilizará menos ancho de banda, especialmente si las condiciones de la red son malas, pero esto tiene un precio .

El problema es la información que debe enviarse. En un modelo de descarga, todos los datos deben llegar al cliente, todo en el orden correcto, pase lo que pase . Si las condiciones de la red son malas y algunos bits de los datos no llegan al cliente, deben reenviarse, y esto aumenta el uso del ancho de banda. Si algunos datos se descomponen, deben volver a ponerse en orden antes de presentarse, y esto disminuye la capacidad de respuesta.

En un modelo de transmisión, está bien si algunos de los datos no llegan al cliente . Si está transmitiendo una película y un marco no llega allí, puede omitirlo y seguir adelante, para que no use ancho de banda adicional en los reenvíos. Si algunos fotogramas están fuera de servicio, solo juegue los que avanzan; una señal momentánea no importará, por lo que esto aumenta la capacidad de respuesta. Sin embargo, también significa que no necesariamente obtienes los datos completos: lo que ves es lo que llegó allí en el primer disparo.

Si tiene que elegir entre los modelos, elija según lo que desee hacer con los datos. Si desea archivarlo y / o posiblemente verlo muchas veces, descárguelo para asegurarse de obtener todo. Si no planea archivar, o solo planea ver los datos una vez, continúe y transmita; probablemente no notará la diferencia en una sola visualización, y si las condiciones de la red son lo suficientemente malas como para que lo note, la descarga sería aún peor.


¿Está diciendo que los servicios de transmisión usan UDP en lugar de TCP para permitir intencionalmente la caída de datos?
FreeAsInBeer

1
@FreeAsInBeer: Sí. TCP incorpora un conjunto de mecanismos de confiabilidad y otras características que son muy útiles para la mayoría de las aplicaciones imaginables. Pero los casos de uso sí existen cuando hay cosas aún más importantes que la confiabilidad, y la transmisión es una de ellas: es más importante mostrar el cuadro correcto en el momento correcto que mostrar cada cuadro. Los juegos en línea son otro ejemplo en el que UDP es popular, por las mismas razones: detener la acción para reconstruir el rastro de los estados de los jugadores es peor que tener que corregir el estado de caída ocasional.
El Spooniest

En realidad, muchos sistemas transmiten datos a través de TCP y el búfer en el lado del cliente. Para transmitir una película, la latencia no es crítica. No hay inconveniente para el usuario si algunos de los cuadros están en un búfer durante un minuto antes de que sea hora de mostrarlos. Pero para usos interactivos como la videoconferencia, la latencia es crítica.
Kasperd

1
kasperd: Estrictamente hablando, eso no es transmisión. Otras respuestas han mencionado servicios que se descargan pero comienzan a reproducirse antes de que finalice la descarga, y eso es lo que están haciendo los sistemas que usted describe.
The Spooniest

+1 para la respuesta menos confusa (hasta la fecha) en este hilo.
Ossifrage cósmico

5

Si realmente está pidiendo "ancho de banda" (bytes / seg) y no "datos totales" (bytes), la pregunta crucial es: ¿durante qué período de tiempo? Si suponemos que el usuario mira el video completo y que se devuelve el mismo códec / calidad, etc., e ignoramos la pequeña sobrecarga de las solicitudes / respuestas de transmisión, entonces los datos totales devueltos son iguales.

Ahora, ¿cuál es el ancho de banda? Hay dos formas de entender su pregunta:

  1. Ancho de banda durante el tiempo que lleva hasta que se complete la descarga. Para la transmisión, debería ver picos de alto ancho de banda (cuando se solicita el próximo fragmento) que vuelven a cero mientras observa ese fragmento hasta que se acerca al final del fragmento y hay un aumento en el ancho de banda nuevamente. Para la descarga, debería ver un ancho de banda muy alto para, digamos, 10 minutos, que se reduce a cero tan pronto como se descarga todo el video. Si detiene el experimento ahora, el ancho de banda para la descarga es obviamente mayor, ya que maximiza su enlace descendente hasta que esté listo.

  2. Ancho de banda durante el tiempo que se ve el video. El tiempo que se está viendo el video es el mismo para la transmisión y la descarga, suponiendo que ambos comiencen a verse de inmediato. El tamaño total de los datos también es el mismo. Dado que el ancho de banda es datos por tiempo, es lo mismo para ambos escenarios.

En el siguiente ejemplo, siempre hay un total de 40 (unidades de datos) descargadas. Pero para "descargar", son 40 en la primera unidad de tiempo, mientras que para "transmitir" son 20 durante las primeras unidades de tiempo (para obtener una gran porción inicial) y luego dos veces 10 para las dos porciones adicionales. Tenga en cuenta que si bien el ancho de banda se representa en el eje y, el área debajo de cada uno de los dos gráficos corresponde a los datos (bytes): si integra bytes / tiempo a lo largo del tiempo, obtiene bytes.


4

No son comparables.

Para la primera instancia, la codificación óptima para la visualización local es diferente de la codificación óptima para la visualización en streaming.

Hablemos de codificación de video.

En la mayoría de los formatos de codificación de video, generalmente hay dos tipos de cuadros:

  1. Trama intracodificada (I-Frame): son tramas que se transfieren en su totalidad, esta trama se puede decodificar sin conocer ninguna otra trama. Un marco intracodificado es esencialmente una imagen estática. Los codificadores los generarían durante las transiciones repentinas. Estos son menos eficientes para comprimir.
  2. Cuadro predicho (cuadro P) o cuadro biprevisado (cuadro B): son cuadros que almacenan solo las diferencias entre cuadros, solo se pueden decodificar si el espectador también conoce los cuadros anteriores y / o los últimos. Estos son mucho más eficientes para comprimir.

La codificación para la visualización local puede aprovechar la ventaja de que el disco rápido busca hacer uso de más cuadros P y B, mientras que un video codificado para una transmisión eficiente tendrá que codificar más I-Frame redundante a lo largo de todo el video, incluso cuando no haya transiciones repentinas para acomodar búsqueda al azar.

Además, hay dos tipos diferentes de transmisión. Puede transmitir una transmisión pregrabada (la mayoría de los videos de Youtube) y transmisiones de eventos en vivo (por ejemplo, Youtube Live). Debido a la necesidad de latencia, la transmisión de eventos en vivo no puede aprovechar las técnicas de codificación avanzadas que requieren una cantidad de tiempo larga o impredecible, mientras que una transmisión pregrabada puede tomar todo el tiempo que necesita para codificar.

El video transmitido también suele estar codificado con velocidad de bits constante (CBR). Para el mismo tamaño de destino, un video de velocidad de bits variable (VBR) generalmente tendrá una mayor calidad que un video CBR. Por el contrario, un video VBR es más pequeño para la misma calidad de un video CBR. Un protocolo de transmisión adaptativo como DASH tiene una tasa de bits adaptativa (ABR), que es un compromiso entre CBR y VBR. ABR permite al espectador adaptarse a los cambios en el ancho de banda de la red. Dado un ancho de banda constante y constante, ABR es más o menos lo mismo que CBR.

Lo que todo esto significa es que, dada la misma calidad y experiencia de visualización , puede codificar video para visualización local de manera más eficiente que el video transmitido, y puede codificar video para transmisiones pregrabadas de manera más eficiente que las transmisiones en vivo.

Luego también hay una sobrecarga en el protocolo de transmisión. Una descarga HTTP normal puede usar codificación de transferencia fragmentada para descargar todo el archivo que tiene una sobrecarga mínima. Una descarga transmitida tendrá que negociar el fragmento y la calidad del fragmento para transferir. En el gran esquema de las cosas, la sobrecarga del protocolo de transferencia es relativamente menor.

En general, para la misma cantidad de video que se ve, el video transmitido debería terminar teniendo una mayor cantidad de ancho de banda. La principal ventaja de la transmisión, en términos de uso de ancho de banda, es que puede ser guardada por personas que descargan pero no ve el video completo, lo que puede ser un ahorro muy significativo.


1

La respuesta es, depende".

La respuesta es NO, para proveedores que alojan video en general. Los proveedores medio decentes que transmiten video controlan la velocidad para garantizar una reproducción fluida y un ancho de banda óptimo para la mayor cantidad de personas posible. Entonces, aunque puede tener mucho ancho de banda, puede decidir darle solo 5Mbit y parecer bastante decente.

Si realiza una descarga HTTP, los algoritmos de control de velocidad TCP se activarán para garantizar que sature uno o ambos extremos de la conexión o cualquier otro elemento intermedio. Entonces, si tuviera 100Mbit disponibles, usará todo lo que pueda obtener o cerca de 100Mbit.

Eso, por supuesto, supone que no hay QoS en ningún lugar entre el cliente y el servidor.

Su pregunta es tan floja que también podría lograr que en algunas configuraciones ingenuas la respuesta también sea SÍ (con supuestos), los anchos de banda son idénticos. Para hacer eso, simplemente suelte el archivo en su servidor web básico y ábralo con su navegador para que un espectador entre en acción. O incruste el video en su servidor web básico y nuevamente, se reproducirá en el navegador y usará un ancho de banda idéntico con la siguiente suposición ... no hay otros usuarios, nadie más comparte la red con usted ... no hay otros factores en juego que puedan alterar su ancho de banda.

Tenga en cuenta que cuando descarga un archivo de un sitio web y luego lo descarga nuevamente, el ancho de banda entre la primera y la segunda descarga puede variar. Esto es simplemente porque la carga en el servidor puede cambiar y la congestión en la red y las rutas de red pueden cambiar.

Así que ahí lo tienes ... depende.


"el ancho de banda entre la primera y la segunda descarga puede variar", pero seguramente está descargando la misma cantidad de datos al final, incluso si uno tarda más que el otro / las condiciones de la red han cambiado.
stemie

@stemie, estará cerca. Diferentes protocolos agregan sobrecarga de protocolo. Pero si no hubo transcodificación o cambio de calidad / velocidad durante el proceso de transmisión, entonces debería ser la misma cantidad de datos de video en teoría.
Matt H

1

Desde el punto de vista de la red, "descargar" y "transmitir" son servicios diferentes, se llama "perfil de tráfico"

Para el servicio de transmisión, la red debe proporcionar un rendimiento constante mínimo (técnicamente "ancho de banda" significa algo diferente), el servicio de transmisión es sensible a las interrupciones y las fluctuaciones. No requiere el rendimiento máximo de la red, el retraso o la latencia no es crítico.

Desde la perspectiva del usuario final significa: El video se ejecutará sin problemas sin interrupciones ni caídas. No importa si el video comienza unos segundos antes o después.

La "descarga" generalmente requiere el máximo rendimiento de red posible, la descarga se realizará lo más rápido posible. Los retrasos, las interrupciones y las fluctuaciones no son críticas.

Una red puede proporcionar más perfiles de tráfico que son completamente diferentes. Por ejemplo, los servicios de voz (llamada telefónica simple) requieren un rendimiento muy bajo pero son muy sensibles a los retrasos (menos de 200 ms)


0

Para agregar a otras respuestas, mi respuesta es: No necesariamente .

Ahora, suponiendo que todo sea igual (sin selección automática de calidad, sin limitación del servidor y / o ISP) ...

El ancho de banda generalmente se define como size_of_data dividido por total_time. (Técnicamente, el término 'apropiado' es rendimiento , pero estoy divagando).

Supongamos que vas a transmitir un video de 2000 segundos con un tamaño de 60 MB.

Con la transmisión, el programa streamer puede limitar su velocidad para evitar el desbordamiento del búfer. Por lo tanto, su encabezado de solicitud HTTP podría incluir un campo Rango . El ancho de banda efectivo desde que comienza la transmisión hasta que finaliza la transmisión sería ~ 60 MB / 2000 segundos = 30 KB / s = 240 kbps.

Sin embargo, si se descarga el video de plano, obtendrá hasta el máximo ancho de banda de su servicio de Internet. Dependiendo de otro uso al mismo tiempo, por supuesto. Entonces, suponiendo un servicio de Internet de 6 Mbps, con un ancho de banda disponible del 50%, obtendrá un ancho de banda de 3 Mbps para la descarga de videos.


0

La transmisión es realmente una forma de descargar.

Cuando mira una película transmitida, su reproductor multimedia descargará partes de ella, se la mostrará y descartará las partes del archivo que se muestran sobre la marcha.

Por lo general, cuando descarga un archivo, espera a que finalice la descarga y solo entonces comienza a verlo. Pero hay reproductores multimedia que pueden mostrarle la parte descargada del archivo y pausar automáticamente y esperar a que se descargue un poco más. Algo así como la transmisión, pero sin descartar el archivo.

Técnicamente, cuando la preocupación es la cantidad total de datos transferidos, no importa cómo lo descargues, sino la diferencia entre el archivo que descargas y el archivo que tu reproductor multimedia descarga para ti como una transmisión. Pueden ser los mismos archivos exactos, y significará el mismo ancho de banda en ambos casos.

Los sitios de medios de transmisión generalmente codifican su contenido para tener una tasa de bits más baja que un disco comprado en la tienda. Pero puede ver una película desde su PC de escritorio en una computadora portátil a través de WiFi utilizando la función de intercambio de archivos de su sistema operativo, y ocupará casi la misma cantidad de tráfico que si la estuviera viendo en el escritorio (como leer bytes desde el disco duro) manejar). Técnicamente, se estaría transmitiendo, mientras ves una película mientras partes de ella se descargan y descartan continuamente.

Entonces, la respuesta es que depende absolutamente del tamaño de los dos archivos , transmitidos a través del reproductor de medios y descargados al disco.


0

La transmisión utiliza el rendimiento de descarga, por lo tanto, puede considerarlo como descarga. Su pregunta es un poco ambigua en cuanto a lo que considera una descarga. Solo puede descargar tanta carga como pueda y esté dispuesto a ofrecer. Entonces, al final, si desea comparar una descarga directa desde HTTP sobre DASH (aún HTTP), por ejemplo, tendría que verificar cuánta descarga está haciendo de cada uno.

Así que supongo que la respuesta es que podría estar usando la misma cantidad ... o menos ... o más. dependiendo de los servidores y la tasa que le están sirviendo.


-2

Sí, es el equivalente. Descargar = Lo descargas solo una vez y permanece en tu computadora. Stream = Descarga temporalmente "algo" a su computadora.


Hay una diferencia entre la cantidad de datos transferidos y el ancho de banda utilizado.
Jonas Schäfer

bien en mi Android, ver un video de una transmisión o descargarlo tiene el mismo uso de datos
Tiago Ribeiro

@JonasWielicki Un hombre sabio dijo una vez: "La cantidad de datos transferidos es la misma". Claro que la cantidad de ancho de banda utilizada varía, ya que debido al almacenamiento en búfer, la velocidad de transferencia es más lenta con el tiempo.
Nenotlep

1
Esta es realmente la respuesta correcta en muchos casos. Muchas veces, en muchos casos, se utiliza exactamente el mismo recurso y protocolo para la transmisión y descarga. Si desea reproducir un recurso a través de HTTP, no es diferente de descargarlo aparte de que lo está reproduciendo mientras se descarga. Claro, hay optimizaciones para la transmisión y diferentes protocolos que pueden cambiar su velocidad de bits a medida que transmite, pero no creo que ese sea el núcleo de la pregunta que se hace. (Sin embargo, merecen mención).
Brad
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.