[MPlayer-dev-eng] MPCF: sub_packet_size concerns

[D Richard Felker III]

On Fri, Feb 14, 2003 at 05:46:36PM +0100, Michael Niedermayer wrote:
> > Hmm, actually, I was just thinking....how about removing the subpacket
> > nonsense entirely and just having a really simple frame/packet format
> > that can be used for audio packets. If you could average 4-6 bytes for
> > the header, overhead would probably be < 5% for an audio-only stream
> > at low bitrate, which probably wouldn't be a significant problem.
> > Unfortunately this precludes the use of startcodes in all audio
> > packets, but they could be used periodically still, and the effects
> > if the file was damaged wouldn't be any worse than storing tons of
> > audio packets in a single container frame...
> the current non keyframe header needs 5-7 bytes approx :) with subpackets its 
> only about 1 byte like ogg, if we would use 5-7 bytes per subpacket then the 
> overhead would be siginficantly larger than than that of ogg streams, and 
> IIRC u didnt like the 1% overhead from ogg so u want 5% now? ;)

I don't like 1% of 700 megs because it affects fitting a movie on a
cdrom. I couldn't care less about 10% of 7 megs. :) Also the 5% was a
fairly conservative estimate; for high bitrate files it's probably
more like 1-2%. Perhaps we should actually check.

Anyway, subpackets DO need timestamps if they're going to be used, so
it's at least 2 bytes per subpacket, not 1, making subpackets seem
like less of a savings (we only save 2-5 bytes per audio packet). At
this point, I think the complexity overhead for doing subpackets
probably makes it better to just forget about them.

If you do decide to keep subpackets, though, there should be both
fixed-packet-size and fixed-decoded-length modes so that either one or
the other can be omitted if possible (this is possible with all codecs
I know except vorbis).

Rich