Каков наилучший протокол для потокового аудио (радио) для мобильных и веб-устройств?

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

Я искал неделю и сделал прототип с движком Wowza (используя HLS и RTMP) и сервером SHOUTcast на Amazon EC2.

использование HLS имеет задержку в 5 секунд, но RTMP и SHOUTcast имеют 2-секундную задержку. С таким результатом, я думаю, я должен выберите RTMP или SHOUTcast.

но я не уверен, что RTMP и SHOUTcast-лучший протокол. :(

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

3 ответов


Это очень широкий вопрос. Начнем с протокола распространения.

Протокол Потоковой Передачи

HLS имеет то преимущество, что позволяет пользователям получать поток в битрейте, который лучше всего подходит для их подключения. Клиенты могут масштабировать вверх/вниз без остановки воспроизведения. Это особенно важно для видео, но для аудио даже мобильные клиенты способны воспроизводить потоки 128kbit в большинстве областей. Если вы намерены иметь различные bitrates доступны и хотите изменить качество в середине потока, тогда HLS-хороший протокол для вас.

недостатком HLS является совместимость. iOS поддерживает его, но это все. Android имеет поддержку HLS, но он по-прежнему глючит. (Возможно, через год или два, когда все люди Android 3.0 уйдут, это не будет такой большой проблемой.) JWPlayer имеет некоторые хаки, чтобы заставить HLS работать во Flash для настольных пользователей.

Я бы не беспокоился о RTMP, если вы не обеспокоены только вспышкой пользователи.

чистая прогрессивная потоковая передача с HTTP-это маршрут, который я почти всегда выбираю. все может играть. (Даже медиаплеер по умолчанию моего Palm Pilot от 12 лет назад.) Это просто реализовать и хорошо понять.

SHOUTcast эффективно HTTP, но плохо реализованная версия, которая имеет проблемы совместимости, особенно на мобильных устройствах. Он имеет нестандартную строку состояния в своем ответе, которая ломает много клиентов. Для icecast является хорошая альтернатива, и это то, что я бы рекомендовал для использования в производстве сегодня. В качестве другого варианта я создал свой собственный потоковый сервис под названием AudioPump, который также является HTTP, и был специально построен для исправления совместимости с мобильными клиентами oddball, такими как родные Android-плееры на старом оборудовании. Он еще не доступен, но вы можете связаться со мной по адресу brad@audiopump.co если хочешь попробовать.

задержка

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

Если вам требуется низкая латентность, вы смотрите на неправильную технологию полностью. Для низкой задержки проверьте Технологии WebRTC.

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

кодек

выбор кодека-это то, что будет диктовать вашу совместимость больше, чем что-либо еще. MP3 легко наиболее совместим, и AAC не далеко позади. Если вы идете с AAC, вы получаете лучшее качество звука для данного битрейта. Большинство людей используют это, чтобы уменьшить свой счет за пропускную способность.

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

другие кодеки включают Vorbis и Opus. Если вы можете использовать Opus, сделайте это, поскольку лицензирование широко открыто, и вы получите хорошее качество для полосы пропускания. Хотя совместимость здесь клиент убийцу опус. (Может быть, через несколько лет будет лучше.) Vorbis-посредственный кодек, но свободный и понятный.

на крайний конец, у меня есть несколько станций, делающих их потоковое в FLAC. Это качество звука без потерь, но вы платите за 8X пропускную способность, как и со станцией MP3 среднего качества. FLAC по потоковой совместимости HTTP не является кодом на данный момент, но он хорошо работает в VLC.

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

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

запись из браузера

вы упомянули пользователей потоковой передачи из браузера. Я построил что-то вроде этого пару лет назад с помощью Web Audio API, где звук захватывается, а затем кодируется и отправляется на серверы Icecast/SHOUTcast. Проверьте это здесь: http://demo.audiopump.co:3000/ краткое объяснение того, как это работает здесь:https://stackoverflow.com/a/20850467/362536

в любом случае, я надеюсь, это поможет вам начать работу.


Streaming straight audio/mpeg (mp3-пакеты) работал везде, где я пробовал.


Если вы разрабатываете приложение, то идите с AAC, если вы просто играете через веб-браузер, то вам нужен HTML5 Имплиментация, которая является MP3. Все пользовательские протоколы, такие как RTMP или SHOUTcast, требуют создания дополнительного пользовательского интерфейса. Есть некоторые сторонние игроки, доступные в мире с открытым исходным кодом. Вы можете использовать их или придерживаться HTML5 MP3/OGG, поскольку большинство людей теперь используют браузер chrome или другие браузеры жалоб HTML5.