Использует ли потоковая передача ту же пропускную способность, что и загрузка?

75

Предполагая, что контент одинакового качества (при прочих равных условиях), использует ли потоковое мультимедиа (то есть видео, аудио) ту же полосу пропускания, что и при его загрузке?

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

stemie
источник
2
Зависит от протокола и кодека: например, загрузка через http и потоковая передача через rtmp или h264 vs vp6. ИМО этот вопрос слишком широк, учитывая количество методов сжатия и передачи данных для сравнения.
Замнюц
Просто чтобы уточнить ваш вопрос. По пропускной способности вы имеете в виду скорость передачи данных, а не размер файла (фильма)?
Мэтт Х
Преимущество загрузки по сравнению с потоковой передачей (которая технически загружается, но только для одноразового использования) состоит в том, что вы можете потреблять материал столько раз, сколько захотите, не тратя на него свою пропускную способность каждый раз. Некоторые мультимедийные проигрыватели могут даже воспроизводить видео, которые вы загружаете в данный момент (не полностью загруженные), создавая ощущение потокового воспроизведения с преимуществом загрузки.
ADTC
3
Да, я имею в виду скорость передачи данных. Причиной, по которой я спросил, было несогласие с моей сестрой, и когда я смотрел онлайн, все, что я мог найти, было расплывчатыми ответами из ответов Yahoo. Я понимаю, что есть много переменных, от которых это зависит, но я подумал, что это, по крайней мере, стоит спросить.
Стели
2
«В компьютерных сетях и информатике пропускная способность, пропускная способность сети, пропускная способность данных или цифровая пропускная способность - это измерение скорости передачи в битах доступных или потребляемых ресурсов передачи данных, выраженной в битах в секунду или кратных ей (бит / с, кбит / с»). , Мбит / с, Гбит / с и т. Д.) - wikipedia.org/wiki/Bandwidth_(computing) "
stemie

Ответы:

43

Это часто не эквивалентно.

Потоковые провайдеры используют протоколы, такие как 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

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

Подводя итоги и проясните некоторые возможные недоразумения: некоторые провайдеры могут ограничить загрузку во время потоковой передачи, используя свое клиентское приложение (например, youtube с html5 или флэш-видеоплеером) или с помощью сервера. Если они не ограничивают скорость с помощью сервера, тогда загрузка будет потреблять большую пропускную способность, поскольку ограничение скорости, которое, возможно, применяется клиентским приложением во время потоковой передачи, не имеет места. Это основной случай, когда используемая пропускная способность отличается от исходного вопроса.


  1. Я знаю, что это своего рода анектодальные доказательства - однако я наблюдал это поведение последовательно.
Йонас Шефер
источник
3
@Psycogeek Youtube - один из примеров использования DASH (если этот комментарий не имеет смысла для вас, прочитайте вступительную часть статьи, на которую я ссылался). Это означает, что проигрыватель, который использует клиент, должен в любом случае запрашивать последовательные фрагменты видео. Сделать шаг оттуда, чтобы прекратить запрашивать больше кусков, если игрок не работает, это просто естественно. Загрузчики, такие как youtube-dl, просто продолжат запрашивать больше фрагментов, пока видео не будет полностью загружено. Таким образом, потоковая передача с DASH влечет за собой немного больше затрат, но, вероятно, оно того стоит (как для пользователя, так и для провайдера) и ничтожно мало.
Йонас Шефер
1
Предполагая, что используются одинаковые кодировка и определение данных (см. Комментарий psychogeek), загрузка будет использовать большую общую пропускную способность. Загрузка видео почти наверняка будет осуществляться с использованием протокола TCP, а потоковая передача будет осуществляться по протоколу UDP или аналогичному подходу с негарантированной доставкой. Таким образом, TCP будет отправлять как минимум больше подтверждений, и, поскольку вы, вероятно, потеряете или повредите хотя бы несколько пакетов, подход tcp на самом деле также будет более загружаемым (поскольку он также будет извлекать потерянные пакеты). Хотя разница очень незначительна по сравнению с размером загружаемого файла, так что это в основном академический характер.
dsollen
2
@dsollen: если отправитель UDP не собирается просто пропускать пакеты, не заботясь о том, существует ли предполагаемый получатель, и UDP, и TCP будут требовать периодических подтверждений; в любом случае подтверждения будут представлять очень небольшую часть общего трафика. Кроме того, форматирование данных таким образом, что каждый пакет может быть понят, даже если предыдущий пакет не получен, обычно подразумевает уровень служебной информации, превышающий то, что требуется для TCP.
суперкат
7
Я бы понизил этот ответ, если бы у меня было достаточно повторений: он не отвечает на вопрос, ключевая фраза «того же качества». Когда поставщик теряет качество, это не при прочих равных условиях .
Замнюц
1
@zamnuts, тогда опубликуйте лучшее и пусть сообщество решит. FWIW, это немного яблок и апельсинов, если вы считаете, провайдер решил провалы качества, но я не думаю, что ответ будет полным без него.
Пагогомез
19

