Czy streaming używa tej samej przepustowości co pobieranie?

75

Zakładając, że treść jest tej samej jakości (ceteris paribus), czy media strumieniowe (tj. Wideo, audio) wykorzystują tę samą przepustowość co pobieranie?

Powiedzmy, że mam pobrać film HD z Amazon lub przesłać go strumieniowo, czy byłoby to równoważne wykorzystanie przepustowości?

stemie
źródło
2
Zależy od protokołu i kodeka: np. Pobieranie przez http i przesyłanie strumieniowe przez rtmp lub h264 vs vp6. IMO to pytanie jest zbyt ogólne, biorąc pod uwagę ilość metod kompresji i transmisji danych do porównania.
zamnuts
Żeby wyjaśnić twoje pytanie. Przez przepustowość masz na myśli szybkość transmisji, a nie rozmiar pliku (filmu)?
Matt H
Zaletą pobierania za pośrednictwem przesyłania strumieniowego (które jest technicznie pobierane, ale tylko do jednorazowego użytku) jest to, że możesz zużywać materiał tyle razy, ile chcesz, bez konieczności każdorazowego wydatkowania na niego przepustowości. Niektóre odtwarzacze multimediów mogą nawet odtwarzać filmy, które aktualnie pobierasz (nie w pełni pobrane), co daje wrażenie „streamingu” z zaletą pobierania.
ADTC
3
Tak, mam na myśli szybkość transmisji danych. Powodem, dla którego zapytałem, było nieporozumienie z moją siostrą i kiedy szukałem w Internecie, mogłem znaleźć tylko niejasne odpowiedzi z odpowiedzi Yahoo. Zdaję sobie sprawę, że jest wiele zmiennych, od których to zależy, ale pomyślałem, że warto było przynajmniej zapytać.
stemie
2
„W sieciach komputerowych i informatyce przepustowość, przepustowość sieci, przepustowość danych lub przepustowość cyfrowa to pomiar przepływności dostępnych lub zużytych zasobów transmisji danych wyrażony w bitach na sekundę lub jego wielokrotności (bit / s, kbit / s , Mbit / s, Gbit / s itp.) - wikipedia.org/wiki/Bandwidth_(computing) ”
stemie

Odpowiedzi:

43

Często nie jest równoważny.

Dostawcy transmisji strumieniowych używają protokołów, takich jak DASH , aby dynamicznie dostosowywać jakość filmu do dostępności przepustowości i wymagań jakościowych użytkowników. Następnie serwery mogą ograniczać szybkość połączenia, aby można było buforować określoną ilość (około 10 sekund, może 30 lub całą minutę), a następnie uzyskuje się tylko przepustowość wymaganą do przesłania zawartości w czasie rzeczywistym. Jest to oczywista optymalizacja z punktu widzenia dostawcy, ponieważ równomiernie rozkłada przepustowość między użytkowników, a ponadto unika na próżno przesyłania danych (np. Gdy użytkownik ogląda film 480p przez 10 minut, bez ograniczeń czasowych i przy zwykłym łączu w dół prawdopodobnie jest już o wiele więcej pobrane, ale zmarnowane, jeśli użytkownicy przestaną oglądać wideo).

Ilość przesłanych danych jest taka sama. W przypadku przesyłania strumieniowego może to jednak potrwać dłużej, ponieważ dostawca może ograniczyć transfer danych do prędkości wymaganej do dostarczenia treści o określonej jakości w czasie rzeczywistym.

Dailymotion jest jednym z dostawców, którzy ograniczają stawki połączeń. Z serwera z połączeniem symetrycznym co najmniej 100 Mbit / s widzimy następujące zachowanie¹:

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

Stawka jest znacznie poniżej tego, co byłoby możliwe (i jest osiągane w przypadku innych dostawców). Ponadto, jeśli spróbujesz innego materiału, okaże się, że szybkość zależy w dużym stopniu od poszczególnych filmów: wideo FullHD łatwo pobiera z> 1 MiB / s, podczas gdy teledysk taki jak ten utrzymuje się na poziomie około 200 KiB / s .

