From: Miguel F. <mi...@ce...> - 2002-11-28 14:25:13
|
hi heiko, On Thu, 2002-11-28 at 11:50, Heiko Schaefer wrote: > :) well, the most experimental part about it is probably that i've removed > most of the inhibiting conditions of that if clause. and adjusting the > clock by the entire value of the gap, not just a smaller fraction of it. right, but these inhibiting conditions were there to prevent doing several updates in a row and not realizing it. it was needed because the metronom feedback loop has a delay due the audio buffers. updating the scr directly takes effect immediately (a feedback loop with zero delay). > what i will try to do is set the clock by smaller steps (so that the clock > won't oscillate heavily or something like that). i would expect to not update the scr often with this mechanism. if we do, we are probably hiding a bug somewhere else. > > the clock/metronom adjusting from audio_out is meant to correct very > > small errors (like caused by a small drift between soundcard reference > > and system clock). unfortunately something must have being wrong there, > > because the correction code seemed way too much used. > > as far as i could tell, the previous implementation of this ADJ_VPTS > branch in the code had no positive effects whatsoever. > > i specifically looked at the value of 'gap' in the audio_out logs and > noticed no improvement in the gap values after ADJ_VPTS had happened (not > even distributed over the next handful of frames). guenter suggested that > METRONOM_ADJ_VPTS_OFFSET is actually supposed to do something entirely > different, namely define a diff between audio and video. i am unsure what > to think. no, you are mistaking it for METRONOM_AV_OFFSET. METRONOM_ADJ_VPTS_OFFSET adds some value to vpts_offset, which would create a difference against predicted values on metronom (see line 402+). as i said, i quite sure it used to work when i coded it because i did a lot of tests with bad sample rates and bad streams... > whichever way, for my mpeg stream the ADJ_VPTS if clause seemed to have no > positive effect and i always ended up in the ao_fill_gap() branch after a > while. and had a skip in the audio, which of course sucks. agreed, it's well known that audio skips are much more annoying to the user than small video jitters. > this is why i guess that some changes (not nevessarily the ones i made) to > the ADJ_VPTS part will be the solution - if the change is subtle enough > then it will most likely not break anything else, and hopefully still give > me smooth playback of my mpeg1 streams. i'm quite happy that no changes to > the metronom seem to be necessary. great! i told you that metronom heuristics were probably not needed to fix your problem! :) in some near future i believe we should have two operation modes (selectable from config) for fixing sample rate drift as James suggested: 1) adjust scr/vpts_offset/whatever to change video speed and match playing sound speed reported by sound card. 2) resample audio to keep video at the nominal rate. both of them have their beneficts, so it should be ok to let the user change the strategy if he wants. regards, Miguel |