[MPlayer-dev-eng] adding a phase-vocoder to mplayer

[bruce m beach]

>> Okay so it looks like you just go into libaf and according to
>> numerous examples, the whole thing is straight-forward, except
>> for af_data_t->len. I assume it is the length of the audio data
>> arriving at the audio filter. The question is what are the typical
>> lengths arriving (i.e a few bytes, several k) and can len be controlled
>> at all. This is because to do the DFTs blocks of data are needed.
>
> In case you are still interested:
> 1) Consider developing it on top of FFmpeg, it is more active,
> though admittedly its filters are not usable in MPlayer, so
> it might not make sense for you.
> 2) You can only assume you always get full samples. If you need
> more than you get you need to buffer it. But note that for
> efficiency reasons MPlayer will try to give you fairly large
> chunks, at least 0.2s but possible 1 second or more.
> But in the end, it is the output module that controls it (and other
> filters in the chain).
Hello Reimar,

I have it running, using the xine library, too satisfy my particular
and simple needs. I run a separate thread for a sound server, get the
video and sound in sync and once in sync they stay in sync. This only
works on the arm processor because it is a SOC. There is the master
clock and all clocks are derived from it. The codec itself phase locks
to the audio clock coming out of the SOC at whatever audio rate is
happening. (Philips S-bus). The problem with FFmpeg right now is that
the granularity is a little to fine for my needs right now.

As for Mplayer, I think that however the data sizes are arriving it
really is a non-problem, since no matter what I still have to buffer
the data. Leaving aside stereo, and datasizes and all that, just
consider that I need to do a 1024 dft and 1025 bytes are in the just
arrived buffer. Do you see that I perform the dft on the first 1024
bytes which is turned into 3072 bytes (for a stretch of 3) and passed
back to the caller. Now the byte 1025 is moved to the beginning of the
pipe and I need to insert 1023 bytes into the pipe from the next call
and so on always cacheing the data and feeding 1024 bytes at a time
into the pipe, passing the resulting data back to the caller.

To find out, the approach would be to simply replace the scaletempo
code with mine, modifying to accept the data as described above.

btw The stretch_factor is a floating point number. If it > 1 then
it slows the sound down (again without pitch change ) by that factor.
If it is 0 < stretch_factor < 1 the the sound speeds up by that
factor.

Bruce


On 3/7/17, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> Hello,
>
> On Wed, Jan 25, 2017 at 05:46:40PM -0800, bruce m beach wrote:
>> On 1/16/17, bruce m beach <brucembeach at gmail.com> wrote:
>> > Hello Everybody
>> >
>> >   I have a a vocoder program that I have written up that works
>> > reasonably well that slows sound by some factor ( say 5 times slower,
>> > whatever you like ) with good fidelity, far better than the current
>> > scaletempo that currently exists. I would like to add it in the style
>> > of 'scaletempo' to mplayer, i.e. something like
>> >
>> >   mplayer -speed 0.25 what_ever_parameters_for_the_vocoder
>> >
>> > so that when you watch the movie at 1/4 speed the sound is properly
>> > tracking and am wondering if somebody can point me in the right
>> > direction to whatever I need to know to do this.
>> >
>> > Bruce
>> >
>>   Okay so it looks like you just go into libaf and according to
>>   numerous examples, the whole thing is straight-forward, except
>>   for af_data_t->len. I assume it is the length of the audio data
>>   arriving at the audio filter. The question is what are the typical
>>   lengths arriving (i.e a few bytes, several k) and can len be controlled
>>   at all. This is because to do the DFTs blocks of data are needed.
>
> In case you are still interested:
> 1) Consider developing it on top of FFmpeg, it is more active,
> though admittedly its filters are not usable in MPlayer, so
> it might not make sense for you.
> 2) You can only assume you always get full samples. If you need
> more than you get you need to buffer it. But note that for
> efficiency reasons MPlayer will try to give you fairly large
> chunks, at least 0.2s but possible 1 second or more.
> But in the end, it is the output module that controls it (and other
> filters in the chain).
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng