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

[Rich Felker]

On Sun, Jul 16, 2006 at 12:11:40AM +0200, Baptiste Coudurier wrote:
> Rich Felker wrote:
> > 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.
> 
> I totally agree. It will avoid fourcc collision which might occur
> according to the specs. Even in AVI some codecs use different fourcc...
> Im also thinking about DV, DVCPRO, DV50, DVCPRO100 which need a clearly
> specified fourcc.

Not sure you understood the normative/informative distinction I was
making, but oh well. :)

> > 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.
> 
> Many format supports Timecode track which defines the timing reference
> not starting at 0 and reference GOP headers timecode in MPEG-2 for
> example. They allows non contiguous timing, and some other features.

NUT explicitly requires contiguous timestamps, or at least monotone.
You could have "jumps", but any jumps are to be interpreted as a frame
with HUGE duration so it would be very unpleasant. :) All frames have
their own timestamps.

If for some strange reason (live stream synchronization, but even then
it's not needed) you really want separate timing reference, you can
use out of band channels or the (not yet written but Michael is
working on it) supplemental NUT streaming protocol.

And if you want to know why you can't use non-monotone timestamps, it
means seeking requires a linear search of the whole file, which is
absolutely unacceptable. Also it's not even well-defined what a "seek
to time X" operation would even mean..

> >> 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.
> 
> For example QDM2 uses 2 atoms. It might be necessary to mention correct
> and clean formating.

How does lavc presently handle this? We should probably just
standardize on whatever packing format lavc uses, if anyone even cares
about QDM2 audio anymore. As long as they're not hell to parse I don't
think it's a terrible sin to keep the header in the format it was in
for its original container, MOV. We (or rather the MKV people, first,
and we copied it) did something similar with vorbis, using an Ogg-like
encoding for the 3 header packets.

> Btw all, sorry for all those points I am talking about now, Im just a
> bit late and I really want to participate in NUT revolution to the
> container world.

Yeah a bit late, but that's ok. :) Glad to have more people excited
about it. It's just that most of the issues you bring up were already
discussed in depth before, but it doesn't hurt to have them discussed
again in public so more people hear about NUT and the rationale. IMO
there's still a HUGE need for a "rationale" document with the NUT spec
so that people reading it understand why the decisions were made the
way they were.

Rich