[MPlayer-dev-eng] A few minor things about NUT

[Rich Felker]

On Sun, Jan 29, 2006 at 07:43:09AM +0200, Oded Shimon wrote:
> > > i will never agree to a spec which has less then 3 copies of the critical
> > > headers
> > 
> > I agree it's good to have copies of the headers, but I don't like the
> > basic conformance requirements not being locally verifiable. For
> > example if you start playing a network stream, and stop it before you
> > reach the third header repetition, did you just play an invalid nut
> > file? :)
> 
> How do you even comply to this rule. My muxer puts headers at begginning, 
> at end, and the very first at 8MB, so for small files it doesn't comply and 
> wouldn't even know how to... Just repeat the headers twice at end? That's 
> illegal I think. (Headers are always followed by syncpoint, and this is 2 
> syncpoints with no data between them)

Nonsense; who ever said headers are followed by a syncpoint?! They're
followed by SOME type of startcode, which may be a syncpoint or
anything else.

So I think you can comply by writing the headers twice at the very
end, but I agree it's stupid..

> What do you do with the syncpoint that must appear after headers at EOF?.. 
> Just checksum the syncpoint pts and ptr?

This is complete and utter nonsense!!! Why the fuck would you have a
syncpoint that's not before frames? It's illegal!!

Syncpoint may come ONLY immediately before a frame. It must come
before a frame if the previous packet was anything except a frame
(e.g. a header). Perhaps this is where you got this nonsense idea
from?

> > Agree 4byte checksum is ok if you want it. The problem of course is
> > not that we _need_ a checksum, just that we need a little bit of
> > delocalization to ensure that the startcode didn't happen to be right
> > before the start of corruption. (I'm not proposing this, but a fixed
> > 32bit startcode or splitting the startcode into two pieces at the
> > beginning and end of the syncpoint should work just as well.)
> 
> It makes it much harder to find by binary search...

I said I wasn't proposing it, just that it's equivalent in some sense.

> 
> > > > > > What do you mean by max dts-pts difference?..
> > > > > 
> > > > > every frame has a dts and a pts, i mean their maximum difference which is
> > > > > max_b_frames(+1) or so for mpeg1/2/4
> > > > 
> > > > Right.. this will be quite useless for non delayed streams as dts=pts 
> > > > always, so if anything i suggest max (abs) difference from last pts...
> > > 
> > > ok
> > 
> > I assume this is only an "if known" property?
> 
> Of course.

OK.

Rich