[MPlayer-dev-eng] MPCF proposal

[D Richard Felker III]

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.

Rich