[mythtv] Android mediacodec woes

[Peter Bennett]

On 06/26/2018 05:32 PM, David Engel wrote:
> 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?
Yes - they are accurate, for the example I looked at. The frame times 
are pased through as equally spaced at 59.94 per second. (1501/90000 of 
a second alternating with 1502/90000 of a second) When playing the same 
file with software decoding I see 3003/90000 of a second on each frame.

> 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.
There are no frame rate changes as such in this case, and I have to bear 
in mind that one frontend may be running on Linux and see a 29.97 frame 
rate and another frontend on Shield will see the same recording with a 
59.94 frame rate.
> 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?
I have not got to that yet, I will look at it when I have finished with 
the frame rate problem, but see my comment below.

>   We might have to resort to some sort of hybrid solution where
> we use software decoding for ff/rew and mediacodec for normal
> decoding.
>
This had occurred to me, but I did not see any easy way to achieve it.

Have you tried FF and REW with a progressive recording? I tried that and 
it seems to work correctly (but I don't use FF and REW normally so I am 
not familiar with what is normal). So I think that maybe once I have 
sorted out the timing, FF and REW may work without any more changes.

Peter