O streaming usa a mesma quantidade de largura de banda que o download?

74

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

Digamos que eu baixasse um filme em HD da Amazon ou transmitisse, seria o uso equivalente de largura de banda?

    
por stemie 08.10.2014 / 11:33

11 respostas

42

Geralmente não é equivalente.

Os provedores de fluxo usam protocolos, como DASH , para ajustar dinamicamente a qualidade do filme à disponibilidade de largura de banda dos usuários e desejos de qualidade. Em seguida, os servidores podem limitar a sua conexão de modo que você possa armazenar em buffer uma certa quantia (algo como 10 segundos, talvez 30 ou um minuto inteiro) e depois você só terá a quantidade de largura de banda necessária para receber o conteúdo em tempo real. Essa é uma otimização óbvia do ponto de vista do provedor, porque ela 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 de 480p por 10 minutos, sem ratelimiting e com um downlink comum, é provável que muito mais do que isso já tenha sido baixado, mas depois desperdiçado se os usuários pararem de assistir ao vídeo).

A quantidade de dados transferida é a mesma. Mas pode levar mais tempo com a transmissão, porque o provedor pode limitar a 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 as conexões. De um servidor com pelo menos 100Mbit / s de conexão simétrica, 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çado com outros provedores). Além disso, se você tentar material diferente, verá que a taxa é altamente dependente do vídeo individual: um vídeo fullhd é facilmente transferido por download com > 1MiB / s, enquanto um vídeo de música como este fica em torno ou abaixo de 200KiB / s.

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

  1. Estou ciente de que isso é uma espécie de evidência anódica - no entanto observei esse comportamento de forma consistente.
por 08.10.2014 / 12:20
19

Supondo que estamos falando da mesma qualidade (ou seja, sem afogamento, frame-skipping ou fluxos de baixa qualidade), então, na melhor das hipóteses, os streams terão a mesma largura de banda que um download, embora isso possa ser feito em um tempo / taxa 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, e sim apenas a alteração (ou delta) entre os quadros. Isso significa que quanto mais história houver (ou seja, usar esse matiz de azul do pixel X no quadro Y), menos precisa ser enviado. 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 que com um download, ele pode ser retomado no "break", e assumiu que o receptor já tem essa informação. O mesmo pode ser usado para áudio, especialmente quando não há uma taxa fixa (ou seja, FLAC em vez de mp3)

Saltar ao redor (pular, retroceder, etc.) também pode afetar o uso - ir além do buffer reduziria a quantidade de largura de banda usada por um fluxo, mas qualquer repetição o aumentaria. Também haveria uma interrupção, o que causaria um aumento no uso (veja acima), e qualquer tipo de "visualização de miniaturas" como o uso do youtube e do netflix também aumentaria levemente a largura de banda.

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

    
por 08.10.2014 / 16:21
7

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

Em questão estão os dados que precisam ser enviados. Em um modelo de download, todos os dados devem chegar ao cliente, tudo na ordem correta, independentemente do . Se as condições da rede forem ruins e alguns bits dos dados não atingirem o cliente, eles deverão ser reenviados e isso aumentará o uso da largura de banda. Se alguns dados chegarem fora de ordem, eles devem ser colocados novamente em ordem antes de serem apresentados, e isso diminui a capacidade de resposta.

Em um modelo de streaming, tudo bem se alguns dos dados não atingirem o 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 em reenvios. Se alguns quadros chegarem fora de ordem, apenas reproduza os que avançarem; um pontinho momentâneo não importa, e isso aumenta a capacidade de resposta. No entanto, isso também significa que você não necessariamente obtém os dados completos: o que você vê é o que quer que tenha chegado lá na primeira filmagem.

Se você tiver que escolher entre os modelos, escolha com base no que deseja fazer com os dados. Se quiser arquivá-los e / ou possivelmente visualizá-los várias vezes, baixe-o que você tem certeza de obter tudo. Se você não planeja arquivar ou apenas planeja visualizar os dados uma vez, vá em frente e transmita; você provavelmente não notará a diferença em uma única visualização e, se as condições da rede estiverem ruins o suficiente para que você perceba, o download seria ainda pior.

    
por 09.10.2014 / 14:55
5

Se você está realmente pedindo por "largura de banda" (bytes / seg) e não "total de dados" (bytes), a questão crucial é: durante qual período de tempo? Se estivermos assumindo que o usuário assiste a todo o vídeo e que o mesmo codec / qualidade etc. é retornado e ignora 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 streaming, você deve ver picos de alta largura de banda (quando o próximo bloco é solicitado) que retornam a zero enquanto você está assistindo esse pedaço até você perto do final do pedaço e há um aumento na largura de banda novamente. Para fazer o download, você deve ver uma largura de banda muito alta por, digamos, 10min, que desce para zero assim que todo o vídeo for baixado. Se você interromper o experimento agora, a largura de banda para download é obviamente maior, já que ele maximiza o downlink até que seja concluído.

  2. Largura de banda durante o tempo em que o vídeo é assistido. O horário em que o vídeo está sendo assistido é o mesmo para o streaming e o download, presumindo que ambos começam a assistir imediatamente. O tamanho total dos dados é o mesmo também. Como a largura de banda é de dados por hora, é o mesmo para ambos os cenários.

No exemplo abaixo, há sempre um total de 40 (unidades de dados) baixados. Mas para "download", é 40 na primeira unidade de tempo, enquanto para "streaming" é 20 durante as primeiras unidades de tempo (para obter um grande pedaço inicial) e, em seguida, duas vezes 10 para os dois blocos 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, você obtém bytes.

    
por 09.10.2014 / 17:58
4

