O streaming usa a mesma quantidade de largura de banda do download?

Supondo que o conteúdo seja da mesma qualidade (ceteris paribus), a mídia de streaming (por exemplo, vídeo, áudio) usa a mesma quantidade de largura de banda que o download?

Digamos que eu deveria baixar um filme em HD da Amazon ou transmiti-lo, seria o uso equivalente da largura de banda?

Muitas vezes não é equivalente.

Os provedores de streaming usam protocolos, como o DASH , para ajustar dinamicamente a qualidade do filme à disponibilidade da largura de banda dos usuários e aos desejos de qualidade. Em seguida, os servidores podem limitar sua taxa de conexão para que você possa armazenar uma certa quantidade de buffer (algo como 10 segundos, talvez 30 ou um minuto inteiro) e, posteriormente, você obtém apenas a quantidade de largura de banda necessária para obter o conteúdo em tempo real. Essa é uma otimização óbvia do ponto de vista do provedor, porque distribui a largura de banda mais igualmente entre os usuários e evita que os dados sejam transferidos em vão (por exemplo, quando o usuário assiste a um filme em 480p por 10 minutos, sem limitar o mouse e com um downlink comum, é provável que muito mais do que isso já tenha sido baixado, mas desperdiçado se os usuários pararem de assistir ao vídeo).

A quantidade de dados transferidos é a mesma. Mas pode levar mais tempo com o streaming, porque o provedor pode limitar a taxa de transferência de dados à taxa necessária para entregar o conteúdo em uma determinada qualidade em tempo real.

O Dailymotion é um dos provedores que limitam a taxa de conexões. Em um servidor com conexão simétrica de pelo menos 100 Mbit / s, vemos o seguinte comportamento¹:

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

A taxa está muito abaixo do que seria possível (e é alcançada com outros fornecedores). Além disso, se você tentar um material diferente, verá que a taxa é altamente dependente do vídeo individual: um vídeo em fullhd é baixado facilmente com> 1 MiB / s, enquanto um videoclipe como esse permanece em torno de 200 KiB / s .

Para resumir tudo e esclarecer alguns possíveis mal-entendidos: Alguns provedores podem limitar o seu download durante o streaming, por meio do aplicativo cliente (por exemplo, youtube com seu player de vídeo html5 ou flash) ou por meio de servidor. Se eles não limitarem a taxa por servidor, o download consumirá mais largura de banda, porque a limitação de taxa que é possivelmente aplicada pelo aplicativo cliente durante o streaming não ocorre. Este é o caso principal quando a largura de banda consumida é diferente em relação à pergunta original.

1. Estou ciente de que essa é uma espécie de evidência anetodal - no entanto, observei esse comportamento de forma consistente.

Supondo que estamos falando da mesma qualidade (ou seja, sem aceleração, pulos de quadros ou fluxos de qualidade inferior), na melhor das hipóteses, os fluxos terão a mesma quantidade de largura de banda que um download, embora isso possa ser feito a uma taxa / tempo mais conveniente para o provedor. Também pode levar mais largura de banda, dependendo de como o vídeo é compactado - na maioria das vezes a imagem inteira não é enviada, apenas a alteração (ou delta) entre os quadros. Isso significa que quanto mais histórico houver (ou seja, usar esse tom de azul do pixel X no quadro Y), menor será o envio. Isso normalmente não aparece muito, mas quando um fluxo é pausado / interrompido por qualquer motivo, esse "histórico" é perdido e precisará ser retransmitido, aumentando assim a largura de banda, enquanto o download pode ser retomado. no "intervalo", e assumiu que o receptor já possui essa informação. O mesmo pode ser usado para áudio, especialmente quando não há uma taxa fixa (por exemplo, FLAC em vez de mp3)

Pular (pular, voltar a enrolar etc.) também pode afetar o uso - passar adiante o buffer reduziria a quantidade de largura de banda usada por um fluxo, mas qualquer re-enrolamento aumentaria. Além disso, haveria uma interrupção, o que causaria aumento no uso (veja acima) e qualquer tipo de "visualização em miniatura", como o que o youtube e o netflix também aumentariam levemente a largura de banda.

