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

[Måns Rullgård]

Baptiste Coudurier <baptiste.coudurier at gmail.com> writes:

> M?ns Rullg?rd wrote:
>> Baptiste Coudurier <baptiste.coudurier at gmail.com> writes:
>> 
>>> M?ns Rullg?rd wrote:
>>>> Baptiste Coudurier <baptiste.coudurier at gmail.com> writes:
>>>>
>>>>> On 6/30/2009 3:08 AM, 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.
>>>>>>
>>>>> Really ?
>>>>>
>>>>> 1110 xxxx ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 or
>>>>> ISO/IEC 14496-2 video stream number xxxx
>>>>>
>>>>> How do you know which codec it is except by parsing the elementary stream ?
>>>> You don't need to know:
>>>>
>>>>   8.1       ISO/IEC 11172-2 compatibility
>>>>   ISO/IEC 11172-2 "constrained parameter" bitstreams shall be
>>>>   decodable by Simple, Main, SNR Scalable, Spatially Scalable and High
>>>>   profile decoders at all levels. Additionally Simple, Main, SNR
>>>>   Scalable, Spatially Scalable and High profile decoders shall be able
>>>>   to decode D-pictures-only bitstreams of ISO/IEC 11172-2 which are
>>>>   within the level constraints of the decoder.
>>>>
>>> You missed the 14496-2 detail :)
>> 
>> That's only allowed if there's a PSM saying so.
>> 
>
> Well, here you drop support for albeit broken files in the wild, which
> is not a direction we want to follow for now.
>
> This does not apply to TS, hwoever users complained about no support for
> TS missing PMT while stream could be still identified correctly (codec
> probing for example).

I don't care about invalid files.  Do we play AVI files with the
header missing?  No.  So why should we attempt to play MPEG files with
bits missing.

> Not talking about tens way of storing codecs like AVS, AC-3, DTS, PCM
> and I miss some.

Those are not part of the ISO standard.  Don't blame the standard for
unofficial extensions.  Those could have been much more cleanly, for
instance by using a proper registration descriptor.

> Really I don't think MPEG* < 4 provides sufficient data to pass
> elementary streams to the decoder decoder reliably.

Funny thing then, that this is precisely what I do almost every day...

-- 
M?ns Rullg?rd
mans at mansr.com