mplayer SVN plays video too fast on FreeBSD

[Tom Evans]

Hi all

I sent this to the mplayer mailing list earlier today, without
thinking that probably someone on multimedia@ has tried to compile
mplayer from svn. Has anyone succesfully managed to do it? - and get a
working player out of it!

Cheers

Tom

---------- Forwarded message ----------
From: Tom Evans <***@googlemail.com>
Date: Mon, Dec 7, 2009 at 2:13 PM
Subject: mplayer SVN plays video too fast on FreeBSD
To: mplayer-***@mplayerhq.hu


Hi all

Nvidia recently released a video driver for FreeBSD 8/amd64 (which was
previously unsupported by nvidia). With this, amd64 users finally got
access to libvdpau.

As such, I wanted to recompile mplayer with support for vdpau.
Unfortunately, the packaged version of mplayer in freebsd is
'mplayer-0.99.11_14' (which comes from MPlayer-1.0rc2.tar.bz2), which
doesn't know about vdpau, so I set about to compile from tip of svn.

So, I checked out mplayer trunk, r29977, and made a few changes to
support compilation on FreeBSD (see attached diff). The program built
and compiled successfully, but every file I play through it has the
video processed way too fast.

It almost looks as though it is trying to benchmark the video by
playing it as fast as possible. A 40 minute TV episode only takes
about 3 minutes to play through! The audio playback was correct, no
distortions.

My configure line for mplayer was:

--enable-png --enable-menu --disable-tv-v4l1 --disable-tv-v4l2 \
--disable-dvdnav --disable-ssse3 --disable-directfb --disable-faac \
--disable-twolame --disable-mencoder --disable-mad --disable-libdv \
--disable-theora --disable-musepack --enable-libdca --enable-speex \
--disable-xanim --disable-live --disable-xmms --disable-jack --disable-nas \
--disable-openal --disable-smb --disable-fribidi --disable-cdparanoia \
--disable-libcdio --disable-ladspa --disable-liblzo
--enable-runtime-cpudetection \
--disable-win32dll --disable-qtx --enable-real
--realcodecsdir=/usr/local/lib/win32 \
--enable-gui --extra-cflags="-I/usr/local/include/freetype2
-I/usr/local/include" \
--enable-freetype --disable-rtc --disable-arts --disable-caca --disable-lirc \
--disable-sdl --disable-svga --disable-aa --disable-esd \
--disable-joystick --extra-libs="-L/usr/local/lib -ldca" \
--prefix=/usr/local --mandir=/usr/local/man --target=amd64-srcbld-freebsd8.0 \
--enable-vdpau

My ~/.mplayer/config looks like:

vo=vdpau,xv
#vo=xv
vc=ffh264vdpau,ffvc1vdpau,ffmpeg12vdpau,ffwmv3vdpau,
cache=65536
fs=1
afm=hwac3

The effect is noticed with vo=vdpau,xv or with vo=xv and vc commented
out. It didn't appear to matter what video was being played, I tried
mkv/x264, avi/xvid and mpeg2/mpeg2ts.

Any ideas?

Cheers

Tom

[Andrius Morkūnas]

Post by Tom Evans
I sent this to the mplayer mailing list earlier today, without
mplayer from svn. Has anyone succesfully managed to do it? - and get a
working player out of it!

I've seen quite a lot of reports of working SVN mplayer on FreeBSD and I've
yet to run into a version that doesn't build/work, but I don't update mplayer
too often.

My setup on amd64:
$ svn diff
Index: vidix/pci.c
===================================================================
--- vidix/pci.c (revision 29978)
+++ vidix/pci.c (working copy)
@@ -481,7 +481,7 @@
#include "sysdep/pci_arm32.c"
#elif defined(__powerpc__)
#include "sysdep/pci_powerpc.c"
-#elif defined(__x86_64__) || defined(__sh__)
+#elif (defined(__x86_64__) || defined(__sh__)) && !defined(__FreeBSD__)
/* Nothing here right now */
#else
#include "sysdep/pci_x86.c"

$ cat build
#!/bin/sh
./configure --extra-cflags=-DBROKEN_RELOCATIONS
gmake -j2

In case you just updated your drivers and compiled mplayer, you may want to
restart FreeBSD, because I've had some issues (not similar to yours) until I
restarted after installing xorg.

Also, did you try building without infinity of configure args?

[Tom Evans]

Post by Andrius Morkūnas

