Udo Richter wrote: > C.Y.M wrote: >> If the answer to this question could be discovered, then problem >> solved. So, >> what you are suggesting is VDR is not doing something that mplayer is >> doing that >> fixes the problem. Hmmmmmm... so then it is not a driver or firmware >> issue >> after all?? Could we agree that much? :) > > I wouldn't go that far. For this concrete case, since it is limited to > one specific channel, there's a good chance that the encoding of the > channel breaks some standards limitation. > There's also most likely nothing wrong on VDR, as VDR is basically just > forwarding data streams. If mplayer does a better job, then its probably > more like a bug workaround. > Generally, things would be a lot better if the driver/firmware would do > A/V resyncing constantly and not just at playback start. That way, A/V > desync wouldn't built up, and desync would only happen for a short time. How come you make the conclusion that this is limited to one specific channel? To my understanding there are multiple channels where this problem occurs. The best to start solving this problem is to try to figure out what happens with the recordings that are correct but still cause desync problems. This has been suggested already by many readers. Since it seems that only few people have access to the firmware source code the debugging is quite limited.. Br, Pasi
