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

[Michael Niedermayer]

Hi

On Thu, Jan 12, 2006 at 07:49:38PM +0200, Oded Shimon wrote:
[...]
> try3:
> 
> syncpoint:
>     startcode                               u(64)
>     coded_pts                               v
>     stream= coded_pts % stream_count
>     pts= coded_pts/stream_count
>     n= 0
>     cache[n++]= 0
>     cache[n++]= back_ptr[0]                 v
>     A= 0
>     for (i=1; i<stream_count; i++) {
>         if (A==0) A                         v
>         if (i==stream_count-1) {
>             if (A>=n) back_ptr[i]= A-n
>             else back_ptr[i]= cache[A]
>         } else {
>             if (A&1) {
>                 A>>= 1
>                 j= A%n;
>                 A/= n;
>             } else {
>                 cache[n]= A>>1
>                 j= n++
>                 A= 0
>             }
>             back_ptr[i]= cache[j]
>         }
>     }
> 
> high bitrate:
> Syncpoints: 27462 size: 430989  (0 subtitle streams)
> Syncpoints: 27473 size: 553144  (2 subtitle streams)
> Syncpoints: 27515 size: 817419  (10 subtitle streams)
> 
> low bitrate:
> Syncpoints: 19403 size: 296722  (0 subtitle streams)
> Syncpoints: 19413 size: 349040  (2 subtitle streams)
> Syncpoints: 19434 size: 433317  (10 subtitle streams)
> 
> 
> I win. :)

congratulations! :)

just for fun (should be dead easy to test), how large would these be if we
would divide by 16384 instead of 8?


> 
> Assuming I didn't fuck anything up... I didn't check any of these except 
> staring at the code thoroughly...
> 
> What I like about try3 is that unlike the other 2 it has no garuntee of 
> 1 byte per stream always... Also it prooved itself to be better. :)
> 
> Your ref idea is very possibly more efficient than all of these, however it 
> comes at the high price of the muxer having to choose ref streams before 
> hand, which is non-trivial. :/

yes and its unpredictable, my idea was (all video then all audio then all
subtitles) and try to order packets during muxing so as to improve syncpoint
size


> 
> We still need a way to efficiently code pts's for non zero decode delay 
> streams together with all this, or are you not convinced yet?...

no iam not convinced

[...]
-- 
Michael