Post by Tom Evans
I sent this to the mplayer mailing list earlier today, without
mplayer from svn. Has anyone succesfully managed to do it? - and get a
working player out of it!

I've seen quite a lot of reports of working SVN mplayer on FreeBSD and I've
yet to run into a version that doesn't build/work, but I don't update mplayer
too often.
$ svn diff
Index: vidix/pci.c
===================================================================
--- vidix/pci.c (revision 29978)
+++ vidix/pci.c (working copy)
@@ -481,7 +481,7 @@
 #include "sysdep/pci_arm32.c"
 #elif defined(__powerpc__)
 #include "sysdep/pci_powerpc.c"
-#elif defined(__x86_64__) || defined(__sh__)
+#elif (defined(__x86_64__) || defined(__sh__)) && !defined(__FreeBSD__)
 /* Nothing here right now */
 #else
 #include "sysdep/pci_x86.c"
$ cat build
#!/bin/sh
./configure --extra-cflags=-DBROKEN_RELOCATIONS
gmake -j2
In case you just updated your drivers and compiled mplayer, you may want to
restart FreeBSD, because I've had some issues (not similar to yours) until I
restarted after installing xorg.
Also, did you try building without infinity of configure args?
--
Andrius

Most of the changes in that diff are fbsd fixes - I'm a bit surprised
your mplayer works properly/efficiently without the bswap fix (it will
be using the naive C version). I'll try recompiling the whole package
with -DBROKEN_RELOCATIONS. I don't think the number of configure
options are affecting it, but I'll try a minimal version as well, just
to see.

Thanks

Tom

[Andrius Morkūnas]

Post by Tom Evans
Most of the changes in that diff are fbsd fixes - I'm a bit surprised
your mplayer works properly/efficiently without the bswap fix (it will
be using the naive C version). I'll try recompiling the whole package
with -DBROKEN_RELOCATIONS. I don't think the number of configure
options are affecting it, but I'll try a minimal version as well, just
to see.
Thanks
Tom

Not the number of configure options, but maybe there is a particular option
that causes problems, and with so many of them, it's hard to tell.
Afaik -DBROKEN_RELOCATIONS is amd64-only thing, I didn't see what arch you
are running on (maybe I just fail at reading). Considering the number of
patches it looks like i386, since last time I checked it required more work
(local patches) than amd64 version.
I'm not an expert and I didn't look at local patches for mplayer too much,
just making it compile was the goal, and it works now. Performance is good.
It's not significantly faster/slower than whatever I've tried on Windows.

[Tom Evans]

Post by Andrius Morkūnas

Post by Tom Evans
Most of the changes in that diff are fbsd fixes - I'm a bit surprised
your mplayer works properly/efficiently without the bswap fix (it will
be using the naive C version). I'll try recompiling the whole package
with -DBROKEN_RELOCATIONS. I don't think the number of configure
options are affecting it, but I'll try a minimal version as well, just
to see.
Thanks
Tom

Not the number of configure options, but maybe there is a particular option
that causes problems, and with so many of them, it's hard to tell.
Afaik -DBROKEN_RELOCATIONS is amd64-only thing, I didn't see what arch you
are running on (maybe I just fail at reading). Considering the number of
patches it looks like i386, since last time I checked it required more work
(local patches) than amd64 version.
I'm not an expert and I didn't look at local patches for mplayer too much,
just making it compile was the goal, and it works now. Performance is good.
It's not significantly faster/slower than whatever I've tried on Windows.
--
Andrius

It's amd64 - I actually already had -DBROKEN_LOCATIONS as one of the
diffs, in the libavcodec Makefile. This was to apply it to the whole
build and see if it helped - it didn't :/

I applied all the patches that were in the ports directory that were
sane and still valid as far as I could tell from the new code and the
cvs log of the patch - most weren't necessary any more, but I guess
the FreeBSD specific bug fix ones hadn't been merged upstream.

Can you tell me what revision you are currently running? I'll try that
revision, see if it works and bisect the breaking change. svnversion
in the checkout, or I think it is printed each time you run mplayer.

Cheers

Tom

[Andrius Morkūnas]

Post by Tom Evans

Post by Andrius Morkūnas

Post by Tom Evans
Most of the changes in that diff are fbsd fixes - I'm a bit surprised
your mplayer works properly/efficiently without the bswap fix (it will
be using the naive C version). I'll try recompiling the whole package
with -DBROKEN_RELOCATIONS. I don't think the number of configure
options are affecting it, but I'll try a minimal version as well, just
to see.
Thanks
Tom