Предполагая, что речь идет об одном и том же качестве (т. Е. Об отсутствии дросселирования, пропуска кадров или потоков с более низким качеством), в лучшем случае потоки будут занимать столько же пропускной способности, что и загрузка, хотя это может быть сделано со скоростью / скоростью удобнее для провайдера. Это также может занять большую полосу пропускания в зависимости от того, как сжато видео - большую часть времени все изображение не отправляется, а только изменение (или дельта) между кадрами. Это означает, что чем больше истории (т. Е. Использовать этот оттенок синего от пикселя X в кадре Y), тем меньше нужно отправлять. Обычно это не очень всплывает, но когда по какой-либо причине поток приостанавливается / прерывается, эта «история» теряется, и ее необходимо будет повторно передавать, увеличивая тем самым пропускную способность, а при загрузке ее можно возобновить. на «перерыве», и предположил, что получатель уже имеет эту информацию. То же самое можно использовать для аудио, особенно там, где нет фиксированной скорости (например, FLAC вместо mp3)

Прыжки вокруг (пропуск, перемотка и т. Д.) Также могут повлиять на использование - продвижение вперед через буфер уменьшит количество полосы пропускания, используемой потоком, но любая перезапись увеличит ее. Также будет иметь место прерывание, которое приведет к увеличению использования (см. Выше), и любой вид «предварительного просмотра эскизов», такой как использование youtube и netflix, также немного увеличит пропускную способность.

Последнее замечание: сжатие: это можно сделать для загрузок, но не для потоков, так как большинство видео уже сжаты, поэтому здесь не будет особой выгоды (хотя может быть место для усиления в отдел высокого разрешения / качества).

user2813274
источник
7

Потоковая передача будет использовать меньшую пропускную способность, особенно если состояние сети плохое, но это дорого обходится .

На вопрос данные, которые должны быть отправлены. В модели загрузки все данные должны поступать к клиенту, все в правильном порядке, несмотря ни на что . Если состояние сети плохое и некоторые биты данных не доходят до клиента, они должны быть отправлены повторно, что увеличивает использование полосы пропускания. Если некоторые данные оказываются там не в порядке, они должны быть приведены в порядок, прежде чем они будут представлены, и это снижает скорость реагирования.

В потоковой модели все в порядке, если некоторые данные не доходят до клиента . Если вы транслируете фильм, а кадр не попадает, вы можете просто пропустить его и двигаться дальше, чтобы не использовать дополнительную пропускную способность при повторных отправках. Если некоторые кадры выходят из строя, просто воспроизведите те, которые идут вперед; мгновенное сообщение не имеет значения, и это увеличивает отзывчивость. Однако это также означает, что вы не обязательно получаете полные данные: все, что вы видите, это то, что вы получили с первого раза.

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

Ложка
источник
Вы говорите, что потоковые сервисы используют UDP вместо TCP, чтобы преднамеренно разрешить отбрасывание данных?
FreeAsInBeer
1
@FreeAsInBeer: да. TCP включает в себя множество механизмов обеспечения надежности и другие функции, которые очень полезны для большинства мыслимых приложений. Но варианты использования действительно существуют, когда есть вещи, даже более важные, чем надежность, и потоковая передача является одним из них: более важно показывать правильный кадр в нужный момент, чем показывать каждый отдельный кадр. Онлайн-игры являются еще одним примером популярности UDP по тем же причинам: остановка действия по восстановлению списка состояний игроков хуже, чем необходимость исправления случайного пропущенного состояния.
Ложная
На самом деле многие системы передают данные через TCP и буферизируют на стороне клиента. Для потокового фильма задержка не критична. Пользователь не испытывает неудобств, если некоторые кадры находятся в буфере в течение минуты, прежде чем пришло время их отображать. Но для интерактивного использования, такого как видеоконференция, задержка имеет решающее значение.
Касперд
1
kasperd: Строго говоря, это не потоковое. В других ответах упоминаются службы, которые загружают, но начинают играть до завершения загрузки, и именно этим занимаются описанные вами системы.
Ложная
+1 за наименее запутанный ответ (на сегодняшний день) в этой теме.
Космическое оссифраж
5

