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