Última observação: compactação: isso pode ser feito para downloads, mas não tanto para fluxos - a ressalva é que a maioria dos vídeos já está compactada, para que não haja muito ganho aqui (embora possa haver espaço para ganhos no ultra- departamento de alta resolução / qualidade).

O streaming usará menos largura de banda, especialmente se as condições da rede forem ruins, mas isso tem um preço .

O problema está nos dados que precisam ser enviados. Em um modelo de download, todos os dados devem chegar ao cliente, na ordem certa, não importa o quê . Se as condições da rede estiverem ruins e alguns bits dos dados não chegarem ao cliente, eles deverão ser reenviados, e isso aumenta o uso da largura de banda. Se alguns dados ficarem fora de ordem, eles deverão ser reordenados antes de serem apresentados, e isso diminuirá a capacidade de resposta.

Em um modelo de streaming, não há problema se alguns dados não chegarem ao cliente . Se você estiver transmitindo um filme e um quadro não chegar lá, basta ignorá-lo e seguir em frente, para não usar largura de banda adicional nos reenvios. Se alguns quadros chegarem fora de ordem, basta reproduzir os que avançam; um toque momentâneo não importa, e isso aumenta a capacidade de resposta. No entanto, isso também significa que você não obtém necessariamente os dados completos: o que você vê é o que chegou lá na primeira tentativa.

Se você precisar escolher entre os modelos, escolha com base no que deseja fazer com os dados. Se você deseja arquivá-lo e / ou possivelmente visualizá-lo várias vezes, faça o download para ter certeza de obter tudo. Se você não planeja arquivar ou planeja visualizar os dados apenas uma vez, vá em frente e faça o stream; você provavelmente não notará a diferença em uma única exibição e, se as condições da rede forem ruins o suficiente para você perceber, o download será ainda pior.

Se você está realmente pedindo "largura de banda" (bytes / s) e não "dados totais" (bytes), a questão crucial é: durante que período de tempo? Se estivermos assumindo que o usuário assiste ao vídeo inteiro e que o mesmo codec / qualidade etc. é retornado e ignoramos a pequena sobrecarga de solicitações / respostas de streaming, o total de dados retornados é igual.

Agora, qual é a largura de banda? Existem duas maneiras de entender sua pergunta:

1. Largura de banda durante o tempo que leva até o download ser concluído. Para o streaming, você verá picos de largura de banda alta (quando o próximo pedaço for solicitado) que retornem a zero enquanto você estiver assistindo aquele pedaço até chegar perto do final do pedaço e houver um aumento na largura de banda novamente. Para fazer o download, você verá uma largura de banda muito alta por, por exemplo, 10 minutos, que cai para zero assim que o vídeo inteiro é baixado. Se você interromper o experimento agora, a largura de banda para download é obviamente maior, pois maximiza o downlink até o término.

2. Largura de banda durante o tempo em que o vídeo é assistido. O tempo em que o vídeo está sendo assistido é o mesmo para streaming e download, supondo que ambos comecem a assistir imediatamente. O tamanho total dos dados também é o mesmo. Como a largura de banda é de dados por tempo, é a mesma para os dois cenários.

No exemplo abaixo, sempre há um total de 40 (unidades de dados) baixadas. Mas para "baixar", são 40 na primeira unidade de tempo, enquanto para "transmitir" são 20 durante as primeiras unidades de tempo (para obter uma grande parte inicial) e depois duas vezes 10 para as duas partes adicionais. Observe que, enquanto a largura de banda é plotada no eixo y, a área sob cada um dos dois gráficos corresponde aos dados (bytes) - se você integrar bytes / tempo ao longo do tempo, obterá bytes.

Eles não são comparáveis.

Para a primeira instância, a codificação ideal para visualização local é diferente da codificação ideal para visualização em fluxo.

Vamos falar sobre codificação de vídeo.

Na maioria dos formatos de codificação de vídeo, geralmente existem dois tipos de quadros:

1. Quadro intra-codificado (quadro I) - esses quadros são transferidos na íntegra; esse quadro pode ser decodificado sem o conhecimento de qualquer outro quadro. Um quadro intra-codificado é essencialmente uma imagem estática. Os codificadores os gerariam durante transições repentinas. Estes são menos eficientes para compactar.
2. Quadro previsto (quadro P) ou quadro bi-previsto (quadro B) - esses são os quadros que armazenam apenas as diferenças entre os quadros; só podem ser decodificados se o espectador também conhecer os quadros anteriores e / ou posteriores. Estes são muito mais eficientes para compactar.