Podsumowując wszystko i usuwając niektóre możliwe nieporozumienia: Niektórzy dostawcy mogą ograniczyć pobieranie podczas przesyłania strumieniowego, za pośrednictwem aplikacji klienckiej (np. YouTube z odtwarzaczem HTML5 lub Flash Video) lub za pomocą serwera. Jeśli nie ograniczają one prędkości za pomocą serwera, pobieranie zużywa większą przepustowość, ponieważ nie ma miejsca ograniczenie prędkości, które może być zastosowane przez aplikację kliencką podczas przesyłania strumieniowego. Jest to główny przypadek, gdy wykorzystywane pasmo różni się w stosunku do pierwotnego pytania.


  1. Zdaję sobie sprawę, że jest to rodzaj dowodów anektodalnych - jednak konsekwentnie obserwowałem to zachowanie.
Jonas Schäfer
źródło
3
@Psycogeek Youtube jest jednym z przykładów używających DASH (jeśli ten komentarz nie ma dla ciebie sensu, przeczytaj wstępną część linku, który podłączyłem). Oznacza to, że odtwarzacz, którego używa klient, musi mimo to zażądać sekwencyjnych fragmentów wideo. Wykonanie kroku stamtąd, aby przestać prosić o więcej części, jeśli gracz nie działa, jest po prostu naturalne. youtube-dlProgramy pobierające, takie jak, będą nadal prosić o więcej fragmentów, dopóki film nie zostanie w pełni pobrany. Tak więc przesyłanie strumieniowe za pomocą DASH pociąga za sobą nieco więcej kosztów, ale prawdopodobnie jest tego warte (zarówno dla użytkownika, jak i dostawcy) i można je pominąć.
Jonas Schäfer
1
Zakładając tego samego kodowania danych oraz definicja i są używane (patrz psychogeek komentarz) ściąganie będzie używać więcej całkowitej przepustowości. Pobieranie wideo prawie na pewno zostanie wykonane za pomocą protokołu TCP, podczas gdy przesyłanie strumieniowe będzie odbywało się w trybie UDP lub podobnym, niegwarantowanym sposobem dostarczania. W ten sposób TCP otrzyma co najmniej więcej paczek, a ponieważ prawdopodobnie stracisz lub uszkodzisz co najmniej kilka pakietów, podejście tcp będzie w rzeczywistości również więcej pobierania (ponieważ pobierze również utracone pakiety). Chociaż różnica jest bardzo niewielka w porównaniu do wielkości pobieranego pliku, więc jest to w większości akademickie.
dsollen
2
@dsollen: O ile nadawca UDP nie pozwoli po prostu przepłynąć pakietom bez względu na to, czy zamierzony odbiorca nadal istnieje, zarówno UDP, jak i TCP będą wymagać okresowych potwierdzeń; w obu przypadkach potwierdzenia będą stanowić bardzo małą część całkowitego ruchu. Ponadto formatowanie danych w taki sposób, że każdy pakiet można zrozumieć, nawet jeśli poprzedni pakiet nie zostanie odebrany, generalnie oznacza narzut poziomu przekraczający poziom wymagany dla protokołu TCP.
supercat
7
Oddałbym tę odpowiedź, gdybym miał wystarczającą liczbę przedstawicieli: nie odpowiada na pytanie, a kluczowym wyrażeniem jest „ta sama jakość”. Gdy dostawca obniża jakość, nie jest to ceteris paribus .
zamnuts
1
@zamnuts, a następnie opublikuj lepszy i pozwól społeczności podjąć decyzję. FWIW, to trochę jabłka i pomarańcze, jeśli uważasz, że dostawca zdecydował się na spadki jakości, ale nie sądzę, że odpowiedź byłaby kompletna bez niego.
paqogomez
19

