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

[Michael Niedermayer]

Hi

On Sat, Jan 14, 2006 at 10:39:42AM +0200, Oded Shimon wrote:
> On Sat, Jan 14, 2006 at 09:28:00AM +0200, Oded Shimon wrote:
> > [...]
> 
> I have some bad news.. I finished implementing at least my solution (it was 
> as easy as I expected!...), but I found another big problem...
> 
> (low bitrate file)
> 
> Before:
> Syncpoints: 19434 size: 433317  (10 subtitle streams)
> Syncpoints: 19432 size: 356410  (10 subtitle streams) (/16384)
> 
> After:
> Syncpoints: 65372 size: 2496660 (10 subtitle streams)
> Syncpoints: 65287 size: 1211460 (10 subtitle streams) (/16384)
> 
> 
> The insane change overhead is very obviously not due to change in syncpoint 
> spec, but thanks to the fact that i finally added the syncpoint placement rule:
> 
> if (nut->last_syncpoint - old_back_ptr > nut->max_distance) put_syncpoint(nut);

:(
funny that noone of us predicted that, it makes sense though ...


> 
> 
> The big problem arises here not only from having to put tons of additional 
> syncpoints, but also now that in the syncpoints themselves, none of the 
> back_ptr's are shared, so they compress horribly. /16384 helps the 
> situation a lot (back_ptr's which point close to each other are now 
> shared), however it still doesn't help the large amount of syncpoints being 
> written.
> 
> Niether solution prevents this problem... The only thing I can think of 
> that helps this is going back to per EVERY stream pts and back_ptr, in its 
> case you can put a single syncpoint after the 10 subtitle packets from the 
> 10 different streams... You could then change the syncpoint placement rule 
> to:
> 
> When putting a keyframe for a certain stream, if it makes back_ptr change 
> by more than T, queue a syncpoint to be written before the next keyfame for 
> this stream. If by then a syncpoint has already been written, don't bother.
> 
> 
> Thoughts anyone?...

yes, ivan is somehow right about that this is all crazy ...
so lets summarize, please correct me if you disagree on something

1. to seek at all we need syncpoints so we can start to decode
2. if we dont know the whole future, we will need some sort of back ptr to
   find a previous keyframe for a user specified timestamp quickly
3a.if the keyframes of any 2 streams are far apart relatively then we will
   not be able to quickly seek and decode both without very significant
   complexity (beyond what we considered in this thread)
3b.if the keyframes of any 2 streams are far apart relatively and we want to
   quickly seek and decode just one of the streams then we need per stream
   back ptrs, at least for some streams
4. if we want optimal seeking (seek to the last syncpoint in O(1) which has
   at least 1 keyframe before a user specified timestamp in a user specified
   set of streams) then we either need many syncpoints (1 after each keyframe
   if GOPs are large) or per stream timestamps for some streams at least

so the questions here are do we need optimal seeking and do we need to seek
quickly to a single stream in cases where we cannot seek in a reasonable
amount of time to all streams?
and thats just the case without index, with index we dont neccesarily have
these limitations

personally i would vote for a single back ptr and timestamp per syncpoint

i dont see why all the mess and rules are usefull if there is no index ...

also consider that 1ptr+1pts and per stream ptr+pts differ only if all of
the following are true:
1. no index
2. there is at least one stream with a large keyframe intervall which the
   user doesnt want to seek to / decode
3. the user wants to seek more exactly then the largest keyframe interval
   of any stream
4. the media is slow so that the time to read the largest keyframe interval
   is significant, also keep in mind here that due to 1. we will have O(log n)
   physical seeks anyway no matter what we do

[...]

-- 
Michael