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

Question

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

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

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

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

EDIT:

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

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

ОБНОВЛЕНИЕ: QuickMediaConverter работает очень хорошо, но не знаю почему. Никаких проблем с тех пор!

Answer 1

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

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

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

2. Seek to Time - это поиск точного времени, которое требует пользователь.

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

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

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

2. VBR - переменная скорость передачи - скорость передачи не является постоянной, она постоянно меняется. Таким образом, в этом случае выясните среднюю скорость передачи файла и затем используйте вышеуказанный метод, в этом случае поиск не будет точным.

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

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

Относительно того, какие форматы поддерживаются Android, смотрите эту ссылку

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

Answer 2

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

если ниже времени есть входные сигналы 10 сек
12 сек
14 сек

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

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