[mythtv] Android mediacodec woes

[John Pilkington]

On 26/06/18 21:11, 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.
> 
> Peter

Some years ago the seektables (getmarkup) were changed to store a direct 
relationship between frame number snd timestamp, in order to allow for 
varying framerates.  I don't know how many formats this affects now, but 
it seems worth mentioning.

John P