[MPlayer-dev-eng] Audio visualization

[Alban Bedel]

On Sun, 17 Feb 2008 20:36:42 +0100
Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:

> Hello,
> On Sun, Feb 17, 2008 at 08:30:45PM +0100, Alban Bedel wrote:
> > On Sun, 17 Feb 2008 18:51:34 +0100
> > Benjamin Zores <ben at geexbox.org> wrote:
> > > What's the status of this finally ?
> > > Is it planned to get in someday ?
> > 
> > Good question. I think the solution I implemented could be accepted
> > as it's not very obstrusive. But as no one commented it is hard to
> > tell.
> 
> I assumed that my opinion is clear: A demuxer calling a decoder is a
> horrible breaking of layering

I see it more as a demuxer filter ;) I don't find it pretty either, but
it is currently the simplest way imho.

> and implementing it as vd makes it
> really hard to pass any options at all without making everything
> global options.

Well, that's a lack from the vd api. It could be fixed.

> Now a different question is what a nice way to do this would be.

If you drop the "demuxer filter" mplayer.c will need quiet some
modifications to still setup a video chain when sh_video == NULL.
Then the audio decoding would need to be modified to also feed the
video chain. A/V sync will probably need some change too (I want
visuals with perfect A/V sync).

All in all, I'm not yet convinced that such approch would be worse it.
It sound like quiet a burden for a minor feature.

> For that part of the question would also be what kind of information
> the visualization needs and in which cases it is most important to
> work. Since the IMGFMT_AUDIO idea was not liked, a different
> possibility would be IMGFMT_GRAY16, where the audio could be placed
> each channel in one line.

I think this is a moot point. Even if the visuals are vf, they have to
be at the start of the chain. So you can use any API you like to ask
them to generate a frame, and such "image format" are never needed.

But if we do end up with mp_image containing audio data at some point,
I would obviously vote for IMGFMT_AUDIO over a perversion of an
existing format.

> Supporting anything besides s16le and some
> fixed samplerate would not (easily, non-hackishly) be possible like
> this though.

Independently of how we interface it with mplayer, we will need an API
similar to the vd for the visuals. And I think it would be a good idea
that it include a format converter/resampler for commons PCM formats.
We can't expect visuals to support many formats and forcing the
soundcard to use what the visual need is obviously not an option.

> This would need some more changes to mplayer.c though.

Way too much imho, but I may still investigate such a solution.

> On the plus side, it would make things like -vf rgbtest less of a
> pain to use at the same time though.

I doubt it, but we'll see.

	Albeu