[vdr] cAudioRepacker error (was: xine plugin sync problems on analog channels)

[Cristiano]

Reinhard, thansk for you response but;

>> I am having some problem with vdr xine and analogtv plugin.
>>
>> I have a client-server vdr installation based on vdr 1.3.34, xine 
>> 0.7.6 plugin, when I select a DVB channel I have no problems but if I 
>> select an analog channel (stream generated by analogtv plugin 0.9.37 
>> with ivtv 0.4.0 and PVR 150 card) I had some sync problem: here is the 
>> xine log:
>>
>> audio jump, diff=-51840
>> audio_out: inserting 27627 0-frames to fill a gap of 51815 pts
>> video jump
>> bad_frame
>> video jump
>> video jump
>> bad_frame
>> video_out: throwing away image with pts 653020 because it's too old 
>> (diff : 6489
>> 9).
>> 200 frames delivered, 14 frames skipped, 1 frames discarded
>> video_out: throwing away image with pts 2753839 because it's too old 
>> (diff : 418
>> 6).
>> bad_frame
>> bad_frame
>> video jump
>> bad_frame
>> bad_frame
>> audio jump, diff=-51850
>> audio_out: inserting 27655 0-frames to fill a gap of 51866 pts
>> video jump
>> bad_frame
>> video jump
>> bad_frame
>> bad_frame
>> 200 frames delivered, 7 frames skipped, 1 frames discarded
>> video_out: throwing away image with pts 5052089 because it's too old 
>> (diff : 4544).
>> 200 frames delivered, 0 frames skipped, 1 frames discarded
>> bad_frame
>> audio jump, diff=-45370
>> audio_out: inserting 24197 0-frames to fill a gap of 45382 pts
>> video jump
>> video jump
>> video jump
>> bad_frame
>> video_out: throwing away image with pts 6157260 because it's too old 
>> (diff : 54139).
>>
>> Searching on the vdr mailing list I found a thread ("problem 
>> vdr-xine-0.7.3 plugin") that seems to be related to this issue.
>> I tried to "play" with WRAP_THRESHOLD values without good results
>>
>> Did you have any suggestion?
> 
> 
> Have a look into xineDevice.c, cXineDevice::PlayCommon3() and comment 
> out the first "if (0)" (i. e. => "// if (0)"). This enables logging of 
> PTS values on console and you can check the offset between audio and 
> video PTS as well as the offset to xine's metronom.
> 
> The offset to xine must allways be positive and should be around 60000 
> pts (= 2/3 seconds). If it gets too small or even negative, then xine 
> will get buffer underruns which may cause the above issue.
> 
> Another parameter to play with is vdr-xine's prebuffer setting. If you 
> enlarge the setting then the above offset to xine should enlarge, too. 
> But there are some drawbacks: when VDR cannot dispose its data to the 
> device, it clears the device (after consecutive poll timeouts) which 
> discards the buffers and causes vdr-xine to setup the prebuffer again 
> and again.
> 
> Especially the analogtv plugin uses "little" buffers for the encoder and 
> therefore it is likely that vdr-xine's prebuffering overflows the 
> encoder buffers which are then in turn cleared. The result is that there 
> is almost no buffer although vdr-xine thinks to have a reasonable sized 
> one (it's on my todolist to change prebuffering to consider xine's 
> metronom).
> 
> For any reason (I still haven't discovered why) there is a difference in 
> the achieveable buffer size when xine is already connected to vdr-xine 
> and you switch to an analogtv channel respectively when xine connects to 
> vdr-xine after VDR was tuned to the analogtv channel. Most often the 
> latter works without the above mentioned issue.
> 

I tried to "play" with buffers values and other parameters without any 
good results.
However I discovered a new interesting vdr log messages :

...
vdr[7985]: cAudioRepacker(0xC0): skipped 288 bytes to sync on next audio 
frame
vdr[7985]: cAudioRepacker(0xC0): skipped 288 bytes to sync on next audio 
frame
...

So, the problem seems to be related to vdr AudioRepacker, did you have 
any suggestion?
I tried a lot of vdr versions with the same issue.

Thanks
Cristiano