Точность MediaPlayer.seekTo(int msecs)

Почему MediaPlayer.seekTo(int msec) так неточно?

Это иногда 30 секунд раньше (с mp3 как переменными, так и постоянными битрейтами)! Является ли поиск со звуком по своей сути проблематичным или этот метод нарушен? Это связано с буферизацией или тем, что?

Я также заметил, что общая продолжительность выполнения getDuration() может быть неправильной (что не является большой проблемой), и я тестировал, что getCurrentPosition() достаточно точен (как в каждые n секунд воспроизведения, он увеличивается по n тыс.). Я на Android 2.2.

Наконец, кто-нибудь знает, какие форматы, если он действительно работает последовательно (желательно, кроме wav, который предположительно это делает)?

EDIT:

Я в основном слушаю подкасты. smodcast и Thinking Allowed были проблемными несколько раз, даже после преобразования/повторного кодирования в CBR. Файлы не повреждены.

QuickMediaConverter (Windows), похоже, работает нормально, но Sound Converter (Ubuntu) создал некоторые изворотливые файлы. Я постараюсь придерживаться прежнего...

UPDATE: QuickMediaConverter работает очень хорошо, но не знаю, почему. С тех пор проблем нет!

Ответ 1

Существует два способа, которыми мультимедийная инфраструктура выполняет операцию поиска в мультимедийном (AV) файле.

Ищите ключевой кадр. Видео при кодировании обычно имеет что-то, называемое I-фреймом или фреймом Key, это означает, что этот кадр имеет много информации и может использоваться для полного декодирования кадра. Чтобы уменьшить объем пространства, все кадры не кодируются как ключевые кадры, а они кодируются как P (предсказанные) кадры или предсказанные кадры, что означает, что вы можете декодировать P-кадр с помощью ключевого кадра.

Таким образом, во время операции поиска в этом случае поиск выполняется для ближайшего ключевого кадра для заданной продолжительности времени. Например, если пользователь ищет 40 секунд и ближайший ключевой кадр находится на 35-й секунде, поиск производится до 35-й секунды, а не до 40-й секунды.
Ищите время - это поиск точного времени, которое требует пользователь.

Поиск по-прежнему выполняется в ближайшем ключевом кадре, поскольку в противном случае вы увидите зеленые патчи или пиксели видео, что крайне нежелательно. Таким образом, поиск выполняется для ключевого кадра, а затем кадры декодируются до требуемого времени, но эти кадры отбрасываются и не отображаются пользователю. В приведенном выше примере все декодированные кадры с 35-го по 40-й секунды отбрасываются и отображаются только кадры за 40 секунд.

В случае только аудиофайлов могут быть два случая (если нет синтаксического анализатора или синтаксического анализатора, который не создает таблицу времени, тогда -)

CBR - постоянная скорость передачи битов - поскольку скорость бит постоянна, мы можем пропустить необходимое количество байтов в заданное время (битрайт * timeToSeek = байты, которые нужно пропустить)
VBR - переменная скорость передачи битов - скорость передачи битов не постоянна, она меняется. Таким образом, в этом случае найдите средний битрейт файла, а затем используйте вышеуказанный метод, в этом случае поиск будет неточным.

Теперь, вернувшись к вашему вопросу, я могу с уверенностью сказать, что он работает хорошо и точно для большинства медиафайлов.

Единственная причина, по которой вы столкнулись с такими проблемами, состоит в том, что медиафайл сам по себе поврежден. (Просто невозможно иметь разницу в 30 секунд во время поиска +, вы говорите, что продолжительность не верна правильно. И ни один из API медиаплеер не работает для Android 2.2)

Что касается форматов, поддерживаемых Android, см. ссылку

Так вы можете попробовать с другим mp3 файлом?

Ответ 2

Я ничего не знаю об андроиде. Но я знаю, что в большинстве форматов медиафайлов есть одно условие, которое называется поисковыми записями или вводами записей. который показывает, что в это конкретное время отсюда видео и аудио должны начинаться играть

если ниже время имеет запись с репликами 10 sec
12 sec
14 секунд

тогда, если вы стремитесь к 11 секундам, он всегда будет играть с 10 секунд если вы стремитесь к 12 секундам, он всегда будет играть с 12 секунд

для лучшего файла поиска должен быть мультиплексирован с высокой записью cues.