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.