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

[Oded Shimon]

On Sat, Dec 31, 2005 at 06:02:08AM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Fri, Dec 30, 2005 at 11:19:07PM -0500, Rich Felker wrote:
> [...]
> > > > > > 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 about delta backpointer lists, so that a syncpoint can reference another
> > > syncpoint and only store the different back pointers, this other syncpoint
> > > obviously must not reference anything but contain a complete list ...
> > 
> > This will require several seek operations on the media in order to
> > complete the seeking, which is quite negative.. Consider slow media.
> 
> wait a second ...
> if you have an index you can probably do it with 1 seek assuming you have
> the index loaded, without an index it will be log n seeks anyway so IMHO
> 1 extra isnt a issue, the complexity of my suggestion might be an issue
> though

Yes, I noticed in that regard it's not so bad, we only care about what 
syncpoints say when we don't have index.

> IMHO just add backptrs with stream groups or 1 backptr for every stream
> and forget about it, people who store 100 streams dont care about overhead
> anyway

100 streams IS insane :) 10 streams, not so much, overhead will be grand 
total of 2-3mb for 700mb I expect.


In other news:

I've completed a frame code table generator! And it kicks ass quite a bit. 
Brings the overhead to 1 byte per packet in audio and 2 bytes per packet in 
video.
The general idea:

1. Store ALL possible combinations of (stream, pts diff, size, is_key) in a 
   hash, saying how many times each combination appeared.
2. Pick the top 10 items in the hash, and write explicit frame codes which 
   handle them. This just about takes care of the entire audio stream, it 
   appears almost all mp3 packets have the exact same size.
3. Take what is left in the hash, and resort by combinations of (stream, 
   size, is_key) (discard size).
4. According to how "popular" a combination is, allocate it whatever is 
   left of the ~230 frame codes where only msb needs to be written after 
   frame code. The more popular, the bigger "mul" it gets.

Here's the funny thing, in part 4, when deciding how popular a combination 
is, I had a bug at first making it decide not by how many packets there 
were with this combination, but by how many different sizes there were for 
this combinations (how many sub-combinations this combination had). It 
actually gave (slightly) BETTER results...

Does anyone have any ideas to improove this generator?
BTW, it's written in perl and it's slow as fuck, takes about 6 seconds to 
generate a table.

- ods15