[NUT-devel] Suggestions [PATCH]

[Rich Felker]

On Wed, Mar 01, 2006 at 01:53:21AM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Tue, Feb 28, 2006 at 05:51:31PM -0500, Rich Felker wrote:
> > On Tue, Feb 28, 2006 at 10:34:22PM +0100, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > the Attached patch does the following:
> > > 
> > > 1. cleanup packets so all have forward_ptr
> > > significantly improves extendability and simplifies stuff
> > > slightly larger overhead (~0.006% which is negligible)
> > 
> > I thought we came up with some reason why it didn't work or didn't
> > make sense for syncpoints (with the following frame header included..)
> 
> hmm, i remember the issue with the checksum over the syncpoint AND frame 
> header but that is fixed below, dunno if there was another issue ...

I think it was just this one.

> > > 2. split checksum into frame and syncpoint checksum
> > > simplification
> > > overhead changes by + 4byte for every packet >64kb (<0.006% worst case)
> > > overhead changes by - syncpoint size + 4 for every packet with dts_diff > 1sec

I missed this 1sec in here. I'm against ANY condition that adds a
physical time unit into NUT. It's unnecessary and limits usage to a
particular timescale (and also forces different muxing if time is
rescaled).

> > Oh, I guess this would be it... But I don't see immediately from the
> > patch how your change works. Can you explain?
> 
> add forward_ptr to syncpoint and move the checksum to the syncpoint
> add a flag to the framecode table which indicates that the frameheader has 
> its own checksum
> add a rule which says that this flag must be set if packet > 64kb or dts
> difference to last dts of last packet > 1 sec

Replace 1 sec by max_pts_diff in header and I will not adamantly
object, but I don't necessarily like it.

> > > 4. always store chapter_start/len
> > > simplification
> > 
> > Not entirely sure what you mean but my impression is that this is ok.
> 
> id like to remove the special case for the global info packets which
> dont have start/len, i mean set them to 0,0 or whatever but why
> use a different bitstream format ...
> this obviously is a very minor issue ...

Yes, I agree it's cleaner to only have one bitstream format.

> > Can the semantics I wanted be duplicated exactly with info packets
> > only? Without storing a redundant irrelevant info packet?
> > 
> 
> hmm probably, but iam not sure if iam happy about these semantics, which
> exactly do you mean? packets must be within chapter_start ... end in the
> stream? thats exactly why i dont like info_streams, theres no way to
> correct a past mistake

And likewise there's no way to correct past audio if you accidentally
said the wrong thing, or past video if you accidentally showed the
wrong thing! Historical revisionism is not part of a container's job.
Should we add a feature to let streams patch-over past audio that they
want to censor, so that when you remux the file to permenant storage
the original audio is overwritten?? :((((

I agree with making it possible to correct [errors but more
importantly omissions in] data while it's still relevant (i.e.
_during_ the frame), but being able to arbitrarily replace any past
data is blatently incorrect IMO. After the end time of the chapter,
the demuxer should _know_ that it has the final, absolute, last-word
values for the info. Otherwise you have to read eternally into the
future to make sure it doesn't change later on, even if you only want
to keep this one clip out of the file... If you're basing the clip to
extract on the info packets themselves, then you can't even know what
clip you want until you read unboundedly into the future, since its
length or start might change!

My intent with the stream semantics is that the packets actually mean
something, locally, without reading the whole file. With the system I
proposed, you know absolutely when a chapter has ended and when you
have the final correct data for it.

Rich