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

[Rich Felker]

On Mon, Jan 09, 2006 at 10:26:03PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Jan 09, 2006 at 03:54:36PM -0500, Rich Felker wrote:
> [...]
> > > > just for the sake of making
> > > > index overhead tiny in one special case. Every other case (intra-only,
> > > > audio files, etc.) will have at least 100-200kb of index.
> > > 
> > > this is false the original index didnt behave that way as it didnt conatain
> > > all keyframes, i remember that you strongly wanted that but i repeatly
> > > rejected it, my index definitly did not behave this way
> > 
> > OK fair enough. I forgot about that part. And I still strongly oppose
> > any method that leaves you with an unbounded (or even long) linear
> > search to find the keyframe you want. Such an index is almost
> > worthless unless you want super-low-resolution seeks, since a binary
> > search will be just as fast..
> 
> 1sec is super-low-resolution?

For audio, yes, 3sec is super-low-resolution. 1sec is fairly low.
Imagine trying to position the starting point between two lines of
dialogue spoken with no gap between, or on the start of a particular
measure in a song.

I know you can say that people should mux the file for the intended
use; however I find that the intended use of the file creator and the
intended use of the end user are quite different. I'd like for NUT to
be the universal format I can use for anything regardless of what the
file creator intended, rather than having to remux. If I wanted to
remux every time I wanted to do something the original format didn't
allow I might as well just have an MKV file..

Incidentally, it doesn't matter for audio-only since linear searching
the whole range is cheap. When it matters is if there are other
streams present making the search expensive.

> hmm, we do have zero-buffer muxing and demuxing? how?
> for muxing (we assume pts==dts) we need at least 1 frame of each stream to
> mux anything that will mean buffering several packets for some streams in 
> practice

No, you just need to know a lower bound on the next pts for each
stream. In practice this is always known (especially for live
sources!) since it's just the duration of the last frame written plus
the last pts.

Codec latency, e.g. decode_delay or mp3lame buffering, is another
matter altogether and there's nothing that can be done about it except
use lowdelay codecs.

> for demuxing over constant bitrate channels with seperate audio and video
> buffers like mpeg* uses, the buffering needed will exceed that of mpeg-ps
> 
> for example:
> the video vbv is full due to big frames, so we cant transmit the next video
> frame and the audio cant be transmitted due to dts ordering restrictions
> in nut, so we must do stuffing where mpeg-ps could fill the audio buffer

If you care and have a proposal for improving this without making
frame order completely arbitrary, I'm willing to listen. Personally
this issue isn't one I care much about but that doesn't mean I'm going
to call it stupid.

Rich