-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 11 Apr 2004, Darren wrote:
> it must be, I guess I'm not using the nvidea timebase though as the
> video is provided from the northbridge chipset which I think is S3
I used to use an S3 ProSavage (onboard my Via chipset motherboard) and
hacked up a kernel module to provide a /dev/nvidia device which Myth could
use to vsync correctly - if you're using that chipset I'll see if I can
dig out the code for you. I'm not using that card anymore - I put an
nVidia MX440 in the box and found the CPU usage was quite a bit lower, and
it interpolates the video when resizing (which the S3 didn't do), so I've
stuck with that.
> based. Anyway the reason I think its working is that when I start
> viewing a channel, I can see the audio is out of sync and hear it warp
> into sync (it sounds quite funny on a music channel). The main thing for
> me is that the video is smooth.
It should remember the average warp factor from the last time you played a
video to reduce the amount of warping it needs to do at the start, but
you're right that you can hear it warp the A/V into sync at the start and
that's something I never got around to fixing. I need to have another
look at the code when I have time, maybe it would be an idea to make it do
the usual frame rescheduling instead of warping the audio for the first
few frames just to get it all in sync to start with.
> I would like to know more about how this mechanism works, so Steve, if
> you have some time can you contact me off list to discuss it. Failing
> that, can you point me to the significant section of code.
Basically, Myth usually uses the sound card's onboard timebase to
determine how fast everything happens. This leads to a constant audio
rate, but since all the clocks in the computer run at a very slightly
different speed it needs to tweak the video frame scheduling slightly
every so often to keep th audio and video in sync. The video timebase
algorithm plays the video at a constant rate and adjusts the audio play
speed instead to keep everything in sync. If your monitor is refreshing
at about the same rate as the video's frame rate then tweaking the video
scheduling means either skipping a frame entirely or extending a frame to
double it's length, which can be noticable. If your monitor is refreshing
at many times the frame rate of the video then this isn't a problem.
The patch against version 0.13 is on my website:
http://www.nexusuk.org/projects/pvr/patches/videotimebase.php
Have a look through that since it makes it very easy to identify the bits
of code responsible. The algorithm was basically done through a bit of
trial and error to see what works best - the "warpfactor" value is
basically the ratio of the audio:video speeds that we want (so a
warpfactor of 1 makes the audio play at the same speed as the video, 2
would make it play twice as fast, 0.5 would make it play half as fast,
etc. The warping of the audio is done in the
NuppelVideoPlayer::AddAudioData() function by copying the audio data into
a new buffer and removing or duplicating samples where necessary.
The warpfactor is calculated in the NuppelVideoPlayer::WarpFactor()
function - this was the trial and error bit. The current system works by
maintaining an average of the warpfactor over a long period of time (10
minutes). It then works out how much it needs to warp the audio from that
average to make the audio and the video converge and also tries to reduce
the amount we'll overshoot (i.e. if the audio is lagging the video then we
can speed up the audio for a while, but if we speed it up too much or for
too long then we'll overshoot and the audio will start to get ahead of the
video). The WarpFactor() function then clips the change in warpfactor to
quite a small amount to try and reduce the amount of warping we can hear -
too large a difference is very noticable, too small a difference and it'll
take too long for the audio and video to converge.
Let me know if any of that didn't make sense :)
- --
- Steve http://www.nexusuk.org/
Servatis a periculum, servatis a maleficum - Whisper, Evanescence
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Public key available at http://www.nexusuk.org/pubkey.txt
iD8DBQFAelCT5zUOsIV3bqERAmP+AJ9GyF/OdgtX4VECpe9MWnNsnCkKrQCghdOl
wnsc9kXIpr+zugM8Rl+5JhE=
=q+ZF
-----END PGP SIGNATURE-----