mediaplayer seekTo() offset в байтах

Question

Я ищу, чтобы получить смещение в байтах, используемых методом seekto() класса MediaPlayer.

Мне было интересно, если бы так или иначе было необходимо получить эту информацию, а если нет, то, если вам нужно рассчитать ее самостоятельно, например: Если в медиафайле зарегистрирована скорость передачи битов в метаданных, и я хотел искать 10 секунд я мог бы использовать следующий расчет:

10(secs)*(bit rate per second)/8 

Могу ли я считать, что MediaPlayer извлекает информацию о скорости передачи битов, используя MediaMetadataRetriever класс?

Я прочитал следующее: Accuracy of MediaPlayer.seekTo(int msecs) И я в курсе проблем с переменной скоростью передачи данных, но я не ищу точности в методе seekto(), а как получить/вычислить значение, которое он использует для смещения для получения новых данных.

Answer 1

Ваша цель внедрения seekTo() на основе смещения является новой, но имеет множество проблем, связанных с этим. Прежде чем перейти к реализации seekTo(), уточните около MediaPlayer и MediaMetadataRetriever. Оба этих класса используют объект MediaExtractor, чтобы получить информацию metadata. Следовательно, MediaPlayerне включает класс MediaMetadataRetriever.

Во-первых, рассмотрим извлечение битрейта. MediaPlayer - это общая реализация, которая должна поддерживать несколько файловых форматов. Следовательно, для вашего дизайна, вам необходимо убедиться, что параметр bitrate извлекается всеми форматами файлов, поддерживаемых вашей системой, как аудио-визуальные форматы, такие как MP4, MPEG-2 TS, AVI, Matroska и т.д. и аудио форматы, как только WAV, MP3 и т.д. В последняя версия для Android, я обнаружил, что только MP3Extractor подвергает битрейт через kKeyBitrate ключ.

Далее, приступив к вашему алгоритму, я обнаружил следующие проблемы, связанные с поиском по размеру.

1. videoaudio и треки сохраняются в чередовании. Следовательно, time * bitrate (in bytes) не будет непосредственно полезен из-за чередования характера ваших входных данных.

2. Необходимо учитывать начальное смещение. В файле есть metadata или boxes, хранящиеся в начале файла, который зависит от формата файла. Вам придется также учитывать это смещение, которое будет отличаться для разных форматов.

3. Если вход имеет больше mnumber треков, как audio, video, text или несколько, а audio треков, как в кино, то проблема будет становиться все более сложным.

4. Видеокадры, как правило, имеют неправильный размер. Несмотря на то, что используется постоянная битрейт , модель, размеры видеокадра могут значительно различаться в зависимости от типа кадра. Как правило, I-frame/IDR-Frame in H.264 может потреблять большое количество бит по сравнению с P-frame или B-frame.Это создаст практические трудности для реализации размера seekTo(). Можно было легко наблюдать 1 с: 5 соотношение с точки зрения размеров кадра для I и P кадры

5. Там есть определенное влияние модели переменной битовой скорости, которую вы уже признали. Следовательно, я пропущу этот момент.

С вышеупомянутых пунктов, не препятствуя вам, я чувствую себя на основе реализации size выглядит сложно.