Hi,
I'm pleased to announce release 0.7.3:
http://home.vr-web.de/~rnissl/vdr-xine-0.7.3.tgz
2005-04-11: Version 0.7.3
- Started detection of AFD header in xine to automatically crop out the interesting part of the image later. - Adopted implementation of cXineDevice::SetDigitialAudioDevice() to different calling order in VDR 1.3.23. - Improved cXineDevice::SetDigitalAudioDevice() when replaying recordings. - Added setup option to automatically make vdr-xine the primary device while xine is connected to vdr-xine (requested by Der_Olli at vdr-portal). - Added setup option to consider all semi transparent colors as opaque to make the menu more readable. - Added commandline option '-s' to switch to skin 'curses' while xine is not connected to vdr-xine (requested by Rantanen Teemu). - Added commandline option '-q' to suppress debug messages (useful in combination with option '-s'). - Moved disconnect to cXineDevice::Stop() to get the new options to work. - Fixed all (?) deadlock situations in RPC command processing (e. g. stopping replay while switching a channel). - Fixed deadlocks in vdr-xine's xread(). A possible drawback is that now a disconnect might happen in such a case. - Fixed VDR's I-frame processing which caused disconnects e. g. while moving cut marks in HDTV recordings. vdr-1.2.23-dvbplayer3.patch is highly recommended for proper operation of vdr-xine. - Improved cXineDevice::StillImage() implementation to immediate display the frame (improves moving cut marks). - Fixed cXineDevice::StillImage() to work properly in combination with the plugin vdr-radio. BUG: xine's driver xxmc shows just a black screen on my EPIA MII-6000E. - Reintroduced usleeps() in input_vdr.c for flush, OSD flush and reset audio. sched_yield() simply caused to much CPU load while waiting about 40 ms to reach the expected state. Improves number of dropped frames when switching channels. - Optimized OSD display: VDR's channel display repeatedly sends a dirty OSD which doesn't differ from the previous one. Improves number of dropped frames while switching channel. BUG: it's still unclear whether this causes some OSD artefacts. - Fixed demux_mpeg_pes' discontinuity detection. Previously, when a PTS wrap happend, xine stopped replay for about 26.5 hours. - vdr-xine now nolonger set's xine's metronom directly but tells it's demuxer to do the job. Improves switching channels. - Optimized implementation of cXineDevice::Clear() in input_vdr.c. BUG: it may happen that xine's audio driver ALSA might get into a state of "silence" where it doesn't recover from until you stop replaying the recording. I still didn't find a way to reproduce this but it has to do with trickspeed, pause, play, and probably cut marks. - Fixed post_vdr.c to detect MRL changes for discovering streams sent from VDR, e. g. when xine is not started with the MRL specified on it's command line. BUG: It's possible that xine crashes due to this detection. xine doesn't allocate a different stream for a different MRL, but maybe other players do. I'm not sure whether I managed to increase the streams usage counter properly (by allocating an event queue) until I detect the new stream respectively MRL. BUG: post_vdr doesn't operate when xine's driver xxmc is used due to some limitation/incomplete implementation in xine's plugin interface. - Fixed xine's deinterlacer interface to take care of cropping. Previously the OSD was resizing like mad e. g. between 1920x1080 and 1920x1088. - Added support for VDR's new AUDIO key in xine (thanks to Darren Salt for reporting this issue).
For this release I suggest the following xine sources:
http://home.vr-web.de/~rnissl/xine-lib-cvs-20050411203000.tar.bz2 http://home.vr-web.de/~rnissl/xine-ui-cvs-20050411203000.tar.bz2
Highly recommended is the following patch:
http://home.vr-web.de/~rnissl/vdr-1.3.23-dvbplayer3.patch http://home.vr-web.de/~rnissl/vdr-1.2.6-dvbplayer3.patch (soon)
Enjoy.
Bye.
hi,
After updating to this version (0.7.3) there are some changes:
(I have also the combined ttxtsubs and subtitles patch from http://users.tkk.fi/~rahrenbe/vdr/)
- remote control is much more responsive and does not queue requests any more - after some 15-20 secs of live TV (with budget) the sound (and sometimes also images) start to have problems. The VDR output says
AFD present: 8 AFD present: 8 bad_frame bad_frame bad_frame bad_frame bad_frame bad_frame bad_frame bad_frame bad_frame bad_frame bad_frame AFD present: 8
- when viewing recordings, vdr-xine recovers from this in a second or two and continues then some time without problems, then stutters again
This is a more detailed log from a live viewing:
AFD present: 8 bad_frame bad_frame bad_frame 6 set_speed 176682 set_speed 238422 set_speed 331537 set_speed 448159 set_speed 534008 set_speed 664190 set_speed 886085 set_speed 960757 set_speed 1000000 200 frames delivered, 3 frames skipped, 7 frames discarded audio discontinuity #10, type is 2, disc_off 7484075394 waiting for in_discontinuity update #10 video discontinuity #10, type is 2, disc_off 7484075394 audio vpts adjusted to audio vpts audio jump, diff=100859 audio discontinuity #11, type is 2, disc_off 7484118594 waiting for in_discontinuity update #11 video discontinuity #11, type is 2, disc_off 7484118594 audio vpts adjusted to audio vpts audio jump, diff=105179 fixing sound card drift by 3514 pts fixing sound card drift by 2632 pts fixing sound card drift by 1971 pts fixing sound card drift by 1475 pts audio discontinuity #12, type is 2, disc_off 7494659394 waiting for in_discontinuity update #12 video discontinuity #12, type is 2, disc_off 7494659394 audio vpts adjusted to audio vpts audio jump, diff=115979 audio discontinuity #13, type is 2, disc_off 7494702594 waiting for in_discontinuity update #13 video discontinuity #13, type is 2, disc_off 7494702594 audio vpts adjusted to audio vpts audio jump, diff=113819
Earlier, there were some occasional "chirp" sounds, but then the audio and video continued without any more pausing and got over the error. For some reason now it seems to not be able to recover from these errors.
Any ideas on what to try - should I add some additional logging commands?
yours, Jouni
Hi,
Jouni Karvo wrote:
After updating to this version (0.7.3) there are some changes:
Huh, changes. When I first read this message I've read "problems" ;-)
(I have also the combined ttxtsubs and subtitles patch from http://users.tkk.fi/~rahrenbe/vdr/)
- remote control is much more responsive and does not queue requests any more
Sounds good, isn't it.
- after some 15-20 secs of live TV (with budget) the sound (and sometimes also images) start to have problems. The VDR output says
AFD present: 8
Do you sometimes see a different value here (most likely 9 = 4:3 image in a 16:9 frame)?
AFD present: 8 bad_frame bad_frame bad_frame bad_frame bad_frame
Most likely a result of dropping frames to sync video and audio.
bad_frame bad_frame bad_frame bad_frame bad_frame bad_frame AFD present: 8
- when viewing recordings, vdr-xine recovers from this in a second or two and continues then some time without problems, then stutters again
This is a more detailed log from a live viewing:
AFD present: 8 bad_frame bad_frame bad_frame 6
Where does this "6" belong to?
set_speed 176682 set_speed 238422 set_speed 331537 set_speed 448159 set_speed 534008 set_speed 664190 set_speed 886085 set_speed 960757 set_speed 1000000 200 frames delivered, 3 frames skipped, 7 frames discarded
Matches the 3 bad_frames.
audio discontinuity #10, type is 2, disc_off 7484075394 waiting for in_discontinuity update #10 video discontinuity #10, type is 2, disc_off 7484075394 audio vpts adjusted to audio vpts audio jump, diff=100859
Why does audio jump forward?
audio discontinuity #11, type is 2, disc_off 7484118594 waiting for in_discontinuity update #11 video discontinuity #11, type is 2, disc_off 7484118594 audio vpts adjusted to audio vpts audio jump, diff=105179
Why does audio jump forward again?
fixing sound card drift by 3514 pts fixing sound card drift by 2632 pts fixing sound card drift by 1971 pts fixing sound card drift by 1475 pts audio discontinuity #12, type is 2, disc_off 7494659394 waiting for in_discontinuity update #12 video discontinuity #12, type is 2, disc_off 7494659394 audio vpts adjusted to audio vpts audio jump, diff=115979
And again?
audio discontinuity #13, type is 2, disc_off 7494702594 waiting for in_discontinuity update #13 video discontinuity #13, type is 2, disc_off 7494702594 audio vpts adjusted to audio vpts audio jump, diff=113819
And again?
Earlier, there were some occasional "chirp" sounds, but then the audio and video continued without any more pausing and got over the error. For some reason now it seems to not be able to recover from these errors.
When audio jumps forward then xine tries to seek video forward too. But as DVB-S broadcasts at a fixed rate, such seeks eat up the buffer (see VDR's output on how large the buffer is after softstart phase) between vdr-xine and xine.
To recover from a buffer underrun you might want to try to pause xine for a few seconds.
Any ideas on what to try - should I add some additional logging commands?
Please enable vdr-xine's PTS logger by changing the if (0) in cXineDevice::PlayCommon3() (xineDevice.c:1018) into a if (1).
All pts* values should always step forward or stay at the same value. The d* values show the difference to xine's metronom and should typically be > 60000.
You might also want to play with xine's demuxer. Locate WRAP_THRESHOLD in xine-lib/src/demuxers/demux_mpeg_pes.c:54 and reduce this value to 90000 (i. e. smaller than the above reported diff). Feel free to experiment with this value, e. g. increase it.
Bye.
hi,
Sounds good, isn't it.
yep.
- after some 15-20 secs of live TV (with budget) the sound (and sometimes also images) start to have problems. The VDR output says
AFD present: 8
Do you sometimes see a different value here (most likely 9 = 4:3 image in a 16:9 frame)?
well, not so far in my tests.
This is a more detailed log from a live viewing:
AFD present: 8 bad_frame bad_frame bad_frame 6
Where does this "6" belong to?
no idea
video discontinuity #10, type is 2, disc_off 7484075394 audio vpts adjusted to audio vpts audio jump, diff=100859
Why does audio jump forward?
no idea
When audio jumps forward then xine tries to seek video forward too. But as DVB-S broadcasts at a fixed rate, such seeks eat up the buffer (see VDR's output on how large the buffer is after softstart phase) between vdr-xine and xine.
well, this would explain why the problem is worse on live TV and viewing recordings is much better.
Please enable vdr-xine's PTS logger by changing the if (0) in cXineDevice::PlayCommon3() (xineDevice.c:1018) into a if (1).
OK.
All pts* values should always step forward or stay at the same value. The d* values show the difference to xine's metronom and should typically be > 60000.
Well, they are when xine plays normally. Then something else happens:
When the sound (and shortly after video) disappears, first dA may jump to a high value. Then it starts getting smaller, and then:
ptsVideo: 8470619536, ptsAudio: 8470531701, ptsPCM: -1, ptsDolby: -1, ptsXine: 8470529869, dV: 89667, dA: 1832, dP: 0, dD: 0 ptsVideo: 8470619536, ptsAudio: 8470551141, ptsPCM: -1, ptsDolby: -1, ptsXine: 8470548677, dV: 70859, dA: 2464, dP: 0, dD: 0 ptsVideo: 8470662736, ptsAudio: 8470551141, ptsPCM: -1, ptsDolby: -1, ptsXine: 8470548690, dV: 114046, dA: 2451, dP: 0, dD: 0 AFD present: 8 ptsVideo: 8470662736, ptsAudio: 8470570581, ptsPCM: -1, ptsDolby: -1, ptsXine: 8470576989, dV: 85747, dA: -6408, dP: 0, dD: 0 ptsVideo: 8470662736, ptsAudio: 8470587861, ptsPCM: -1, ptsDolby: -1, ptsXine: 8470595307, dV: 67429, dA: -7446, dP: 0, dD: 0 AFD present: 8 ptsVideo: 8470705936, ptsAudio: 8470587861, ptsPCM: -1, ptsDolby: -1, ptsXine: 8470613362, dV: 92574, dA: -25501, dP: 0, dD: 0 ptsVideo: 8470705936, ptsAudio: 8470607301, ptsPCM: -1, ptsDolby: -1, ptsXine: 8470622747, dV: 83189, dA: -15446, dP: 0, dD: 0
Even negative. In this example, when dA goes to approx -100000, dV goes also negative. At this phase, the "bad frame" messages appear:
ptsVideo: 8471267536, ptsAudio: 8471155941, ptsPCM: -1, ptsDolby: -1, ptsXine: 8471234869, dV: 32667, dA: -78928, dP: 0, dD: 0 AFD present: 8 ptsVideo: 8471267536, ptsAudio: 8471173221, ptsPCM: -1, ptsDolby: -1, ptsXine: 8471262836, dV: 4700, dA: -89615, dP: 0, dD: 0 ptsVideo: 8471267536, ptsAudio: 8471192661, ptsPCM: -1, ptsDolby: -1, ptsXine: 8471290400, dV: -22864, dA: -97739, dP: 0, dD: 0 ptsVideo: 8471310736, ptsAudio: 8471192661, ptsPCM: -1, ptsDolby: -1, ptsXine: 8471290461, dV: 20275, dA: -97800, dP: 0, dD: 0 AFD present: 8 bad_frame ptsVideo: 8471310736, ptsAudio: 8471212101, ptsPCM: -1, ptsDolby: -1, ptsXine: 8471309123, dV: 1613, dA: -97022, dP: 0, dD: 0 bad_frame bad_frame
The pts* values do seem to increase as expected.
You might also want to play with xine's demuxer. Locate WRAP_THRESHOLD in xine-lib/src/demuxers/demux_mpeg_pes.c:54 and reduce this value to 90000 (i. e. smaller than the above reported diff). Feel free to experiment with this value, e. g. increase it.
With 90000, the problem is still there. Putting 50000 makes this problem much worse. With 200000, the dA seems to depend on the channel (mux?). For "YLE TV1", it seems mainly float around 30000, while "the Voice" shows around 70000 (the same as with YLE and WRAP_THRESHOLD 120000).
I'll keep the 200000 for a while now and see how it looks like.
Thanks for the help.
your, Jouni
Quoting Jouni Karvo jouni.karvo@tkk.fi:
hi,
Sounds good, isn't it.
yep.
- after some 15-20 secs of live TV (with budget) the sound (and sometimes also images) start to have problems. The VDR output says
AFD present: 8
Do you sometimes see a different value here (most likely 9 = 4:3 image in a 16:9 frame)?
well, not so far in my tests.
@Reinhard: If you are interested in such a sample I can send you one. It is rather short (only 4 to 5 GOPs) but very helpful for AFD testing.
Stefan Lucke
Hi, since I switched from 0.7.2 to 0.7.3 I have again and again the following problem: when I go from replay mode to fast forward (or fast backward) by pressing right (or left) on the remote, the picture stops and only after a while I see the fast forward running picture (or backward). Sometimes I have to wait rather long, then the number n in CLEAR(n) was higher than 40. The output looks like below, and the stop seems to be at the CLEAR, the higher n, the longer.
vdr: osdflush: n: 3, 23.0 +++ CLEAR(10) --- CLEAR(10) vdr: osdflush: n: 1, 9.1 bad_frame bad_frame bad_frame +++ CLEAR(11) --- CLEAR(11) bad_frame vdr: osdflush: n: 1, 10.2 vdr: osdflush: n: 231, 1624.1 vdr: osdflush: n: 14, 104.6 vdr: osdflush: n: 4, 30.2 +++ CLEAR(12) --- CLEAR(12) vdr: osdflush: n: 1, 10.8 bad_frame bad_frame bad_frame bad_frame vdr: osdflush: n: 1, 7.4
Stability has really improved in this version, while in 0.7.2 I had to restart fbxine often, this didn't happen at all up to now.
Jörg
Hi,
Jouni Karvo wrote:
Please enable vdr-xine's PTS logger by changing the if (0) in cXineDevice::PlayCommon3() (xineDevice.c:1018) into a if (1).
OK.
All pts* values should always step forward or stay at the same value. The d* values show the difference to xine's metronom and should typically be > 60000.
Well, they are when xine plays normally. Then something else happens:
When the sound (and shortly after video) disappears, first dA may jump to a high value. Then it starts getting smaller, and then:
Well, I've reformatted the output a little bit to show you what happens:
deltaV ptsVideo deltaAV ptsAudio deltaA deltaDisc
8470619536 -87835 -87835 8470531701 43200 19440 19440 8470551141 111595 111595 8470662736 19440 -92155 -92155 8470570581 43200 17280 17280 8470587861 118075 118075 8470705936 19440 -98635 -98635 8470607301
Columns ptsVideo and ptsAudio show you the PTS seen on PES packets with the specified content. deltaV and deltaA show the difference in PTS of consecutive packets of the specified type. Finally, deltaAV shows the difference between two consecutive packets of different type and deltaDisc results in the difference of two consecutive packets.
A few words how xine works: xine's metronom dictates when audio frames respecitively video images need to be sent to the hardware. Therefore the metronom generates virtual presentation time stamps (vpts). vpts and the PTS of the stream are related and differ by vpts_offset. vpts_offset is calculated when xine's demuxer sees the first PTS of the stream and later, when the demuxer sees the PTS of stream jump. A typical jump happens when the 33 bit PTS counter overflows which happens about every 26.5 hours.
When the demuxer indicates a discontinuity, a special buffer element is put on both the video and the audio fifo. Then when audio and video decoder process this element, both decoders wait for the other to reach this state too. At this point, all packets with PTS before the jump have been processed and it is now safe to compute vpts_offset with the new PTS when the jump was detected. After that, any further PTS after the wrap will be transformed into a vpts that is continuous (vpts is a 64 bit counter and doesn't see a wrap in a humans life).
demux_mpeg_pes's wrap detection code considered the wrap of video PTS and audio PTS independently. I. e., it indicated a discontinuity when either deltaV or deltaA where larger then WRAP_THRESHOLD (default 120000). The code relied on the wrap to happen on consecutive audio and video packets, i. e. it didn't work properly in the case where after a video discontinuity an audio packet with a PTS value before the wrap was seen. The example below shows this more clearly (PTS is considered to be just a single digit):
works for: V7 A7 V8 V9 A9 V0 V1 A1 V2 V3 A3 didn't work: V7 V8 A7 V9 V0 A9 V1 V2 A1 V3 V4
In such a case an audio jump was detected and output was hold for about 26.5 hours.
As it was almost impossible to reorder audio and video packets in a way that the original constraint of the code was fulfilled, I've modified the wrap detection code in demux_mpeg_pes for vdr-xine-0.7.3: it nolonger determines the wrap by independently looking on audio respectively video PTSs.
Instead it simply looks on the delta of two consecutive PTS values (see column deltaDisc in the above table). This fixed the problem for my sample stream where a real wrap happend. Let's repeat the above example:
works for: V7_A7_V8_V9_A9:V0_V1_A1_V2_V3_A3 works for: V7_V8_A7_V9:V0:A9:V1_V2_A1_V3_V4
Legend: _ indicates a delta below WRAP_THRESHOLD and : a delta above this value. Now, up to three discontinuities are indicated to xine's metronom to properly decode the area V9:V0:A9:V1.
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.
Even negative. In this example, when dA goes to approx -100000, dV goes also negative. At this phase, the "bad frame" messages appear:
This is the effect of xine seeking the stream to catch up. Negative values indicate that xine want's already display frames that vdr-xine has not even got from VDR to send it to xine. One could take this number as latency time of the connection VDR -- vdr-xine -- xine.
You might also want to play with xine's demuxer. Locate WRAP_THRESHOLD in xine-lib/src/demuxers/demux_mpeg_pes.c:54 and reduce this value to 90000 (i. e. smaller than the above reported diff). Feel free to experiment with this value, e. g. increase it.
With 90000, the problem is still there. Putting 50000 makes this problem much worse. With 200000, the dA seems to depend on the channel (mux?). For "YLE TV1", it seems mainly float around 30000, while "the Voice" shows around 70000 (the same as with YLE and WRAP_THRESHOLD 120000).
I'll keep the 200000 for a while now and see how it looks like.
It is true that the total buffer differs from channel to channel. There is even a difference when you switch to the same channel again. It has to do with xine seeking to skip the PTS difference between the first audio and video packet.
vdr-xine's extra buffering tries to compensate this effect but the resulting buffer still differs. vdr-xine-0.7.4 will have a new softstart algorithm that takes into account the absolute buffer established. And it may also take into account the latency of the connection to further reduce the number of dropped frames when switching channels.
Bye.
Hi,
Joerg Riechardt wrote:
since I switched from 0.7.2 to 0.7.3 I have again and again the following problem: when I go from replay mode to fast forward (or fast backward) by pressing right (or left) on the remote, the picture stops and only after a while I see the fast forward running picture (or backward). Sometimes I have to wait rather long, then the number n in CLEAR(n) was higher than 40. The output looks like below, and the stop seems to be at the CLEAR, the higher n, the longer.
This is a known issue and I'll try to fix it.
vdr: osdflush: n: 3, 23.0 +++ CLEAR(10) --- CLEAR(10) vdr: osdflush: n: 1, 9.1
The number beneath CLEAR is just a sequence number. Before other fixes I had the problem that xine got stuck within the opening (+++) and the closing (---) CLEAR, but vdr-xine got stuck within a different CLEAR, too.
Bye.
Hi,
Stefan Lucke wrote:
@Reinhard: If you are interested in such a sample I can send you one. It is rather short (only 4 to 5 GOPs) but very helpful for AFD testing.
Feel free to send it to me privately or maybe just an URL.
Bye.
hi,
Reinhard Nissl writes:
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).
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)?
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.
yours, Jouni
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.
hi,
Reinhard Nissl writes:
How does a set top box cope with that channel?
I don't have one. I'll try to find time next weekend to make some more tests. I also might make some deltaAV statistics collection for the channel then.
yours, Jouni
hi,
I have started some kind of statistics collection.
Reinhard Nissl writes:
If you run xine with --verbose=2, do you see a discontinuity reported at that time, maybe in conjunction with an audio jump?
I have now used this with WRAP_THRESHOLD = 200000 and made some statistics from YLE TV1. It seems that different channels vary here a lot - I'll make some more tests.
See:
http://www.netlab.hut.fi/~kex/vdr-xine.html
Also:
It seems that I got now two audio jumps in 50mins, and you see the deltaAV values. The stats gathering stuff is still going on, and I'll update that page later.
If you have an idea on what would be a good thing to watch, I can try and collect that info, too.
The audio jumps in this case seem to happen for some other reason - see log excerpt:
ptsVideo: 5859333790, ptsAudio: 5859271851, ptsPCM: -1, ptsDolby: -1, ptsXine: 5859212243, dV: 121547, dA: 59608, dP: 0, dD: 0 load_plugins: plugin mad will be used for audio streamtype 01. load_plugins: plugin dxr3-mpeg2 failed to instantiate itself. video_out_xv: VO_PROP_INTERLACED(0) load_plugins: plugin mpeg2 will be used for video streamtype 00. audio_alsa_out:open pause_resume=1 output sample rate 48000 audio jump, diff=0 video_out_xv: VO_PROP_INTERLACED(0) osd: can't find out current locale character set video_out: throwing away image with pts 66254 because it's too old (diff : 29609). video_out: throwing away image with pts 68054 because it's too old (diff : 28620). video_out: throwing away image with pts 69854 because it's too old (diff : 27088). input_vdr: flush buffers (vb: 0, ab: 0, vf: 0, af: 0) done. prebuffer=0 pts video_out_xv: VO_PROP_INTERLACED(0) video discontinuity #4, type is 0, disc_off 0 waiting for audio discontinuity #4 ao_close audio_out: no streams left, closing driver audio discontinuity #4, type is 0, disc_off 0 waiting for in_discontinuity update #4 vpts adjusted with prebuffer to 99321 input_vdr: flush buffers (vb: 0, ab: 0, vf: 0, af: 0) done. prebuffer=0 pts ao_flush (loop running: 1) video discontinuity #5, type is 0, disc_off 0 waiting for audio discontinuity #5 audio discontinuity #5, type is 0, disc_off 0 waiting for in_discontinuity update #5 vpts adjusted with prebuffer to 250142 osd: can't find out current locale character set osd: can't find out current locale character set set_speed 750000 video discontinuity #6, type is 2, disc_off 5674956190 waiting for audio discontinuity #6 audio discontinuity #6, type is 2, disc_off 5674956190 waiting for in_discontinuity update #6 vpts adjusted with prebuffer to 275892 video_out_xv: VO_PROP_INTERLACED(0) load_plugins: plugin mpeg2 will be used for video streamtype 00. set_speed 723000 video_out_xv: VO_PROP_INTERLACED(0) set_speed 610504 osd: can't find out current locale character set video_out: throwing away image with pts 284892 because it's too old (diff : 7691). video_out: throwing away image with pts 286692 because it's too old (diff : 5891). video_out: throwing away image with pts 288492 because it's too old (diff : 4091). video_out: throwing away image with pts 290292 because it's too old (diff : 2291). set_speed 406734 set_speed 219492 set_speed 151509 set_speed 186515 load_plugins: plugin mad will be used for audio streamtype 01. audio_alsa_out:open pause_resume=1 output sample rate 48000 set_speed 750000 audio jump, diff=12259 video jump set_speed 743915 video_out: throwing away image with pts 319092 because it's too old (diff : 7214). video_out: throwing away image with pts 320892 because it's too old (diff : 5414). video_out: throwing away image with pts 322692 because it's too old (diff : 3614). video_out: throwing away image with pts 324492 because it's too old (diff : 1814). set_speed 673031 set_speed 520034 set_speed 347636 set_speed 269462 set_speed 167740 set_speed 159165 set_speed 235632 set_speed 404240 set_speed 560476 set_speed 769202 set_speed 929870 set_speed 1000000 200 frames delivered, 6 frames skipped, 11 frames discarded osd: can't find out current locale character set video_out: throwing away image with pts 12634692 because it's too old (diff : 38605). video_out: throwing away image with pts 12641892 because it's too old (diff : 32436). fixing sound card drift by 3648 pts video_out: throwing away image with pts 12674292 because it's too old (diff : 2757). fixing sound card drift by 2787 pts fixing sound card drift by 2087 pts 200 frames delivered, 23 frames skipped, 3 frames discarded fixing sound card drift by 1562 pts osd: can't find out current locale character set fixing sound card drift by -1250 pts fixing sound card drift by -1250 pts fixing sound card drift by -1250 pts fixing sound card drift by -1250 pts fixing sound card drift by -1250 pts fixing sound card drift by -1250 pts fixing sound card drift by -1250 pts fixing sound card drift by -1250 pts fixing sound card drift by -1250 pts fixing sound card drift by -1250 pts fixing sound card drift by -1250 pts fixing sound card drift by -1250 pts fixing sound card drift by -1250AFD present: 8 ptsVideo: 5859333790, ptsAudio: 5859291291, ptsPCM: -1, ptsDolby: -1, ptsXine: 5859231613, dV: 102177, dA: 59678, dP: 0, dD: 0
yours, Jouni
-
Joerg Riechardt -
Jouni Karvo -
Reinhard Nissl -
Stefan Lucke