[mythtv] Interlaced Mediacodec counts fast

[Peter Bennett]

On 2/21/19 8:12 AM, Mark Spieth wrote:
> Hi Peter
>
> I have been using avsync2 and mediacodec with interlaced recorded TV 
> program.
>
> I play back at faster than real time e.g. x1.2 or x1.5. The counter 
> for the end of the program reaches 0 before the actual end of the 
> program, thus reverting to x1.0. It seems to be the same ratio 
> regardless of the rate played.
>
I will look into this. Others have also reported it.
> I notice AVsync2 does not update framesPlayedExtra. Is this important?
>
I see that - it seems to be some sort of adjustment for wrong frame 
rate. I will take a look at that.
> How is the frame doubling that mediacodec accounted for when 
> calculating the number of framesPlayed which detemines the end of 
> content and also the OSD time played/time remaining?
>
When I first did mediacodec, the time counter was going at double speed 
when playing at normal rate, because it had frame rate from ffmpeg as 30 
but was actually getting 60 frames per second. The fix is that if it is 
running a double frame rate this way it only increments frame counter 
every second frame.
> There are 2 variables m_double_framerate and m_double_process. Are 
> either of these responsible or is there another mechanism?
>
Those are for frame doubling in the render (OpenGL). They are not 
relevant to frame doubling in the decoder, which is now used by 
mediacodec, vaapi2 and nvdec.
> I am a bit confused and you may be able to shed some light on this 
> progressive play back of interlaced content with a mediacodec decoder. 
> I am trying to fix this (obviously) as it is quite annoying as 
> medicacodec seems to play interlaced content very nicely compared with 
> S/W decode and S/W deinterlacer.
>
> Note this effect does not happen for non interlaced content.
>
> Thanks
> Mark
>
I would like to change the way time is tracked to use the timestamps 
instead of frame counter. I have long had the problem that the time goes 
off when playing some file types. This results in the problem you 
described, and also causes forward jumps to sometimes go backward or 
jump by the wrong amount. One thing that I am unsure of is how to handle 
it if the time code in the file resets. I wonder if that happens in 
recordings.

Peter