Eles não são comparáveis.

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

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

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

  1. Quadro intra-codificado (I-Frame) - são quadros transferidos por completo, este quadro pode ser decodificado sem o conhecimento de qualquer outro quadro. Um quadro Intra-codificado é essencialmente uma imagem estática. Codificadores gerariam estes durante transições repentinas. Estes são menos eficientes para compactar.
  2. Quadro previsto (Quadro P) ou Quadro bi-previsto (Quadro B) - são quadros que armazenam apenas as diferenças entre quadros, só podem ser decodificados se o visualizador 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 aproveitar as tentativas do disco rápido de usar mais quadros P e B, enquanto um vídeo codificado para transmissão eficiente terá que codificar o I-Frame mais redundante ao longo de todo o vídeo, mesmo quando não houver súbita transições para acomodar a busca aleatória.

Além disso, existem dois tipos diferentes de streaming. Você pode transmitir um stream pré-gravado (a maioria dos vídeos do Youtube) e transmissões de eventos ao vivo (por exemplo, o Youtube Live). Devido à necessidade de latência, o streaming de eventos ao vivo não pode tirar proveito de técnicas de codificação avançadas que demoram 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 alvo, um vídeo de taxa de bit variável (VBR) terá tipicamente uma qualidade superior a 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 adaptativo como o DASH possui uma taxa de bits adaptativa (ABR), que é um compromisso entre o CBR e o VBR. A ABR permite que o espectador 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 dada a mesma qualidade e experiência de visualização , você pode codificar vídeo para exibição local de maneira mais eficiente do que vídeos transmitidos e codificar vídeo para fluxos pré-gravados com mais eficiência do que transmissões ao vivo.

Depois, há também uma sobrecarga no protocolo de streaming. Um download normal de HTTP pode usar a codificação de transferência em partes para fazer o download do arquivo inteiro, que tem um mínimo de sobrecarga. Um download transmitido terá que negociar o trecho e a qualidade do trecho a ser transferido. No grande esquema das coisas, a sobrecarga do protocolo de transferência é relativamente menor.

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

    
por 09.10.2014 / 02:48
1

A resposta é "Depende".

A resposta é NÃO, para provedores que hospedam vídeos em geral. Provedores meio decentes que transmitem vídeo avaliam o controle para garantir uma reprodução suave e largura de banda ideal para o maior número de pessoas possível. Então, mesmo que você tenha muita largura de banda, pode decidir dar apenas 5Mbit e parecer ainda bastante decente.

Se você fizer um download HTTP, os algoritmos de controle de taxa de TCP serão acionados para garantir que você sature uma ou ambas as extremidades da conexão ou algo entre elas. Então, se você tivesse 100Mbit disponíveis, ele usaria tudo que conseguir ou cerca de 100Mbit.

Isso, obviamente, pressupõe que não há QoS acontecendo em qualquer lugar entre o cliente e o servidor.

Sua pergunta é tão solta que eu também poderia fazer isso em algumas configurações ingênuas a resposta também é 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 aproveite. Ou incorpore o vídeo ao servidor da Web básico e, novamente, ele será reproduzido no navegador e use largura de banda idêntica. 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ê faz o download de um arquivo de um site e depois o 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 de rede podem mudar.

Então você tem isso ... depende.

    
por 09.10.2014 / 05:59
1

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 um throughput mínimo constante (tecnicamente, "largura de banda" significa algo diferente), o serviço de streaming é sensível a interrupções e jitter. Não requer o rendimento máximo da rede, o atraso ou a latência não é crítico.

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

"Downloading" geralmente requer o máximo de throughput de rede possível, o download deve ser concluído o mais rápido possível. Atrasos, interrupções e jitter não são críticos.

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

    
por 11.10.2014 / 19:47
0

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

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

Largura de banda é geralmente definida como size_of_data dividido por total_time. (Tecnicamente, o termo 'bom' é taxa de transferência , mas eu discordo).

Vamos supor que você vai transmitir um vídeo de 2000 segundos com 60 MB.

Com o streaming, o programa de streamer pode fazer sua própria limitação de taxa para evitar o estouro de buffer. Portanto, o cabeçalho de solicitação HTTP pode incluir um campo de intervalo . A largura de banda efetiva desde a transmissão começa até que o fluxo final termine em ~ 60 MB / 2000 segundos = 30 KB / s = 240 kbps.

No entanto, se você baixar o vídeo diretamente, você terá até a largura de banda máxima do seu serviço de Internet. Dependendo de outro uso ao mesmo tempo, é claro. Assim, assumindo um serviço de Internet de 6 Mbps, com 50% de largura de banda disponível, você terá uma largura de banda de 3 Mbps para o download de vídeo.

    
por 09.10.2014 / 09:46
0

O streaming é realmente uma maneira de fazer o download.

Quando você assiste a um filme transmitido, seu reprodutor de mídia faz o download de partes dele, mostra-as e descarta as partes do arquivo exibidas na hora.

Normalmente, quando você faz o download de um arquivo, aguarda o término do download e só então começa a assisti-lo. Mas existem media players capazes de mostrar a parte baixada do arquivo e pausar automaticamente e aguardar o download de um pouco mais. Tipo como streaming, mas sem descartar o arquivo.

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

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

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

    
por 10.10.2014 / 00:55
0

O fluxo contínuo usa seu processamento de download, portanto, você pode considerá-lo como um download. Sua pergunta é um pouco ambígua quanto ao que você considera um download. Você só pode fazer o download do upload que puder e estiver disposto a oferecer. Então, no final, se você quiser comparar um download direto do HTTP sobre o DASH (ainda HTTP), por exemplo, você teria que verificar quanto você está fazendo o download de cada um.

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

    
por 10.10.2014 / 02:56
-2

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

    
por 08.10.2014 / 11:50