I second that, please don't let it drop again.. Is anyone actually working on this, Klaus, Oliver, ANYONE? Even the sync on live BBC1 on DVB-T in the UK drifts regularly out of sync and the only way to fix it is to channel change, this is with the latest CVS drivers and the latest firmware. Older firmware seems to improve things. Regards, Morfsta On 10/27/06, Chad Flynt <hoochster@xxxxxxxxxx> wrote: > > Hadn't heard any more on this, did anyone get ahold of the mplayer > source or the softplay source to find out how things are working in > it? Just didn't want the subject to get dropped again heh. > > C.Y.M wrote: > > >Torgeir Veimo wrote: > > > > > >>On 24 Oct 2006, at 12:44, C.Y.M wrote: > >> > >> > >> > >>>Somehow, mplayer is able to detect the areas in the VDR recordings > >>>that need > >>>extra "padding" to keep the sync. There must be some kind of pattern > >>>in the > >>>data that the player recognizes and it knows it must insert a null > >>>frame. How > >>>to go about finding how it works and creating an algorithm. > >>> > >>> > >>So you're certain that it's always picture frames being dropped, causing > >>audio to be behind the video? > >> > >> > >> > > > >>From what I understand, it could be either video or audio that is using > >"stacked" data. Either a video frame that does not "change" or perhaps a > few > >seconds of silence on the audio track could trigger this. > > > >Best Regards. > > > >_______________________________________________ > >vdr mailing list > >vdr@xxxxxxxxxxx > >http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > > > > > > > _______________________________________________ > vdr mailing list > vdr@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.linuxtv.org/pipermail/vdr/attachments/20061027/bbf13e62/attachment.htm
