I'm not sure if it's been answered yet, but I thought I'd throw this out: mplayer uses either LAVC or FAME [depending on how mplayer was compiled/configured] to convert EVERYTHING to MPEG1 before it is sent to the DVB Device. In essence, it transcodes in realtime. Not too efficient, but since transcoding to MPEG 1 takes little resources, most people probably don't notice. I know it's probably what most of you didn't want to hear, but I figured you guys would want to know. whoman421 On 11/3/06, VDR User <user.vdr@xxxxxxxxx> wrote: > > I joined the mplayer mailing list and have tried to seek help/information > from those nice folks.. The following is part of one of my exchanges. > Maybe the part about the timestamp may be of some help? > > > I asked a couple specific questions and included some quotes from other > > posts to provide an idea of what we're looking at as the cause. I can't > > tell you what the exact problem is because we're still trying to figure > that > > out... And a good place to start is by comparing the differences > between > > the software that has the problem and software that doesn't. We're > > trying to figure out what mplayer does, if anything, with regards to > > repacking, the pes layer, pcr data, etc. during the "playback" of a VDR > "recording". > > nothing particular: the pes packetization is as standard as you can get, > except that IIRC there's a timestamp on every single frame, > rather than once every 0.5-0.7 seconds; this fact alone can make a > lot of difference during playback. > Does the desync that you are experiencing get worse with time or does > it regularly decrease and next increase? > > > _______________________________________________ > 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/20061103/ba9af51f/attachment.htm
