[mythtv] DVB aspect change mid-stream loses frames?

[Steve Davies]

Ed Wildgoose wrote:

> Steve Davies wrote:
>
>> Hi,
>>
>> I have noticed recently that if the aspect ratio of a DVB stream 
>> changes during playback, then a number of frames and some audio are 
>> dropped as a result of the switch (as if the current buffers are 
>> flushed). This occurs in both directions 4:3->16:9 and vice versa.
>>
>> I am quite sure that this was not the case late last year, but cannot 
>> say for sure when it might have changed. I have trawled CVS and the 
>> commits list for clues, and my favourite CVS log entry on the subject 
>> has to be revision 1.386 (14/11/2004) of NuppelVideplayer.cpp where 
>> the ReinitVideo() call was added on aspect change. This seems to 
>> request a buffer cleardown as if a seek has been made, which would (I 
>> believe) lose a chunk of frames.
>>
>> Can anyone comment on the advisability of commenting out the final 
>> ClearAfterSeek() call in ReinitVideo, or even suggest a fix for me?
>
>
> Well, it probably needs to be put into a special case function because 
> I think ReinitVideo is called for other reasons as well.  I agree 
> though that it is annoying - you lose the last second of audio before 
> an advert break.


I can't actually find any other calls to ReinitVideo, but I agree a 
"bool flush_buffers=true" parameter to ReinitVideo would probably be the 
cleaner way to do this, with flush_buffers set to false for the aspect 
change case. I'll see if this works for me.

> Also slightly annoying while we are talking about this issue is that 
> the ReinitVideo is called when the frame is *decoded*, rather than 
> when it is displayed.  So usually I get the last few frames of the 
> show stretched a little, and then the new stuff appears in the correct 
> aspect ratio.


Yes, I used to see this, but at least the audio is clean - Losing the 
last word of a sentence is what really bugs me.

> I guess we need a less vigorous function to just handle the aspect 
> ratio change and for it really to be triggered when the frame is 
> displayed (or perhaps just for the decoder to make a note of the issue 
> and call the Reinit function some X frames later, where this is the 
> number of frames ahead that we are decoding...)


Agreed, would storing an extra bool against each frame to indicate a 
ReinitVideo be the way to do it? Or is some sort of reinit countdown 
better - This would assume that only one aspect change occurs in the 
space of the buffered frames.

There is also a very rare condition where seeking back and forth across 
an aspect change can cause incorrect clipping of the Xv window (A 4:3 
picture + OSD in a 4:3 screen, but clipped to a letterboxed 16:9) - I 
have been unable to reproduce this reliably, it just happens sometimes.

Steve