Если вы действительно запрашиваете «пропускную способность» (байт / сек), а не «общее количество данных» (байт), решающий вопрос: в течение какого периода времени? Если мы предполагаем, что пользователь просматривает все видео и возвращается тот же кодек / качество и т. Д., И игнорируют небольшие издержки потокового запроса / ответов, то общее количество возвращаемых данных равно.

Теперь, какова пропускная способность? Есть два способа понять ваш вопрос:

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

  2. Пропускная способность во время просмотра видео. Время просмотра видео одинаково как для потоковой передачи, так и для загрузки, при условии, что оба сразу начинают смотреть. Общий размер данных одинаков. Поскольку пропускная способность является данными за раз, она одинакова для обоих сценариев.

В приведенном ниже примере всегда загружено 40 (единиц данных). Но для «загрузки» это 40 в первой единице времени, в то время как для «потоковой передачи» это 20 в первые единицы времени (чтобы получить большой начальный чанк), а затем дважды 10 для двух дополнительных чанков. Обратите внимание, что хотя полоса пропускания отображается на оси Y, область под каждым из двух графиков соответствует данным (в байтах) - если вы интегрируете байты / время с течением времени, вы получаете байты.

MB21
источник
4

Они не сопоставимы.

Для первого случая оптимальное кодирование для локального просмотра отличается от оптимального кодирования для потокового просмотра.

Давайте поговорим о кодировании видео.

В большинстве форматов кодирования видео обычно есть два типа кадров:

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

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

Также есть два разных типа потоковой передачи. Вы можете иметь потоковую передачу предварительно записанного потока (большинство видео на Youtube) и прямые трансляции событий (например, Youtube Live). Из-за необходимости задержки потоковое событие в реальном времени не может использовать преимущества передовых методов кодирования, которые занимают длительное или непредсказуемое время, в то время как предварительно записанный поток может занять столько времени, сколько ему необходимо для кодирования.

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

Все это означает, что при одинаковом качестве и качестве просмотра вы можете кодировать видео для локального просмотра более эффективно, чем потоковое видео, и вы можете кодировать видео для предварительно записанных потоков более эффективно, чем прямые трансляции.

Тогда есть также издержки в протоколе потоковой передачи. Обычная загрузка HTTP может использовать кодирование передачи по частям для загрузки всего файла с минимальными издержками. Потоковая загрузка должна согласовывать порцию и качество порции для передачи. В общей схеме издержки протокола передачи относительно незначительны.

В целом, при одинаковом количестве просматриваемого видео потоковое видео должно занимать большую полосу пропускания. Основное преимущество потоковой передачи с точки зрения использования полосы пропускания состоит в том, что она может сэкономить людям, которые загружают, но не смотрят видео в полном объеме, что может быть очень существенной экономией.

Ли Райан
источник
1

Ответ «Это зависит».

Ответ НЕТ, для провайдеров, которые размещают видео в целом. Половинные приличные провайдеры, которые транслируют видео, контролируют скорость, чтобы обеспечить плавное воспроизведение и оптимальную пропускную способность для максимально возможного количества людей. Так что, хотя у вас может быть много пропускной способности, он может решить выделить вам только 5 Мбит и выглядеть все еще вполне прилично.

Если вы загружаете HTTP, тогда включаются алгоритмы управления скоростью TCP, чтобы обеспечить насыщение одного или обоих концов соединения или чего-либо промежуточного. Так что, если у вас было доступно 100 Мбит, он будет использовать все, что может получить, или почти 100 Мбит.

Это, конечно, предполагает, что QoS не происходит нигде между клиентом и сервером.

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

Имейте в виду, что при загрузке файла с веб-сайта и последующей его загрузке пропускная способность между первой и второй загрузкой может изменяться. Это просто потому, что нагрузка на сервер может измениться, а загруженность сети и сетевые пути могут измениться.

Так что у вас это есть ... это зависит.

Мэтт Н
источник
«Пропускная способность между первой и второй загрузкой может варьироваться», но, безусловно, в конце она загружает тот же объем данных, даже если один занимает больше времени, чем другой / условия сети изменились.
Стели
@stemie, это будет близко. Различные протоколы добавляют издержки протокола. Но если в процессе потоковой передачи не было транскодирования или изменения качества / скорости, то теоретически это должен быть тот же объем видеоданных.
Мэтт Х
1

С точки зрения сети «загрузка» и «потоковая передача» - это разные услуги, это называется «профиль трафика».

