Комментарии 15
Если вы имели в виду этот FFmpegMediaPlayer то он только для аудио, кстати у этого же разработчика нормально работающий FFmpegMediaMetadataRetriever есть.
У Vitamio странная лицензионная политика и закрытый код.
Да, готового варианта с FFMpeg я тоже не нашел в свое время.
У Vitamio странная лицензионная политика и закрытый код.
Да, готового варианта с FFMpeg я тоже не нашел в свое время.
Да, вы правы, это я был настолько невнимательным, что не заметил audio only.
А почему же закрытый? Или вы про native часть?
А почему же закрытый? Или вы про native часть?
Имел недавно дело с VideoView и MediaPlayer. Оказалось, что VideoView вообще не рекомендуется использовать, если в приложении требуется функционал серьезнее, чем просто проигрывание. Народ co StackOverflow рекомендует использовать отдельно SurfaceView в паре с MediaPlayer.
Было бы неплохо написать обзорный пост популярных альтернативных инструментов для проигрывания видео на Android.
Было бы неплохо написать обзорный пост популярных альтернативных инструментов для проигрывания видео на Android.
Работа через SurfaceView добавляет вам возможностей по масштабированию и анимациям, но MediaPlayer остается тот же, который используется в VideoView.
Возможно для чего-то и удобнее использовать связку SurfaceView и MediaPlayer, но для простого плеера VideoView действительно упрощает жизнь. Собственно, это и есть расширение SurfaceView с MediaPlayer внутри.
Вообще-то я бы добавил, что каждый производитель меняет свой проигрыватель. Но для полноты картины лишь добавлю список проблем, которые приходят в голову:
1. Отсутствие разумной поддержки стримов, старые стримы (RTSP) блокируют роутеры, новые на базе протокола HTTP на старых платформах не поддерживаются.
2. Перезагрузка активити (например при ротации дисплеем) не выгружает нативный MediaPlayer.
3. Течёт куда-то память в нативном плеере, да так, что на некторых платформах может телефон тупо замёрзнуть.
4. Проблема с прокруткой простых и потоковых видео.
5. А также Vitamio уже платный! :-)
6. Проблема с проигрыванием HD видео, неработающее аппаратное ускорение
и так далее…
Именно поэтому мы решили использовать оба способа проигрывания видео (native + vitamio) с немалой логикой и большими стараниями, с достаточно большим тестированием на всех возможных и невозможных платформах.
PS: Видео и аудио под Android — это геморой. И не дай бог Вам почувствовать на собственной шкуре ярость разгневанных хомячков-пользователей, которые не видят за всем этим ничего кроме своего экрана.
1. Отсутствие разумной поддержки стримов, старые стримы (RTSP) блокируют роутеры, новые на базе протокола HTTP на старых платформах не поддерживаются.
2. Перезагрузка активити (например при ротации дисплеем) не выгружает нативный MediaPlayer.
3. Течёт куда-то память в нативном плеере, да так, что на некторых платформах может телефон тупо замёрзнуть.
4. Проблема с прокруткой простых и потоковых видео.
5. А также Vitamio уже платный! :-)
6. Проблема с проигрыванием HD видео, неработающее аппаратное ускорение
и так далее…
Именно поэтому мы решили использовать оба способа проигрывания видео (native + vitamio) с немалой логикой и большими стараниями, с достаточно большим тестированием на всех возможных и невозможных платформах.
PS: Видео и аудио под Android — это геморой. И не дай бог Вам почувствовать на собственной шкуре ярость разгневанных хомячков-пользователей, которые не видят за всем этим ничего кроме своего экрана.
Полностью согласен. Работа с MediaPlayer в андроиде доставляет в первую очередь боль. Из своего опыта: в реализации плеера на многих самсунгах методы getDuration() и getCurrentPosition() могут возвращать что угодно, только не duration и position (проигрывали ауди и видео стримы). Что бы OnBufferingUpdateListener и OnErrorListener возвращали что-то вменяемое вместо 0 и MEDIA_ERROR_UNKNOWN остается только мечтать.
А как у этих библиотек с аппаратным ускорением декодирования и видео?
Или все на процессоре?
Или все на процессоре?
На сайте Vitamio говорят следующее:
Hardware decoder isn't perfect, suggest users to switch decoder manually…
То есть аппаратное ускорение есть, но в каком смысле оно «не идеальное» — сказать сложно.
Hardware decoder isn't perfect, suggest users to switch decoder manually…
То есть аппаратное ускорение есть, но в каком смысле оно «не идеальное» — сказать сложно.
Vitamio у себя юзают тот же OMXCodec, который через хак добывают.
Проблемы с нестабильностью MediaPlayer связаны с вендорами, которые могут нестандартно реализовать свои кодеки, яркий пример — Allwinner.
Из фреймворков для мультимедиа могу порекомендовать github.com/google/ExoPlayer. На последнем Google IO в секции про Android TV главный разработчик сего фреймворка про него рассказывал.
ExoPlayer внутри использует MediaCodec API.
Проблемы с нестабильностью MediaPlayer связаны с вендорами, которые могут нестандартно реализовать свои кодеки, яркий пример — Allwinner.
Из фреймворков для мультимедиа могу порекомендовать github.com/google/ExoPlayer. На последнем Google IO в секции про Android TV главный разработчик сего фреймворка про него рассказывал.
ExoPlayer внутри использует MediaCodec API.
И учтите, что для большинства устройств может быть запущено только два OMXCodec инстанса на процесс. Т.е. вы не можете в одном окне проиграть больше двух видео одновременно.
В рамках android framework, мы можете принудительно создать MediaCodec который будет работать на софтверном гугловом декодере и вот на нем уже проигрывать несколько видео в окне.
В рамках android framework, мы можете принудительно создать MediaCodec который будет работать на софтверном гугловом декодере и вот на нем уже проигрывать несколько видео в окне.
Подозреваю что все так плохо потому что для media API нужно что производители устройства сконфигурировали аппаратное ускорение для своего железа и тут получаем что за весь pipeline отвечает Google + DeviceVendor + GPU Vendor.
Еще один хороший фреймворк github.com/bbcallen/ijkplayer.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не используйте MediaPlayer и MediaMetadataRetriever в Android