Not the number of configure options, but maybe there is a particular option
that causes problems, and with so many of them, it's hard to tell.
Afaik -DBROKEN_RELOCATIONS is amd64-only thing, I didn't see what arch you
are running on (maybe I just fail at reading). Considering the number of
patches it looks like i386, since last time I checked it required more work
(local patches) than amd64 version.
I'm not an expert and I didn't look at local patches for mplayer too much,
just making it compile was the goal, and it works now. Performance is good.
It's not significantly faster/slower than whatever I've tried on Windows.
--
Andrius

It's amd64 - I actually already had -DBROKEN_LOCATIONS as one of the
diffs, in the libavcodec Makefile. This was to apply it to the whole
build and see if it helped - it didn't :/
I applied all the patches that were in the ports directory that were
sane and still valid as far as I could tell from the new code and the
cvs log of the patch - most weren't necessary any more, but I guess
the FreeBSD specific bug fix ones hadn't been merged upstream.
Can you tell me what revision you are currently running? I'll try that
revision, see if it works and bisect the breaking change. svnversion
in the checkout, or I think it is printed each time you run mplayer.
Cheers
Tom

$ mplayer | head -n 1
MPlayer SVN-r29975-4.2.1 (C) 2000-2009 MPlayer Team
$ uname -sr
FreeBSD 8.0-STABLE

You may want to discuss this with mplayer guys, maybe it's a known issue
and not FreeBSD-specific.

[Tom Evans]

Post by Tom Evans
Most of the changes in that diff are fbsd fixes - I'm a bit surprised
your mplayer works properly/efficiently without the bswap fix (it will
be using the naive C version). I'll try recompiling the whole package
with -DBROKEN_RELOCATIONS. I don't think the number of configure
options are affecting it, but I'll try a minimal version as well, just
to see.
Thanks
Tom

I tried

configuration: --extra-cflags=-DBROKEN_RELOCATIONS
-I/usr/local/include/freetype --enable-freetype --enable-vdpau

I had to apply your vidix fix (don't think that was being compiled
before). Same behaviour as before, video is far far too fast.

I also reverted the other patches, leaving just your vidix fix, the
fix to enable bswap and the fix to ao_oss - exactly the same result.

Cheers

Tom

[Robert Noland]

Post by Tom Evans
Hi all
I sent this to the mplayer mailing list earlier today, without
mplayer from svn. Has anyone succesfully managed to do it? - and get a
working player out of it!

I haven't tried mplayer from SVN, but the video playing too fast issue
is your audio codec. mplayer (and gstreamer, iirc) seem to set the
frame rate based on the audio. Generally, what I have seen is that
people with ATI/AMD (radeon) video cards with HDMI ports end up with the
HDMI port as dsp0. If you aren't running the radeonhd driver with the
AUDIO option set, the codec isn't initialized properly and so the video
plays too fast. To correct this issue, usually all you need to do is
set the sysctl hw.snd.default_unit to the correct pcm device. Basically,
if you have the following:

balrog% cat /dev/sndstat
FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
Installed devices:
pcm0: <HDA ATI R6xx HDMI PCM #0 HDMI> at cad 0 nid 1 on hdac0 kld
snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
pcm1: <HDA Analog Devices AD1989B PCM #0 Analog> at cad 0 nid 1 on hdac1
kld snd_hda [MPSAFE] (1p:4v/1r:2v channels duplex default)
pcm2: <HDA Analog Devices AD1989B PCM #1 Analog> at cad 0 nid 1 on hdac1
kld snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
pcm3: <HDA Analog Devices AD1989B PCM #2 Digital> at cad 0 nid 1 on
hdac1 kld snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
pcm4: <HDA Analog Devices AD1989B PCM #3 Digital> at cad 0 nid 1 on
hdac1 kld snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)

Setting "sysctl hw.snd.default_unit=1" will choose the primary analog
pcm for audio output and mplayer will work fine.

robert.

