[MPlayer-dev-eng] [PATCH] ad_mpg123: runtime format switch and not closing stream during decodeh

[Reimar Döffinger]

On Mon, Sep 23, 2013 at 09:50:02PM +0200, Thomas Orgis wrote:
> Am Mon, 23 Sep 2013 21:16:18 +0200
> schrieb Reimar Döffinger <Reimar.Doeffinger at gmx.de>: 
> 
> > > even mixing MP2 and MP3 pieces. There, ad_mpg123 is more tolerant than
> > > ffmp3 or ffmp3float.
> > 
> > I'm quite sure I explained it somewhere... Anyway this isn't more tolerant,
> > the only issue when using ffmp3 is that ad_ffmpeg prefers the container framerate
> > over the one in the audio stream.
> > Unfortunately for raw mp3 that is complete nonsense, however for mp3 in avi for example it can be necessary to play correctly.
> 
> Well, should ad_mpg123 avoid format changes for the same reason? That
> would mean allowing libmpg123 to decode, but ignoring output until
> format matches the proper one again (whichever that is).

Sorry, this is not about formats.
Does ffmp3 have issues with format changes? That would be a bug.
I only meant sample rate.
And even there it's not that one is more correct than the other,
it's just that they work for different cases.
And no, that's not reason to change it.

> > > PS: I would like to offer default (16 bit) and floating point output,
> > > the difference being this line in ad_mpg123:
> > > 
> > > mpg123_param(con->handle, MPG123_ADD_FLAGS, MPG123_FORCE_FLOAT, 0.);
> 
> > Just to be clear, you are asking about how to add this to mpg123, not MPlayer?
> 
> No. It is an inherent feature of libmpg123 that it can produce
> differing formats. In case of s16 vs. f32 this means using different
> synth functions, in assembly for SSE and x86-64 SSE, that remove the
> need for any extra format conversion afterwards (at least on my Core2,
> it is really quicker to work with s16 in the synth, less difference on
> more modern CPUs).
> 
> What I am asking is how to best integrate this option. Would be best
> way indeed be to offer ad_mpg123.c and ad_mpg123float.c which enable
> `mplayer -ac mpg123` for default format s16 and `mplayer -ac
> mpg123float` for floating point format, without adding postprocessing
> filters (like ffmp3 and ffmp3float)? Of course, what I'd do in that
> case is to write one "template" and have the c files include it.

That is overkill to have two .c files.
You can just have two entries in /etc/codecs.conf both pointing to
ad_mpg123.
To distinguish them you can e.g. set the "dll" value which you can
read from ad_mpg123 during init as sh_audio->codec->dll

> I just wondered if there is another way to communicate preference for
> s16 or f32 before decoding. Aside performance, you could prefer f32
> also for s16 output, if MPlayer wants to do high-quality conversion to
> s16 itself ...

Well, -af-adv can be used to specify whether fixed-point or floating
point should be preferred during filtering.
Not sure whether it's a good idea to try to make decoders use that.
For video filtering you'd be using a special "format" filter to
indicate which format you want to be used, but that doesn't
work for audio since there is no format negotiation, and I
doubt you'd want to go to such extreme lengths as implementing that...