[FFmpeg-devel] [PATCH] seperate parser from codec selection

[Michael Niedermayer]

On Tue, May 26, 2009 at 06:56:14PM +1200, Paul Kendall wrote:
> On Tuesday 26 May 2009 02:02:09 pm Michael Niedermayer wrote:
> > On Sun, May 17, 2009 at 03:25:22PM +1200, Paul Kendall wrote:
> > > This patch allows an AVStream to specify a parser_id separately to the
> > > codec_id. This will be useful for streams such as DVB-T which has AAC
> > > audio which may be contained in an LATM multiplexed stream.
> > >
> > > The patch will fall-back to using the codec_id for parser selection if
> > > the parser_id is set to CODEC_ID_NONE, which is the default.
> >
> > I do not like having 2 codec ids.
> >
> > [...]
> >
> > >      enum CodecID codec_id; /* see CODEC_ID_xxx */
> > > +    enum CodecID parser_id; /* see CODEC_ID_xxx */
> >
> > even less so without any documentation
> >
> > [...]
> Micheal, would it be preferable to make a new enum for parsers such as 
> PARSER_ID_xxx?

no

fields are not just random numbers to be hacked as needed for each issue
without thought about the semantical effect.

codec_id represents the format of the bitstream

Either it is the same for the various AAC variants, in which case all code
claiming to support CODEC_ID_AAC should also support all AAC variants (as they
are implicated by the codec_id)

OR

there are 2 AAC codec_ids in which case there are at least 2 options
A. find a way to chain demuers cleanly, each would have its own codec_id
   clearly seperated
B. extend the API of bitstream filters so they can change codec_id and
   add have a pre and post automatic bitstream filtering codec_id, this
   requires review and adjustment of all code using codec_id

There maybe other options, but CODEC_ID_AAC cannot mean different things
depending on where its used that would be a too obscure design, that noone
would understand.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090526/90707e90/attachment.pgp>