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

[Baptiste Coudurier]

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:
>>>
>>>> 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.

Again, you may not care, but other people do.
We do play a large amount of AVI files with broken headers and
incomplete headers. We attempt to play MPEG files with bits missing
because it is in some way possible. It's your choice.

>> 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.

But it's not, and we decide to support them when it's reasonable.

>> 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...

How many files existing in the wild, in percentage do you support ?
PCM, DTS, AC3, DVD, Blu-ray, and so on.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org