[MPlayer-dev-eng] How to retrieve the actual number of audio channels?

[wm4]

On Tue, 25 Mar 2014 14:34:59 +0100
Ingo Brückl <ib at wupperonline.de> wrote:

> wm4 wrote on Mon, 24 Mar 2014 21:15:52 +0100:
> 
> > On Mon, 24 Mar 2014 17:20:41 +0100
> > Ingo Brückl <ib at wupperonline.de> wrote:
> 
> >> It seems that sh_audio->channels only reports the number of channels of a
> >> downmix(?):
> >>
> >>   AUDIO: 48000 Hz, 2 ch, ac3be, 448.0 kbit/29.17% (ratio: 56000->192000)
> >>
> >> How can I retrieve the information about the actual 6 channels, not just
> >> the 2 channels (which I still don't understand with AC3 pass-through
> >> S/PDIF, by the way).
> >>
> >> I would then block balance control for number of channels != 2.
> >>
> >> (This question may be related to my recent postings "Sound issue with ac3
> >> on PC speakers" on the user list.)
> 
> > Maybe this was already explained in that thread, but this is how spdif
> > works. It pretends that the audio stream is PCM, and uses a "fake"
> > audio format for that, like 2 channels at 48000Hz. What really happens
> > is that the audio stream contains compressed audio packets, framed into
> > the spdif protocol (or whatever it's called), and padded to achieve the
> > same bitrate as the "fake" audio PCM would.
> 
> Thanks for the excellent explanation. I'm finally going to understand.
> 
> If I get you right, MPlayer does this "fake" audio in order to have an
> old-fashioned audio stream (because it really hasn't one due to the
> pass-through S/PDIF). This is the reason why the "reported" audio doesn't
> play with the PC speakers, because it isn't what it pretends to be.
> 
> Right?

This is how spdif works in the first place. I don't know the history,
but it appears to be a dirty hack to transfer compressed data over a
connection that was made for PCM only. The receiver looks at the bits,
and if it finds a frame header (or whatever), it decides it's
compressed data, otherwise PCM.

> > So, these streams contain compressed packets. The only way to know to
> > what these decompress are either:
> > [...]
> > 3) rely on what libavformat returns in the stream header, since
> >    libavformat already does 1)+2) automatically
> 
> Is this what
> 
>   ==> Found audio stream: 0
>   ======= WAVE Format =======
>   Format Tag: 8192 (0x2000)
>   Channels: 6
>   [...]
> 
> does report? Since the channel information is/was available somewhere
> sometime, is there a way to (and how?) access it?

Yes. Well, I don't know (my own fork changed most of this), you probably
have to dig into sh_audio->wf. demux_lavf.c should have code to copy
these parameters from AVCodecContext into mplayer data structures.

> > Looks like you want 3)
> 
> Yes, but on the other hand, can't the "fake" audio PCM have the actual number
> of channels instead of two, since it's a fake anyway?

No, it's not entirely "fake". It needs to have the correct bitrate, and
audio APIs probably expect this format too.

> > but of course that doesn't work with the builtin demuxers used e.g. for
> > DVD.
> 
> What a bummer!
> 
> Ingo