Thanks Reinhard!Upgraded now to vdr-1.4.6-1-bigpatch + your speed up patch. 
It's working and I also see some increase in speed. I think now the limiting 
factor here on my side are the audio and video buffers of xine. If I make them 
too small, I get frame drops. But anyways: your tweak is putting switching 
speed to the limit.Regards,Martin> Date: Sun, 6 May 2007 22:23:03 +0200> From: 
[EMAIL PROTECTED]> To:> Subject: [vdr] [ANNOUNCE] VDR sync 
early patch> > Hi,> > the motivation for this patch was to speed up zapping 
channels when> using vdr-xine, i. e. to shorten the time from pressing the 
remote> button till audio and video appear.> > FF card users may only see the 
effect of this patch when the FF card is> running in transfer mode.> > The idea 
is to not wait for the first I frame in transfer mode. Although> output devices 
"can't" decode any frames before the first I frame, the> contained PTS in the 
PES packets allows the device to synchronize audio> and video even before the 
first video frame appears on screen.> > Another issue which is addressed by 
this patch is that audio packets> were not delivered to the device immediately 
after switching the> channel, so the above change didn't have any effect. 
Calling> EnsureAudioTrack() fixes this.> > How much speed up can be expected? 
Well, it varies from zap to zap as it> depends on a couple of parameters like 
the offset of audio and video> PTS, whether a PTS is available per frame, the 
number of frames till the> next I frame arrives, etc. But a speed up should be 
noticeable.> > BTW: Testers of plugin ** should comment out the following line 
in> cTSBuffer::Get() in file device.c, like that:> > //        if(!device->***) 
device->***=new c***;> > This change is highly recommended if you experience 
buffer overflows> while switching channels, though they are not related to the 
sync early> patch.> > Bye.> -- > Dipl.-Inform. (FH) Reinhard Nissl> 
Live Search: Gefunden! Tolle Bilder von Paris Hilton gibt es hier!
vdr mailing list

Reply via email to