[MPlayer-dev-eng] rethinking nut!

[D Richard Felker III]

On Mon, Mar 29, 2004 at 12:22:52AM +0200, Michael Niedermayer wrote:
> > Without subpackets, this means at least 5% overhead for 128kbit mp3
> > audio, and probably worse for typical vorbis. Very bad. How could we
> > improve the situation:
> >
> > 1. Store stream id in with flags. It should be a 3-bit field, with the
> >    special value of 111 meaning there's a separate vlc field in the
> >    entry afterwards storing the stream id (used only when there are
> >    more than 7 streams).
> no, use ceil(log2(stream_count)) bits, many files will have fewer then 8 
> streams, for example audio only files 

Well my thought was that using a variable number of bits in a
bitfield/flags byte would be a pain...so it would be convenient to
just use a small fixed number, and then a whole additional vlc field
if the value doesn't fit.

> > 2. Make flags a vlc field, with the essentials at the beginning, and
> >    video-specific stuff later (so we don't waste space on those fields
> >    for audio/subtitle packets).
> what is video specific in the flags?!

Not totally video-specific, but "priority" will normally only be
nonzero for video frames. Dropping audio frames is nonsense anyway, so
even if audio with reference frames does exist, it's not useful to
know which frames are reference.

Actually, I don't know of any other flags right now. Other ones we
originally had:

checksum_flag - deprecated
msb_timestamp_flag - this will still exist somehow, but the whole
timestamp system can probably be optimized more.
subpacket_type - deprecated

So we have plenty space in the "flags" byte for now...

> > 3. Make timestamp optional, with a default timestamp-delta in the
> >    stream header. Optionally have a 2-bit timestamp selector field,
> >    with 11=full timestamp in its own vlc field, and 00,01,10 being 3
> >    predefined deltas from the stream header (useful for vorbis audio
> >    and post-ivtc mixed-fps material :).
> and also nice for the not so nice b frames, anyway i suggest to update the 3 
> values to the last recent used timestamp differences for each stream, this 
> has several advantages
> 1. the demuxer doesnt and shouldnt know which timestamp deltas each codec 
> prefers
> 2. it can adapt to changing fps, ...

Agree! This is much better.

> additionally iam strongly against fixed delta timestamps without a escape code 
> to code a different difference, this reminds me of the too small coefficent 
> range in msmpeg4

Notice what I said. value of 11 would indicate that the full timestamp
follows, vlc-coded. This "full" timestamp could be either absolute, or
an "lsb_timestamp" relative to the previous "msb_timestamp". IMO the
whole lsb/msb timestamp system could probably be simplified some.

> > 4. Eliminate backwards pointers. I know this one will be really
> >    controversial since they do add robustness for damaged files, but
> >    IMO a whole vlc field is a lot to spend on each frame. This point
> >    definitely calls for discussion. Maybe there's a way we could use
> >    backwards pointers in some packets but not others...?
> yes, have different packet types, for example
> type 2 64bit starcode + bidirectional pointers and independant of previous 
> data except main header
> type 1 bidirectional pointers, has only lsb timestamp (= needs last type 2 
> frame) but doesnt need previous type 1 frames
> type 0 only forward pointer and delta timestamp
> 
> 2<------>1<--------->1<------>1
> 2->0->0->1->0->0->0->1->0->0->1
> 
> and btw writing the forward pointers in the type 1/2 frames doesnt require 
> buffering huge amounts of data as the only reason for type 0 frames is the 
> overhead of the headers, so if the frames are large there would be no need 
> for type 0 frames

Perhaps. It still complicates things by requiring any buffering at
all. I'd be inclined to always have forward pointers point to the very
next packet (of any type) and only have backwards pointers point to
the previous type 1/2 packet.

> > Alex, Michael, and others interested in container formats: please post
> > your thoughts on the matter. But remember: IMO it's better to design
> > something simple that we'll actually implement, rather than bloatware
> > specs like Matroska that would require hundreds of KB of code to
> > use... (which we're too lazy to write!)
> fully agree
> well actually i first wanted to flame u for suggesting to remove subpackets :) 

:))))))))

> but after i thought about it a bit they can be really annoying for a muxer
> 
> btw nut draft patch attached, comments welcome

I'll read the new draft soon. Thanks!

Rich