Я использую MediaCodec для декодирования видеодорожки, поступающей от MediaExtractor. Он работает в асинхронном режиме с выходом Surface. Мне нужно иметь возможность произвольно искать в видео определенные кадры.
Когда вызывается onOutputBufferAvailable () , я ожидаю, что bi.presentationTimeUs будет содержать метку времени для кадра: его метку времени в дорожке видеофайла.
Сначала это действительно происходит, но после попытки поиска назад к другому времени с помощью MediaExtractor.seekTo (...) возвращаемые таймфреймы кажутся "застрявшими": они совпадают с последними кадр перед вызовом seekTo ().
Если я правильно понимаю вещи после поиска, я не могу ожидать выходные буферы для всех ранее представленных входных буферов, поскольку некоторые из них могут содержать B кадров, которые не могут быть декодированы без более поздних данных. Поэтому я не могу просто отслеживать временные метки на основе временных меток входных буферов.
Если I flush () буферизует, этой проблемы не возникает, временные метки правильные, но тогда асинхронные обратные вызовы становятся очень проблематичными. (не могу быть уверен, какие буферы все еще действительны ... попробуйте {} - использование буферов в конечном итоге сломает кодек, очевидно, не может просто продолжать работать после выдачи ошибки)
В противном случае кадры имеют правильное содержание, а отчеты кодеков поддерживают адаптивное воспроизведение. Я тестирую на Oreo.
Есть ли способ получить правильные временные метки без использования flush () - кодека? Это ожидаемое поведение или ошибка библиотеки?