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
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