Zakładając, że mówimy o tej samej jakości (tj. Bez ograniczania przepustowości, przeskakiwania klatek lub strumieni o niższej jakości), wówczas w najlepszym wypadku strumienie będą pobierać taką samą przepustowość jak pobieranie, chociaż można to zrobić w określonym czasie / tempie wygodniejsze dla dostawcy. Może to również wymagać większej przepustowości w zależności od sposobu kompresji wideo - przez większość czasu cały obraz nie jest wysyłany, a jedynie zmiana (lub delta) między ramkami. Oznacza to, że im więcej historii (tzn. Użyj odcienia niebieskiego z piksela X w ramce Y), tym mniej trzeba wysłać. Zwykle nie wyskakuje to zbyt wiele, ale gdy strumień zostanie z jakiegokolwiek powodu wstrzymany / przerwany, ta „historia” zostanie utracona i będzie musiała zostać ponownie przesłana, co zwiększy przepustowość, a podczas pobierania można ją wznowić na „przerwie”, i założył, że odbiorca ma już tę informację. To samo można zastosować w przypadku audio, szczególnie tam, gdzie nie ma stałej szybkości (tj. FLAC zamiast mp3)

Przeskakiwanie (przeskakiwanie, ponowne nawijanie itp.) Może również wpływać na użycie - przejście do przodu bufora zmniejszyłoby szerokość pasma wykorzystywanego przez strumień, ale każde ponowne nawijanie zwiększyłoby go. Nastąpiłoby również przerwanie, które spowodowałoby zwiększone użycie (patrz wyżej), a każdy rodzaj „podglądu miniatur”, taki jak użycie YouTube i Netflix, również nieznacznie zwiększyłoby przepustowość.

Ostatnia uwaga: kompresja: można tego dokonać w przypadku pobierania, ale nie w przypadku strumieni - zastrzeżenie polega na tym, że większość filmów jest już skompresowana, więc nie zyska się tutaj wiele (chociaż może być miejsce na zyski w ultra- dział wysokiej rozdzielczości / jakości).

użytkownik 2813274
źródło
7

Strumieniowanie zużywa mniejszą przepustowość, szczególnie jeśli warunki sieciowe są złe, ale ma to swoją cenę .

Problemem są dane, które należy wysłać. W modelu pobierania wszystkie dane muszą docierać do klienta we właściwej kolejności, bez względu na wszystko . Jeśli warunki sieciowe są złe, a niektóre bity danych nie docierają do klienta, należy je ponownie wysłać, co zwiększa wykorzystanie przepustowości. Jeśli niektóre dane nie są uporządkowane, muszą zostać uporządkowane przed ich przedstawieniem, co zmniejsza szybkość reakcji.

W modelu przesyłania strumieniowego jest OK, jeśli niektóre dane nie docierają do klienta . Jeśli przesyłasz strumieniowo film, a klatka tam nie dociera, możesz po prostu go pominąć i przejść dalej, aby nie używać dodatkowej przepustowości przy ponownych wysyłkach. Jeśli niektóre klatki nie działają, po prostu zagraj w te, które idą do przodu; chwilowe uderzenie nie będzie miało znaczenia, więc zwiększa to szybkość reakcji. Oznacza to jednak również, że niekoniecznie dostajesz pełne dane: wszystko, co widzisz, jest tym, co dostałeś na pierwszym zdjęciu.

Jeśli musisz wybierać między modelami, wybierz na podstawie tego, co chcesz zrobić z danymi. Jeśli chcesz go zarchiwizować i / lub ewentualnie wyświetlić wiele razy, pobierz go, aby mieć pewność, że otrzymasz wszystko. Jeśli nie planujesz archiwizować lub planujesz tylko raz wyświetlić dane, możesz przesyłać strumieniowo; prawdopodobnie nie zauważysz różnicy podczas jednego oglądania, a jeśli warunki sieciowe są na tyle złe, że zauważysz, pobieranie będzie jeszcze gorsze.

