From: James Courtier-D. <Ja...@su...> - 2002-04-05 22:45:34
|
Mfreitas wrote: >Hi James, > >(sorry for not quoting the message very well: my mail server is down, i >copied that from geocrawler) > >>What I think the problem is: - >>On the Subtitle menu, after the first video frame (A single still >>image), audio plays, and the audio buffer is filled, but the video >>buffer is now empty. >>When a button is pressed, the menu starts playing from the beginning, >>so >>a new still image is received from the dvdnav plugin. >>The metronom code recognises this as a discontinuity, and therefore >>adjusts the global vpts_offset, but the audio still has sound in it's >>buffer to play, so as the VPTS values are calculated from the PTS and >>VPTS_OFFSET, the vpts values for the old audio packets is then wrong, >>I.E. Set ages in the future, and this a lot of "Audio fill with >>0-samples" happens, before xine will display the new Video still frame. >> > > >This should not happen the way you said. First, what fifo are you talking >about? > The fifo between demuxer and decoder. I.E. before the calls to metronom got_audio and got_video. In this particular case, the audio fifo will be full, and the video fifo will be empty when the discontinuity occurs. When the discontinuity occurs, the video packets will arrive at the decoder immeadiately and then when decoded, call metronom_got_video_frame, which will reset the vpts_offset value, before all the audio packets still buffered up in the audio_fifo have been pts->vpts stamped, so then the wrong vpts_offset value will be used for the audio pts->vpts conversion, and thus the problems. > > >There are fifos both between demuxer and decoder (buf_element) and between >decoder and driver (audio_buffer). audio_buffer don't have pts (only vpts), >so any buffers there really don't care about vpts_offset changes. the >discontinuity information is passed to metronom within buf_element fifo. >therefore, when a discontinuity is processed all old pts values have already >being decoded. > >So the only way a wrong pts could be delivered to metronom is: >1) demuxer haven't properly detected the discontinuity, therefore sending >wrong pts to decoder. >2) decoder holded an old pts value (before the discontinuity) and used it >with the new audio. This should be fixed automatically by the metronom's >in_discontinuity counter. Unfortunately if two discontinuities are detected >very closely in_discontinuity may not work as intended. > >>How I think we could solve it: - >>At the demuxer stage, each packet is given a discontinuity count. >> > >As discontinuity and pts are already serialized (on fifo), this counter >makes no sense. > >What we can do to improve the case 2 above is passing discontinuity control >buffers to decoder, so it may forgot any old pts references. > My proposal is to provide a method for vpts_offset to be different form audio and video around discontinuities. I.E. audio might be using VPTS_OFFSET[10], and video might be using VPTS_OFFSET[11]. But when the audio catches up with the discontinuity, it will then start using VPTS_OFFSET[11] as well. Thus, the VPTS_OFFSET used in the pts->vpts calculations will always be correct, even during a discontinuity. >>I think these changes will fix the above problems. >>I would welcome comments before I start coding it ? >> > >I think this is a completely overengineering, besides you may not fix the >actual problem. > >Would you mind waiting until tomorrow before start coding this? I also have >received the akira dvd so i may try it at home to find out what exactly the >problem is. > >regards, > >Miguel > I will wait, I wanted to discuss the problem first anyway before coding. I have some other libspudec and video_overlay coding to do before that anyway. Cheers James |