[MPlayer-dev-eng] Finalize NUT spec

[Michael Niedermayer]

Hi

On Fri, Jan 27, 2006 at 05:40:09PM +0200, Oded Shimon wrote:
> We're almost there.
> 
> 1) EOR in index.
> I propose, in this section of index:
>             for(; j<n && j<syncpoints; j++){
>                 if (!has_keyframe[j][i]) continue
>                 A                           v
>                 last_pts += A
>                 keyframe_pts[j][i] = last_pts
>             }
> 
> Change to:
> 
>             for(; j<n && j<syncpoints; j++){
>                 if (!has_keyframe[j][i]) continue
>                 A                           v
>                 if (A) {
>                     last_pts += A
>                     keyframe_pts[j][i] = last_pts
>                 } else {
>                     A                       v
>                     last_pts += A
>                     eor_pts[j][i] = last_pts
>                 }
>             }
> 
> Where EOR pts should only be given if there isn't any keyframe in the 
> _entire_ syncpoint region (between this syncpoint and the last syncpoint)
> 
> S EOR3 K7 EOR10 S => key 7
> 
> S frame7 EOR10 S => eor 10
> 
> S K7 EOR10 S .... S .... S K13 S => key 7, eor 10, no key, key 13
> 
> I think this breaks optimal seeking in some silly situations, I'm not sure, 
> maybe strict interleaving saves you from that. Either way, I don't think it 
> is worth fixing.
> Found it:
> S K7 S ... S ... S EOR10 K13 S
> 
> We want pts 11, we'll end up at K7 cause EOR10 is "silenced" by the K13. 
> Only question left, do we care. I don't.

if we drop optimal seeking, can we then also drop the pts per first keyframe
from the index?

anyway heres an alternative suggestion for EOR indexes
1. store keyframe flags per syncpoint & stream (like we do currently)
2. store relevances flags per syncpoint & stream same way as keyframes 
   so all syncpoints after a EOR are non relevant until the next keyframe
3. store nonkeyframe flags like keyframe flags (not needed for this but could
   come in handy for other things and overhead should be negligible)


> 
> 
> 2) info streams
> They make single back_ptr rediculously big if you don't ignore them, and it 
> wouldn't make sense to special case them. You can use EOR closely after the 
> info frame, or you can repeat the info frame over and over... All solutions 
> are non-ideal (and not theoretically correct)..

just repeat info packets and single back_ptr will be fine, or use nonkeyframe
flags to skip "empty" segments


> 
> 3) compare_ts
> Could someone give an "accurate" code for this? I'm no good at this 
> overflowing math. :)

av_rescale_rnd() in libavutil/mathematics.c


> 
> 4) what is a fourcc
> Maybe it should be a seperate document from NUT spec, tied with it.

hmm, whatever but dont reinvent the wheel, the "fourccs" from avi&mov
should be used whereever possible


> 
> 5) index repetition
> It can appear at any arbitrary point in the file, if it appears at all, it 
> must be pointed to by index_ptr at EOF.

index repeation -> multiple indexes but 1 index_ptr or do we have several?


[...]

> Michael you said you had some minor comments? Now would be the time...

hmm, forgot them all :(

[...]
-- 
Michael