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

[Michael Niedermayer]

Hi

On Sat, Dec 31, 2005 at 09:00:03PM +0200, Oded Shimon wrote:
> On Sat, Dec 31, 2005 at 06:37:35PM +0200, Oded Shimon wrote:
> > On Sat, Dec 31, 2005 at 04:54:25PM +0100, Michael Niedermayer wrote:
> > > do we really need to allow a backptr to point to the current syncpoint? what
> > > do we loose if we would point to the previous?
> > 
> > [...]
> > 
> > BTW, I'm not sure if it's worth it, but we might want to make 'type' 
> > setable by repeat's lsb. In the case of subtitles, you'll have these back 
> > ptr's...
> > 
> > 1 2 3 4 0 0 0 1 2 3 4 5 0 0 0 0 0 ...
> > 
> > Which is basically bringing out the worst in both methods. I'll investigate 
> > this later...
> 
> OK, theoretically, we don't need perfect accuracy and having back_ptr point 
> different is ok. In practice, it complicates things and makes things more 
> unpredictable.
> 
> I'm done implmenting the idea I had, and it works perfectly, I'm even a bit
> shocked by its low space consumption...
> 
> (for 700mb file, 2 streams)
> Your index idea:   105220 bytes
> My new index idea: 101889 bytes
> My new index idea, after throwing away accuracy: 95928
> 
> IMO, 6kb is not worth throwing away the accuracy and complicating matters.
> BTW, the first 92KB is the syncpoint data, the rest of the 8kb is the 
> repeat stuff... So, unless you have 50 audio streams, the inaccuracy thing 
> really doesn't matter...
> 
> Here's my index idea in detail...
> 
> for(i=0; i<stream_count; i++) {
>     j = 0;
>     while (j < n) {
>         repeat = get_s(); // NOTE THE 'S'
>         type = (repeat > 0);
>         repeat = abs(repeat);
>         b = repeat & 1;
>         repeat = (repeat >> 1)+1;
>         if (type) {
>             for(k=0; k<repeat; k++)
>                 syncpoint[j+k].stream[i].back_ptr = syncpoint[j-b].pos_div8;
>         } else {
>             for(k=0; k<repeat; k++)
>                 syncpoint[j+k].stream[i].back_ptr = syncpoint[j+k-b].pos_div8;
>         }
>         j += repeat;
>     }
> }
> 
> The flaw: 1 and -1 are identical, it's a wasted value. Does anybody care? 
> Also I think in a smart muxer, 0 should never be used...
> 
> The good: In a very possible scenario of "1 2 3 4 5 0 0 0 0 1 2 3 4 5" in 
> subtitles, this code scales perfectly, taking up least space possible.
> 
> I vote for this to be official index.

i vote in favor of putting the type into repeat, but i vote against the zero
back_ptr which points to the current syncpoint
i also vote in favor for pos/8 instead of pos/16384 if the gain is just ~5%
of the index

[...]
-- 
Michael