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

[Michael Niedermayer]

On Thu, May 28, 2009 at 07:44:45PM +1200, Paul Kendall wrote:
> On Tuesday 26 May 2009 09:26:50 pm Paul Kendall wrote:
> > Further investigation shows that the parser was being closed in
> > av_estimate_timings_from_pts. This was after the parser had run and
> > changed the codec_id to CODEC_ID_AAC from CODEC_ID_LATM. When
> > av_read_frame was then called it had no parser so it created one,
> > an AAC parser.
> >
> > I have attached a patch that in the two places where this was happening
> > it gets an ID from the parser, closes the parser and constructs a new
> > one with the previous parser's ID so even though there is a new codec_id
> > it will use the previous/correct parser type.
> >
> > Hopefully this patch is acceptable for what needs to be done.
> >
> > Cheers,
> > Paul
> 
> Any comments on this patch?

ive already said that seperate codec_ids require amongth other things a
full review of all code using codec_id [that is each use of codec id has
to be checked if it should use the prefilter or postfilter codec_id
as well as changes to the bitstream
filter API, maybe ive been unclear but you will have to do this review,
if you insist on being able to change codec_ids in a bitstream filter.
And thats just the closest i see to what you are doing, you cannot just
add a second codec id that selects the parser, that one is fundamentally
wrong besides it isnt going to work, being able to change codec ids (which
of course includes multiple changes) in bitstream filters is one of several
options as ive written in my other mail

You are just hacking places that outright fail with an approuch that is
broken to begin with.

The big problem seems to be that you try very hard not to implement this
cleanly, sorry but if you try to do something that isnt supported by the
API that needs the API to be extended not just randomly a variable added
in some random struct and then all places that outright fail with a 
single test case be hacked randomly.

For ffmpeg the different solutions all are usefull indepenant of each
other, chaining demuxers is nice to have, and so is being able to change
codec ids in bitstream filters.


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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- 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/20090528/dc4ab614/attachment.pgp>