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