[MPlayer-dev-eng] Nut proposal [Re: Cleaning your nuts]

[D Richard Felker III]

On Thu, Apr 22, 2004 at 02:26:32PM +0300, Ville Saari wrote:
> On Thu, Apr 22, 2004 at 12:14:20AM -0400, D Richard Felker III wrote:
> 
> > First some points about stream code. In a simple 2-stream file, you'll
> > never need to vlc code stream_id. Coding as -1/same/+1 always works.
> 
> Except at sync points. It can be made to work for 3 streams too with a

Of course. In the previous paragraph I said that no predictive coding
was allowed in the presence of startcode (type2) frame.

> small addition to the specification: Allow stream id's to wrap around
> so that the last stream plus one means the first stream and first minus
> one the last.

Agree.

> Another idea: If the file has 4 streams or less, store the stream id
> directly in those two bits and use the vlc/-1/same/+1-scheme only
> for files with 5 or more streams. That way vlc ids are never needed
> for 1-4 stream files - not even at sync points!

A better idea: allow the global header to define the meaning of the 4
codes. If there are more than 4 streams, one of the codes must always
indicate vlc. But rather than the +1/same/-1 system, it might be
preferable to use 01,10,11 to indicate three audio streams (since
audio has lots of small packets) and then vlc-code the stream id for
all others. Or if you have just 2 audio streams, you could use the
third code for one of the +1/same/-1 purposes.

Someone (Ivan? :) might object that this sounds like bringing back the
framecode lookup table nightmare. But IMO it's very different. My
objection to framecode is that you have a single number that indices
all of the properties of the frame (streamid, size, pts, ...), making
it confusing and hard to choose a good table (because of multiple
constraints).

Rich