[MPlayer-DOCS] [PATCH] update -channels to match observed behavior

Corey Hickey bugfood-ml at fatooh.org
Fri Sep 2 12:07:34 CEST 2005


Reimar Döffinger wrote:
> Hi,
> On Fri, Sep 02, 2005 at 10:17:24AM +0200, Guillaume POIRIER wrote:
> 
>>Thanks Corey for taking the time to investigate on this. I don't quite
>>know what to do here. Should MPlayer behave as stated on the docs
>>(because maybe there has been a regression lately, but MPlayer used to
>>behave like the doc says), or should the doc be changed to reflect
>>MPlayer's behaviour?
>>
>>I truely don't know what do do about it.
> 
> 
> Me neither (I was the one who "broke" it).
> The problem with the stated (old) behaviour is that if you use filters like
> surround, hrtf, channels etc. you never have a chance to get it to
> behave correctly, since you set the number of channels at the beginning
> and at the end of the filter chain at the same time - but they should be
> different.

I agree with you completely here. I prefer the current behavior because
it is more flexible. I can't actually come up with any good real-world
examples here (I should be sleeping right now), so this one is a bit
contrived:

Let's say I have a DVD with 5.1 AC3 audio and a 4-speaker setup. I want
to play the DVD in stereo on the front speakers and the same stereo on
the rear speakers. Currently, I can specify -channels 2 so liba52 does a
proper downmix, and then use -af channels to copy the channels the way I
want.

$ mplayer dvd://1 -channels 2 -af channels=4:4:0:0:0:2:1:1:1:3

With mplayer's old behavior, if I remember right, -channels 2 would
cause the two rear channels to be dropped anyway. I can't say for sure
because I never really figured out how to properly manipulate channels
until very recently -- perhaps because it didn't make sense to me before
Reimar broke it. :) I somehow managed to figure it out today despite the
docs being wrong...

> On the other hand, a lot of aos still react wrong when they are asked to
> play 6 channel audio - and this is what MPlayer will currently do when
> you pass it e.g. uncompressed 6 channel pcm.
> I just can't think of a sane solution - except maybe adding yet another
> options.

I was messing with 6-channel PCM earlier. On my system (alsa and a sound
blaster live) mplayer decodes 6 channels and outputs 6 channels. What
happens when playing such a file where the sound card/driver can only
handle 2 channels? What should happen? I suppose the most tolerant
behavior would be for mplayer to automatically insert -af channels=2,
but this would result in the extra channels being discarded. Pan could
be used to downmix, but that's getting complicated and I get the
impression there's no standard for the channel order. See some samples here:
http://www.tsp.ece.mcgill.ca/MMSP/Documents/AudioFormats/WAVE/Samples.html

Maybe a reasonable compromise would be to automatically use -af
channels=2 _unless_ -channels (or -af channels) is specified on the
command line or config file. In that case it's up to the user to make
sure the output channels are correct.


In any case, I digress. As a short term solution I vote for simply
applying my docs patch. I don't know how long it's been since Reimar
changed mplayer's channel behavior but I get the impression bug reports
haven't been forthcoming. Audio filtering is somewhat obscure, though a
lot of fun now that I understand what's going on.

Time for bed.

-Corey




More information about the MPlayer-DOCS mailing list