On Wed, Feb 21, 2007 at 11:12:43PM +0100, Reinhard Nissl wrote:
Actually, I don't know how this is done in the case of a FF card and what the firmware has to do in this regard. A guess -- which could explain the issues you see -- would be that sync is not maintained continuously. So after having maintained sync for some time, audio and video frames are simply taken out of some FIFOs at a constant rate and presented to the user -- this should keep audio and video in sync as originally maintained. But when then for example an audio frame gets lost due to a lost TS packet, audio and video get out of sync as the lost packet brakes filling the FIFOs at a constant rate. When you try to reproduce this effect by seeking back in the recording, then sync is maintained actively and you don't see this issue again at that position in the recording.
If the resulting Mpeg-Audio stream is broken in such a way that the HW-Decoder runs into trouble from which it can not recover the Audio HW_buffer gets emptied very fast which .. in fact .. results in a silent but very fast video sequence. For the next firmware I've added a dectection of such an unrecoverable audio decoder error to restart the audio decoder as fast as possible.
Btw: With xine and mplayer I hear a short noise and nothing happen with the running picture. Maybe the mplay software decoder its self has some checking about the Mpeg-Audio stream and the AV synchronization does not depend on the audio PTS.
Werner