[MPlayer-dev-eng] MPCF proposal

[D Richard Felker III]

On Tue, Mar 11, 2003 at 11:40:59AM +0100, Michael Niedermayer wrote:
> > I believe there are still some problems with the way audio packets
> > will be stored. In particular, I think it's essential that the demuxer
> > be able to obtain any codec-level audio packet and its timestamp
> > without having access to the codec. Otherwise it's impossible to
> > cut or splice audio files with any degree of precision.
> >
> > I see two possible solutions...
> >
> > a) Try to minimize the header size even more and do away with
> > subpackets, i.e. all codec-level audio packets get stored in their own
> > muxer-level packet.
> >
> > b) Store byte lengths and sample lengths of each subpacket
> > vlc-encoded. If packet size in bytes and/or in samples is fixed, then
> > the spec should require that one or both be omitted.
> >
> > IMO, solution (a) is much cleaner, but probably sacrifices a bit on
> > file size. Therefore, solution (b) might be more appropriate. But...if
> > it's really worth having subpackets to minimize filesize overhead,
> > perhaps it would be better to just make a more minimal form for audio
> > packets to begin with.
> IMHO a and b are not solutions at all
> i mean if we have 10ms per subpacket & 50 subpackets then your suggestions 
> will allow 10ms precise seeking/cutting, thats fine but what if a audio codec 

Yes, and that's definitely a worthwhile benefit. Especially when
you're only adding one byte per subpacket to the overhead (and only
for codecs where the decoded packet length isn't constant, i.e. only
ogg).

> uses larger packets like 500ms per subpacket? iam sure that compression can 
> be improved with larger subpackets so this will very likely happen sooner or 
> later if its not allready done by some codecs

Such a codec would have limited use IMO since seeking and realtime
streaming would be effectively impossible.

I don't think calling my suggestion "not a solution" just because a
pathological codec could still prevent precise seeking is a valid
complaint... My proposal allows seeking at whatever the codec's
resolution of precision is, whereas the existing spec (like ogg :/)
enforces an artificial restriction on seeking beyond that.

Yes, for a player that's decoding the audio you could seek to a
subpacket by going to the beginning of a muxer packet and then
decoding but throwing away samples until you get to the desired
position. However, IMHO this places too much burder on the player, and
it likely won't do it! One of the points of MPCF is to be simple to
implement, and if you require silly hacks like that outside the
demuxer layer to properly seek, I don't call that simple. :(

> the only solution is to cut less precisse and specify the start/end-timestamps
> indeed this is just a very simple play-list/cue-list

This is a very bad approach. Consider the case where you want to be
able to remove extra stuff from the beginning of a recording you made.
You may very well not want other people to be able to recover 0.5 sec
of what you cut, depending on the content. A method of cutting a file
that doesn't really cut the info off but just hides it sounds like a
microsoft-ism! (Think msword quicksave!)

Rich