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

[Rich Felker]

On Sat, Jul 15, 2006 at 10:49:02PM +0200, Baptiste Coudurier wrote:
> NUT system is the best one around. Still I persist to say that wraping
> specs are needed, and even more for ambiguous codecs wraping formats,
> and a fourcc for each codec recognized must be written in the specs,
> that means standardized.

Let's propose a compromise: additional information on the NUT website
or with the spec that's labelled "informative" as opposed to
"normative", clarifying what the general rules mean for particular
codecs.

> > Some nonsense things cannot be, but they won't be able to be stored in
> > any other existing container either.
> 
> DV in AVI exists. DV in MOV also, PS in MOV, who knows...

You misunderstood what I meant by nonsense things. I'm not talking
about illegal wrapping but utterly non-frame-based compression formats
and the like. Things that we should not even try to consider now
since, if they're ever made, they will probably not play by the rules
that people would expect them to at this present time.

BTW there's nothing wrong with storing DV in another container as long
as you store just video and not both audio and video muxed together as
one pseudo-stream.

> > The one line would be the same for every codec so it's pointless.
> 
> IMHO not for H264,

Yes for H264. No for vorbis; it required a tiny supplemental spec due
to incompleteness of the codec spec.

> > What about timecode ? Subtitles ?
> 
> There is no specifications in NUT specs about wraping those kind of
> data. A stream type identifier is not sufficient IMHO.

What do you mean by timecodes? I assumed you meant timestamps but
maybe something else like chapter info..?

As for subtitles, the subtitle codec_id specifies the format of the
data.

> I just read the specs again and I also do not see and decent standard to
> pack extradata for specific codec. Just put the MOV atoms in NUT ?

Extradata is a single binary data block whose format is specified by
the codec. For most codecs its obvious what it should be. For Xiph
codecs a 'supplemental codec spec' is needed, as has been discussed on
the nut devel list.

Rich