[MPlayer-dev-eng] [PATCH] change demuxer for radio from "rawaudio" to "audio"
Alban Bedel
albeu at free.fr
Sun Jul 22 18:12:09 CEST 2007
On Sun, 22 Jul 2007 20:41:35 +0700
"Vladimir Voroshilov" <voroshil at gmail.com> wrote:
> > I'm not the maintener of that part of code but I'm against such
> > nonsense: code like that belongs to muxers. If you want to avoid
> > passing the samplerate
> > you can find cleaner solutions (STREAM_CTL/DEMUXER_CTL come to mind)
>
> There is currently only one solution except above - touching grobal
> ariables directly.
> I don't like it. Above methods looks much better.
I don't like it either, but I fully aggre with Nico. Adding a muxer to
every stream that produce raw data is definitly not the solution.
> I don't know where call such demuxer ioctl from and how STREAM_CTL
> can help me.
The stream are already reporting the format they contain when possible,
that's how the rawaudio demuxer is selected here. The correct solution
is for the demuxer to query the stream for "extanded" informations about
the data format and use it when available.
This can be done by calling a control on the stream or extanding the
stream API to allow the streams to export the extra info when they are
oppend. I would prefer the later bcs if we come around to have filters
(for gzip, text encoding conversion, etc), we will need stack of formats
(like gzip, latin1).
> Moreover such ioctls will be very demuxer-specific. There is not much
> common code.
Well, that's the whole point of control(), allowing to cleanly and
simply extands the API when needed.
> .
> There is another solution (i'm not sure is it acceptable or not) -
> create demuxer from inside stream and tweak properties of created
> sh_audio or similar structure.
That's even worse. Streams have no business assuming what the user want
to do with it, and such poking inside a demuxer wouldn't be acceptable
either.
Albeu
More information about the MPlayer-dev-eng
mailing list