[vdr] softdevice A/V sync

Tony Houghton h at realh.co.uk
Thu Jan 26 22:00:52 CET 2006

Having got softdevice working recently (with Matrox G450 TV out), I've
used it to watch a couple of films I've recorded. On one of them it
seemed fine, but on the other there was a noticeable delay between audio
and video. Every so often the picture would go sort of jerky for a few
seconds as if it were dropping frames to try to get back in sync, but
failing. The amount of delay seemed fairly consistent.

I had a similar problem with MPlayer (except the periods of jerking)
until someone told me to try -ao oss because it's buggy with alsa. Is
softdevice's audio code based on MPlayer's, perhaps?

libsoftmpeg's IDEAS file
mentions adjusting the speed of sound playback (presumably by
resampling) to avoid buffer xruns if the sound card's clock doesn't
quite match the broadcast stream's. I think this resampling idea could
be used to approach A/V sync from a different angle.

The curent problem is that existing players are designed to play the
sound at a certain rate and then sync the picture to it. That means if
video playback is also synced to vblank, and you can't control the video
card's clock, you have to drop or repeat frames to adjust the picture
timing. If you don't bother syncing video frame changeovers to the
hardware vblank it tends to cause "tearing" artifacts for progressive
scan video, and is pretty disastrous for interlaced video.

So seeing as there's a need to keep the video in sync with the hardware,
why not base the playback timing on the video and adjust the sound to
match it instead of the other way round? There are plenty of resampling
libraries already available. You may still need to drop/repeat frames to
keep up with a broadcast stream, but this approach could offer an
improvement and avoid sound glitches from xruns if the video card's
clock is a closer match to the source than the sound card's - in my PC
I'd trust the Matrox more than its £5 sound card, but users with good
sound cards just may be better off with the current method. For playback
of recordings though I think my idea should give smoother results.

TH * http://www.realh.co.uk

More information about the vdr mailing list