2015-09-15 3 views
1

Я испытываю проблему с кадром при воспроизведении видео. Мы просто перешли от ICS к KK4.4. Видео очень маленькое разрешение 320x240. Нет звука, чтобы сделать вещи простыми.Проблема с кадром с воспроизведением видео

Systrace находится в следующем месте: https://www.dropbox.com/s/bee6xymg3kpn4ft/mytrace2.html?dl=0

Я позволил тройной буферизации и hwcomposer является порождающей поддельной VSync, чтобы в SurfaceFlinger.

Я вижу следующие вопросы:

  1. тройной буферизации не включен должным образом, поскольку videodecoder выделяет очереди 7 буферов. Если трехмерная буферизация работает нормально для каждого кадра, который ставится в очередь из TimedEventQueue (OnVideoEvent), буфер, который должен быть удален, должен быть на 2 слота позади. Для Ex: если мы заказываем buf 4, тогда buf 2 должен быть отменен, но то, что получает dequeued, является немедленным предыдущим буфером, который открывается только после того, как он получит возможность запускаться в следующий раз. Следовательно, задержка и в свою очередь вызывает отключение буферов для видео, чтобы догнать.

  2. SurfaceFlinger сам занимает некоторое время, чтобы закончить.

  3. Vsync не включается в соответствующее время, скажем каждые 33 мс для видео 30 кадров в секунду. Проблема с логикой генерации vsync в HWComposer или vsync не включается eventControl из-за отсутствия фактических буферов в очереди?

Обновления от ниже комментария, который я сделал: Других вещей, которые я отметил, что в асинхронном режиме и mDequeueBufferCannotBlock флаги являются ложными и, следовательно, getMinUndequeuedBufferCount() возвращает 1 и, таким образом, мы видим непосредственный предыдущий буфер попросило для dequeue, а не буфер 2 слота позади. PLease дайте мне знать, если есть дыра в понимании выше. И все, что я могу сделать, чтобы обойти это

Любая помощь очень ценится.

ответ

1
  1. Видеокодеки решают, сколько буферов им нужно. Конфигурация BufferQueue - это согласование.

  2. Я не вижу, где SurfaceFlinger занимает много времени, чтобы закончить. Посмотрите на линию /system/bin/surfaceflinger - она ​​работает быстро.

  3. Нет никакой ценности в пробуждении и выполнении работы, когда нет работы, поэтому VSYNC отключается, если ничего не происходит. Ваше последнее предположение верно: если вы посмотрите на строку SurfaceView, вы можете увидеть корреляцию между отсутствующими буферами и отсутствием пробуждения в SurfaceFlinger.

Я вижу между звука 180 мс прибытия кадров на SurfaceView BufferQueue, что составляет около 5.5fps. В процессе mediaserver есть несколько длинных разделов onVideoEvent - какой кодек вы используете?

Вы описали это как проблему с кадром - какой игрок вы используете?

+0

Спасибо за ответ. Мы используем кодек OMX и Android-плеер для Android. Теперь OnVideoEvent занимает больше времени, потому что dequeuebuffer занимает много времени большую часть времени. Теперь DequeueBuffer занимает много времени с тех пор, как surfaceView, пытающийся деактивировать, по-прежнему удерживается поверхностным flinger.Поверхностный flinger выпустил его только в следующем экземпляре, после того как он приобрел следующий буфер. –

+0

Другими вещами, которые я отметил, является то, что флаги async и mDequeueBufferCannotBlock являются ложными, и поэтому getMinUndequeuedBufferCount() возвращает 1, и поэтому мы видим, что сразу же предыдущий буфер запрашивается для удаления из очереди, а не за 2 слота для буфера. PLease дайте мне знать, если есть дыра в понимании выше. И все, что я могу сделать, чтобы обойти это. –

+0

Все, что может мне помочь .. :) –

Смежные вопросы