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

[Oded Shimon]

On Sat, Jan 14, 2006 at 11:42:07AM +0100, Michael Niedermayer wrote:
> 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 ...

Actually, I did! I just completely forgot it in the huge mess of this 
thread :) To recall the very FIRST mail in this thread:

-
8. syncpoints too big?

I still think that in my not-so-pathological scenario of 10 subtitles
stream syncpoint overhead can be huge. More so with my syncpoint rule.
Rich, you said the scenario I gave won't happen:

<syncpoint> <tiny sub1> <syncpoint> <sub2> <syncpoint> <sub3> ...

all the subtitles change together, have a tiny size, and the syncpoints are
huge, 20-30 bytes, you'll get 400 bytes of data with 1000 bytes of
overhead.
-

> > 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

I recall saying at one point let's do single pts and back_ptr, and linear 
search the area only if there isn't an index (you have to do a ton of seeks 
anyway), and be optimal when you do have an index. The only reason I can 
remember why this idea was shot down was because it raised demuxer 
complexity in that seeking with index and without is significantly 
different. It does kind of suck considering my demuxer was smart enough to 
dynamically build the index while playing... This would be much harder to 
do.

I mostly don't mind going back to single back_ptr and have optimal seeking 
only when there is an index... I have a feeling not everyone will agree to 
this though... :)

- ods15