[Ffmpeg-devel] Re: integrating AVS decoding into MPlayer

[Rich Felker]

On Sat, Jul 15, 2006 at 01:07:45PM +0200, Baptiste Coudurier wrote:
> >> IMHO people did something stupid trying to wrap every codec in every
> >> container. Sorenson 3 is contained in MOV until further notice, same for
> >> QDM2. You should not wrap them into AVI until it is standardized.
> > 
> > Nonsense. This proprietary "you should use our shitty container if you
> > want to use our codec" attitude is what MUST GO! It's the problem with
> > Xiph as well.
> 
> The other attitude produced DV in AVI crap, Vorbis in another container
> mess, fourcc collisions, FMP4 nonsense. H264 NAL reformating shit, MP3
> frame wraping shit, etc...

It produced none of these things. What produced these things was the
fact that these codecs were originally designed (by idiot designers)
to only work in one container, so that (bigger idiot) windows users
came up with obviously-incorrect ways to store them in other
containers with double-container nonsense.

What I'm talking about is very different. NUT is very specific about
how arbitrary codecs must be stored, but the same requirements that
work for NUT work for any sane container. The same frames stored in
NUT can be stored in AVI and a proper player will play them just fine.

> IMHO If a container wants to support a codec, it shall standardize it,
> and an application shall not just decide a "fourcc" and just cook
> something in his corner.

No, this is nonsense. The whole point with NUT's codec support is that
there is NO NEED for a special per-codec standard for storage. A
general rule applies to all codecs, and then no additional effort is
needed.

> Well I could persist and say that using another container is just stupid
> since a decent player will play it anyway.

The ability to play is not the question at hand. The questions are:
- efficient seeking
- error recovery
- overhead
- complete information
- pipability
- ...

> >>> Our proposal is that people adopt the fourcc system and use it in all
> >>> formats. This has nothing to do with using nasty MS data structures
> >>> (BITMAPINFOHEADER, etc.), just using a naming system that's already
> >>> human-readable, computer-efficient, and just plain sane.
> >> That is the easiest solution and IMHO the best one. Adopting a
> >> "standardized" fourcc table for NUT and maintaining it in the specs is a
> >> good choice, choosing AVI ones or MOV ones by default if fourcc exists.
> >> You need to pick MOV ones for some codecs of course.
> > 
> > Finally something we agree on. :)))
> 
> Of course and I hope NUT will be the "reference" container in a few years.

:))))))))))

Rich