[mythtv] Jerkiness with double rate deinterlace

[Mark Spieth]

On 9/6/2018 4:51 AM, David Engel wrote:
> On Wed, Sep 05, 2018 at 02:29:49PM -0400, Peter Bennett wrote:
>> On 09/05/2018 12:08 PM, David Engel wrote:
>>> On Wed, Sep 05, 2018 at 10:59:59AM -0400, Peter Bennett wrote:
>>>> Hi David
>>>>
>>>> I looked at your output (https://pastebin.com/69KzcQqr) and it seems the
>>>> deinterlacer is working correctly.
>>> I see, now.  I got confused by "Unable to enable Video Output based
>>> deinterlacing" and "bled Video Output based deinterlacing" thinking
>>> that all deinterlacing had failed and was disabled.  Those messages
>>> should probably more clearly state the video output deinterlacing is
>>> not needed because decoder deinterlacing is being done.
>>>
>>>> The problem seems to be that the "predict
>>>> drop frame" keeps dropping frames. The frame rate is 60 and the refresh is
>>>> 60 but it still drops so many frames.
>>> The predictive frame dropping should not be done in that case.  Are
>>> yous sure deinterlacer being selected is really 2x?  I suspect the
>>> decision whether to drop is being made using bad information or too
>>> early or isn't being rechecked at the appropriate time.
>>>
>>>> I have noticed the same thing but only
>>>> in certain recordings. In some cases it only drops frames during the show
>>>> and not during the commercials, in some cases during one commercial and not
>>>> during another. This deinterlacer, like the shield, is treated as a 60fps
>>>> progressive stream and does not use the m_double_framerate indicator in
>>>> playback. The gl hardware 2x deinterlacer is treated as a 30fps stream and
>>>> uses the m_double_framerate and does not drop frames.
>>> Perhaps something significant in the stream like frame rate is
>>> changing during the commercials.  I remember several years ago when
>>> Time Warner inserted SD, local commercials into HD streams.  My HDPVR
>>> would properly record the 720p > 480i > 720p transitions, but MythTV
>>> didn't handle them as gracefully at the time.
>>>
>>> David
>>>
>>>> I wonder what the consequences would be of using a different sync method
>>>> than DRM and/or skipping the "predict drop frame" process.
>>>>
>>>> Perhaps the predict drop frame can be adjusted.
>>>>
>>>> One thing may be relevant - the deinterlace filters introduce garbage pts
>>>> values in the deinterlaced frames so I added logic to insert a good value
>>>> there. On the first frame copy the input pts and on the second I add half
>>>> the interval. Perhaps something about that is incorrect or inconsistent with
>>>> the predict drop frame. I will look at this a bit more and try some other
>>>> things.
>>>>
>>>> Peter
>> Here are some samples:
>>
>> 1. This is a ticker at 29.97 fps and plays completely smoothly with no
>> frames dropped
>> https://www.dropbox.com/s/6q9bieitx2bd6bb/ticker_1080i.mkv?dl=0
> FWIW, the sample I've been using also from BBCA.  I'm pretty sure it is
> constant, 30 fps, interlaced.
>
>> 2. This is also from a recording. The dancing at the beginning is 25 fps
>> progressive. Then the golf club scene is 25fps interlaced (50 fps
>> effectively) and the  predictor is dropping lots of frames. Then the "and
>> now ABC presents" and picture of Coulson is 30fps interlaced (60 effective)
>> and no frames get dropped. After that it switches to 25 FPS interlaced (50
>> effective) again and frames are being dropped.
>>
>> https://www.dropbox.com/s/18psskmw79ujavf/interlace.mkv?dl=0
> As I tried to say, but perhaps not clearly, the predictor might not be
> getting re-initialized when the stream changes.
>
>> As far as I can see, the code only calculates the fps once, and from that it
>> calculates the frame interval. The frame interval can change but I don't
>> think it is recalculated.
>> I tried commenting the setting of avsync_predictor_enabled in
>> MythPlayer::SetFrameInterval. That seems to play it smoothly without
>> dropping any frames.
>>
>> It does not make sense to drop frames when it is doing 25 fps (actually 50)
>> and not drop any when doing 30 fps (actually 60).
>>
>> My refresh rate is 60.
>>
>> I think we need to either disable the predictor or fix it.
> Disabling is not acceptable.  It fixes a very real problem.  In fact,
> I've been wanting to suggest to Mark that be extended to handle cases
> where the effective frame rate is less than the refresh rate.  In
> those cases, it should prefictly decide which frames to extend.
>
> It sounds like the predictor needs to be re-initialized when the
> stream changes.
I think we might need to decouple deinterlacing from AVSync.
This would then represent a consistent frame stream to AVSync for display.
If we can rely on PTS (DTS?) for frame timing then we may not have to 
assume a frame rate as we can calculate on a frame by frame basis the 
actual frame delta T but that may be excessively prone to jitter and add 
noise to the algo.

Changing the framerate that AVSync sees on the fly should not be a 
problem. A full AVSync reinit should not be necessary.
I will have a look tomorrow (sat) to see the impacts. The changing 
framerates and interlace modes during a playback was never considered.
Even changing the interlace mode (m_doublerate) on the fly should not be 
a problem either. I am going from memory here though and may be mistaken 
but should not be to hard to make this true.

As for extending frames when the rate is slower than the refresh rate, I 
thought this was already implemented.

The way the algo works is with a fractional delta T (A-V) and when it 
becomes > 1 or < -1 skip/repeat a frame.
Where refresh rate is 59.9 and the stream rate is 60, you should see 
only the odd frame skipped according to the expected ratio (i.e. not many).

Also the other problem with vsync with some drivers is that some dont 
present the true refresh rate to the system but just allow the frames to 
be shown/rendered at the stream rate and it handles the display in the 
driver with double/triple bufferring. This is one by GL sync and DRM 
should be better than busy wait and other vsync methods. Android uses 
busy wait AFAIR.

Mark