Lo streaming utilizza la stessa quantità di larghezza di banda del download?

Supponendo che il contenuto sia della stessa qualità (ceteris paribus), i media in streaming (ovvero video, audio) utilizzano la stessa larghezza di banda del download?

Supponiamo che dovessi scaricare un film HD da Amazon o trasmetterlo in streaming, sarebbe un uso equivalente della larghezza di banda?

Spesso non è equivalente.

I provider di streaming utilizzano protocolli, come DASH , per adattare dinamicamente la qualità del film alla disponibilità della larghezza di banda degli utenti e ai desideri di qualità. Quindi i server possono limitare la velocità della connessione in modo da poter bufferizzare un determinato importo (qualcosa come 10 secondi, forse 30 o un minuto intero) e in seguito si ottiene solo la quantità di larghezza di banda richiesta per ottenere il contenuto in tempo reale. Questa è un'ovvia ottimizzazione dal punto di vista del provider, perché diffonde la larghezza di banda più equamente tra gli utenti e inoltre evita che i dati vengano trasferiti invano (ad esempio quando l'utente guarda un film 480p per 10 minuti, senza ratelimitare e con un downlink comune, è probabile che molto più di quello sia già scaricato, ma poi sprecato se gli utenti smettono di guardare il video).

La quantità di dati trasferiti è la stessa. Tuttavia, lo streaming potrebbe richiedere più tempo, poiché il provider potrebbe limitare il trasferimento dei dati alla velocità richiesta per fornire il contenuto in una data qualità in tempo reale.

Dailymotion è uno dei provider che limita le connessioni. Da un server con una connessione simmetrica di almeno 100 Mbit / s, vediamo il seguente 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

Il tasso è molto al di sotto di quanto sarebbe possibile (ed è raggiunto con altri fornitori). Inoltre, se provi materiale diverso, scoprirai che la tariffa dipende fortemente dal singolo video: un video fullhd si scarica facilmente con> 1 MiB / s, mentre un video musicale come questo rimane intorno o inferiore a 200 KiB / s .

Per riassumere e chiarire alcuni possibili fraintendimenti: alcuni provider potrebbero limitare il download durante lo streaming, tramite l'applicazione client (ad es. YouTube con il loro lettore html5 o flash video) o tramite server. Se la velocità non ti limita per mezzo del server, il download consumerà più larghezza di banda, poiché la limitazione della velocità che è eventualmente applicata dall'applicazione client durante lo streaming non ha luogo. Questo è il caso principale in cui la larghezza di banda consumata è diversa rispetto alla domanda originale.

1. Sono consapevole che si tratta di una prova aneddotica: ho comunque osservato questo comportamento in modo coerente.

Supponendo che stiamo parlando della stessa qualità (ovvero nessun flusso di limitazione, frame-skipping o di qualità inferiore), nella migliore delle ipotesi i flussi impiegheranno la stessa quantità di larghezza di banda di un download, anche se potrebbe essere fatto in un tempo / frequenza più conveniente per il fornitore. Potrebbe anche richiedere più larghezza di banda a seconda di come viene compresso il video - il più delle volte non viene inviata l'intera immagine, piuttosto solo il cambiamento (o delta) tra i frame. Ciò significa che maggiore è la cronologia (ovvero utilizza quella tonalità di blu dal pixel X nel riquadro Y), minore è la necessità di inviarla. Questo di solito non appare molto, ma quando uno stream viene messo in pausa / interrotto per qualsiasi motivo, questa "cronologia" viene persa e dovrà essere ritrasmessa, aumentando così la larghezza di banda, mentre con un download può essere ripresa alla "rottura", e supponevo che il destinatario avesse già queste informazioni. Lo stesso può essere usato per l'audio, specialmente dove non c'è una tariffa fissa (cioè FLAC invece di mp3)

Saltare (saltare, riavvolgere, ecc.) Potrebbe anche influire sull'utilizzo: andare oltre il buffer ridurrebbe la quantità di larghezza di banda utilizzata da un flusso, ma qualsiasi riavvolgimento lo aumenterebbe. Inoltre ci sarebbe un interrupt, che causerebbe un maggiore utilizzo (vedi sopra), e qualsiasi tipo di "anteprima in anteprima" come quello che usano youtube e netflix aumenterebbe leggermente anche la larghezza di banda.

