mplayer SVN plays video too fast on FreeBSD

[Tom Evans]

On Tue, Dec 8, 2009 at 7:29 PM, Tom Evans <tevans.uk at googlemail.com> wrote:
> On Tue, Dec 8, 2009 at 3:44 PM, Tom Evans <tevans.uk at googlemail.com> wrote:
>> On Tue, Dec 8, 2009 at 3:14 PM, Robert Noland <rnoland at freebsd.org> wrote:
>>> On Mon, 2009-12-07 at 19:14 +0000, Tom Evans wrote:
>>>> 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!
>>>
>>> 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.
>>>
>>
>> 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
>>
>
> 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;