Post by Tom Evans
Cheers
Tom
---------- Forwarded message ----------
Date: Mon, Dec 7, 2009 at 2:13 PM
Subject: mplayer SVN plays video too fast on FreeBSD
Hi all
Nvidia recently released a video driver for FreeBSD 8/amd64 (which was
previously unsupported by nvidia). With this, amd64 users finally got
access to libvdpau.
As such, I wanted to recompile mplayer with support for vdpau.
Unfortunately, the packaged version of mplayer in freebsd is
'mplayer-0.99.11_14' (which comes from MPlayer-1.0rc2.tar.bz2), which
doesn't know about vdpau, so I set about to compile from tip of svn.
So, I checked out mplayer trunk, r29977, and made a few changes to
support compilation on FreeBSD (see attached diff). The program built
and compiled successfully, but every file I play through it has the
video processed way too fast.
It almost looks as though it is trying to benchmark the video by
playing it as fast as possible. A 40 minute TV episode only takes
about 3 minutes to play through! The audio playback was correct, no
distortions.
--enable-png --enable-menu --disable-tv-v4l1 --disable-tv-v4l2 \
--disable-dvdnav --disable-ssse3 --disable-directfb --disable-faac \
--disable-twolame --disable-mencoder --disable-mad --disable-libdv \
--disable-theora --disable-musepack --enable-libdca --enable-speex \
--disable-xanim --disable-live --disable-xmms --disable-jack --disable-nas \
--disable-openal --disable-smb --disable-fribidi --disable-cdparanoia \
--disable-libcdio --disable-ladspa --disable-liblzo
--enable-runtime-cpudetection \
--disable-win32dll --disable-qtx --enable-real
--realcodecsdir=/usr/local/lib/win32 \
--enable-gui --extra-cflags="-I/usr/local/include/freetype2
-I/usr/local/include" \
--enable-freetype --disable-rtc --disable-arts --disable-caca --disable-lirc \
--disable-sdl --disable-svga --disable-aa --disable-esd \
--disable-joystick --extra-libs="-L/usr/local/lib -ldca" \
--prefix=/usr/local --mandir=/usr/local/man --target=amd64-srcbld-freebsd8.0 \
--enable-vdpau
vo=vdpau,xv
#vo=xv
vc=ffh264vdpau,ffvc1vdpau,ffmpeg12vdpau,ffwmv3vdpau,
cache=65536
fs=1
afm=hwac3
The effect is noticed with vo=vdpau,xv or with vo=xv and vc commented
out. It didn't appear to matter what video was being played, I tried
mkv/x264, avi/xvid and mpeg2/mpeg2ts.
Any ideas?
Cheers
Tom
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia

[Tom Evans]

Post by Robert Noland

Post by Tom Evans
Hi all
I sent this to the mplayer mailing list earlier today, without
mplayer from svn. Has anyone succesfully managed to do it? - and get a
working player out of it!

I haven't tried mplayer from SVN, but the video playing too fast issue
is your audio codec.  mplayer (and gstreamer, iirc) seem to set the
frame rate based on the audio.  Generally, what I have seen is that
people with ATI/AMD (radeon) video cards with HDMI ports end up with the
HDMI port as dsp0.  If you aren't running the radeonhd driver with the
AUDIO option set, the codec isn't initialized properly and so the video
plays too fast.  To correct this issue, usually all you need to do is
set the sysctl hw.snd.default_unit to the correct pcm device. Basically,
balrog% cat /dev/sndstat
FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
pcm0: <HDA ATI R6xx HDMI PCM #0 HDMI> at cad 0 nid 1 on hdac0 kld
snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
pcm1: <HDA Analog Devices AD1989B PCM #0 Analog> at cad 0 nid 1 on hdac1
kld snd_hda [MPSAFE] (1p:4v/1r:2v channels duplex default)
pcm2: <HDA Analog Devices AD1989B PCM #1 Analog> at cad 0 nid 1 on hdac1
kld snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
pcm3: <HDA Analog Devices AD1989B PCM #2 Digital> at cad 0 nid 1 on
hdac1 kld snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
pcm4: <HDA Analog Devices AD1989B PCM #3 Digital> at cad 0 nid 1 on
hdac1 kld snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
Setting "sysctl hw.snd.default_unit=1" will choose the primary analog
pcm for audio output and mplayer will work fine.
robert.

Thanks Robert, the mplayer list also said that mplayer syncs to audio,
so I've got a few things to check there tonight :)

I'm not using radeonhd or hdmi, I have an amplifier connected to the
onboard snd_hda via spdif, and use spdif pass through if available on
the source. I already specify hw.snd.default_unit=2, since that is
seemingly the correct device:

FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
Installed devices:
pcm0: <HDA VIA VT1708S_0 PCM #0 Analog> at cad 0 nid 1 on hdac0 kld
snd_hda [MPSAFE] (1p:1v/1r:1v channels duplex)
pcm1: <HDA VIA VT1708S_0 PCM #1 Digital> at cad 0 nid 1 on hdac0 kld
snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
pcm2: <HDA VIA VT1708S_0 PCM #2 Digital> at cad 0 nid 1 on hdac0 kld
snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex default)

Audio plays correctly for both AC3 and MP3 audio tracks in both
mplayer svn and the port. I wonder if it is possible the codec on this
snd_hda card is slightly 'strange' and doing something out of the
ordinary - maybe I'll have a browse of the linux azalia driver and see
if they have any quirks for it.

Cheers

Tom

[Tom Evans]

Post by Tom Evans

Post by Robert Noland

Post by Tom Evans
Hi all
I sent this to the mplayer mailing list earlier today, without
mplayer from svn. Has anyone succesfully managed to do it? - and get a
working player out of it!

I haven't tried mplayer from SVN, but the video playing too fast issue
is your audio codec.  mplayer (and gstreamer, iirc) seem to set the
frame rate based on the audio.  Generally, what I have seen is that
people with ATI/AMD (radeon) video cards with HDMI ports end up with the
HDMI port as dsp0.  If you aren't running the radeonhd driver with the
AUDIO option set, the codec isn't initialized properly and so the video
plays too fast.  To correct this issue, usually all you need to do is
set the sysctl hw.snd.default_unit to the correct pcm device. Basically,
balrog% cat /dev/sndstat
FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
pcm0: <HDA ATI R6xx HDMI PCM #0 HDMI> at cad 0 nid 1 on hdac0 kld
snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
pcm1: <HDA Analog Devices AD1989B PCM #0 Analog> at cad 0 nid 1 on hdac1
kld snd_hda [MPSAFE] (1p:4v/1r:2v channels duplex default)
pcm2: <HDA Analog Devices AD1989B PCM #1 Analog> at cad 0 nid 1 on hdac1
kld snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
pcm3: <HDA Analog Devices AD1989B PCM #2 Digital> at cad 0 nid 1 on
hdac1 kld snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
pcm4: <HDA Analog Devices AD1989B PCM #3 Digital> at cad 0 nid 1 on
hdac1 kld snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
Setting "sysctl hw.snd.default_unit=1" will choose the primary analog
pcm for audio output and mplayer will work fine.
robert.

Thanks Robert, the mplayer list also said that mplayer syncs to audio,
so I've got a few things to check there tonight :)
I'm not using radeonhd or hdmi, I have an amplifier connected to the
onboard snd_hda via spdif, and use spdif pass through if available on
the source. I already specify hw.snd.default_unit=2, since that is
FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
pcm0: <HDA VIA VT1708S_0 PCM #0 Analog> at cad 0 nid 1 on hdac0 kld
snd_hda [MPSAFE] (1p:1v/1r:1v channels duplex)
pcm1: <HDA VIA VT1708S_0 PCM #1 Digital> at cad 0 nid 1 on hdac0 kld
snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
pcm2: <HDA VIA VT1708S_0 PCM #2 Digital> at cad 0 nid 1 on hdac0 kld
snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex default)
Audio plays correctly for both AC3 and MP3 audio tracks in both
mplayer svn and the port. I wonder if it is possible the codec on this
snd_hda card is slightly 'strange' and doing something out of the
ordinary - maybe I'll have a browse of the linux azalia driver and see
if they have any quirks for it.
Cheers
Tom

Ok, I've made a few more tests. It seems that the problem only comes
about when I run mplayer svn with '-ao oss -afm hwac3'. If I run with
'-ao none' or with '-ao oss' (ie playing 2 channel pcm out over the
digital output), then the video plays back at the correct rate.

Just to reiterate, all of those options work correctly with the
version in ports - if only that supported vdpau :)

Alexander, is this like anything you have come across before with the
snd_hda driver? I have bootverbose logs of snd_hda if that helps[1].

Cheers

Tom

[1] http://pastebin.ca/1707268

[Tom Evans]

Post by Tom Evans

Post by Tom Evans

Post by Robert Noland

Post by Tom Evans
Hi all
I sent this to the mplayer mailing list earlier today, without
mplayer from svn. Has anyone succesfully managed to do it? - and get a
working player out of it!

