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. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@xxxxxx
