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

[Michael Niedermayer]

Hi

On Wed, Jan 04, 2006 at 01:39:42PM -0500, Rich Felker wrote:
> On Wed, Jan 04, 2006 at 11:52:03AM +0100, Michael Niedermayer wrote:
> > > Well, what is it about it that bothers you? The overhead? I've already 
> > > prooved that in high bitrate files, the overhead is irrelavent, and in low 
> > > bitrate files, the frame headers are most of the overhead anyway. (If you 
> > > do not agree with my tests please offer a better testing scenario)
> > 
> > i suggest to make per stream pts and back_ptrs optional
> 
> If they're optional they're useless -- this is like stupid matroska
> where it's optional whether you want to store pts (lacing crap). As
> soon as the essential information is optional, the container sucks
> because idiots will omit it, plus the demuxer has to be MUCH more

and if its not omitable someone will fork and it would be omited again
trying to enforce philosophical rules does not work, people will do
what they think is best, if they dont need some stuff in the files for
their purposes but that stuff means overhead they will find a way
to remove it, this is one reason why open source is better then closed 
source its easy to change stuff against the developers will


> complicated to handle both cases correctly. The whole reason we have
> pts per-frame is that we insist on allowing frame-exact seeking (well
> also remuxing and ease of playback :), so it doesn't make sense to
> make frame-exact seeking infeasible..

frame exact seeking != finding the optimal keyframe in O(n) where n is
significantly smaller then keyint as frame exact seeking itself needs
O(keyint)

also if the muxer can go back and update past syncpoints then the method
with no back pointers and only a single pts per syncpoint allows frame
exact seeking, if the muxer cant seek back its quite questionable how
important frame exact seeking is


> 
> I'm totally willing to drop per-stream pts in syncpoints entirely if
> you have a O(log n) algorithm (without index) and O(1) with only a
> single media seek algorithm (with index) to seek to the optimal point,
> and any linear searching is bounded by small constant * max_distance
> (i.e. not O(keyint)).

why is finding the optimal point important at all? if we can find it in
99% of the cases and a near point in the remaining that seems fine
why should the user have to accept 2x overhead for something she doesnt
need?

[...]

-- 
Michael