Декодирование HTTP Audio Stream из Icecast с минимальной задержкой

Question

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

Наивным решением было бы просто получить доступ к http://myhostname:8000/my_mountpoint для получения потока, но тег <audio> выполняет внутреннюю буферизацию перед воспроизведением и приводит к довольно высокой задержке.

Текущее решение: Я использовал ReadableStreams API для декодирования (используя decodeAudioData API Web Audio) и воспроизведения фрагментов данных путем маршрутизации декодированных данных в Audio Контекст назначения (внутренние колонки). Это работает и значительно снижает задержку.

Проблема: Этот потоковый API, хотя и экспериментальный, должен технически работать на последних версиях Chrome, Safari, Opera, FF (после установки определенного флага). Однако у меня проблемы с decodeAudioData во всех других браузерах, кроме Chrome и Opera. Я считаю, что FF и Safari не могут декодировать частичные данные MP3, потому что я обычно слышу короткую активацию динамиков, когда начинаю потоковую передачу. В Safari обратный вызов на успешном decodeAudioData никогда не вызывается, а FF просто говорит EncodingError: The given encoding is not supported.

Есть ли какие-нибудь обходные пути, если я хочу хотя бы заставить его работать на Safari и FF? Отличается ли реализация decodeAudioData в Chrome и Safari так, что одна работает с частичным MP3, а другая нет?

Answer 1

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

Есть несколько проблем с вашей настройкой, которые препятствуют минимально возможной задержке:

• HTTP Progressive (тип потоковой передачи, используемый Icecast и аналогичными), работает через TCP, надежный транспорт. Если пакет потерян, существует некоторая задержка во время его повторной передачи клиенту, прежде чем данные будут доставлены в браузер. Это гарантирует, что каждый бит звука будет слышен по порядку, но может вызвать задержку. Для низкой задержки обычно используются UDP-пакеты, так что любые потерянные пакеты можно просто пропустить, а не ждать, что вызовет сбой, но клиент удерживает задержку.

• MP3 не является отличным кодеком для малой задержки. Есть лучшие кодеки, такие как Opus, которые более эффективны и могут генерировать меньшие сегменты.

• Как вы видели, клиенты по умолчанию буферизуют больше при потоковой передаче по HTTP.

Однако в идеальных условиях я использовал потоковую передачу HTTP Progressive с задержкой менее 250 мс в Chrome и настраиваемом сервере. Могу поспорить, что вы могли бы получить аналогичную производительность из Icecast, если бы вы отключили буферизацию на стороне сервера и использовали другой кодек.

Однако у меня проблемы с decodeAudioData во всех других браузерах, кроме Chrome и Opera. Я считаю, что FF и Safari не могут декодировать частичные данные MP3

Да, decodeAudioData() предназначен для декодирования всего файла. Вам будет трудно декодировать произвольно сегментированные фрагменты с точностью до выборки.

К счастью, есть способ делать то, что вы хотите ... Расширения MediaSource.

https://developer.mozilla.org/en-US/docs/Web/API/Media_Source_Extensions_API

По сути, вы можете использовать тот же интерфейс ReadableStream и передать данные в SourceBuffer, чтобы в итоге воспроизвести обычный тег <audio>. Это работает с обычным звуком MP3 от Icecast и аналогичных серверов, если вы справились с любыми проблемами.

Answer 2

Как уже упоминалось @Brad, Opus отлично подходит для малой задержки. Я написал декодер WASM Opus с низкой задержкой, который можно использовать с Streams, и запустил еще одну демонстрацию, которая демонстрирует, как воспроизводить частичные файлы с помощью decodeAudioData():

• опус-поток-декодер готов к производству
• получить поток аудио это необслуживаемая демонстрация POC, которая должна указывать вам правильное направление.

Answer 3

Не используйте Icecast, если вам нужна задержка менее секунды!

Не используйте Icecast, если вам нужна задержка менее 10 секунд и вы не имеете полного контроля над всей цепочкой программного обеспечения и сети!

Да, это ответ, а не комментарий. Icecast не предназначен для таких случаев использования. Он был разработан для несинхронного массового вещания данных по протоколу HTTP.

То, что вы объясняете, звучит так, как будто вы действительно должны рассмотреть что-то, что было разработано с низкой задержкой, например web-RTC.

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