Чи використовує потокове передавання стільки ж пропускної здатності, скільки й завантаження?

Припускаючи, що вміст має таку ж якість (ceteris paribus), чи потокове мультимедіа (тобто відео, аудіо) використовує таку ж кількість пропускної здатності, як і її завантаження?

Скажімо, я повинен був завантажити HD фільм з Amazon або потік його, це було б еквівалентне використання пропускної здатності?

74
Залежить від протоколу та кодека: напр. завантажити через http і stream через rtmp або h264 проти vp6. ІМО це питання занадто широке з урахуванням обсягу стиснення і методів передачі даних для порівняння.
додано Автор noclayto, джерело
Просто для уточнення вашого питання. За пропускною здатністю ви маєте на увазі швидкість передачі даних, а не розмір файлу (фільму)?
додано Автор Matt H, джерело
@stemie На запитання було написано "дані", а не "пропускна здатність". Якщо я вас правильно розумію, це не те, що ви просили. Однак більшість відповідей відповідає, що оскільки питання після "пропускної здатності" невдалим. Див. мою відповідь для пояснення плутанини .
додано Автор ucsky, джерело
Перевагою завантаження над потоковим потоком (який технічно завантажується, але тільки для одноразового використання) є те, що ви можете споживати матеріал стільки разів, скільки ви хочете, не витрачаючи на нього щоразу пропускну здатність. Деякі медіаплеєри можуть навіть відтворювати відео, які ви зараз завантажуєте (не повністю завантажені), надаючи "відчуття" потокового відео з перевагою завантаження.
додано Автор ADTC, джерело
"У комп'ютерних мережах і інформатиці, пропускна здатність, пропускна спроможність мережі, пропускна здатність даних або цифрова пропускна здатність - це вимірювання бітової швидкості доступних або споживаних ресурсів передачі даних, виражених у бітах на секунду або кратними (біт/с, кбіт/с , Мбіт/с, Гбіт/с і т.д.) - wikipedia.org/wiki/Bandwidth_(computing) "
додано Автор ty., джерело
Так, я маю на увазі швидкість передачі даних. Причина, по якій я запитала, була незгода з моєю сестрою, і коли я дивлюся в Інтернет, все, що я міг знайти, - це неясні відповіді з відповідей Yahoo. Я розумію, що є багато змінних, від яких залежить, але я думав, що це, принаймні, варто запитати.
додано Автор ty., джерело

11 Відповіді

Це часто не є еквівалентом.

Потокові провайдери використовують протоколи, такі як DASH , щоб динамічно коригувати якість фільму для користувачів Доступність пропускної здатності та якість бажань. Тоді сервери можуть обмежити швидкість вашого з'єднання так, що ви можете буферизувати певну суму (приблизно 10 секунд, може бути, 30 або цілу хвилину), а потім ви отримаєте лише величину смуги пропускання, необхідну для отримання вмісту в реальному часі. Це очевидна оптимізація з точки зору постачальника, оскільки вона поширює смугу пропускання більш рівноправно серед користувачів і, крім того, уникає передачі даних, які будуть передані марно (наприклад, коли користувач спостерігає фільм 480p протягом 10 хвилин, без збільшення та з загальною низхідній лінії зв'язку, цілком імовірно, що набагато більше, ніж те, що вже завантажено, але потім витрачається даремно, якщо користувачі перестають дивитися відео).

Кількість переданих даних однакова. Але це може зайняти більше часу з потоковою передачею, оскільки провайдер може обмежити передачу даних до швидкості, необхідної для доставки вмісту в заданій якості в реальному часі.

Dailymotion є одним з провайдерів, які обмежують швидкість з'єднання. Від сервера з симетричним з'єднанням не менше 100 Мбіт/с ми бачимо наступне поведінку:

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

The rate is much below what would be possible (and is achieved with other providers). Also, if you try different material, you’ll find that the rate is highly dependent on the individual video: a fullhd video easily downloads with > 1 MiB/s, while a a music video such as this stays around or below 200 KiB/s.

Підсумувати всі можливі непорозуміння: Деякі провайдери можуть обмежити завантаження під час потокової передачі, через клієнтське додаток (наприклад, youtube з html5 або флеш-відеоплеєром) або за допомогою серверних засобів. Якщо вони не обмежують швидкість сервером, то завантаження споживатиме більше смуги пропускання, оскільки обмеження швидкості, яке можливо застосовується клієнтським додатком під час потокового відео, не відбувається. Це головний випадок, коли споживана смуга пропускання відрізняється від вихідного питання.


  1. Я усвідомлюю, що це своєрідні анектодальні докази, але я послідовно спостерігав за такою поведінкою.
