предполагая, что контент имеет такое же качество (при прочих равных условиях), использует ли потоковый медиа (т. е. видео, аудио) тот же объем пропускной способности, что и загрузка?
скажем, я должен был скачать фильм HD от Amazon или поток его, было бы эквивалентное использование пропускной способности?
2458
это часто не эквивалентны.
поставщики потоковой передачи используют протоколы, такие как тире, динамически регулировать качество фильма к наличию ширины полосы частот потребителей и желаниям качества. Затем серверы могут ограничить скорость вашего соединения, чтобы вы могли буферизировать определенное количество (что-то вроде 10 секунд, может быть, 30 или целую минуту), а затем вы получаете только объем пропускной способности, необходимый для получения контента вам в режиме реального времени. Это очевидное оптимизация с точки зрения провайдера, потому что она распределяет пропускную способность более равномерно среди пользователей и, кроме того, избегает передачи данных напрасно (например, когда пользователь смотрит фильм 480p в течение 10 минут, без ratelimiting и с общей нисходящей ссылкой, вполне вероятно, что гораздо больше, чем это уже загружено, но затем впустую, если пользователи перестают смотреть видео).
в размере data передано то же самое. Но это может занять больше времени потоковая передача, поскольку поставщик может ограничить скорость передачи данных скоростью, необходимой для доставки контента в заданном качестве в режиме реального времени.
Dailymotion является одним из провайдеров, которые ограничивают скорость соединения. С сервера с симметричным подключением не менее 100 Мбит/с мы видим следующее поведение1:
Kompyoutube-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
скорость намного ниже того, что было бы возможно (и достигается с другими поставщиками). Кроме того, если вы попробуете другой материал, вы обнаружите, что скорость сильно зависит от отдельного видео: видео fullhd легко загружается с > 1 Мб / с, в то время как музыкальное видео, такое как это, остается вокруг или ниже 200 Кб/с.
чтобы подвести итог и прояснить некоторые возможные недоразумения: некоторые провайдеры могут ограничить загрузку во время потоковой передачи, через свое клиентское приложение (например, youtube с их HTML5 или flash video player) или с помощью серверных средств. Если они не ограничивают скорость вас серверными средствами, то загрузка будет потреблять больше пропускной способности, потому что ограничение скорости, которое возможно применено клиентским приложением во время потоковой передачи, не имеет места. Это основной случай, когда потребляемая пропускная способность отличается по отношению к исходному вопросу.
предполагая, что мы говорим о том же качестве (т. е. без дросселирования, пропуска кадров или потоков более низкого качества), то в лучшем случае потоки будут принимать ту же пропускную способность, что и загрузка, хотя это может быть сделано за раз/скорость, более удобную для поставщика. Это может также занять больше пропускной способности в зависимости от того, как видео сжимается - большую часть времени все изображение не отправляется, а только изменение (или дельта) между кадрами. Это означает, что больше истории есть (т. е. используйте этот оттенок синего от пикселя X в кадре Y), тем меньше там должно быть отправлено. Это обычно не появляется много, но когда поток приостановлен / прерван по какой-либо причине, эта "история" теряется и должна быть повторно передана, таким образом увеличивая пропускную способность, в то время как с загрузкой, это может быть возобновлено в "перерыве", и предположил, что получатель уже имеет эту информацию. То же самое можно использовать для аудио, особенно там, где нет фиксированной скорости (например, FLAC вместо mp3)
прыгать вокруг (прыгать, перемотки и т. д.) может также повлиять на использование-переход за пределы буфера уменьшит пропускную способность, используемую потоком, но любая повторная намотка увеличит ее. Также будет прерывание, которое вызовет увеличение использования (см. выше), и любой вид "предварительного просмотра миниатюр", например, использование youtube и netflix, также немного увеличит пропускную способность.
последнее примечание: сжатие: это может быть сделано для загрузки, но не так много для потоков-предостережение в том, что большинство видео уже сжаты, поэтому здесь не будет много достигнуто (хотя в отделе сверхвысокого разрешения/качества может быть место для увеличения).
потоковая передача будет использовать меньшую пропускную способность, особенно если условия сети плохие, но это происходит по цене.
речь идет о данных, которые должны быть отправлены. в модели загрузки, все данные должны достичь клиента, все в правильном порядке, независимо от того, что. Если сетевые условия плохи,и некоторые биты данных не достигают клиента, они должны быть повторно отправлены, и это увеличивает использование пропускной способности. Если какие-то данные попадут туда не по порядку, их нужно будет поставить в порядок перед представлением, а это снижает оперативность.
в потоковой модели это нормально, если некоторые данные не доходят до клиента. Если вы транслируете фильм, а кадр не попадает туда, вы можете просто пропустить его и двигаться дальше, поэтому вы не используете дополнительную пропускную способность при повторной отправке. Если некоторые кадры выходят из строя, просто воспроизводите те, которые идут вперед; мгновенный всплеск не будет иметь значения, и поэтому это увеличивает отзывчивость. Однако, это также означает, что вы не обязательно получаете полные данные: все, что вы видите, - это то, что получилось на первом снимке.
Если вам нужно выбрать между моделями, выберите на основе того, что вы хотите сделать с данными. Если вы хотите, чтобы архивировать его и / или, возможно, просмотреть его много раз, а затем загрузить его так, что вы уверены, чтобы получить все. Если вы не планируете архивировать или планируете просматривать данные только один раз, продолжайте потоковую передачу; вы, вероятно, не заметите разницы ни на одном просмотр, и если сетевые условия достаточно плохи, что вы заметили, то загрузка будет еще хуже.
Если вы действительно спрашиваете "пропускную способность" (байт / сек), а не "общие данные" (байт), решающий вопрос: в течение какого периода времени? Если мы предполагаем, что пользователь просмотрел все видео, и что тот же кодек/качество и т. д. возвращается и игнорирует небольшие издержки потокового запроса / ответов, тогда общие возвращенные данные равны.
какова пропускная способность? Есть два способа понять ваш вопрос:
пропускная способность в течение времени, необходимого для завершения загрузки. для потоковой передачи вы должны увидеть всплески высокой пропускной способности (когда запрашивается следующий кусок), которые возвращаются к нулю, пока вы смотрите этот кусок, пока вы не приблизитесь к концу блока, и снова произойдет всплеск пропускной способности. Для загрузки вы должны увидеть очень высокую пропускную способность, скажем, 10 минут, которая опускается до нуля, как только загружается все видео. Если вы остановите эксперимент сейчас, очевидно, что пропускная способность для загрузки выше, так как это искажает вашу нисходящую ссылку, пока это не будет сделано.
пропускная способность во время просмотра видео. время просмотра видео одинаково как для потоковой передачи, так и для загрузки, предполагая, что оба сразу начинают смотреть. Общий размер данных также одинаков. Поскольку пропускная способность-это данные за раз, она одинакова для обоих сценариев.
в приведенном ниже примере, всегда есть в общей сложности 40 (единиц данных) загружаемый. Но для " загрузки "это 40 в первой единице времени, в то время как для" потоковой передачи " это 20 в течение первых единиц времени (чтобы получить большой начальный кусок), а затем дважды 10 для двух дополнительных кусков. Обратите внимание, что в то время как пропускная способность отображается на оси y, область под каждым из двух графиков соответствует данным (байтам) - если вы интеграция байт/время, вы получите байт.
они несопоставимы.
во-первых, оптимальная кодировка для локального просмотра отличается от кодировки optima для потокового просмотра.
поговорим о кодировании видео.
в большинстве форматов кодирования видео обычно существует два типа кадров:
кодирование для локального просмотра можно воспользоваться быстрый диск стремится сделать использование в то время как видео, закодированное для эффективной потоковой передачи, должно будет кодировать более избыточный I-кадр вдоль всего видео, даже если нет никаких внезапных переходов для размещения случайного поиска.
кроме того, существует два разных типа потоковой передачи. Вы можете иметь потоковую передачу предварительно записанного потока (большинство видео Youtube) и живых потоков событий (например, Youtube Live). Из-за необходимости задержки потоковое живое событие не может воспользоваться преимуществами передовых методов кодирования, которые долгое и непредсказуемое время, в то время как предварительно записанный поток может занять столько времени, сколько он должен кодировать.
потоковое видео также обычно кодируется с постоянной скоростью передачи (CBR). Для того же целевого размера видео с переменной скоростью передачи (VBR) обычно будет иметь более высокое качество, чем видео CBR. Наоборот, видео VBR меньше для того же качества видео CBR. Адаптивный протокол потоковой передачи как DASH имеет адаптивный битрейт (ABR), который является компромиссом между CBR и VBR. ABR позволяет телезрителю приспособиться к изменениям в ширине полосы частот сети. Учитывая постоянную, последовательную пропускную способность, ABR более или менее совпадает с CBR.
что все это означает, что учитывая то же качество и опыт просмотра, вы можете кодировать видео для локального просмотра более эффективно, чем потоковое видео, и вы можете кодировать видео для предварительно записанных потоков более эффективно, чем живые потоки.
тогда есть также накладные расходы в потоковом протоколе. Один обычная загрузка HTTP может использовать фрагментированную кодировку передачи для загрузки всего файла, который имеет очень минимальные издержки. Потоковая загрузка должна согласовывать фрагмент и качество передаваемого фрагмента. В большой схеме вещей издержки протокола передачи относительно незначительны.
в целом, для того же количества просмотренного видео, потоковое видео должно в конечном итоге занять большее количество пропускной способности. Основным преимуществом потоковой передачи с точки зрения использования полосы пропускания является что он может спасти людей, которые скачивают, но не смотрят видео в полном объеме, что может быть очень значительной экономией.
ответ "Это зависит".
ответ нет, для провайдеров, которые размещают видео в целом. Половина достойных провайдеров, которые транслируют видео, контролируют скорость, чтобы обеспечить плавное воспроизведение и оптимальную пропускную способность для как можно большего количества людей. Таким образом, несмотря на то, что у вас может быть много пропускной способности, он может решить дать вам только 5 мбит и выглядеть по-прежнему вполне прилично.
Если вы делаете загрузку HTTP, то алгоритмы управления скоростью TCP будет удар, чтобы убедиться, что вы насытить один или оба конца соединения или что-нибудь между ними. Поэтому, если у вас было 100 Мбит, он будет использовать все, что может получить или около 100 Мбит.
Это, конечно, предполагает, что нет QoS происходит где-нибудь между клиентом и сервером.
Ваш вопрос настолько свободен, что я мог бы также сделать это так, что в некоторых наивных настройках ответ тоже да (с допущениями), полосы идентичны. Для этого просто перетащите файл на ваш основной веб-сервер и откройте его с браузер, так что зритель пинает В. Или встроить видео на ваш основной веб-сервер и снова, он будет играть в браузере и использовать одинаковую пропускную способность со следующим предположением... другие пользователи, никто другой сети с вами... никаких других факторов, которые могут изменить вашу полосу пропускания.
имейте в виду, что при загрузке файла с веб-сайта, а затем загрузить его снова пропускная способность между первой и второй загрузки может варьироваться. Это просто потому, что нагрузка на сервер может измениться, и перегрузка в сети и сетевые пути могут измениться.
Так что у вас есть... это зависит от.
с точки зрения сети "загрузка" и "потоковая передача" - это разные сервисы, это называется "профиль трафика"
для потокового сервиса сеть должна обеспечивать минимальную постоянную пропускную способность (технически "пропускная способность" означает что-то другое), потоковый сервис чувствителен к прерываниям и дрожанию. Он не требует максимальной пропускной способности сети, задержки или задержки не критичен.
с точки зрения конечного пользователя это означает: видео должно работать гладко без interrupptions или капель. Это не имеет значения, если видео начинается на несколько секунд раньше или позже.
"загрузка" обычно требует максимальной пропускной способности сети, загрузка должна быть завершена как можно быстрее. Задержки, перерывы и дрожание не критические.
сеть может предоставлять больше профилей трафика, которые полностью отличаются. Например голосовые услуги (простой телефонный звонок) requrie очень низкая пропускная способность, но очень чувствительны для задержек (менее 200 мс)
чтобы добавить к другим ответам, мой ответ:Не обязательно.
теперь, предполагая, что все равно (без автоматического выбора качества, без регулирования с сервера и / или ISP)...
ширина полосы обычно определяется как size_of_data, деленное на total_time. (Технически, "правильный" термин производительность, но я отвлекся).
предположим, вы собираетесь транслировать 2000-секундное видео размером 60 МБ.
с streaming, программа стример может сделайте свое собственное ограничение скорости, чтобы предотвратить переполнение буфера. Таким образом, заголовок HTTP-запроса может включать поле диапазона. The эффективное пропускная способность с начала потоковой передачи до окончания потоковой передачи будет составлять ~ 60 МБ / 2000 секунд = 30 кб / с = 240 Кбит / с.
однако, если вы скачаете видео прямо, вы получите до максимальная пропускная способность вашего интернет-сервиса. В зависимости от использования в в то же время, конечно. Таким образом, предполагая, что интернет-сервис 6 Мбит / с, с 50% доступной пропускной способностью, вы получите пропускную способность 3 Мбит / с для загрузки видео.
потоковое действительно способ загрузки.
когда вы смотрите потоковое видео, медиа-плеер будет загружать его части, показать их вам, и выбросьте показаны фрагменты файла на лету.
Как правило, когда вы загружаете файл, вы ждете завершения загрузки, и только после этого начинаете его просмотр. Но есть медиа-плееры, которые способны показывать Вам загруженную часть файла и автоматически приостанавливать и ждать загрузки еще. Вроде потоковой передачи, но без отбрасывания файла.
технически, когда речь идет об общем объеме передаваемых данных, не имеет значения, как вы их загружаете, но разница между файлом, который вы загружаете, и файлом, который ваш медиаплеер загружает для вас как поток. Это могут быть одни и те же файлы, и в обоих случаях это будет означать одинаковую пропускную способность.
потоковые медиа-сайты обычно кодируют свой контент с более низким битрейтом, чем купленный в магазине диск. Но вы можете смотреть фильм с настольного компьютера на ноутбуке через Wi-Fi, используя функцию обмена файлами вашей ОС, и он будет занимать почти столько же трафика, как если бы вы смотрели его на рабочем столе (как читать байты с жесткого диска). Технически это будет течь, как вы смотрите фильмы в частях он постоянно загружен и выбросить.
Так что ответ это абсолютно зависит от размера двух файлов пройдя через медиа-плеер и загружается на диск.
потоковая передача использует пропускную способность загрузки, поэтому вы можете рассматривать ее как загрузку. Ваш вопрос немного неоднозначен относительно того, что вы считаете загрузкой. Вы можете загрузить столько, сколько они могут и готовы предложить. Поэтому, в конце концов, если вы хотите сравнить прямую загрузку с HTTP через DASH (все еще HTTP), например, вам нужно будет проверить, сколько загрузки вы делаете с каждого.
поэтому я думаю, что ответ заключается в том, что он может использовать ту же сумму... или менее... или более. в зависимости от серверов и скорости они служат вам.
Да, это эквивалент. Скачать= вы загружаете его только один раз, и он остается на вашем компьютере. Stream= вы временно загружаете "что-то" на свой компьютер.
 |  |  |  |  |  |  |  |  |  |
Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]
