[MPlayer-dev-eng] MPCF: sub_packet_size concerns

[D Richard Felker III]

On Fri, Feb 14, 2003 at 05:51:36PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Friday 14 February 2003 15:52, D Richard Felker III wrote:
> > 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.
> hmm, i dont remember that point on the goals list ...

It wasn't on your goals list, but it was among the points in my
original post on -users that sparked interest in making a good
container format.

> anyway isnt the number of samples per packet constant ? if not then we need to 
> think about this a bit

Unfortunately, no. That's the reason why vorbis audio cannot be stored
reliably in avi files. :( AVI (stupidly) requires either the bytes per
frame, or else the decoded samples per frame, to be a constant.

> some possible solutions:
> 1. limit the maximum length (in time) of a packet so that precisse enough 
> seeking is possible

IMHO this is a very very bad solution; it could lead to serious a/v
desync after multiple reencodes with seeking. And if container frames
are short enough to make precise seeking possible, you'll only have a
couple audio packets per frame, and so you'll get more overhead by
using subpackets rather than less. :(

> 2. add a optional timestamp or number of samples to the subpackets

I like this option. Or just doing away with subpackets altogether.

> 3. decode a whole packet and drop the samples until the point to which we want 
> to seek

This is also very bad because you can't seek without the decoder.
Think of mencoder -oac copy -ss foo.

Rich