Плеер ogg/vorbis для мобильных приложений

[soundeng]

Требуется встроить в приложения для Android и IPhone плеер для воспроизведения потока ogg/vorbis. Сейчас, со слов разработчика, поток воспроизводит система и из-за этого очень большое время буферизации и приложение существенно жрет батарею мобильника. Он предлагает встроить непосредственно в приложение какой-нибудь плеер, умеющий воспроизводить поток ogg/vorbis. Сам разрабатывать его он не совсем хочет. Может подскажете в каком направлении мне, как заказчику, копать, где почитать. Это мое условие, что моя радиостанция в мобилах будет играть в ogg/vorbis, а не в мр3 как они хотят. Вот и просят с меня детали. А информации очень мало. Буду очень благодарен!

[VEG]

soundeng, сожалею, но опыта программирования под Android у меня нет. Знаю точно, что в Android с первых версий встроена родная поддержка формата Ogg Vorbis, и что-то мне подсказывает, что вряд ли бы Google встроила плохой декодер.

[soundeng]

Жаль. Может еще куда-нибудь запостить? Мой разработчик уже нервничает. А я думаю, что если это реализвать, то открывается еще одна страница в использовании ogg/vorbis.

[VEG]

Так я не понимаю в чём проблема. Android поддерживает Ogg Vorbis по умолчанию. Почему вы решили, что там встроен плохой декодер?

[soundeng]

Потому что это не работает. Потому что есть баги, потому что плеер останавливается при смене метаданных. И т.д. и т.п. Да, звучит. И все!. Больше ничего. Ни описаний, ни поддержки. НИЧЕГО!!! И я вообще уже не рад, что связался с vorbis. Конечно, если постоянно долбить одни и те же темы в форумах, как из под винды играть ogg и т.д. Тогда vorbis будет на слуху. А тут попытка внедрить его немного дальше. И тишина. Отказываюсь от него. Буду играть aac

[VEG]

Если какие-то проблемы со встроенным в Android декодером — необходимо отправить соответствующий багрепорт в Google. В самом Android для всех звуков используется этот формат по умолчанию. Описание соответствующего API также необходимо искать у Google. Даже если подходящего API нет — всегда можно написать собственный велосипед — все спецификации и исходные коды формата доступны.

[Janik]

Странная ситуация.
Впечатление такое, что речь идёт не о мобильнике на Android, а речь идёт о попытке как-то воспроизвести ogg vorbis на платформе iOS. Проблемы будут. И батарея, действительно, -- будет сильно расходываться. Очень сильно. Буферизация дорожки, "песок" на больших битрейдах и всё остальное ...
На последних версиях "Андроида" никаких проблем нет. Можно ещё подкрутить много-чего для более комфортного воспроизведения ogg, но это сложная задача. Проблема здесь одна -- не существует толковой договорённости между производителями электроники о том, что и как использовать следует. Google прописал в спецификации самые базовые параметры. По сути, никто ничем не ограничен.
Надежда на Sony, которая резво взялась за разработку сотовых телефонов и сделала ставку на качество звучания музыки, объединив воедино подразделения Sony Walkman, Sony mobile. К проблеме подключилась и Sony Music Entertainment -- эксперт в сфере звукозаписи. Создан великолепно звучащий фирменный программный плеер.



Кроме того, внедрена новейшая технология беспроводной передачи 2-х канального аудиосигнала на беспроводные головные телефоны и принимающие модули Hi-Fi аппаратуры высокого разрешения с техническими характеристиками, превосходящими в два раза качество CD-DA, по стандарту A2DP (одна из 30-ти разновидностей Bluetooth), суть которой заключена в том, что при установлении связи передатчик и приёмник согласуют кодек, который будет использован, а также параметры кодирования. За основу передающего кодека в базовом пакете выбирается один из пяти стандартов ( MPEG-1, MPEG-2, MPEG-4, AAC, и ATRAC). Архитектура стандарта расчитана на расширение. Надеюсь, Bluetooth 4, который в данный момент разрабатывается, расширит этот список и до ogg vorbis. Samsung однако, это уже сделал в версии 3.

