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

[Michael Niedermayer]

Hi

On Thu, Jan 05, 2006 at 04:04:17PM +0200, Oded Shimon wrote:
[...]
> > furthermore we havnt thought about error resistance of these features its
> > part of the goals, and being ignored entirely
> > what if a the pts or back ptrs are damaged? how do we ensure recovery of
> > the demuxer?
> > 
> > i really dont want to flame but every few month iam being confronted with a
> > new set of 3-5 requirements which are absolute and undisscussable and which
> > nut must conform too while everything else is not worth even mentioning
> > 
> > first it was 1pass no buffering, strict dts, absolute minimal overhead,
> > absolute no redundancy to avoid inconsistant files, ...
> > now its optimal seeking, 1pass (dunno if the strict no buffer rule was droped?)
> > dts ordering and overhead doesnt matter at all anymore, ...
> 
> Well, you miss all the IRC convos where most of this takes place. :)
> 
> Looking back at it all now, I think you are right, we should go back to 
> single back_ptr, "percise optimal seeking" isn't all that useful, Rich was 
> mostly thinking for video editors when he brought it up, and now that I 
> think of it, they will most likely use intra only codecs anyway. As for 
> music videos, I found that "keyframe percision" is actually very high, 
> I've never had a nut seek going more then 3 seconds off target. (with 
> single back_ptr). Single back_ptr is still necessary IMO, because otherwise 
> using NUT for video editing is impossible altogether. BTW, given this, the 
> rule for syncpoint pts is using the max keyframe pts across all streams, 
> this is the only correct way for doing it (and without global timebase at 
> all, we should still use coded_pts). The index is the old syncpoint index I 
> proposed - those with a common back_ptr can be removed, making a tiny 10kb 
> index per hour. The nice pro to all this, I already have the demuxer fully 
> implemented. :) The biggest thing I still hate with back_ptr - subtitles. 
> (As in, any stream with gaps.) back_ptr will be huge and useless, and EOR 
> can't really be enforced, it is merely a hint.

why? the "non relevant" streams are just ignored in the single back_ptr

[...]

-- 
Michael