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

[Oded Shimon]

On Fri, Dec 30, 2005 at 03:11:33PM -0500, Rich Felker wrote:
> 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.

Damnit, I gave that part much thought, and forgot it all, now I need to 
re-think it.

S2 K ........ S1 ... P

if S1-S2 is bigger than max_distance, than by my rule, if there is a 
keyframe before P, there must be a syncpoint after S1. So, good.
Keep going from S2 to the nearest syncpoint, as you always must.

if S1-S2 is smaller than max_distance, then my rule doesn't even apply here 
and you can have just about anything. You must keep going until you hit P.

S2 K ........ S1 .. K P

^ this CAN happen with my rule, just scale this whole picture down so it's 
smaller than max_distance.

I think, you can also stop when you reach max_distance from S2... No, until 
you reach max_distance from last K.

It's a very minimal gain in the linear search, but you can stop when:

S2 K .......... S1 ......... P
   ^==== max_distance ==> X

You Can stop when you reach X instead of when you reach P. Whichever.

> > 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..?

I guess, whatever.
Having them in a common variable is sane in regards to space, but 
completely confusing in having one part of the flags being able to appear 
only in frame code, and the the other part being able to be set right 
before frame.

> > 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).

Ok, whatever. /8 is pretty in regards to >>3 anyway. :)

> > 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...

What do you think of the other idea, with the common pts thing. I think 
it's good, it removes completely redundant syncpoints.

- ods15