From: James Courtier-D. <Ja...@su...> - 2001-10-23 12:54:21
|
Hello Currently, there is a problem with the wraparound/audio_out code in xine. Currently, audio_out.c will call fill_gap if the vpts > buffer_vpts. During normal playing to streams, this does not cause a problem, because there is always both audio and video in the stream. So, the buffer_vpts will always keep up with the vpts. A problem appears when there is a stream with only video, and not audio, and then audio appears later. I.E. DVD Still menu(without sound) followed by an animated menu. This causes a difference between the buffer_vpts and the vpts. The user will see messages like: - audio_out: inserting 47988 0-frames to fill a gap of 90000 pts. I am looking into it, but I wanted to hear what other people thought a good solution would be. Cheers James -- Nothing in this world is exactly what it appears to be. |
From: Andrew M. <an...@an...> - 2001-10-23 14:43:07
|
James Courtier-Dutton wrote: > > This causes a difference between the buffer_vpts and the vpts. > The user will see messages like: - > audio_out: inserting 47988 0-frames to fill a gap of 90000 pts. Unfortunately I see that message, repeating behind a jammed up Xine with monotonous regularity. Nothing particularly repeatable, but mostly when jumping from chapter to chapter in a DVD. The only cure is to ctrl-c xine and restart. Even hitting the UI "power button" doesn't do it ... it just hangs waiting for something to happen ... which never does. Andy M |
From: <bar...@t-...> - 2001-10-23 20:03:26
|
Hi James, On Tue, 23 Oct 2001, James Courtier-Dutton wrote: > A problem appears when there is a stream with only video, and not audio, and > then audio appears later. > I.E. DVD Still menu(without sound) followed by an animated menu. ok - exactly for that case I added the void (*got_audio_still) (metronom_t *this); function to metronom - this function can be used to tell metronom about a still image without sound being displayed so it can update it's internal vpts counters. Probably there's a small bug in that function or in the code using it (audio_decoder.c). > This causes a difference between the buffer_vpts and the vpts. > The user will see messages like: - > audio_out: inserting 47988 0-frames to fill a gap of 90000 pts. which isn't that bad as a/v will be in sync after this messages, while they're slightly off-sync before. But of course this code should be reviewed for any remeining bugs - I'd be very happy to hear if you find anything that's wrong. Cheers, Guenter -- time is a funny concept |