A codificação para visualização local pode tirar proveito das buscas rápidas em disco para usar mais quadros P e B, enquanto um vídeo codificado para streaming eficiente terá que codificar quadros I mais redundantes ao longo de todo o vídeo, mesmo quando não houver transições repentinas para acomodar busca aleatória.

Além disso, existem dois tipos diferentes de streaming. Você pode ter a transmissão de um fluxo pré-gravado (a maioria dos vídeos do Youtube) e fluxos de eventos ao vivo (por exemplo, o Youtube Live). Devido à necessidade de latência, o evento ao vivo de streaming não pode tirar proveito das técnicas avançadas de codificação que levam um tempo longo ou imprevisível, enquanto um fluxo pré-gravado pode levar o tempo necessário para codificar.

O vídeo transmitido também geralmente é codificado com taxa de bits constante (CBR). Para o mesmo tamanho de destino, um vídeo com taxa de bits variável (VBR) normalmente terá uma qualidade mais alta que um vídeo CBR. Por outro lado, um vídeo VBR é menor para a mesma qualidade de um vídeo CBR. Um protocolo de streaming adaptável como o DASH tem uma taxa de bits adaptável (ABR), que é um compromisso entre CBR e VBR. O ABR permite que o visualizador se adapte às mudanças na largura de banda da rede. Dada uma largura de banda constante e consistente, o ABR é mais ou menos o mesmo que o CBR.

O que tudo isso significa é que, com a mesma qualidade e experiência de visualização , é possível codificar o vídeo para visualização local com mais eficiência do que o vídeo transmitido e você pode codificar o vídeo para fluxos pré-gravados com mais eficiência do que os fluxos ao vivo.

Depois, há também uma sobrecarga no protocolo de streaming. Um download HTTP normal pode usar a codificação de transferência em partes para fazer o download de todo o arquivo que possui uma sobrecarga mínima. Um download transmitido terá que negociar a parte e a qualidade da parte a ser transferida. No grande esquema das coisas, a sobrecarga do protocolo de transferência é relativamente pequena.

No geral, para a mesma quantidade de vídeo assistida, o vídeo transmitido deve levar uma quantidade maior de largura de banda. A principal vantagem do streaming, em termos de uso da largura de banda, é que ele pode ser salvo por pessoas que fazem o download, mas não assiste o vídeo na íntegra, o que pode ser uma economia muito significativa.

A resposta é "Depende".

A resposta é NÃO, para provedores que hospedam vídeo em geral. Os provedores decentes que transmitem vídeo controlam a taxa de modo a garantir uma reprodução suave e a largura de banda ideal para o maior número de pessoas possível. Portanto, mesmo que você tenha muita largura de banda, pode optar por fornecer apenas 5Mbit e ainda parecer bastante decente.

Se você fizer um download HTTP, os algoritmos de controle de taxa TCP serão ativados para garantir que você sature uma ou as duas extremidades da conexão ou qualquer outra coisa. Portanto, se você tivesse 100Mbit disponível, ele usará tudo o que puder obter ou se aproximar de 100Mbit.

É claro que isso pressupõe que não há QoS acontecendo entre o cliente e o servidor.

Sua pergunta é tão frouxa que eu também poderia fazer com que, em algumas configurações ingênuas, a resposta também fosse SIM (com suposições), as larguras de banda são idênticas. Para fazer isso, basta soltar o arquivo no servidor da Web básico e abri-lo com o navegador para que o espectador entre em ação. a seguinte suposição ... nenhum outro usuário, ninguém mais compartilhando a rede com você ... nenhum outro fator em jogo que possa alterar sua largura de banda.

Lembre-se de que, quando você baixa um arquivo de um site e, em seguida, baixa novamente, a largura de banda entre o primeiro e o segundo download pode variar. Isso ocorre simplesmente porque a carga no servidor pode mudar e o congestionamento na rede e os caminhos da rede podem mudar.

Então aí está ... depende.

Do ponto de vista da rede, "download" e "streaming" são serviços diferentes, é chamado de "perfil de tráfego"

