1

Я просто слушал Spotify, и мое интернет-соединение оборвалось. Хотя я не был удивлен, что он все еще закончил песню (из-за буферизации), я был удивлен, когда она перешла к следующей и продолжала играть в течение нескольких минут (а затем я вернул интернет).

Как долго Spotify может продолжать играть после потери соединения? Предположим, что никакие файлы не "включены в автономном режиме".

1 ответ1

2

Задача может быть сложнее для анализа, чем просто "время его"

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

Что касается размера буфера в любой момент времени - он автоматически настраивается и может варьироваться от 15 до целой песни, в зависимости от источника, партнера или сервера [см. Ниже]

Я включил эти статьи только для дальнейшего прочтения - слишком много, чтобы привести их здесь, но дать достаточно упрощенные объяснения.
Spotify For Dummies имеет хорошую статью о кеше и о том, как настроить его размер
Технология Spotify: как Spotify Works имеет некоторую простую информацию о том, как работает технология потоковой передачи.

Я нашел авторитетный документ по этому вопросу, написанный Гуннаром Крейцем и Фредриком Нимеля ...
Spotify - большой масштаб, низкая задержка, потоковая передача музыки по запросу P2P

Выдержка:

Данный трек может быть одновременно загружен с сервера и нескольких разных пиров. Если одноранговый узел слишком медленно удовлетворяет запрос, запрос повторно отправляется другому одноранговому узлу или, если получение данных стало слишком срочным, серверу.
Во время потоковой передачи с сервера клиенты ограничивают свои запросы так, что они не получают более чем приблизительно 15 секунд опережающей текущей точки воспроизведения, если для дорожки доступны одноранговые узлы. При загрузке из одноранговой сети такое регулирование не происходит, и клиент пытается загрузить всю воспроизводимую в данный момент дорожку. Если пользователь меняет дорожки, запросы, относящиеся к текущей дорожке, прерываются.
Файлы, обслуживаемые в одноранговой сети, разбиваются на куски размером 16 КБ. При определении того, от каких узлов запрашивать чаны, клиент сортирует одноранговые узлы по их ожидаемому времени загрузки (вычисленному как число байтов ожидающих запросов от узла, разделенное на среднюю скорость загрузки, полученную от этого однорангового узла) и жадно запрашивает самый срочный чанк. от однорангового узла с наименьшим предполагаемым временем загрузки (а затем обновляет ожидаемое время загрузки). Это означает, что порции трека запрашиваются в последовательном порядке. Поскольку все одноранговые узлы, обслуживающие файл, имеют весь файл, запрос блоков по порядку не влияет на доступность или скорость загрузки.
Клиент может получить не более ожидающих запросов от данного однорангового узла о данных, которые, по его мнению, может доставить одноранговый узел за 2 секунды. Исключением является то, что всегда разрешено получать запросы на 32 кБ ожидающих от однорангового узла. Если расчетное время загрузки для блока превышает момент времени, в который требуется блок, этот блок не запрашивается.

...

Клиенты Spotify не ограничивают размер буфера, и, следовательно, суть проблемы заключается в соответствующем моделировании канала и использовании этой информации для настройки начальной задержки воспроизведения. В качестве упрощения клиент рассматривает только канал к серверу для регулировки задержки.
Клиенты Spotify используют марковскую модель пропускной способности, наблюдаемую клиентом (т. Е. Подверженную изменению запаздывающей задержки, потере пакетов и управлению перегрузкой TCP). Клиенты наблюдают за пропускной способностью, достигнутой во время загрузки с сервера, для оценки цепочки Маркова. Сохраняются и используются только данные, собранные за последние 15 минут загрузки. Состояния цепи Маркова - это пропускная способность в течение 1 секунды, дискретизированная до 33 различных уровней от 0 до 153 кБ / с (более детализированная при более низких пропускных способностях).
Модель не используется для вычисления явной задержки воспроизведения. Вместо этого до начала воспроизведения клиент периодически использует цепочку Маркова для имитации воспроизведения дорожки, начиная с текущего объема буферизованных данных и текущей пропускной способности данных. Каждое такое моделирование считается неудачным или проходящим, в зависимости от того, произошло ли опустошение или нет. Клиент выполняет 100 симуляций, и если более одного из них дает сбой, он ждет дольше, прежде чем начать воспроизведение. Во время этих симуляций клиент делает упрощенное предположение, что данные потребляются с постоянной скоростью, несмотря на тот факт, что используемый кодек имеет кодирование с переменным битрейтом.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .