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

[Michael Niedermayer]

Hi

On Sat, Jan 14, 2006 at 01:33:40PM +0200, Oded Shimon wrote:
> 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.
> -

so with the optimal seeking + one pts for delay=0 streams (either just one
for all or one additional for delay>0) we will end up with O(n^2 log n)
overhead or so, nice ...
so thats off the table ...
with 1 ptr and 1 pts per stream its O(n log n) and with 1ptr and 1pts per SP
its O(log n)
all that IMHO, i didnt proof anything, just wild guessing ... the log n comes
from the unavoidably larger number of bits to point to more keyframes from
more streams


> 
> > > 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... :)

yep probably :(

[...]

-- 
Michael