Для потоковой службы сеть должна обеспечивать минимальную постоянную пропускную способность (технически «пропускная способность» означает нечто иное), потоковая служба чувствительна к прерываниям и дрожанию. Это не требует максимальной пропускной способности сети, задержка или задержка не являются критическими.

С точки зрения конечного пользователя это означает: видео должно работать плавно, без перерывов и падений. Не имеет значения, начинается ли видео на несколько секунд раньше или позже.

«Загрузка» обычно требует максимально возможной пропускной способности сети, загрузка должна быть завершена как можно быстрее. Задержки, прерывания и дрожание не являются критическими.

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

Вернфрид Домшайт
источник
0

Чтобы добавить к другим ответам, мой ответ: не обязательно .

Теперь, предполагая, что все одинаково (без автоматического выбора качества, без регулирования с сервера и / или интернет-провайдера) ...

Пропускная способность обычно определяется как size_of_data, деленная на total_time. (Технически, «правильный» термин - пропускная способность , но я отвлекся).

Предположим, вы собираетесь транслировать 2000-секундное видео размером 60 МБ.

При потоковой передаче программа streamer может самостоятельно ограничивать скорость, чтобы предотвратить переполнение буфера. Таким образом, его заголовок HTTP-запроса может содержать поле Range . Эффективная пропускная способность , так как потоковые не начинается до тех пор , потоковые концов затем будет ~ 60 МБ / 2000 сек = 30 кб / с = 240 Кбита.

Тем не менее, если вы загрузите видео сразу, вы получите до максимальной пропускной способности Вашего Интернет. В зависимости от другого использования в то же время, конечно. Таким образом, предполагая, что интернет-сервис со скоростью 6 Мбит / с при 50% доступной пропускной способности, вы получите 3 Мбит / с для загрузки видео.

pepoluan
источник
0

Потоковая передача действительно является способом загрузки.

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

Как правило, когда вы загружаете файл, вы ждете окончания загрузки и только потом начинаете смотреть его. Но есть медиаплееры, которые могут показать вам загруженную часть файла, автоматически сделать паузу и ждать, пока будет загружена еще какая-то часть. Вроде как потоковое, но без удаления файла.

Технически, когда речь идет об общем объеме передаваемых данных, не имеет значения, как вы их загружаете, а разница между файлом, который вы загружаете, и файлом, который ваш медиаплеер загружает для вас в виде потока. Это могут быть одни и те же файлы, и это будет означать одинаковую пропускную способность в обоих случаях.

Потоковые медиа-сайты обычно кодируют свой контент, чтобы иметь более низкую скорость передачи данных, чем купленный в магазине диск. Но вы можете смотреть фильм со своего настольного ПК на ноутбуке через Wi-Fi, используя функцию обмена файлами в вашей ОС, и он будет занимать почти такой же объем трафика, как если бы вы смотрели его на рабочем столе (как чтение байтов с жесткого диска). водить машину). Технически это будет потоковая передача, когда вы смотрите фильм, а его части постоянно загружаются и удаляются.

Таким образом, ответ заключается в том, что это абсолютно зависит от размера двух файлов - передаваемых через медиаплеер и загружаемых на диск.

user1306322
источник
0

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

Поэтому я думаю, что ответ заключается в том, что он может использовать ту же сумму ... или меньше ... или больше. в зависимости от серверов и скорости их обслуживания.

MinusFour
источник
-2

Да, это эквивалент. Загрузить = Вы загружаете его только один раз, и он остается на вашем компьютере. Stream = Вы временно загружаете «что-то» на свой компьютер.

Тьяго Рибейро
источник
Существует разница между объемом передаваемых данных и используемой полосой пропускания.
Йонас Шефер
ну на моем андроиде смотрю видео из потока или скачиваю у него такое же использование данных
Тиаго Рибейро
@JonasWielicki Один мудрец однажды сказал: «Количество передаваемых данных одинаково». Конечно, величина используемой полосы пропускания варьируется, поскольку из-за буферизации скорость передачи со временем снижается.
Ненотлеп
1
Это действительно правильный ответ во многих случаях. Часто во многих случаях один и тот же ресурс и протокол используются для потоковой передачи и загрузки. Если вы хотите воспроизвести ресурс по HTTP, это ничем не отличается от его загрузки, кроме того, что вы воспроизводите его во время загрузки. Конечно, есть оптимизация для потоковой передачи и различные протоколы, которые могут изменить ваш битрейт во время потоковой передачи, но я не думаю, что это основа задаваемого вопроса. (Тем не менее, они заслуживают упоминания.)
Брэд,