[MPlayer-dev-eng] MPCF: sub_packet_size concerns

[D Richard Felker III]

On Fri, Feb 14, 2003 at 09:52:20AM -0500, 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.
> 
> BTW2, how are negative numbers VLC-encoded? I assume they're needed here.

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...

Rich