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

[Rich Felker]

On Wed, Jan 04, 2006 at 11:05:46AM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Wed, Jan 04, 2006 at 01:41:51AM -0500, Rich Felker wrote:
> > On Tue, Jan 03, 2006 at 09:34:32PM +0100, Michael Niedermayer wrote:
> > > > 9. add EOR and SOR stream flags
> > > 
> > > EOR: abstain
> > > SOR: NO
> > 
> > SOR was my idea. IMHO there's no way you can have any sane sense of
> > the dts for the first decode_delay frames after a break due to EOR,
> > unless you have something like SOR to initialize the dts buffer to
> > something sane (other than -1 -1 ...).
> > 
> > If you want dts to be meaningful rather than just a pointless
> > numbering, EOR without SOR is quite harmful to that goal..
> 
> well but then we would need multiple SORs ...
> the meaningless initial DTS issue also occurs after seeking to any keyframe

Yes, uau pointed this out too. :)
Unless having dts for these frames is absolutely essential to
anything, I retract the SOR proposal since it doesn't help. IMO we
won't have any subtitle streams with decode_delay in the near future
anyway so we could leave it unspecified what to do with such streams.

BTW I'd somewhat like to make it illegal to store more audio or video
frames after EOR and only allow this for subtitles and info streams.

> > > 17. remove index repeation possibility
> > > NO
> > 
> > I'm against index repetition since there's no reliable way to find the
> > repeated index, and since the index is 100% redundant data anyway. If
> > the index is missing, index for all the parts of the file that are
> > intact can be reconstructed easily. Oded's demuxer implementation
> > auto-builds the full index in memory as part of its binary search
> > process.
> 
> i dont agree here, videos are commonly on read only media (cd,dvd,...)
> so rebuilding the index isnt possible seeks on these are slow -> binary
> search is slow
> finding a repeated index is trivial, just put a list of index positions
> in the main header, yes it doesnt work with 1sequential pass muxing but
> i think most will prefer 2 pass muxing for their cdr over a slowly seekable
> cd if it gets damaged which for cdr is again not so unlikely
> its just a optional feature for people who have different goals then you
> AFIACS it has no disadvantages for others ...

I'm not strongly opposed as long as it's clear that any compliant
implementation MUST read the index from EOF in the absence of such
headers, if the implementation supports indices at all. It's
unacceptable if popular implementations store index at beginning and
then popular demuxer implementations refuse to use index unless it's
at the beginning..

Rich