Icecast поток повторяется после перерывов на мобильных устройствах

Question

Запуск Icecast 2.4.4 в Ubuntu 16.04 с рабочим источником, смонтированным со стандартного входа звуковой карты Darkice.С момента включения вступления на горе в нашей соответствующей конфигурации ниже, мы получаем отчеты о повторении потока после прерывания на мобильных устройствах, таких как Android или iPhone:

<limits>
    <clients>3000</clients>
    <sources>10</sources>
    <queue-size>524288</queue-size>
    <client-timeout>30</client-timeout>
    <header-timeout>15</header-timeout>
    <source-timeout>10</source-timeout>
    <!-- If enabled, this will provide a burst of data when a client
         first connects, thereby significantly reducing the startup
         time for listeners that do substantial buffering. However,
         it also significantly increases latency between the source
         client and listening client.  For low-latency setups, you
         might want to disable this. -->
    <burst-on-connect>1</burst-on-connect>
    <!-- same as burst-on-connect, but this allows for being more
         specific on how much to burst. Most people won't need to
         change from the default 64k. Applies to all mountpoints  -->
    <burst-size>943718</burst-size>
</limits>
<http-headers>
    <header name="Access-Control-Allow-Origin" value="*" />
</http-headers>
<mount>
    <mount-name>/wmnf_high_quality</mount-name>
    <max-listeners>3000</max-listeners>
    <intro>/wmnf_high_quality.mp3</intro>
</mount>

Мне не удалось скопироватьпроблема на моем Samsung Galaxy s5, когда поступает звонок или текст, поток поднимается с того места, на котором остановился, когда завершается звонок или уведомление заканчивается.Вступление повторяется, как и должно, после отключения / повторного подключения, вызванного прерыванием, но мой поток все еще жив после этого.В сообщениях говорится, что поток повторяется в последние 5-10 минут после прерывания, они могут нажать на кнопку паузы / воспроизведения, чтобы снова получить живой звук в нашем приложении.

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

Я жду отзывов, чтобы узнать, происходит ли это при прослушивании проигрывателя нашего веб-сайта на мобильном устройстве.Отчеты пока от нашего приложения для Android / iPhone.Я не разрабатывал приложение, поэтому я не уверен в плеере.Я также попросил их попробовать поток, доступный в приложении TuneIn.Опять же, я не могу дублировать себя.

Answer 1

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

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

Вторая проблема заключается в том, что у вас чрезвычайно большой размер пакета.Большинству игроков требуется две секунды буферизованных аудиоданных, чтобы начать воспроизведение.Игрокам также нравится видеть некоторый непротиворечивый звук перед началом воспроизведения, чтобы слушателю не пришлось терпеть второй раунд буферизации позже.Поэтому я обычно рекомендую от 5 до 10 секунд размера пакета.В вашем случае при 128 КБ 10 секунд буфера составляют 256 КБ.Ваш текущий размер пакета составляет почти минуту.Этот большой буфер обычно не сбрасывается на клиент так быстро, как вы хотели бы.Причина в том, что приложение проигрывателя будет обеспечивать некоторое противодавление, что приведет к более низкому окну TCP, что означает, что сервер может только выдвинуть так много буфера, прежде чем сервер должен буферизоваться на своем конце.

Я сделал несколькобыстрое тестирование с Wireshark на вашем потоке /wmnf_high_quality:

Есть две строки: отправленные байты и размер окна TCP.Они в основном следуют друг за другом.В самом начале соединения окно широко открыто, и сервер начинает сбрасывать этот пакетный буфер клиенту.Однако в течение 1 секунды это окно полностью закрывается.Это не так, пока игрок не сможет немного пройти через свой начальный буфер, прежде чем он снова откроется.Сервер сбрасывает больше этого большого буфера, и окно снова закрывается.В конце концов мы достигли стабильного воспроизведения, и вы можете увидеть, как появляется этот паттерн spikey.То, что здесь происходит, это то, что у игрока есть много буферизованных данных на его конце, и он будет принимать только поток данных с сервера.Сервер отправляет все, что может, но размер окна снова уменьшается до ~ 1 КБ.

В этом примере в любой момент времени во время стабильного воспроизведения у нас есть клиент, который, вероятно, имеет около 256 КБ - 512 КБ буферизованногоданные и сервер с общим объемом доступного буфера около 1 МБ, медленно передавая клиенту медленный поток из середины этого буфера.Это должно продемонстрировать, что пакетный буфер слишком велик, так как он не может быть использован клиентами достаточно быстро.

Теперь проблема смешивания, которая может вызывать разъединение ... размер очереди.Icecast не поддерживает отдельный буфер в памяти для каждого отдельного клиента.У него есть один буфер, из которого он читает.Значение <queue-size> устанавливает размер этого буфера.Если клиенты слишком далеко отстают, их связь будет разорвана.Недостаток настройки большего queue-size невелик.Память на сервере фактически свободна для тех размеров, о которых мы говорим, поэтому все сводится к тому, чтобы позволить пользователям проскользнуть через посредственное соединение или просто отключить их полностью.Однако ваш случай немного отличается ...

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

Я бы порекомендовал следующее:

• Установите burst-size на 252144 (128 кбит * 8 бит на байт * 1024 байта на килобайт * 10 секунд = 256 КБ)
• Установите queue-size на 4xburst-size.
• Удалить вступительный файл.Играйте вступление через код на вашем сайте, а не в самом потоке.