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
