Interlaced Mediacodec counts fast on Shield

[mspieth]

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.

[Peter Bennett]

Proposed, lightly tested, fix

[Peter Bennett]

This fix only applies to avsync2. Elapsed playback time is now based on the timecodes of the frames rather than count of number of frames played. This should help with any video or situation where the timecode advances at the wrong rate.

I have a 30 minute recording that I played using mediacodec on shield at 1.5x. Before this change it reverted to 1.0x and showed 30 playback minutes when it was actually only 2/3 through (at the 20 minute point approximately). With the patch the timings are correct and it reaches the end of the recording correct;y at the 1.5x speed, also the timings displayed with Info are now correct.

I have done some tests with cutpoints also, and they seem OK with this change.

[mspieth]

This may be a buffer problem as markk suggests.

[mspieth]

Add patch which will mitigate any ntp time jumps that occur during playback and avsync2.

Feel free to disregard the sleep loop which is supposed to trick the scheduler from deferring this thread/process after the actual time expired. The trick is used elsewhere in myth too.

[Peter Bennett]

I agree that I should have used QElapsedTimer here. I will make the change, but ...

One thing mystifies me, I cannot see where the timer is started. According to the QElapsedTimer documentation, the timer is invalid until QElapsedTimer::start() is called, and I cannot find any call to start() in the patch. It would be good enough to just call start() in the constructor, I think, and it could continue timing until destroyed.

Is something missing or am I missing something?

[mspieth]

Sorry I missed copying the m_avTimer.start() in mythplayers constructor.

[mspieth]

Also its probably a good idea to read the use avsync2 setting in teh constructor and cache it as I think it will make mysql a bit busy.

[Peter Bennett]

AFAIK All settings are cached, only read from sql the first time accessed.

[Peter Bennett <pbennett@…>]

In 6a5fb07fa/mythtv:

AVSync2: Use frame timestamps to determine elapsed play time

MythTV uses frame count to determine the elapsed time of a recording
for display, jumps, etc. This can be inaccurate with variable rate
content and also with frame doubling being done in the decoder.
This change recalculates the frame count based on the time code.
This ensures MythTV elapsed time will be accurate.

Fixes #13416

[Mark Spieth <mark@…>]

In d5a2223bf2/mythtv:

AVSync2: Change to use monotonic timer

Use a monotonic timer to avoid possible problems when time is reset
during playback.

Refs #13416

Signed-off-by: Peter Bennett <pbennett@…>

[Peter Bennett <pbennett@…>]

In bceea69806/mythtv:

AVSync2: Use frame timestamps to determine elapsed play time

MythTV uses frame count to determine the elapsed time of a recording
for display, jumps, etc. This can be inaccurate with variable rate
content and also with frame doubling being done in the decoder.
This change recalculates the frame count based on the time code.
This ensures MythTV elapsed time will be accurate.

Fixes #13416

(cherry picked from commit 6a5fb07fa17d7a7da09bd8a7be0394c8e4948122)

[Peter Bennett]

Reopening as this needs to be fixed another way. The applied fix will be reverted.

Explanation -

It causes jumps in the frame numbers which prevent the VideoOutput classes detecting a discontinuity and releasing out of date reference frames for multi-frame deinterlacers

[Peter Bennett]

Closing this again as the frame discontinuity issue is now being handled differently and this fix has been committed again. Also, changing the way this works will be a lot of work and it is working well as is.