Форматы контейнера потокового аудио - PullRequest
2 голосов
/ 17 июля 2011

Когда я начинаю получать живой аудио (радио) поток (например, MP3 или AAC), я думаю, что полученные данные не являются видом необработанного битового потока (то есть выходного сигнала необработанного кодера), но они всегда заключаются в некоторый формат контейнера. Если это предположение верно, то, я думаю, я не могу начать потоковую передачу с произвольного места потока, но мне нужно подождать некоторый байт синхронизации. Это правильно? Обычно это иметь несколько байтов синхронизации? Есть ли заголовок после байта синхронизации, из которого я могу угадать используемый кодек, количество каналов, частоту дискретизации и т. Д .?

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

Некоторые потоки, такие как icecast, используют заголовки в ответе HTTP, где включена информация, относящаяся к потоку, но я думаю, что могу пропустить их и напрямую работать с форматом steam.

Это правильно?
С уважением,
Sten

Ответы [ 4 ]

3 голосов
/ 18 июля 2011

Doom9 имеет отличную стартовую информацию о форматах mpeg и aac frame.Shoutcast будет время от времени добавлять некоторые «метаданные», и это действительно тривиально.Я хочу поделиться с вами этим.У меня есть приложение, которое может захватывать все виды потоков, и среди них есть shoutcast, aac и mp3.В первых версиях файлы обрезались в произвольной точке в зависимости от времени, например каждые 5 минут, независимо от кадров mp3 / aac.Это как-то нормально для mp3 (файлы воспроизводились), но очень плохо для aacplus.

Дело в том, что декодер aacplus НЕ прощает неправильные данные, и у меня было все, от нарушений доступа до таинственныхЗавершение работы программного обеспечения без каких-либо ошибок.

В любом случае, если вы хотите захватить поток, открыть сокет для сервера, прочитать ответ, у вас будет какой-то заголовок, а затем использовать эту информацию для удаления метаданных.это будет введено сейчас и потом.Используйте информацию заголовка как для aacplus, так и для mp3, чтобы определить границы фреймов, и попробуйте их соблюдать и разделить файл в нужном месте.

заголовок mp3-кадра:

aacplus заголовок фрейма:

также это:

2 голосов
/ 17 июля 2011

Когда вы смотрите на SHOUTcast / Icecast, встречающиеся данные - это чистые аудиоданные MPEG Layer III, и ничего более.(При условии, что вы не запрашивали метаданные.)

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

Опять же, для них нет «формата контейнера».Это просто необработанные данные.

Теперь, если вам нужны метаданные, вы должны запросить их с сервера.Затем данные просто вводятся в поток каждые x число байтов.Смотри http://www.smackfu.com/stuff/programming/shoutcast.html.

1 голос
/ 17 июля 2011

К сожалению, это не всегда так просто, проверьте формат и примечания здесь: Формат заголовка фрейма MPEG

0 голосов
/ 18 июля 2011

Я продолжу обсуждение, отвечая самому себе (даже нам не рекомендуется это делать):

Я также изучал потоковые данные и обнаружил, что часто последовательность ff f3 82 70 повторяется - это япредложить заголовок фрейма MPEG, поэтому я пытаюсь посмотреть, что это значит:

ff f3 82 70 (hex) = 11111111 11110011 10000010 01110000 (bin)

Analysis
11111111111 | SYNC
10          | MPEG version 2
01          | Layer III
1           | No CRC
1000        | 64 kbps
00          | 22050Hz
1           | Padding
0           | Private 
01          | Joint stereo
11          | ...

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

BR STEN

...