Как серверы и клиенты Shoutcast имеют дело с заголовками фреймов и зависимостями фреймов?

Question

Краткая история:

Если я сам намерен получить, а затем отправить Shoutcast совместимый звуковой поток, обработанный моим приложением, то, как сделать это правильно, используя mp3 (DE/EN) кодер библиотеки? Псевдокод, или лучше - хромовый mp3-код, будет высоко оценен.

Длинная история:

Более конкретные вопросы, которые беспокоят меня были вызваны article about mp3, который говорит:

Как правило, кадры являются независимыми элементами. Каждый кадр имеет свой собственный заголовок и аудиоинформацию. Нет заголовка файла. Поэтому вы можете вырезать любую часть файла MPEG и правильно воспроизвести (это должно быть сделано на границах кадра, но большинство приложений будут обрабатывать неправильные заголовки ). Для уровня III это не на 100% правильно. Из-за внутренней организации данных в файлах третьего уровня MPEG версии 1 кадры часто зависят друг от друга, и их нельзя обрезать точно так же.

Это заставило меня задуматься, как серверы и клиенты Shoutcast имеют дело с заголовками фреймов и зависимостями кадров.

Должен ли я кодировать только постоянный битрейт (CBR), если я хочу достичь максимальной совместимости с большинством игроков Shoutcast?

Является ли заголовок mp3-фрейма, используемый вообще или формат потока, выводится из определенного HTTP-заголовка протокола Shoutcast?

Гарантирует ли протокол Shoutcast (или распространенная практика), чтобы начать подавать mp3-поток на границах кадра и продолжать отвечать кусками, которые разрезаются на границах кадров? Но каков минимальный или рекомендуемый размер mp3-фрейма для потоковой передачи живого звука?

Как Shoutcast справляется с зависимостями кадров - делает ли он что-то особенное с кодировкой mp3, чтобы гарантировать, что обслуживаемый поток не имеет фреймов, которые зависят от предыдущих кадров (если это даже возможно)? Или, возможно, он игнорирует эти зависимости на стороне сервера/клиента, тем самым уменьшая качество звука или даже артефакты?

Answer 1

Серверы SHOUTcast не знают и не заботятся о передаваемых через них данных. Они отправляют его как есть. Фактически вы можете отправлять произвольные данные через сервер SHOUTcast и получать его. SHOUTcast будет сегментировать данные мультимедиа везде, где размер буфера падает.

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

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