[soundeng]

Спасибо! Огромное! Наконец-то вразумительный ответ. Но речь действительно о попытке воспроизводить поток ogg/vorbis в Android-приложении. Уже четвертый месяц бьемся над всякими проблемами. Действительно, андроид воспроизводит ogg по-умолчанию аппаратно. Но, возникают проблемы. 1. С метаданными. При их смене, плеер останавливается. Известная проблема, фиксировалась для браузера Firefox. На андроиде повторилась. Решили. 2. Приложение перестает играть поток ogg каждые 12 часов. Причем не после 12 часов непрерывного воспроизведения на устройстве, а с момента запуска потока. Повторяется 100% на всех версиях андроида независимо от того, играл он в этот момент поток или нет. Просто на всех телефонах приложение не может воспроизвести поток. При перезапуске потока на стриммере все начинает играть. Кодировал и VLC и Sonos4 и Visonair - результат одинаков. Но мы используем аппаратный декодер Андроид в приложении. И я думаю, что в этом и все проблемы. Сейчас попробуем встроить в приложение декодер от ffmpeg.

[Janik]

Мне кажется, дело в кэше. Есть такая "слабость", в слишком разборчивом "Андроиде" запоминать список недавно воспроизведёных дорожек. Меня на эту мысль натолкнула функция просмотра истории открытых приложений за последние 12 часов. "Андроид" даже скриншотит всё это дело. Также, у меня есть приложение, которое подчищает этот самый кэш. В нём стабильно гуляют мегабайт 30 всякого хлама.
Дальше уже подсказать не могу -- полный баран.

[VEG]

Приложение перестает играть поток ogg каждые 12 часов. Причем не после 12 часов непрерывного воспроизведения на устройстве, а с момента запуска потока.

У меня есть предположение по этому поводу. В каждом фрейме Ogg есть поле absolute granule position 64 бита. В нём указано точное смещение этого потока в сэмплах. При частоте дискретизации 44100 сэмплов в секунду получаем:
44100 × 60 = 2646000 сэмплов в минуту
2646000 × 60 = 158760000 сэмплов в час
158760000 × 12 = 1905120000 сэмплов в 12 часов
Число 1905120000 в двоичном виде (32 бита):
0111 0001 1000 1101 1101 0011 0000 0000
Ещё совсем немного — и в первом бите будет установлена единица. Есть подозрение, что в стандартном декодере Android это поле воспринимается как знаковое 32 разрядное (хотя должно быть беззнаковым 64 разрядным). Поэтому воспроизведение и прекращается при переполнении — первый бит воспринимается как наличие знака минус, что некорректно.
Каким образом вы решили проблему при передаче метаданных следующего трека? Подозреваю, что вы считываете аудиопоток, вручную разбираете пакеты Ogg (это несложно, спецификация контейнера простая), отлвавливаете момент смены stream serial number, и когда это происходит, инициируете новую копию декодера. Если это так, то добавить сброс absolute granule position будет достаточно просто — для этого достаточно будет в пришедшем потоке при смене stream serial number вручную пересчитывать absolute granule position начиная с 0. Вообще по идее стример должен был бы это сам делать, но наверное почему-то не делает. Теорию нужно проверить. Описание структуры ogg ферйма найдёте здесь.

[soundeng]

Спасибо за информацию. Проверим.

Проблему метаданных решили просто: добавили в приложение еще один поток (mp3 48kb/s) на всякий случай и считываем из него метаданные, которые отображаем в приложении. А на потоке ogg метаданные выключены. Минус такого решения: если потоки будут с разных источников, но такое маловероятно.

[VEG]

добавили в приложение еще один поток (mp3 48kb/s) на всякий случай и считываем из него метаданные

Да уж :) Наверное разборка входящего потока и его последующая сборка в поток буд-то он только что начал транслироваться (для скармливания этого декодеру) было бы всё-таки несколько проще. У Ogg достаточно простой формат потока, я даже сам как-то его пакеты вручную разбирал.