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

[D Richard Felker III]

On Thu, Apr 22, 2004 at 06:28:35PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Thursday 22 April 2004 16:40, D Richard Felker III wrote:
> [...]
> > 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).
> i disagree, we can easily add a default frame_code table to the spec which is 
> near identical to this flags system, and it would still allow more 
> complicated muxers to choose better frame_code tables, while the flags system 
> makes this impossible

I'm mostly convinced, and was in the process of writing an email to
that effect. But I'm still not sure that framecode is any better than
having several fields with their lengths configurable in the header
and their meanings configurable in the global & stream headers. For
example, global header defines the stream_id field as 2 bits, and says
that 00=stream1, 01=stream3, 10=stream4, 11=vlc, then each stream
defines the number of bits used for data_size_lsb, keyframe, pts
codes, etc. (BTW, keyframe flag can be omitted for intra-only codecs
including all worthwhile audio codecs. :))

What do you think? If you're still strongly in favor of framecode,
I'll go ahead and send my proposal for changes with framecode.

> choosing a good table also isnt a difficult multiple constraints thing either, 
> its just assigning the 255 framecodes depending upon the likeliness of all 
> possible frame_codes (excluding the packet_size)

But maybe you don't know the likeliness until after encoding... :(

> we dont know their likeliness yes, but we can guess based upon common sense, 
> keyframe in audio/video, frame type likelyness, full timestamp likely, ...
> and after all designing a static flags header isnt any different, we also make 
> guesses about the likeliness and try to pack it in a byte, only difference is 
> that its not extendible in the future

Perhaps.

Rich