Hi, Jouni Karvo wrote: > > To come back to your problem: when you read about demuxing you'll find > > that there is a typical delta between audio and video of up to 700 ms > > which corresponds to 63000 pts. So I thought the default WRAP_THRESHOLD > > of 120000 pts would be ok to not trigger any false discontinuities. As > > you wrote below, a larger value seems to fix your problem. Would you > > please be so kind and try 150000 (= 5/3 seconds) and if this doesn't > > solve the issue 180000 (= 2 seconds). As this value typically serves for > > detecting a PTS wrap, it would also be ok to choose a really larger > > value up to 2^31. > > I have now tried with 200000. This runs pretty well, there is approx > one pause of sound approx one second every 3-4 hours. (VDR recovers > and image is not affected). If you run xine with --verbose=2, do you see a discontinuity reported at that time, maybe in conjunction with an audio jump? > With 150000, it still runs. Now the approx one second pause seems to > happen once every 15-60min. (and recovery is also working) > > So, it seems that there is some probability distribution of these > deltas, and increasing WRAP_THRESHOLD reduces the probability that the > delta is too large. > > Is there any upper limit of the possible delta values (less than this > 2^31)? I don't think so. It typically should detect wraps from about 2^33 - 1 to about 0 and back. > Is there any harm to have a really large value? If not, then I guess > it would be good to have a large value so as to make the problem > probability small. Well, you might try 900000 (= 10 seconds). Any jump below these value might then cause an audio jump of up to 10 seconds (= delay of up to 10 seconds). Strange is, that such a shift between PTS of audio and video packets needs to be compensated by a buffer to synchronize them. A buffer of 200000 / 90000 seconds still seems to be not large enough in your case. How does a set top box cope with that channel? Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@xxxxxx