Para o serviço de streaming, a rede precisa fornecer uma taxa de transferência constante mínima (tecnicamente "largura de banda" significa algo diferente), o serviço de streaming é sensível a interrupções e instabilidade. Não requer que a taxa de transferência máxima da rede, atraso ou latência não seja crítica.

Da perspectiva do usuário final, isso significa: O vídeo deve ser executado sem problemas, sem interrupções ou quedas. Não importa se o vídeo começa alguns segundos antes ou depois.

O "download" geralmente requer o máximo rendimento possível da rede; o download deve ser finalizado o mais rápido possível. Atrasos, interrupções e instabilidade não são críticos.

Uma rede pode fornecer mais perfis de tráfego que são completamente diferentes. Por exemplo, serviços de voz (chamada telefônica simples) exigem taxa de transferência muito baixa, mas são muito sensíveis a atrasos (menos de 200 ms)

Para adicionar a outras respostas, minha resposta é: não necessariamente .

Agora, supondo que tudo seja igual (sem seleção automática de qualidade, sem limitação do servidor e / ou ISP) ...

A largura de banda é geralmente definida como size_of_data dividido pelo total_time. (Tecnicamente, o termo 'adequado' é taxa de transferência , mas discordo).

Suponhamos que você transmita um vídeo de 2000 segundos com tamanho de 60 MB.

Com o streaming, o programa streamer pode fazer sua própria limitação de taxa para impedir o estouro de buffer. Portanto, seu cabeçalho de solicitação HTTP pode incluir um campo Intervalo . A largura de banda efetiva desde o início da transmissão até o término da transmissão seria de ~ 60 MB / 2000 segundos = 30 KB / s = 240 kbps.

No entanto, se você baixar o vídeo de imediato, você vai ter até o máximo de banda do seu serviço de Internet. Dependendo de outro uso ao mesmo tempo, é claro. Portanto, assumindo um serviço de Internet de 6 Mbps, com 50% de largura de banda disponível, você terá 3 Mbps de largura de banda para baixar vídeos.

Streaming é realmente uma maneira de baixar.

Quando você assiste a um filme transmitido, o seu media player faz o download de partes dele, mostra-as e descarta as partes exibidas do arquivo em tempo real.

Normalmente, quando você baixa um arquivo, aguarda a conclusão do download e só então começa a assisti-lo. Mas existem players de mídia capazes de mostrar a parte baixada do arquivo, pausar automaticamente e aguardar o download. Meio que gosta de streaming, mas sem descartar o arquivo.

Tecnicamente, quando a preocupação é com a quantidade total de dados transferidos, não importa como você os baixa, mas a diferença entre o arquivo que você baixa e o que o seu media player baixa para você como um fluxo. Eles podem ser os mesmos arquivos exatos e significarão a mesma largura de banda nos dois casos.

Os sites de mídia de streaming geralmente codificam seu conteúdo para ter uma taxa de bits mais baixa do que um disco comprado em loja. Mas você pode assistir a um filme do seu PC de mesa em um notebook via Wi-Fi usando a função de compartilhamento de arquivos do seu sistema operacional, e ocupará quase a mesma quantidade de tráfego como se estivesse assistindo na área de trabalho (como ler bytes do disco rígido) dirigir). Tecnicamente, seria transmitido, enquanto você assiste a um filme enquanto partes dele são baixadas e descartadas continuamente.

Portanto, a resposta é que depende absolutamente do tamanho dos dois arquivos - transmitidos via media player e baixados para o disco.

O streaming usa a taxa de transferência do download, portanto, você pode considerá-lo como download. Sua pergunta é um pouco ambígua quanto ao que você considera um download. Você pode fazer o download apenas do upload que eles puderem e estão dispostos a oferecer. Portanto, no final, se você deseja comparar um download direto do HTTP sobre o DASH (ainda HTTP), por exemplo, você deve verificar quanto download está fazendo de cada um.

Então eu acho que a resposta é que ele poderia estar usando a mesma quantidade ... ou menos ... ou mais. dependendo dos servidores e da taxa em que estão servindo.

Sim, é o equivalente. Download = Você faz o download apenas uma vez e permanece no seu computador. Stream = Você transfere temporariamente "algo" para o seu computador.