Здравствуйте, butcha, Вы писали:

B>Здравствуйте, VictorKozachek, Вы писали:

VK>>Количество кода — не шутка :) Я имею ввиду код, который нада писать, а так, я статик либу сделал и юзаю. Только вот иногда их энкодер возвращает ошибку на GetOutputData. Пока не могу понять почему :(

B>Понятно, я пока с енкодером не занимался — только скомпилировал, подключил к ффпег попробовал отрыть — открывается. А родной ффпег аас енкодер уже при инициализации вываливал ошибку деления на ноль. Мне и код писать не надо — в ффпег есть обёртки над vo-aac, open-amr так что я узаю всё через ффпег.

Да, я поговорил с неким товарищем Мартином из тима Opencore-amr на предмет этой ошибки и он мне все прояснил и теперь декодер и енкодер работают. Вся проблема в генах, как оказалось. AMR пакет, который считывается из RSTP, да и не только, состоит из нескольких фреймов с определенным размером, в моем случае пакет содержит 4 фрейма по 16 байт, первый байт служебный и содержит размер фрейма, который можно получить парсингом, код его имеется в примере, вот он, если что:

const int sizes[] = { 12, 13, 15, 17, 19, 20, 26, 31, 5, 6, 5, 5, 0, 0, 0, 0 };

int size = sizes[(packet.data[0] >> 3) & 0x0f];

Декодировать нужно каждый фрейм по отдельности, такая рекомендация этого товарища. С энкодером тут обстоит так, AAC encoder воспринимает буфер не менее 1024 байтов, посему давать ему чтото тменьшее нет смысла, он вернет ошибку. Для этого, нада декодированный фреймы складывать в буфер и как только он достигнет нужного размера, процессить энкодирование. Работает 100%, но, блин, я пока не пойму по какому принципу работает, точнее требует буферы AudioQueue на iPhone. Она процессит буферы быстрее, чем работает процедура декодирования, тут и возникают проблемы :(