[mythtv] Interlaced Mediacodec counts fast
Peter Bennett
pb.mythtv at gmail.com
Thu Feb 21 16:04:26 UTC 2019
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
More information about the mythtv-dev
mailing list