[MPlayer-dev-eng] Audio visualization

Pavel Modilaynen kopli at mail.ru
Tue Feb 5 16:47:33 CET 2008


Monday, February 4, 2008, 7:04:21 PM, Alban Bedel wrote:
> On Mon, 4 Feb 2008 15:05:35 +0300
> Pavel Modilaynen <kopli at mail.ru> wrote:
>> This is the simpliest method as you can see.
>> To make this audio dependent we just need to read audio output buffer,
>> transform correspondingly and fill video buffer in this demuxer.

> I think you are missing the point that the data comming from the demuxer
> is still encoded.

It seems to be you didn't catch my idea.
I meant that in demux_audio.c: demux_audio_fill_buffer () call for
video stream (assuming we've created a faked video stream) it is
possible to read audio output buffer (just want to emphasize this -
audio output buffer with data after audio decoder).
I.e. we have raw audio samples and we can do with them whatever we
want.
We just have to deal with endiannes, sample size, sign which is
not painfull and this variety can be easily converted to one
common format (for example signed 16 bit).
Then it is trivial to draw an oscillogram of audio signal
which I've already done and it works fine.

Nevertheless I consider my current modifications a little bit hacky
and messy and I can propose this feature for mplayer in the following
preliminary form:
New files:
  - vz.c/vz.h - main audio visualization functionality (like ad.c,
  vf.c,.. ), table of visualizers, entries;
  - vz_xxx.c - visualizer's implementation itself / access to external
  libs (sticking to the conception of libmpcodecs)
  
And functionality might be the following:
  - in demux_audio.c: demux_audio_open() - check if visualization
    needed, and call vz_init () which calls appropriate
     vz_xxx.c: init ()
  - in demux_audio.c: demux_audio_fill_buffer () - check if
  visualization was enabled - pass control to vz_process() which
  calls vz_xxx.c: process ()
That is intuitively understandable imho.

I do not want to mess the MPlayer code, and my proposals I think is
a minimal harm for this great benefit that this feature gives.
But what do fathers of MPlayer developers think about it?



Thank you for your consideration.
-- 
Pavel Modilaynen




More information about the MPlayer-dev-eng mailing list