[mythtv] Android mediacodec woes

[David Engel]

On Tue, Jun 26, 2018 at 04:11:39PM -0400, Peter Bennett wrote:
> The double framerate that I am getting from mediacodec is proving to be a
> rather complicated problem to solve. With the situation the way it is now,
> the display of elapsed time is wrong and jumps are very wrong. For example
> after watching for 5 minutes, the OSD shows 10 minutes, and doing a forward
> jump of 1 minute jumps to the real 11 minutes, i.e. jumps forward 6 minutes
> instead of jumping forward 1 minute. Jumping back a minute  actually jumps
> forward 4 minutes.
> 
> Detecting the condition is easy enough. Fixing it, not so easy.
> 
> I first thought that I could simply double the fps value stored in
> AVFormatDecoder and MythPlayer. That does not work. I found that the
> MpegPreProcess is resetting it back to 29.97 on the next frame. Why do we
> parse the Mpeg input? Maybe that should be eliminated. We could get
> framerate from the decoded timestamps.
> 
> I then realized that the whole approach of changing the fps is flawed
> because the code uses framecount all over the place for calculating
> positions in the file. If the frame count from the demultiplexer (avformat)
> is half the frame count from the decoder, all sorts of calculations go
> wrong.
> 
> There is a feature in MythPlayer for m_double_framerate for double framerate
> deinterlacers. I am now thinking I should extend that to support this new
> situation of double framerate interlacer that is built into the decoder. It
> will need a number of changes, currently m_double_framerate is disabled as
> soon as it sees a non-deinterlaced frame. Currently m_double_framerate
> indicator causes the same frame to be passed to the video output twice, now
> it will need two consecutive frames passed to the video output.
> 
> Another option is just drop every second frame. This would be easiest but
> that will surely reduce the quality, which is not what we want.

I don't believe dropping every other frame would be acceptable.  I
know I wouldn't like it.

Are the timestamps in each frame correct?  Some years ago, someone (I
forget who) reworked the seek table (and possibly markup table too),
to properly handle recordings which contained frame rate changes (*).
Some of that logic might need to be used here.  So when we want to
skip ahead one minute, instead of asking what frame am I on, ask what
is the time of the frame I'm on.

Not to pile on, but here's a couple more issues.  When we ff/rew, we
want to decode a single frame, skip ahead, decode a single frame, skip
ahead, repeat.  How much data do we need to feed the decoder to get
the desired frame out and can we detect and discard any undesired
frames?  We might have to resort to some sort of hybrid solution where
we use software decoding for ff/rew and mediacodec for normal
decoding.

David

(*)I started writing this before John Pilkington's reply came in.  We
are both referring to the same changes.

David
-- 
David Engel
david at istwok.net