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.