Icecast2: буферы точки монтирования при воспроизведении в браузере долгое время

Question

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

<icecast>
  <location>Earth</location>
  <admin>[e-mail]</admin>
  <limits>
    <clients>200</clients>
    <sources>3</sources>
    <threadpool>5</threadpool>
    <queue-size>524288</queue-size>
    <client-timeout>20</client-timeout>
    <header-timeout>15</header-timeout>
    <source-timeout>60</source-timeout>
            <burst-on-connect>0</burst-on-connect>
            <burst-size>65535</burst-size>
  </limits>

  <authentication>
            <source-password>hackme</source-password>
            <relay-password>hackme</relay-password>
            <admin-user>admin</admin-user>
    <admin-password>hackme</admin-password>
  </authentication>

      <!-- {%comment-open-if:icecast.directory.yp-url==""%} -->
  <directory>
    <yp-url-timeout>15</yp-url-timeout>
    <yp-url>http://yp.shoutcast.com</yp-url>
  </directory>
  <directory>
        <yp-url-timeout>15</yp-url-timeout>
        <yp-url>http://www.oddsock.org/cgi-bin/yp-cgi</yp-url>
    </directory>
   <directory>
        <yp-url-timeout>15</yp-url-timeout>
    <yp-url>http://dir.xiph.org/cgi-bin/yp-cgi</yp-url>
  </directory>
  <!-- {%comment-close-if:icecast.directory.yp-url==""%} -->

      <hostname>test.test</hostname>
      <port>8008</port>
  <bind-address>1.1.1.1</bind-address>

  <!-- Only define a <mount> section if you want to use advanced options,
         like alternative usernames or passwords -->
      <mount>
    <bitrate>128</bitrate>
    <mount-name>/mp3</mount-name>
    <fallback-override>0</fallback-override>
    <fallback-when-full>0</fallback-when-full>
    <public>1</public>
    <max-listeners>150</max-listeners>
    <fallback-mount></fallback-mount>
    <genre>alternative</genre>
    <type>audio/mpeg</type>
  </mount>

  <mount>
    <bitrate>64</bitrate>
    <mount-name>/mobile</mount-name>
    <fallback-override>0</fallback-override>
    <fallback-when-full>0</fallback-when-full>
    <public>1</public>
    <max-listeners>50</max-listeners>
    <fallback-mount></fallback-mount>
  </mount>

  <fileserve>1</fileserver>

      <paths>
            <basedir>/usr/local/centovacast/var/vhosts/tester/</basedir>
            <logdir>var/log/</logdir>
    <webroot>web/</webroot>
    <adminroot>admin/</adminroot>
    <pidfile>var/run/server.pid</pidfile>
            <alias source="/" dest="/status.xsl"></alias>
  </paths>

  <logging>
    <accesslog>access.log</accesslog>
    <errorlog>error.log</errorlog>
    <playlistlog>playlist.log</playlistlog>
    <loglevel>2</loglevel>
    <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
      </logging>

  <security>
    <chroot>0</chroot>
      </security>

</icecast>

Answer 1

Попробуйте увеличить размер очереди и размер пакета:

<queue-size>1048576</queue-size>
<burst-size>943718</burst-size>

Я не могу объяснить это ясно, но вы можете следовать этой теме: https://www.internet-radio.com/community/threads/very-slow-buffering-in-android.20139/

Answer 2

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

Тем не менее, задержка минуты очень долго. Была проблема с LAME (3.99.1, я думаю?), Который создавал потоки, с которыми Chrome было трудно синхронизироваться. Вы не упомянули, какой кодер вы используете, но если он использует LAME, попробуйте обновить или понизить версию. Если вы используете что-то еще, попробуйте переключиться на LAME. Кроме того, попробуйте другие браузеры, чтобы увидеть, если вы получаете эту проблему только в Chrome.

Прогрессивный MP3 по HTTP (такой же, как у вас) - наиболее распространенная форма интернет-радио, и он может работать просто отлично, если настроен правильно.