[MPlayer-dev-eng] Lots of stuff for NUT

[Rich Felker]

On Fri, Dec 30, 2005 at 09:10:02PM +0200, Oded Shimon wrote:
> This means, to seek, you must do these steps:
> Go to S2, linear seek until you either:
> 1. pass P
> OR
> 2. you find a syncpoint AND (S1-S2) is more than max_distance.

I don't see how 2 makes sense.

> 6. seperate control and stream flags in frame code
> 
> Especially now with EOS, we have flags which just control frame codes 
> (invalid and msb filesize) and flags which control the actual stream (key 
> and EOS). To make an "absoloute minimal" frame code table you need atleast 
> 4 codes, not 1, to accomodate for all the EOS and key combinations. I 
> partially agree that they should be seperated, but in this manner - to 
> avoid bloating the frame code table, they should still be under the same 
> variable, "flags", however another flag can be set, saying that you can 
> only set the stream flags right before the frame. (key or EOS)
> So, uhh, new set of flags... I've reordered them to what i think is more 
> logical order...
> 0x01 - msb size
> 0x02 - set flags right before frame
> 0x04 - invalid frame code
> stream flags
> 0x08 - keyframe
> 0x10 - EOS

Maybe reordering is not necessary..?

> 7. real back ptr is back ptr / (10 + number of streams)
> 
> The smallest amount of space a syncpoint can take:
> 
> <8 byte startcode> <1 byte pts> <1 byte per back ptr> <1 byte frame code>
> 
> That's (10+number of streams), back ptr can divide by that, it actually 
> does make the index about 1kb smaller or so...

Saving 1k out of 80k is rather pointless, and this is rather ugly.
It's nice to keep multiplication and division to a minimum anyway for
small implementations (even tho I know it's already needed for
timebase).

> 8. syncpoints too big?
  [...]
> Rich had the idea of "stream group" which makes a group of streams be 
> treated effectively as one for all back ptr purposes. Not so good...

Yes I hate this idea...

> If nobody replies to this mail I'm gonna be so pissed...

:)))))))))))

Rich