[MPlayer-dev-eng] MPCF proposal

[Michael Niedermayer]

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 

[...]

Michael