On Fri, Feb 17, 2006 at 09:47:16AM -0500, Rich Felker wrote:
On Fri, Feb 17, 2006 at 01:56:03PM +0200, Oded Shimon wrote:
On Thu, Feb 16, 2006 at 04:31:59PM +0100, Michael Niedermayer wrote:
Hi
On Wed, Feb 15, 2006 at 10:43:25PM -0500, Rich Felker wrote:
On Thu, Feb 16, 2006 at 01:10:41AM +0100, Michael Niedermayer wrote:
btw, why doesnt the syncpoint have a packet header / forward ptr !?
Because the damn thing is already way too big! :(
that makes it non-extendible which breaks one of nuts goals
IMO no.. frame headers can have arbitrary extendiblity, and syncpoints are unique - their checksum doesn't come at the end of the syncpoint, but at the following frame header...
As for forward ptr in checksum, it slightly annoys my coding because i do:
header -> temp buffer forward_ptr - length of header+4 -> file temp buffer -> file checksum of temp buffer -> file
So I'd have to somehow push the forward ptr to the begginning of the temp buffer or some other solution. It doesn't matter badly though, I'm not really against it.
But syncpoints don't need forward ptr though because they are special, they carry themselves AND the following frame header... So you'd have to do some weird thing where the forward ptr only points to the end of the syncpoint, and then there's the frame header, and THEN there is the checksum. it's ugly IMO...
This is all your implementation issue.
BTW, implementation should have some importance, if there's no way to accomplish something without ugly hacks in code it's bad. :/ But this isn't such a scenario.
If the header is enclosed in the checksum, it's natural to consider it part of the syncpoint packet anyway. Also there's no reason a checksum needs to come from just one buffer. As long as you pass a state pointer to your checksum function you can checksum arbitrarily many different buffers as if they were all connected..
Yes, I know, this is why I said I'm not against forward_ptr being in checksum, but I am against forward_ptr being in syncpoints! The point of forward_ptr being in syncpoints is to be able to add fields to syncpoints, not to frame headers, cause we already have that, right? The structure is: <startcode> <forward_ptr> <syncpoint> <reserved> <frame header> <checksum> (reserved being reserved bytes for syncpoint) Now, where the hell does the forward_ptr point to? If it points to after the checksum like all other headers, you won't know where the hell to start parsing the frame header. Pointing to right before the frame header is weird, because the checksum comes later. Putting the reserved bytes of the _syncpoint_ after the frame header is even weirder (data of syncpoint cut in two pieces??) - ods15