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

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

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

Це часто не рівнозначно.

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

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

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

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

Коефіцієнт значно нижчий від можливого (і досягається з іншими постачальниками). Крім того, якщо ви спробуєте інший матеріал, ви побачите, що швидкість сильно залежить від окремого відео: відео в повному форматі легко завантажується з> 1 Мбіт / с, тоді як музичне відео, наприклад таке, залишається близько 200 Кіб / с .

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

1. Я знаю, що це свого роду анектодальні докази, однак я спостерігав цю поведінку постійно.

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

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

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

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

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

У потоковій моделі це нормально, якщо частина даних не доходить до клієнта . Якщо ви потоково передаєте фільм, і кадр не потрапляє туди, ви можете просто пропустити його та рухатися далі, тому ви не використовуєте додаткову пропускну здатність для повторних повторних переглядів. Якщо деякі кадри виходять з ладу, просто грайте в ті, що йдуть вперед; миттєвий блиск не має значення, і тому це підвищує чуйність. Однак це також означає, що вам не обов'язково отримувати повні дані: все, що ви бачите, те, що трапляється на першому знімку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ширина пропускної здатності зазвичай визначається як розмір_да_даних, поділений на загальний_час. (Технічно "правильний" термін є пропускною здатністю , але я відхиляюсь).

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

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

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

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

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

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

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

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

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

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

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

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