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: firstname.lastname@example.org> 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