From: Heiko S. <hsc...@ft...> - 2002-11-28 13:51:18
|
Hey Miguel, thanks for your thoughts, your mail was somewhat reassuring to read ;) > i've just checked your change on cvs log and it seems you reverted to > the old behaviour (i guess it's probably safe to say that the feedback > loop is more experimental than this approach! :) :) 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. 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). > 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. 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. 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. > in theory the main difference between adding to scr or to vpts_offset is > that the later would cause the metronom to distribute the error over > several frames. if you advance the scr too much, frames will be dropped > instead. yes, i think that is occasionally happening right now (hard to tell) - that is why i want to make the changes to the scr smaller, i'm planning to fiddle with that in the evening. regards, Heiko |