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
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
