[MPlayer-dev-eng] MPCF proposal

[D Richard Felker III]

On Tue, Mar 11, 2003 at 09:26:28PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Tuesday 11 March 2003 20:01, D Richard Felker III wrote:
> > On Tue, Mar 11, 2003 at 03:28:27PM +0100, Michael Niedermayer wrote:
> > > Hi
> > >
> > > On Tuesday 11 March 2003 14:55, D Richard Felker III wrote:
> > > > On Tue, Mar 11, 2003 at 11:40:59AM +0100, Michael Niedermayer wrote:
> > >
> > > [...]
> > >
> > > > > 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. :(
> > >
> > > hmm, ok, u won, i agree that for simplicity its better to store the
> > > samplecount or timestamp per subpacket somehow, do u know the typical
> > > size of vorbis packets? perhaps we could save some space by RLE encoding
> > > them
> >
> > Hmm. I was thinking it was small enough to fit in one byte, but maybe
> > not with vlc... IIRC they tend to be around 200 bytes, but I may be
> > entirely wrong. I can try to figure it out later if no one else knows.
> ogminfo seems prints the subpacket size (with a few -v) but not the number of 
> samples in a subpacket which would be needed for simple seeking/cuting ...
> the size of the subpackets is too random for rle, and yes its often larger 
> than 300 so it wont fit in a byte unless we use some difference vlc encoding 

Hmm, yeah, encoding difference from the previous packet's length
rather than absolute length would probably make it one byte most of
the time with vlc. Alternatively you could first compute a base length
(either smallest packet length in the superpacket, or else average or
something) and then store all lengths as an offset from that base...

Rich