[FFmpeg-cvslog] r19173 - trunk/libavformat/adtsenc.c
Tue Jun 30 19:34:52 CEST 2009
On 6/30/2009 3:37 AM, 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.
How so ? Can you please point at specific problems with examples ?
Libavformat can perfectly work well without libavcodec.
Now if you mean that parsing of elementary stream should be done in
libavformat instead of parser and duplicate the code to be standalone,
that's one point of view, it may be better.
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
More information about the ffmpeg-cvslog