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