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

Reimar Döffinger Reimar.Doeffinger
Tue Jun 30 13:03:15 CEST 2009


On Tue, Jun 30, 2009 at 11:37:44AM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> 
> > 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.
> 
> This means that lavf is unsuitable for the files it is meant to
> handle.  Well done.

No, it means that in order to provide a more convenient API it needs
codec support to handle some containers that by themselves are a bit too
inconvenient. If that was a good choice is a different point though.



More information about the ffmpeg-cvslog mailing list