20

I'm using MediaCodec and MediaExtractor to play video at variable rates, both forwards and backwards. The code is using something like SpeedControlCallback to establish inter-frame pauses - feeding it the presentationTimeUs field from the output buffers.

This works fine, 99% of the time, however it seems like the AVC codec on the Samsung S6 provides incorrect presentation times when seeking backwards - they're pinned at whatever the highest value was when seeking forwards, if that makes any sense. The data in the buffers is correct / changing - it just doesn't correspond to the fixed presentation time.

The S6 can handle backward seeks in MP4 files with a brand/ftype of avc1, but other-branded H.264 video I've tried (mp42, isom) don't work 100% of the time. The same files work fine on a Samsung S5, and every other device I've tried.

The codec logs this:

09-15 11:16:21.611 2992-16618/? W/EXYNOS_VIDEO_DEC﹕ sCurrentTimestamp(6002033) is smaller than latestTimeStamp(7001744), uses latestTimeStamp

At each backwards seek (SEEK_TO_PREVIOUS_SYNC), and will provide that erroneous latestTimestampValue for all of the keyframes.

Has anybody encountered a similar problem with the AVC codec on the Galaxy S6, or is in a position to offer any (non-hacky) solutions?

moe
  • 452
  • 2
  • 10
  • What is the question? You probably found a bug around playing certain AVC files on certain hardware backwards. Video is hard, seeking is harder and playing backwards is even harder. Depending on the GOP structure - you have to decode forward, hold the decoded frames in memory and then pass them backwards. Again - what do you like to know? – Markus Schumann Sep 24 '15 at 19:45
  • Apologies for omitting a defined question - I am curious about whether anybody else has encountered this specific bug on this specific hardware. – moe Sep 25 '15 at 14:23

0 Answers0