I haven't tried mplayer from SVN, but the video playing too fast issue
is your audio codec.  mplayer (and gstreamer, iirc) seem to set the
frame rate based on the audio.  Generally, what I have seen is that
people with ATI/AMD (radeon) video cards with HDMI ports end up with the
HDMI port as dsp0.  If you aren't running the radeonhd driver with the
AUDIO option set, the codec isn't initialized properly and so the video
plays too fast.  To correct this issue, usually all you need to do is
set the sysctl hw.snd.default_unit to the correct pcm device. Basically,
balrog% cat /dev/sndstat
FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
pcm0: <HDA ATI R6xx HDMI PCM #0 HDMI> at cad 0 nid 1 on hdac0 kld
snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
pcm1: <HDA Analog Devices AD1989B PCM #0 Analog> at cad 0 nid 1 on hdac1
kld snd_hda [MPSAFE] (1p:4v/1r:2v channels duplex default)
pcm2: <HDA Analog Devices AD1989B PCM #1 Analog> at cad 0 nid 1 on hdac1
kld snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
pcm3: <HDA Analog Devices AD1989B PCM #2 Digital> at cad 0 nid 1 on
hdac1 kld snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
pcm4: <HDA Analog Devices AD1989B PCM #3 Digital> at cad 0 nid 1 on
hdac1 kld snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
Setting "sysctl hw.snd.default_unit=1" will choose the primary analog
pcm for audio output and mplayer will work fine.
robert.

Thanks Robert, the mplayer list also said that mplayer syncs to audio,
so I've got a few things to check there tonight :)
I'm not using radeonhd or hdmi, I have an amplifier connected to the
onboard snd_hda via spdif, and use spdif pass through if available on
the source. I already specify hw.snd.default_unit=2, since that is
FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
pcm0: <HDA VIA VT1708S_0 PCM #0 Analog> at cad 0 nid 1 on hdac0 kld
snd_hda [MPSAFE] (1p:1v/1r:1v channels duplex)
pcm1: <HDA VIA VT1708S_0 PCM #1 Digital> at cad 0 nid 1 on hdac0 kld
snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex)
pcm2: <HDA VIA VT1708S_0 PCM #2 Digital> at cad 0 nid 1 on hdac0 kld
snd_hda [MPSAFE] (1p:1v/0r:0v channels simplex default)
Audio plays correctly for both AC3 and MP3 audio tracks in both
mplayer svn and the port. I wonder if it is possible the codec on this
snd_hda card is slightly 'strange' and doing something out of the
ordinary - maybe I'll have a browse of the linux azalia driver and see
if they have any quirks for it.
Cheers
Tom

Ok, I've made a few more tests. It seems that the problem only comes
about when I run mplayer svn with '-ao oss -afm hwac3'. If I run with
'-ao none' or with '-ao oss' (ie playing 2 channel pcm out over the
digital output), then the video plays back at the correct rate.
Just to reiterate, all of those options work correctly with the
version in ports - if only that supported vdpau :)
Alexander, is this like anything you have come across before with the
snd_hda driver? I have bootverbose logs of snd_hda if that helps[1].
Cheers
Tom
[1] http://pastebin.ca/1707268

I've discovered the problem, reverting a sound rate fix in mplayer's
libao2/ao_oss.c fixes it. Sorry to bother anyone.

Cheers

Tom

PS:

For posterity, it is this change that broke it:

------------------------------------------------------------------------
r29750 | cladisch | 2009-10-05 08:42:02 +0100 (Mon, 05 Oct 2009) | 1 line

fix calculation of ao_data.bps for sample formats with more than 16 bits
------------------------------------------------------------------------
Index: libao2/ao_oss.c
===================================================================
--- libao2/ao_oss.c (revision 29749)
+++ libao2/ao_oss.c (revision 29750)
@@ -396,8 +396,19 @@
}

ao_data.bps=ao_data.channels;
- if(ao_data.format != AF_FORMAT_U8 && ao_data.format != AF_FORMAT_S8)
+ switch (ao_data.format & AF_FORMAT_BITS_MASK) {
+ case AF_FORMAT_8BIT:
+ break;
+ case AF_FORMAT_16BIT:
ao_data.bps*=2;
+ break;
+ case AF_FORMAT_24BIT:
+ ao_data.bps*=3;
+ break;
+ case AF_FORMAT_32BIT:
+ ao_data.bps*=4;
+ break;
+ }

ao_data.outburst-=ao_data.outburst % ao_data.bps; // round down
ao_data.bps*=ao_data.samplerate;