The Spooniest
źródło
Czy twierdzisz, że usługi przesyłania strumieniowego używają UDP zamiast TCP, aby celowo zezwolić na upuszczenie danych?
FreeAsInBeer,
1
@FreeAsInBeer: Tak. TCP zawiera szereg mechanizmów niezawodności i innych funkcji, które są bardzo przydatne w większości możliwych do wyobrażenia aplikacji. Ale istnieją przypadki użycia, w których istnieją rzeczy nawet ważniejsze niż niezawodność, a jednym z nich jest streaming: ważniejsze jest pokazanie właściwej klatki we właściwym momencie niż pokazanie każdej klatki. Gry online to kolejny przykład popularności UDP z tych samych powodów: zatrzymanie akcji w celu odtworzenia śladu stanów gracza jest gorsze niż konieczność korygowania sporadycznego stanu upuszczenia.
The Spooniest
W rzeczywistości wiele systemów przesyła strumieniowo dane przez TCP i bufor po stronie klienta. W przypadku przesyłania strumieniowego filmu opóźnienie nie jest krytyczne. Użytkownik nie odczuwa żadnych niedogodności, jeśli niektóre ramki będą znajdować się w buforze przez minutę, zanim nadejdzie czas ich wyświetlenia. Ale w przypadku zastosowań interaktywnych, takich jak wideokonferencje, opóźnienie ma kluczowe znaczenie.
kasperd
1
kasperd: Ściśle mówiąc, to nie jest streaming. Inne odpowiedzi wspomniały o usługach, które pobierają, ale zaczynają grać przed zakończeniem pobierania, i to właśnie robią opisane systemy.
Spooniest,
+1 za najmniej mylącą odpowiedź (do tej pory) w tym wątku.
Kosmiczny Ossifrage,
5

Jeśli naprawdę pytasz o „przepustowość” (bajty / s), a nie „dane całkowite” (bajty), kluczowe pytanie brzmi: w jakim okresie? Jeśli założymy, że użytkownik ogląda cały film i że ten sam kodek / jakość jest zwracany itp. I zignorujemy niewielki narzut związany z żądaniami / odpowiedziami przesyłania strumieniowego, wówczas zwrócone dane są równe.

Teraz jaka jest przepustowość? Istnieją dwa sposoby zrozumienia pytania:

  1. Przepustowość w czasie do zakończenia pobierania. W przypadku przesyłania strumieniowego powinieneś zobaczyć gwałtowne wzrosty przepustowości (gdy żądany jest następny fragment), które wracają do zera podczas oglądania tego fragmentu aż do końca fragmentu i ponownie następuje wzrost przepustowości. Podczas pobierania powinieneś zobaczyć bardzo wysoką przepustowość, powiedzmy, 10min, która spada do zera, gdy tylko cały film zostanie pobrany. Jeśli teraz przerwiesz eksperyment, przepustowość pobierania jest oczywiście wyższa, ponieważ maksymalizuje twoje łącze w dół, dopóki nie zostanie zakończone.

  2. Przepustowość podczas oglądania wideo. Czas oglądania wideo jest taki sam dla przesyłania strumieniowego i pobierania, przy założeniu, że oba zaczną oglądać natychmiast. Całkowity rozmiar danych jest również taki sam. Ponieważ przepustowość to dane na czas, jest taka sama dla obu scenariuszy.

W poniższym przykładzie zawsze pobieranych jest w sumie 40 (jednostek danych). Ale w przypadku „pobierania” jest to 40 w pierwszej jednostce czasu, podczas gdy w przypadku „przesyłania strumieniowego” jest to 20 w pierwszych jednostkach czasu (aby uzyskać dużą początkową porcję), a następnie dwa razy 10 w przypadku dwóch dodatkowych części. Zauważ, że chociaż szerokość pasma jest wykreślona na osi y, obszar pod każdym z dwóch wykresów odpowiada danym (bajtom) - jeśli zintegrujesz bajty / czas w czasie, otrzymasz bajty.

mb21
źródło
4

Nie są porównywalne.

Po pierwsze, optymalne kodowanie do oglądania lokalnego różni się od kodowania optymalnego do oglądania strumieniowego.

Porozmawiajmy o kodowaniu wideo.

