[MPlayer-dev-eng] MPCF: sub_packet_size concerns

[Michael Niedermayer]

Hi

On Friday 14 February 2003 17:28, D Richard Felker III wrote:
> 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.
no, but
i have considered it (use the least significant bit a sign)
0 -> 0
1 -> 1
2 -> -1
3 -> 2
4 -> -2
...
but it doesnt seem worth the extra complexity, as there is nearly no place 
where we actually need them

>
> 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? ;)

[...]

Michael