[vdr] problem vdr-xine-0.7.3 plugin

[Reinhard Nissl]

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 at gmx.de