W większości formatów kodowania wideo występują zwykle dwa rodzaje ramek:

  1. Ramka kodowana wewnętrznie (I-Frame) - są to ramki przesyłane w całości, ramka ta może być dekodowana bez wiedzy o żadnej innej ramce. Ramka kodowana wewnątrz jest zasadniczo statycznym obrazem. Kodery generowałyby je podczas nagłych zmian. Są mniej wydajne w kompresji.
  2. Przewidywana ramka (ramka P) lub przewidywana podwójnie ramka (ramka B) - są to ramki przechowujące tylko różnice między ramkami, można je dekodować tylko wtedy, gdy widz zna również poprzednie i / lub ostatnie ramki. Są znacznie bardziej wydajne w kompresji.

Kodowanie do lokalnego wyświetlania może skorzystać z szybkiego szukania dysku, aby skorzystać z większej liczby ramek P i B, podczas gdy wideo zakodowane w celu wydajnego przesyłania strumieniowego będzie musiało kodować więcej nadmiarowych ramek I wzdłuż całego wideo, nawet jeśli nie ma nagłych przejść, aby pomieścić losowe wyszukiwanie.

Istnieją również dwa różne rodzaje przesyłania strumieniowego. Możesz przesyłać strumieniowo wcześniej nagrany strumień (większość filmów z YouTube) i transmisje z wydarzeń na żywo (np. Youtube Live). Ze względu na opóźnienie transmisja na żywo nie może korzystać z zaawansowanych technik kodowania, które zajmują dużo czasu lub są nieprzewidywalne, a wstępnie nagrany strumień może zająć tyle czasu, ile potrzeba do zakodowania.

Strumieniowe wideo jest również zwykle kodowane ze stałą przepływnością (CBR). W przypadku tego samego rozmiaru docelowego wideo o zmiennej przepływności (VBR) będzie zazwyczaj miało wyższą jakość niż wideo CBR. I odwrotnie, wideo VBR jest mniejsze dla tej samej jakości wideo CBR. Adaptacyjny protokół przesyłania strumieniowego, taki jak DASH, ma adaptacyjną przepływność (ABR), co stanowi kompromis między CBR a VBR. ABR umożliwia przeglądarce dostosowanie się do zmian przepustowości sieci. Biorąc pod uwagę stałą, stałą przepustowość, ABR jest mniej więcej taki sam jak CBR.

Oznacza to, że biorąc pod uwagę tę samą jakość i jakość oglądania , możesz kodować wideo do lokalnego wyświetlania bardziej efektywnie niż wideo przesyłane strumieniowo, i możesz kodować wideo dla wcześniej nagranych strumieni bardziej efektywnie niż strumieni na żywo.

Następnie w protokole przesyłania strumieniowego występuje również narzut. Podczas zwykłego pobierania HTTP można użyć kodowania przesyłania fragmentarycznego, aby pobrać cały plik, który ma bardzo minimalny narzut. Przesyłane strumieniowo pobieranie będzie musiało negocjować porcję i jakość porcji do przesłania. W wielkim schemacie rzeczy narzut protokołu przesyłania jest stosunkowo niewielki.

Ogólnie rzecz biorąc, dla tej samej ilości oglądanych filmów, przesyłane strumieniowo wideo powinno ostatecznie zająć większą przepustowość. Podstawową zaletą przesyłania strumieniowego, jeśli chodzi o wykorzystanie przepustowości, jest to, że może oszczędzać osoby, które pobierają, ale nie oglądają filmu w całości, co może być bardzo znaczącą oszczędnością.

Lie Ryan
źródło
1

Odpowiedź brzmi „to zależy”.

Odpowiedź brzmi NIE, w przypadku dostawców hostujących wideo w ogóle. Pół przyzwoitych dostawców, którzy przesyłają strumieniowo wideo, kontroluje szybkość transmisji, aby zapewnić płynne odtwarzanie i optymalną przepustowość dla jak największej liczby osób. Więc nawet jeśli masz dużą przepustowość, może zdecydować się dać ci tylko 5Mbit i nadal wyglądać całkiem przyzwoicie.

Jeśli pobierzesz HTTP, uruchomią się algorytmy kontroli szybkości TCP, aby zapewnić nasycenie jednego lub obu końców połączenia lub cokolwiek pomiędzy. Więc jeśli miałeś 100Mbit dostępne, wykorzysta wszystko, co może uzyskać lub blisko 100Mbit.

