[MPlayer-dev-eng] MPCF: sub_packet_size concerns

[D Richard Felker III]

On Fri, Feb 14, 2003 at 12:13:17PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Friday 14 February 2003 07:12, D Richard Felker III wrote:
> > Michael, I was just reading thru mpcf.txt again, and I'm a bit
> > confused about how the sub_packet_size field is supposed to work. Are
> > you assuming audio will always be multiple fixed-size packets per
> > container-level packet? This is definitely not the case for vorbis,
> > which uses variable size packets, so if our new container can only
> > handle fixed-sized audio packets, it's mostly useless, since the
> > immediate use would be to mux vorbis audio with mpeg4.
> >
> > If this isn't a problem, the document at least needs to specify how
> > variable-length audio packets should be stored. Somehow storing a
> > whole mpcf packet for each audio packet (several hundred bytes) seems
> > really wasteful. Do you have something in mind to handle this better?
> ok fixed, i am no audio expert and i didnt think much about the subpacket 
> stuff and missed that its not able to handle variable length subpackets :(((

What about in addition to storing subpacket_size_diff[], also storing
subpacket_length_diff[] for decoded lengths. That would make subpacket
seeking possible, solving one of the main idiocies of ogg format. IMHO
we don't want to repeat the brain damage of ogg where you can only
seek to page boundaries!! One of the main points of mpcf was to allow
arbitrary seeking in audio files.

BTW2, how are negative numbers VLC-encoded? I assume they're needed here.

> there are a few questions after the fix though
> 1. should we allow multiple video frames to be put into one frame, and use the 
> same subpacket syntax?
> does this add any overhead to the demuxers?
> what about the timestamps then, for audio the number of samples from each 
> packet after decoding solves that but for video we would need timestamps or 
> disallow variable fps with subpackets
> IMHO, its best to disallow subpackets for video streams, but iam not sure if 
> its the best solution for low bitrate streams

Agree, this is nonsense. For audio it makes sense -- a single time
unit of audio is one sample, so you HAVE to put multiple time units
together in one packet anyway or you'll make the stream 100x bigger
rather than compressing it and end up drinking a whole lot of cola. :)
If the codec's packets already cover multiple time units, the
container's might as well too. Nothing like this really applies to
video.

If you're worried about overhead for super low bitrate video streams,
my recommendation would be to rip some unnecessary junk out of the
headers.

But on the other hand, if the demuxer already knows about multiple
subpackets for audio, perhaps it's no more work to support that with
video too.... I think it's nonsense, but if it helps and doesn't
complicate the code, perhaps it's worth allowing.

Rich