42
додано
Я не знаю, youtube використовується тільки для продовження буферизації, але тепер конкретні буфери, повинні бути деякі зв'язку з клієнтом за межами нормального ACK для пакетів (або як це працює).
додано Автор Steven Hepting, джерело
якщо ми припустили, що таку ж точну інформацію завантажується або передавалося, чи існує загальна цифра для додаткових накладних витрат, які можуть існувати в будь-якому напрямку від потокової передачі? Візьміть приклад конкретного ресурсу YouTube, який можна завантажити у вигляді всього файлу, або youtube буферизований і переданий у потоковому режимі за допомогою flash або html5.
додано Автор Steven Hepting, джерело
@ NPSF3000 (поки що не бачили ваш коментар, вибачте) Ні, і фактично відео-сайти, такі як youtube, повинні використовувати TCP (через якийсь HTTP), тому що браузери не дозволять їм використовувати що-небудь інше. Але, як ви сказали, використання TCP у цьому випадку краще в будь-якому випадку; він також має кращий досвід кінцевого користувача, оскільки NAT все ще широко розгортається, і TCP набагато краще, коли мова йде про отримання через NAT (якщо з'єднання ініційовано кінцевим користувачем).
додано Автор Dennis, джерело
@zamnuts Я впевнений, що моя відповідь була правильною раніше, але я уточнила в додатковому пункті, щоб очистити її. Я лише кілька годин тому зрозумів, звідки виникла вся плутанина: в інженерії, пропускна здатність - це швидкість передачі даних, а іноді люди посилаються на пропускну здатність кількості переданих даних . У будь-якому випадку, я сподіваюся, що зараз краще з доданим абзацом.
додано Автор Dennis, джерело
@Psycogeek Youtube є одним з прикладів використання DASH (якщо цей коментар не має сенсу для вас, прочитайте вступну частину статті, яку я зв'язав). Це означає, що гравець, який використовує клієнт, повинен запитувати послідовні фрагменти відео. Прийнявши крок, щоб припинити запитувати більше шматочків, якщо гравець не працює, це просто природно. Завантажувачі, такі як youtube-dl , просто продовжуватимуть запитувати більше шматочків, доки відео не буде повністю завантажено. Таким чином, потокове передавання з DASH має трохи більше накладних витрат, але це, можливо, варто (як для користувача, так і для провайдера) і нехтувати.
додано Автор Dennis, джерело
@Psycogeek Я не впевнений, що я правильно розумію ваше питання. Які накладні витрати ви очікуєте?
додано Автор Dennis, джерело
Я б принизив цю відповідь, якщо маю достатньо репліка: це не відповідає на питання, ключова фраза - "така ж якість". Коли провайдер знижує якість, це не ceteris paribus .
додано Автор noclayto, джерело
Припускаючи, що використовуються однакові кодування даних і визначення (див. Коментар psychogeek), завантаження буде використовувати більше загальної пропускної здатності. Завантаження відео майже напевно буде зроблено за допомогою протоколу TCP, в той час як потокове передавання буде UDP або аналогічним не гарантованим підходом. Таким чином, TCP матиме більше посилань на мінімум, і оскільки ви, мабуть, втратите або пошкодите принаймні кілька пакетів, то підхід tcp буде більше завантажуватися (також він буде вилучати втрачені пакети). Хоча різниця дуже незначна в порівнянні з розміром завантаження, тому це в основному академічне.
додано Автор DK., джерело
@dsollen: Якщо відправник UDP не просто дозволить потокам пакетів, не піклуючись про те, чи бажаний одержувач все ще існує, UDP і TCP вимагатимуть періодичних підтверджень; в будь-якому випадку підтвердження буде представляти дуже малу частину загального трафіку. Крім того, форматування даних таким чином, що кожен пакет можна зрозуміти, навіть якщо попередній пакет не був прийнятий, в загальному випадку передбачає додаткові накладні витрати, за винятком того, що буде потрібно для TCP.
додано Автор supercat, джерело
@zamnuts, потім опублікуйте краще і дайте спільноті вирішити. FWIW, його трохи яблук і апельсинів, коли ви вважаєте, що постачальник вирішив якісні падіння, але я не думаю, що відповідь буде повною без неї.
додано Автор paqogomez, джерело
@dsollen будь-яка причина для потокового відео, щоб використовувати UDP замість TCP? Я стверджую, що з огляду на те, що потокове відео, як правило, не в режимі реального часу, і включає великі обсяги даних, може бути набагато простіше і простіше використовувати гарантовані системи доставки - напр. TCP завантажує кілька секунд партій відео заздалегідь (буферизація). Очевидно, що для потокової трансляції (наприклад, відеоконференції) у UDP є набагато сильніший випадок.
додано Автор NPSF3000, джерело

Припускаючи, що ми говоримо про таку ж якість (наприклад, відсутність дроселювання, пропускання кадрів або потоки з більш низькою якістю), то в кращому випадку потоки забирають таку ж кількість пропускної здатності, що й завантаження, хоча це може бути зроблено за часом/швидкістю зручніше провайдеру. Це також може займати більше смуги пропускання в залежності від того, як відео стискається - більшу частину часу не передається все зображення, а просто зміна (або дельта) між кадрами. Це означає, що чим більше історії існує (тобто використовувати колірний відтінок синього від пікселя X у кадрі Y), тим менше потрібно відправити. Зазвичай це не виникає багато, але коли пауза призупинена/перервана з якої-небудь причини, ця "історія" втрачається і потребує повторної передачі, що збільшує пропускну здатність, тоді як при завантаженні її можна відновити на "перерві", і припустив, що приймач вже має цю інформацію. Те ж саме можна використовувати для аудіо, особливо там, де немає фіксованої швидкості (тобто FLAC замість mp3)

Стрибки навколо (пропуск, повторна обмотка і т.д.) також можуть вплинути на використання - перехід від буфера зменшить пропускну здатність потоку, але будь-яка повторна обмотка збільшить її. Крім того, буде переривання, яке призведе до збільшення використання (див. Вище), і будь-який вид "мініатюри", як те, що YouTube і Netflix використання також трохи збільшити пропускну здатність.

Останнє зауваження: стиснення: це може бути зроблено для завантаження, але не стільки для потоків - це застереження, що більшість відео вже стиснуто, так що тут не було б багато нажито (хоча може бути місце для виграшу в ультра- відділ високої роздільної здатності/якості).

19
додано

Streaming will use less bandwidth, especially if network conditions are bad, but this comes at a price.

Йдеться про дані, які необхідно надіслати. У моделі завантаження всі дані повинні охоплювати клієнта, все в правильному порядку, незалежно від того, що . Якщо умови мережі погані, а деякі біти даних не досягають клієнта, вони повинні бути повторно надіслані, а це збільшує використання пропускної здатності. Якщо деякі дані потрапляють туди з ладу, вони повинні бути повернуті в порядок, перш ніж вони будуть представлені, і це зменшує швидкість реагування.

In a streaming model, it's OK if some of the data doesn't reach the client. If you're streaming a movie and a frame doesn't get there, you can just skip it and move on, so you don't use additional bandwidth on resends. If some frames get there out of order, just play the ones that go forward; a momentary blip won't matter, and so this increases responsiveness. However, it also means that you don't necessarily get the full data: whatever you see is whatever got there on the first shot.

If you have to choose between the models, choose based on what you want to do with the data. If you want to archive it and/or possibly view it many times, then download it so that you're sure to get everything. If you don't plan on archiving, or only plan on viewing the data once, then go ahead and stream; you probably won't notice the difference on a single viewing, and if network conditions are bad enough that you do notice, then downloading would be even worse.

7
додано
+1 для найменш заплутаної відповіді (на сьогоднішній день) у цій темі.
додано Автор Mikhail, джерело
Ви хочете сказати, що потокові служби використовують UDP замість TCP, щоб навмисно дозволити пропущені дані?
додано Автор Mark Henderson, джерело
Насправді багато систем передають дані через TCP і буфер на стороні клієнта. Для потокового перегляду фільму затримка не є критичною. Немає ніяких незручностей для користувача, якщо деякі з кадрів трапляються в буфері протягом однієї хвилини, перш ніж настав час для їх відображення. Але для інтерактивних застосувань, таких як відеоконференції, затримка критична.
додано Автор kasperd, джерело
@FreeAsInBeer: Так. TCP створює багато механізмів надійності та інших функцій, які дуже корисні для найбільш уявних додатків. Але випадки використання DO існують там, де є речі, які є більш важливими, ніж надійність, і потокове передавання є одним з них: важливіше показати правильний кадр у потрібний момент, ніж показувати кожний окремий кадр. Інтернет-ігри є ще одним прикладом, де UDP користується популярністю, з тих же причин: припинення дії по відновленню сліду держав гравця гірше, ніж для того, щоб виправляти випадковий стан.
додано Автор The Spooniest, джерело
kasperd: Строго кажучи, це не потокове. Інші відповіді вказали послуги, які завантажуються, але починають грати до завершення завантаження, і саме це роблять системи, які ви описуєте.
додано Автор The Spooniest, джерело

Якщо ви дійсно просите "пропускну здатність" (байт/сек), а не "загальні дані" (байти), вирішальним питанням є: за який період часу? Якщо ми припускаємо, що користувач переглядає ціле відео та повертається той самий кодек/якість тощо, і не звертає уваги на невеликі накладні витрати на запит/відповідь, то загальна кількість повернутих даних дорівнює.

Тепер, що таке пропускна здатність? Є два способи зрозуміти своє запитання:

  1. Пропускна здатність за час, який триватиме до завершення завантаження. Для потокового показу видно, що високий рівень пропускної здатності (коли запитується наступний фрагмент) повертається до нуля, коли ви повторно спостерігаючи, що шматок, поки ви біля кінця шматка і є сплеск в пропускну здатність знову. Для завантаження, ви повинні побачити дуже високу пропускну здатність, скажімо, 10min, яка знижується до нуля, як тільки все відео буде завантажено. Якщо зараз ви зупините експеримент, пропускна здатність для завантаження, очевидно, вища, оскільки вона максимізує вашу низхідну лінію, поки вона не буде виконана.

  2. Пропускна здатність під час перегляду відео. Час перегляду відео є однаковим як для потокового відео, так і для завантаження. Загальний розмір даних також є однаковим. Оскільки пропускна здатність є даними за час, вона є однаковою для обох сценаріїв.

У прикладі нижче завжди завантажено всього 40 (одиниць даних). Але для "завантаження", це 40 в першу одиницю часу, в той час як для "потокового" це 20 протягом перших одиниць часу (щоб отримати великий початковий шматок), а потім двічі 10 для двох додаткових блоків. Зверніть увагу, що в той час як смуга пропускання нанесена на осі у, область під кожним з двох графіків відповідає даним (байтам) - якщо ви інтегрувати байти/час з часом, ви отримуєте байти.

5
додано

Вони не порівнянні.

Для першого прикладу оптимальне кодування для локального перегляду відрізняється від кодування optima для потокового перегляду.

Поговоримо про кодування відео.

У більшості форматів кодування відео зазвичай існують два типи кадрів:

  1. Внутрішньо-кодований кадр (I-Frame) - це кадри, які передаються в повному обсязі, цей кадр може бути декодований без знання будь-якого іншого кадру. Внутрішньо-кодований кадр є, по суті, статичним зображенням. Кодери генерують їх під час різких переходів. Вони менш ефективні для стиснення.
  2. Передбачений кадр (P-Frame) або Bi-предсказанный кадр (B-Frame) - це кадри, які зберігають тільки відмінності між кадрами, їх можна декодувати, тільки якщо глядач також знає попередні та/або останні кадри. Вони набагато ефективніше стискати.

Кодування для локального перегляду може скористатися швидким диском, який намагається використати більше P і B кадрів, в той час як відео, кодоване для ефективного потокового відео, повинно кодувати більш зайвий I-Frame по всьому відео, навіть якщо немає раптових переходів випадкового пошуку.

Крім того, існує два різних типи потокової передачі. Ви можете мати потокове передавання попередньо записаного потоку (більшість відео YouTube) і потоки подій у прямому ефірі (наприклад, YouTube Live). У зв'язку з необхідністю затримки потокове подія в прямому ефірі не може скористатися передовими методами кодування, які займають довгий або непередбачуваний проміжок часу, тоді як попередньо записаний потік може займати стільки часу, скільки потрібно для кодування.

Потокове відео також зазвичай кодується з постійною швидкістю бітів (CBR). Для одного і того ж цільового розміру відео з змінною швидкістю (VBR) зазвичай має більш високу якість, ніж відео CBR. І навпаки, відео VBR є меншим для такої ж якості відео CBR. Адаптивний потоковий протокол типу DASH має адаптивний бітрейт (ABR), який є компромісом між CBR і VBR. ABR дозволяє глядачеві адаптуватися до змін пропускної здатності мережі. Враховуючи постійну, послідовну пропускну здатність, ABR є більш-менш таким же, як CBR.

Все це означає, що з однаковою якістю та враженням від перегляду , можна кодувати відео для локального перегляду більш ефективно, ніж потокове відео, а також можна кодувати відео для попередньо записаних потоків ефективніше, ніж потоки у прямому ефірі.

Потім є також накладні витрати в потоковому протоколі. Звичайне завантаження HTTP може використовувати кодову передачу кодування для завантаження всього файлу, який має мінімальне навантаження. Потокове завантаження доведеться обговорити шматок і якість шматка для передачі. У великій схемі речей, накладні витрати на протокол передачі відносно незначні.

Загалом, за аналогічну кількість переглянутого відео, потокове відео повинно мати більшу пропускну здатність. Основною перевагою потокової передачі, з точки зору використання пропускної здатності, є те, що вона може заощаджувати користувачами, які завантажуються, але не переглядає відео в повному обсязі, що може бути дуже значною економією.

4
додано

Так, це еквівалент. Завантажити = Ви завантажуєте його лише один раз і залишається на вашому комп'ютері. Stream = Ви тимчасово завантажуєте "щось" на комп'ютер.

2
додано
Існує різниця між кількістю переданих даних і використовуваною пропускною здатністю.
додано Автор Dennis, джерело
Це дійсно правильна відповідь у багатьох випадках. Часто в багатьох випадках для потокової передачі та завантаження використовується той самий ресурс і протокол. Якщо ви хочете відтворити ресурс за протоколом HTTP, він не відрізняється від завантаження, окрім того, що ви його відтворюєте під час завантаження. Звичайно, існують оптимізації для потокової передачі та різні протоколи, які можуть змінити ваш бітрейт під час потоку, але я не думаю, що це основне питання. (Однак вони заслуговують на згадку.)
додано Автор Brad, джерело
@JonasWielicki Мудрець одного разу сказав: "Кількість переданих даних однакова". Звичайно, кількість використовуваної смуги пропускання змінюється, внаслідок буферизації швидкість передачі повільніше з часом.
додано Автор Ionic, джерело
а на моєму андроїді, що переглядає відео з потоку або завантажує його, має однакове використання даних
додано Автор Tiago Ribeiro, джерело

Відповідь: "Це залежить".

Відповідь НІ, для провайдерів, які приймають відео взагалі. Половина пристойних постачальників, які здійснюють потокове відео, контролюють темпи, щоб забезпечити плавне відтворення та оптимальну пропускну здатність для максимальної кількості людей. Таким чином, навіть якщо у вас є багато пропускної здатності, він може вирішити дати вам тільки 5Mbit і виглядати ще досить пристойно.

Якщо ви виконуєте завантаження HTTP, то алгоритми управління швидкістю передачі протоколів TCP забезпечать, що ви наситите один або обидва кінці з'єднання або що-небудь між ними. Отже, якщо у вас є 100Mbit доступний, він буде використовувати все, що він може отримати або близько 100Mbit.

Це, звичайно, припускає, що між клієнтом і сервером не відбувається жодного QoS.

Ваше питання настільки вільне, що я міг би зробити це так, що в деяких наївних налаштуваннях відповідь також ТАК (з припущеннями), смуги пропускання однакові. Щоб зробити це, просто відпустіть файл на свій основний веб-сервер і відкрийте його у вашому браузері, щоб глядач запустився. Або вставте відео на основний веб-сервер, і знову він буде відтворюватися в браузері і використовувати ідентичну пропускну здатність з наступне припущення ... немає інших користувачів, ніхто інший не розділяє мережу з вами ... ніяких інших факторів, які можуть змінити вашу пропускну здатність.

Майте на увазі, що коли ви завантажуєте файл з веб-сайту, а потім знову завантажуєте його, пропускна здатність між першим і другим завантаженням може змінюватися. Це просто тому, що навантаження на сервер може змінюватися, а перевантаження в мережі та мережеві шляхи можуть змінюватися.

Так що у вас є ... це залежить.

1
додано
@stemie, Це буде близько. Різні протоколи додають накладні витрати на протокол. Але якщо не було транскодування або зміни якості/швидкості під час потокового процесу, то це має бути таке ж кількість відеоданих в теорії.
додано Автор Matt H, джерело
"пропускна здатність між першим і другим завантаженням може змінюватися", але, безумовно, вона завантажує таку ж кількість даних в кінці, навіть якщо вона займає більше часу, ніж інша/змінені умови мережі.
додано Автор ty., джерело

З точки зору мережі "завантаження" і "потокове" використовуються різні сервіси, це називається "профіль трафіку"

Для сервісу потокової передачі мережа повинна забезпечити мінімальну постійну пропускну здатність (технічно "смуга пропускання" означає щось інше), послуга потокової передачі чутлива до переривань і джиттера. Він не вимагає максимальної пропускної здатності мережі, затримки або затримки не є критичними.

З точки зору кінцевого користувача це означає: відеозапис буде працювати безперебійно, без втручання або падіння. Немає значення, якщо відео починається кілька секунд раніше або пізніше.

"Завантаження" зазвичай вимагає максимально можливої ​​пропускної здатності мережі, завантаження повинно бути завершено якнайшвидше. Затримки, перерви і джиттер не є критичними.

Мережа може надавати більше профілів трафіку, які повністю відрізняються. Наприклад, голосові послуги (простий телефонний дзвінок) вимагають дуже низької пропускної здатності, але дуже чутливі до затримок (менше 200 мс)

1
додано

Щоб додати до інших відповідей, моя відповідь: Не обов'язково .

Тепер, припускаючи, що все є рівним (немає автоматичного вибору якості, немає дроселювання з сервера та/або ISP) ...

Bandwidth is usually defined as size_of_data divided by total_time. (Technically, the 'proper' term is throughput, but I digress).

Давайте припустимо, що ви збираєтеся відтворити відео в розмірі 2000 секунд розміром 60 МБ.

За допомогою потокової передачі програма стримера може виконати власне обмеження швидкості, щоб запобігти переповненню буфера. Отже, заголовок HTTP-запиту може включати поле діапазону . ефективна пропускна здатність, починаючи з потоку, поки потокові кінці не становитимуть ~ 60 Мб/2000 секунд = 30 Кб/с = 240 кбіт/с.

Однак, якщо ви завантажите відео безпосередньо, ви отримаєте до максимальну пропускну здатність вашої служби Інтернету. Залежно від іншого використання одночасно, звичайно. Таким чином, припускаючи інтернет-сервіс на 6 Мбіт/с, з 50% доступною пропускною здатністю, ви отримаєте 3 Мбіт/с для завантаження відео.

0
додано

Потокове відео - це спосіб завантаження.

Коли ви дивитеся потокове відео, ваш мультимедійний програвач завантажить його частини, покаже їх вам, і відкине показані частини файлу на льоту.

Зазвичай, коли ви завантажуєте файл, ви чекаєте завершення завантаження і тільки потім починаєте його переглядати. Але є медіа-плеєри, які здатні показувати вам завантажену частину файлу і автоматично призупиняти і чекати, поки будуть завантажені інші. Начебто потокове, але не відкидаючи файл.

Технічно, коли занепокоєння викликає загальний обсяг переданих даних, не має значення, як ви його завантажуєте, але різниця між завантаженим файлом і файлом, який ваш медіаплеєр завантажує для вас як потік. Вони можуть бути однаковими точними файлами, і це буде означати однакову пропускну здатність в обох випадках.

Потокові мультимедійні сайти зазвичай кодують свій вміст, щоб мати нижчий бітрейт, ніж куплений в магазині диск. Але ви можете переглядати фільм зі свого настільного комп'ютера на ноутбуці через WiFi, використовуючи функцію обміну файлами у вашій ОС, і це займе майже стільки ж трафіку, як якщо б ви його дивилися на робочому столі (як читати байти з жорсткого диска) привід). Технічно це було б потокове, як ви дивитеся фільм в той час як частини його безперервно завантажуються і відкидаються.

Так що відповідь це абсолютно залежить від розміру двох файлів - передається через медіа-плеєр і завантажується на диск.

0
додано

Потокове передавання використовує пропускну здатність завантаження, тому ви можете розглянути її як завантаження. Ваше питання трохи неоднозначне щодо того, що ви вважаєте завантаженням. Ви можете завантажити лише стільки завантажень, які вони можуть і готові запропонувати. Отже, врешті-решт, якщо ви хочете порівняти пряме завантаження з HTTP через DASH (як і раніше HTTP), вам доведеться перевірити, скільки завантажень ви робите з кожного.

Тому я думаю, що відповідь полягає в тому, що вона може використовувати ту ж саму суму ... або менше ... або більше. залежно від серверів і швидкості, яку вони обслуговують.

0
додано