To oczywiście zakłada, że ​​pomiędzy klientem a serwerem nie zachodzi QoS.

Twoje pytanie jest tak luźne, że mógłbym je również zadać, aby w niektórych naiwnych konfiguracjach odpowiedź brzmiała TAK (przy założeniu), przepustowość jest identyczna. Aby to zrobić, po prostu upuść plik na podstawowy serwer sieciowy i otwórz go w przeglądarce, aby uruchomić przeglądarkę. Lub umieść wideo na podstawowym serwerze internetowym i ponownie, będzie on odtwarzany w przeglądarce i użyje identycznej przepustowości z następujące założenie ... brak innych użytkowników, nikt inny nie współużytkuje sieci z tobą ... żadnych innych czynników, które mogą wpłynąć na przepustowość.

Należy pamiętać, że podczas pobierania pliku ze strony internetowej, a następnie pobierania go ponownie, przepustowość między pierwszym a drugim pobieraniem może się różnić. Jest tak po prostu dlatego, że obciążenie serwera może się zmieniać, a przeciążenie sieci i ścieżki sieciowe mogą się zmieniać.

Więc masz to ... to zależy.

Matt H.
źródło
„przepustowość między pierwszym a drugim pobieraniem może się różnić”, ale na pewno pobiera tę samą ilość danych, nawet jeśli jedno trwa dłużej niż drugie / warunki sieciowe uległy zmianie.
stemie
@stemie, będzie blisko. Różne protokoły zwiększają obciążenie protokołu. Ale jeśli nie było transkodowania ani zmiany jakości / szybkości podczas procesu przesyłania strumieniowego, teoretycznie powinna być taka sama ilość danych wideo.
Matt H
1

Z punktu widzenia sieci „pobieranie” i „streaming” to różne usługi, nazywa się to „profilem ruchu”

W przypadku usługi przesyłania strumieniowego sieć musi zapewniać minimalną stałą przepustowość (technicznie „przepustowość” oznacza coś innego), usługa przesyłania strumieniowego jest wrażliwa na przerwy i fluktuacje. Nie wymaga maksymalnej przepustowości sieci, opóźnienia ani opóźnienia nie jest krytyczna.

Z punktu widzenia użytkownika końcowego oznacza to: Wideo powinno działać płynnie, bez przerw i upuszczeń. Nie ma znaczenia, czy wideo rozpocznie się kilka sekund wcześniej czy później.

„Pobieranie” zwykle wymaga maksymalnej możliwej przepustowości sieci, pobieranie powinno zostać zakończone tak szybko, jak to możliwe. Opóźnienia, przerwy i fluktuacje nie są krytyczne.

Sieć może zapewniać więcej profili ruchu, które są zupełnie inne. Na przykład usługi głosowe (proste połączenia telefoniczne) wymagają bardzo niskiej przepustowości, ale są bardzo wrażliwe na opóźnienia (mniej niż 200 ms)

Wernfried Domscheit
źródło
0

Aby dodać do innych odpowiedzi, moja odpowiedź brzmi: niekoniecznie .

Teraz, zakładając, że wszystko jest równe (brak automatycznego wyboru jakości, brak ograniczania przepustowości z serwera i / lub dostawcy usług internetowych) ...

Przepustowość jest zwykle definiowana jako wielkość_danych podzielona przez całkowity czas. (Technicznie „właściwy” termin to przepustowość , ale dygresuję).

Załóżmy, że zamierzasz przesyłać strumieniowo 2000-sekundowy film o rozmiarze 60 MB.

W przypadku przesyłania strumieniowego program do streamingu może wprowadzać własne ograniczenia prędkości, aby zapobiec przepełnieniu bufora. Tak więc nagłówek żądania HTTP może zawierać pole Range . Efektywna przepustowość od streamingu zaczyna aż strumieniowych końców będzie wówczas ~ 60 MB / 2000 sekund = 30 KB / s = 240 kbps.

