[FFmpeg-cvslog] r19173 - trunk/libavformat/adtsenc.c

[Reimar Döffinger]

On Tue, Jun 30, 2009 at 11:08:16AM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> 
> > On Tue, Jun 30, 2009 at 11:44:33AM +0200, Benjamin Larsson wrote:
> >> Reimar D?ffinger wrote:
> >> > Huh? That may be true for the particularly ugly formats, but there
> >> > should be quite few formats/codecs where it doesn't.
> >> > Also, a libavcommon wouldn't help a bit with that issue, so it that
> >> > seems irrelevant in this discussion...
> >> 
> >> Most stuff is broken without codecs.
> >
> > Examples? Also I think it is possible to have the parser without the
> > codecs, though I think it currently doesn't save much space.
> > What are the codecs needed for except containers that contain
> > insufficient data (basically MPEG-*)?
> 
> MPEG-* contains sufficient data to pass the elementary streams to the
> correct decoder.  Stop claiming otherwise.

Yes, but the libavformat API currently promises more AFAIK: properly
split frames, at least some reasonable values for width/height/fps etc.
So for libavformat MPEG-* does not contain sufficient data. Whether the
conclusion is to wish for MPEG-* containers to die or to change
libavformat or something in-between is a different question.
Anyway in this case libavformat depends on libavcodec due to the API,
adding a libavcommon will not help there.
Anyway I don't want to lead a container-codecs-etc. flame war, the
question was what advantage would it have to make libavformat not link
against libavcodec _by adding and only adding a libavcommon_.
I don't see a point, since libavcodec can be reduced to sufficient size
except for the cases where we simply need codec code to make libavformat
behave as it _currently_ is supposed to behave.