[Ffmpeg-devel] Containers

[Måns Rullgård]

Steve Lhomme <steve.lhomme at free.fr> writes:

> M?ns Rullg?rd wrote:
>> Steve Lhomme <steve.lhomme at free.fr> writes:
>>
>>> Rich Felker wrote:
>>>> On Fri, Apr 28, 2006 at 06:17:39PM +0200, Steve Lhomme wrote:
>>>>>> Matroska is overly complicated and bloated.
>>>>> What do you find complicated ?
>>>>>
>>>>> Given 3 developers wrote their own parser simply based on the one
>>>>> HTML page of specs.
>>>> And how many lines of code is their parser? It's fucking huge!!
>>>> Even if it were simple, a parser is only a tiny part of a demuxer. The
>>>> complicated part is the semantics.
>>> Haali's splitter (used in the official DShow splitter and in TCPMP) is
>>> smaller than the parser in FFMPEG and handles far more semantics and
>>> codecs.
>> That sentence alone is proof that matroska is a flawed format.  A
>> demuxer should not need any specific handling of different codecs
>> beyond a simple table of codec identifiers.
>
> Well, I spend a lot of time thinking about what a container is. And I
> came to a different conclusion. Apparently I'm not alone since in
> GStreamer ID3 tags are considered a container and I think they are
> right, it's probably the most minimalist container.

ID3v2 can rightfully be considered a container, albeit a bad one.
It's not even particularly suitable for its intended purpose.  In
fact, it doesn't even have a well-defined purpose.

>> If you think lines of code are important, consider these line counts
>> for a few demuxers I have written myself purely based on the specs:
>> matroska 1808
>> avi      1094
>> ogg      1147
>> mpeg ps   688
>> mpeg ts   842
>> The matroska demuxer handles only the basics (reading and seeking),
>> and makes no attempts to recover from errors in the file.  The others
>> are complete with error recovery.
>> I'm not claiming that my code is particularly efficient or well
>> written, but I suspect that all code I write is of similar quality.  I
>> thus believe that the line counts may indicate something about the
>> complexity of those formats.
>
> Given ogg is unusable without parsing the codec data I don't think
> it's fair to compare it.

The number above includes codec handling for vorbis, theora, flac, and
the bastard ogm format.  The ogg parser core is 576 lines, one for
each scanline in a PAL video.

> And I wouldn't compare containers as they have different designs,
> goals, good sides and bad sides. For example in that list only AVI
> and matroska have seek entry (optional in matroska as most of it)
> and can do chapters (theoretical in AVI).

What we are saying is that we have tried and failed to find *any* good
sides of matroska.  It's nothing personal, we just don't like bloat.

-- 
M?ns Rullg?rd
mru at inprovide.com