Jednakże, jeśli pobrać film wprost, dostaniesz się do maksymalnej przepustowości swojego serwisu internetowego. Oczywiście w zależności od innych zastosowań w tym samym czasie. Zakładając, że usługa internetowa wynosi 6 Mb / s przy 50% dostępnej przepustowości, uzyskasz przepustowość 3 Mb / s do pobierania filmów.

pepoluan
źródło
0

Streaming to naprawdę sposób pobierania.

Podczas oglądania filmu przesyłanego strumieniowo odtwarzacz multimedialny pobierze jego części, wyświetli je i odrzuci pokazane części pliku w locie.

Zwykle podczas pobierania pliku czekasz na zakończenie pobierania, a dopiero potem zaczynasz go oglądać. Istnieją jednak odtwarzacze multimedialne, które potrafią wyświetlić pobraną część pliku i automatycznie wstrzymać i poczekać na pobranie kolejnych plików. Trochę jak streaming, ale bez odrzucania pliku.

Technicznie, gdy problemem jest łączna ilość przesłanych danych, nie ma znaczenia, jak je pobierzesz, ale różnica między plikiem, który pobierasz, a plikiem, który odtwarzacz multimediów pobiera dla Ciebie jako strumień. Mogą to być dokładnie te same pliki, co w obu przypadkach oznacza taką samą przepustowość.

Witryny mediów strumieniowych zwykle kodują ich zawartość w celu uzyskania niższej przepływności niż płyta kupiona w sklepie. Ale możesz oglądać film z komputera stacjonarnego na notebooku przez Wi-Fi, korzystając z funkcji udostępniania plików w swoim systemie operacyjnym, i będzie on zajmował prawie taki sam ruch, jak gdybyś oglądał go na komputerze (jako odczyt bajtów z twardego napęd). Technicznie rzecz biorąc, byłby przesyłany strumieniowo, gdy oglądasz film, podczas gdy jego części są ciągle pobierane i odrzucane.

Odpowiedź brzmi: to absolutnie zależy od wielkości dwóch plików - przesyłanych strumieniowo przez odtwarzacz multimedialny i pobieranych na dysk.

użytkownik1306322
źródło
0

Przesyłanie strumieniowe wykorzystuje przepustowość pobierania, dlatego można uznać to za pobieranie. Twoje pytanie jest nieco niejednoznaczne, co uważasz za pobranie. Możesz pobrać tylko tyle plików, ile mogą i są skłonni zaoferować. Na koniec, jeśli chcesz na przykład porównać proste pobieranie z HTTP przez DASH (wciąż HTTP), musisz sprawdzić, ile pobierasz z każdego.

Wydaje mi się, że odpowiedź brzmi, że można użyć tej samej kwoty ... lub mniej ... lub więcej. w zależności od serwerów i stawki, którą ci obsługują.

MinusFour
źródło
-2

Tak, to jest odpowiednik. Pobierz = pobierasz go tylko raz i pozostaje na twoim komputerze. Strumień = Tymczasowo pobierasz „coś” na swój komputer.

Tiago Ribeiro
źródło
Istnieje różnica między ilością przesyłanych danych a wykorzystywaną przepustowością.
Jonas Schäfer
dobrze na moim Androidzie, oglądając film ze strumienia lub pobranego, ma to samo wykorzystanie danych
Tiago Ribeiro,
@JonasWielicki Mądry człowiek powiedział kiedyś: „Ilość przesyłanych danych jest taka sama”. Upewnij się, że wykorzystywana przepustowość jest różna, ponieważ ze względu na buforowanie prędkość transferu jest wolniejsza w czasie.
Nenotlep
1
To właściwie właściwa odpowiedź w wielu przypadkach. Często w wielu przypadkach do przesyłania strumieniowego i pobierania używany jest dokładnie ten sam zasób i protokół. Jeśli chcesz odtwarzać zasób przez HTTP, nie różni się niczym od pobierania go poza tym, że odtwarzasz go podczas pobierania. Jasne, istnieją optymalizacje do przesyłania strumieniowego i różne protokoły, które mogą zmienić twoją przepływność podczas przesyłania strumieniowego, ale nie sądzę, że to jest sedno zadawanego pytania. (Zasługują jednak na wzmiankę.)
Brad