Ultima nota: compressione: questo potrebbe essere fatto per i download, ma non tanto per gli stream: il fatto è che la maggior parte dei video sono già compressi, quindi non ci sarebbe molto da guadagnare qui (anche se potrebbe esserci spazio per guadagni nell'ultra- dipartimento alta risoluzione / qualità).

Lo streaming utilizzerà meno larghezza di banda, soprattutto se le condizioni della rete sono cattive, ma questo ha un prezzo .

In questione sono i dati che devono essere inviati. In un modello di download, tutti i dati devono raggiungere il cliente, tutti nel giusto ordine, qualunque cosa accada . Se le condizioni di rete non sono buone e alcuni bit di dati non raggiungono il client, devono essere reinviati e ciò aumenta l'utilizzo della larghezza di banda. Se alcuni dati arrivano fuori servizio, devono essere rimessi in ordine prima di essere presentati e ciò riduce la reattività.

In un modello di streaming, va bene se alcuni dei dati non raggiungono il client . Se stai riproducendo un film in streaming e un fotogramma non ci arriva, puoi semplicemente saltarlo e andare avanti, quindi non utilizzare ulteriore larghezza di banda per i rinvii. Se alcuni fotogrammi arrivano fuori servizio, basta suonare quelli che vanno avanti; un blip momentaneo non ha importanza, e quindi questo aumenta la reattività. Tuttavia, significa anche che non ottieni necessariamente tutti i dati: tutto ciò che vedi è ciò che è arrivato al primo colpo.

Se devi scegliere tra i modelli, scegli in base a cosa vuoi fare con i dati. Se vuoi archiviarlo e / o possibilmente visualizzarlo più volte, quindi scaricalo in modo da ottenere tutto. Se non prevedi di archiviare o pianifichi di visualizzare i dati una sola volta, procedi e esegui lo streaming; probabilmente non noterai la differenza in una singola visualizzazione e se le condizioni della rete sono abbastanza cattive da notare, il download sarebbe anche peggio.

Se stai davvero chiedendo "larghezza di banda" (byte / sec) e non "dati totali" (byte), la domanda cruciale è: in quale periodo di tempo? Se supponiamo che l'utente guardi l'intero video e che venga restituito lo stesso codec / qualità ecc. E ignori il piccolo sovraccarico di richieste / risposte di streaming, i dati totali restituiti saranno uguali.

Ora, qual è la larghezza di banda? Esistono due modi per comprendere la tua domanda:

1. Larghezza di banda durante il tempo necessario per il completamento del download. Per lo streaming dovresti vedere picchi di larghezza di banda elevata (quando viene richiesto il blocco successivo) che tornano a zero mentre stai guardando quel blocco fino a quando non ti avvicini alla fine del blocco e c'è di nuovo un picco di larghezza di banda. Per il download, dovresti vedere una larghezza di banda molto elevata per, diciamo, 10min che scende a zero non appena viene scaricato l'intero video. Se interrompi l'esperimento ora, la larghezza di banda per il download è ovviamente più alta poiché massimizza il tuo downlink fino al completamento.

2. Larghezza di banda durante il periodo di visione del video. Il tempo di visualizzazione del video è lo stesso sia per lo streaming che per il download, supponendo che entrambi inizino a guardare immediatamente. Anche la dimensione totale dei dati è la stessa. Poiché la larghezza di banda è data per volta, è la stessa per entrambi gli scenari.

Nell'esempio seguente, vengono sempre scaricati in totale 40 (unità di dati). Ma per "scaricare", è 40 nella prima unità di tempo, mentre per "streaming" è 20 durante le prime unità di tempo (per ottenere un grosso blocco iniziale) e quindi due volte 10 per i due blocchi aggiuntivi. Notare che mentre la larghezza di banda è tracciata sull'asse y, l'area sotto ciascuno dei due grafici corrisponde ai dati (byte), se si integrano byte / tempo nel tempo, si ottengono byte.

Non sono comparabili.

Per la prima istanza, la codifica ottimale per la visualizzazione locale è diversa dalla codifica optima per la visualizzazione in streaming.

Parliamo di codifica video.

Nella maggior parte dei formati di codifica video, di solito esistono due tipi di frame:

1. Frame intra-codificato (I-Frame): si tratta di frame trasferiti per intero, questo frame può essere decodificato senza la conoscenza di altri frame. Una cornice con codice Intra è essenzialmente un'immagine statica. Gli encoder li genererebbero durante transizioni improvvise. Questi sono meno efficienti da comprimere.
2. Frame previsto (frame P) o frame predetto (frame B): sono frame che memorizzano solo le differenze tra i frame, possono essere decodificati solo se lo spettatore conosce anche i frame precedenti e / o ultimi. Questi sono molto più efficienti da comprimere.

La codifica per la visualizzazione locale può trarre vantaggio dalla rapida ricerca del disco per utilizzare più frame P e B, mentre un video codificato per uno streaming efficiente dovrà codificare I-Frame più ridondante lungo l'intero video anche quando non ci sono transizioni improvvise per adattarsi ricerca casuale.

Inoltre, ci sono due diversi tipi di streaming. Puoi avere lo streaming di uno stream preregistrato (la maggior parte dei video di Youtube) e dei flussi di eventi live (ad esempio Youtube Live). A causa della necessità di latenza, lo streaming di eventi live non può sfruttare le tecniche di codifica avanzate che richiedono un periodo di tempo lungo o imprevedibile, mentre uno streaming preregistrato può richiedere tutto il tempo necessario per la codifica.

Anche i video in streaming sono generalmente codificati con bit rate costante (CBR). A parità di dimensioni target, un video con velocità in bit variabile (VBR) avrà in genere una qualità superiore rispetto a un video CBR. Al contrario, un video VBR è più piccolo per la stessa qualità di un video CBR. Un protocollo di streaming adattivo come DASH ha un bitrate adattivo (ABR), che è un compromesso tra CBR e VBR. ABR consente allo spettatore di adattarsi ai cambiamenti nella larghezza di banda della rete. Data una larghezza di banda costante e costante, ABR è più o meno lo stesso di CBR.

Ciò significa che, data la stessa qualità ed esperienza visiva , puoi codificare i video per la visualizzazione locale in modo più efficiente rispetto ai video in streaming e puoi codificare i video per i flussi preregistrati in modo più efficiente rispetto ai flussi live.

Quindi c'è anche un sovraccarico nel protocollo di streaming. Un download HTTP regolare può utilizzare la codifica di trasferimento a blocchi per scaricare l'intero file con un sovraccarico minimo. Un download in streaming dovrà negoziare il blocco e la qualità del blocco da trasferire. Nel grande schema delle cose, l'overhead del protocollo di trasferimento è relativamente minore.

Nel complesso, per la stessa quantità di video guardati, i video in streaming dovrebbero finire per richiedere una maggiore quantità di larghezza di banda. Il vantaggio principale dello streaming, in termini di utilizzo della larghezza di banda, è che può salvare dalle persone che scaricano ma non guarda il video per intero, il che può essere un risparmio molto significativo.

La risposta è, dipende".

La risposta è NO, per i provider che ospitano video in generale. I fornitori decenti che trasmettono in streaming video effettuano il controllo della velocità in modo da garantire una riproduzione fluida e una larghezza di banda ottimale per il maggior numero di persone possibile. Quindi, anche se potresti avere molta larghezza di banda, potrebbe decidere di darti solo 5Mbit e sembrare ancora abbastanza decente.

Se si esegue un download HTTP, verranno avviati algoritmi di controllo della velocità TCP per assicurarsi di saturare una o entrambe le estremità della connessione o qualsiasi altra via di mezzo. Quindi, se avessi 100 Mbit disponibili, utilizzerà tutto ciò che può ottenere o vicino a 100 Mbit.

Ciò ovviamente presuppone che non vi sia alcun QoS tra il client e il server.

La tua domanda è così libera che potrei anche farlo in modo che in alcune configurazioni ingenue la risposta sia anche SÌ (con ipotesi), le larghezze di banda sono identiche. Per fare ciò, è sufficiente rilasciare il file sul server Web di base e aprirlo con il browser in modo che entri in contatto un visualizzatore. O incorporare il video sul server Web di base e, di nuovo, verrà riprodotto nel browser e utilizzerà la stessa larghezza di banda con il seguente presupposto ... nessun altro utente, nessun altro che condivide la rete con te ... nessun altro fattore in gioco che possa alterare la tua larghezza di banda.

Tenere presente che quando si scarica un file da un sito Web e lo si scarica nuovamente, la larghezza di banda tra il primo e il secondo download può variare. Questo semplicemente perché il carico sul server può cambiare e la congestione sulla rete e i percorsi di rete possono cambiare.

Quindi il gioco è fatto ... dipende.

Dal punto di vista della rete "download" e "streaming" sono servizi diversi, si chiama "profilo del traffico"

Per il servizio di streaming la rete deve fornire un throughput costante minimo (tecnicamente "larghezza di banda" significa qualcosa di diverso), il servizio di streaming è sensibile alle interruzioni e al jitter. Non richiede la massima velocità di trasmissione, ritardo o latenza della rete non è fondamentale.

Dal punto di vista dell'utente finale significa: il video deve funzionare senza interruzioni o interruzioni. Non importa se il video inizia pochi secondi prima o dopo.

Il "download" di solito richiede il massimo throughput di rete possibile, il download deve essere completato il più rapidamente possibile. Ritardi, interruzioni e jitter non sono fondamentali.

Una rete può fornire più profili di traffico che sono completamente diversi. Ad esempio i servizi vocali (semplice telefonata) richiedono una velocità di trasmissione molto bassa ma sono molto sensibili ai ritardi (meno di 200 ms)

Per aggiungere ad altre risposte, la mia risposta è: non necessariamente .

Ora, supponendo che tutto sia uguale (nessuna selezione automatica della qualità, nessuna limitazione dal server e / o ISP) ...

La larghezza di banda è generalmente definita come size_of_data divisa per total_time. (Tecnicamente, il termine "corretto" è throughput , ma sto divagando).

Supponiamo che stai per trasmettere in streaming un video di 2000 secondi di dimensioni 60 MB.

Con lo streaming, il programma streamer potrebbe fare un proprio limite di velocità per prevenire l'overflow del buffer. Pertanto, l'intestazione della richiesta HTTP potrebbe includere un campo Intervallo . La larghezza di banda effettiva dall'inizio dello streaming fino alla fine dello streaming sarebbe quindi di ~ 60 MB / 2000 secondi = 30 KB / s = 240 kbps.

Tuttavia, se si scarica il video a titolo definitivo, si arriva fino alla larghezza di banda massima del servizio di Internet. A seconda dell'altro utilizzo allo stesso tempo, ovviamente. Quindi, supponendo un servizio Internet di 6 Mbps, con una larghezza di banda disponibile del 50%, otterrai una larghezza di banda di 3 Mbps per il download di video.

Lo streaming è davvero un modo per scaricare.

Quando guardi un film in streaming, il tuo lettore multimediale ne scaricherà parti, te le mostrerà e scarterà al volo le parti mostrate del file.

In genere, quando si scarica un file, si attende il completamento del download e solo allora si inizia a guardarlo. Ma ci sono lettori multimediali che sono in grado di mostrarti la parte scaricata del file e di mettere automaticamente in pausa e attendere che altri vengano scaricati. Un po 'come lo streaming, ma senza scartare il file.

Tecnicamente, quando il problema riguarda la quantità totale di dati trasferiti, non importa come lo scarichi, ma la differenza tra il file scaricato e il file che il tuo lettore multimediale scarica per te come stream. Possono essere gli stessi file esatti e significheranno la stessa larghezza di banda in entrambi i casi.

I siti di streaming multimediali di solito codificano il loro contenuto per avere un bitrate inferiore rispetto a un disco acquistato in negozio. Ma puoi guardare un film dal tuo PC desktop su un notebook tramite WiFi usando la funzione di condivisione dei file del tuo sistema operativo e occuperà quasi la stessa quantità di traffico come se stessi guardando sul desktop (come byte letti dal disco rigido guidare). Tecnicamente sarebbe in streaming, mentre guardi un film mentre parti di esso vengono continuamente scaricate e scartate.

Quindi la risposta è che dipende assolutamente dalla dimensione dei due file : trasmessi in streaming tramite Media Player e scaricati sul disco.

Lo streaming utilizza il throughput del download, quindi puoi considerarlo come download. La tua domanda è un po 'ambigua su cosa consideri un download. Puoi scaricare solo il maggior numero di upload che possono e sono disposti a offrire. Quindi, alla fine, se si desidera confrontare un download diretto da HTTP su DASH (sempre HTTP), ad esempio, è necessario verificare la quantità di download che si sta eseguendo da ciascuno di essi.

Quindi immagino che la risposta sia che potrebbe usare la stessa quantità ... o meno ... o più. a seconda dei server e della tariffa che ti stanno offrendo.

Sì, è l'equivalente. Download = Lo scarichi solo una volta e rimane sul tuo computer. Stream = Scarica temporaneamente "qualcosa" sul tuo computer.