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

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

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

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

Потоковые провайдеры используют протоколы, такие как 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. Я знаю, что это своего рода анектодальные доказательства - однако я наблюдал это поведение последовательно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 может использовать кодирование передачи по частям для загрузки всего файла с минимальными издержками. Потоковая загрузка должна согласовывать порцию и качество порции для передачи. В общей схеме издержки протокола передачи относительно незначительны.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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