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

[Michael Niedermayer]

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?


> 
> > > and I really doubt most of the developers
> > > have even followed this or know or understand the differences. I know
> > > one developer who will just vote whichever way he thinks will make NUT
> > > suck, out of spite...
> > 
> > well IMO you dont need to understand the details to vote, its about the
> > effects for the end user not if the details match your philosophy of
> > how it should be done
> 
> I think it's about both, but which it should be about is part of the
> matter under discussion. Matching the philosophy is part of matching
> the needs of an advanced user, imo. If you want to make Windows users
> happy, anything that can store multiple streams and subtitles will do.
> Hell, they're even happy with AVI. One of my big goals for NUT all
> along has been universality. This does not mean bloating it with every
> optional feature someone might want, but it has always meant things
> like zero-buffer muxing and demuxing, pipability/streamability, full
> pts info, and IMO it should also include sufficient information to
> seek to any point in constant-bounded time.

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
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

[...]

-- 
Michael