[Mplayer-cvslog] CVS: main/DOCS/tech mpcf.txt,1.30,1.31

[Michael Niedermayer]

Hi

On Sunday 07 September 2003 22:29, D Richard Felker III wrote:
> On Sun, Sep 07, 2003 at 03:16:29AM +0200, Michael Niedermayer wrote:
> > Hi
> >
> > On Sunday 07 September 2003 03:03, Alex Beregszaszi wrote:
> > [...]
> >
> > > > > Btw, I would remove the stream_count, file_size and length_in_msec
> > > > > fields from the main header. The demuxer should read startcodes and
> > > > > handle all the streamheaders it has found and the
> > > > > file_size/len_in_msec fields could be placed in an optional packet,
> > > > > or in the info packet.
> > > >
> > > > the stream_count may be usefull for allocating an array of streams
> > > > which some demuxers might do
> > > > but i agree that length_in_msec and file_size fields arent essential
> > > > and should be moved to a info packet
> > >
> > > It may be used for calculating avg bitrate, but we have a field for avg
> > > bitrate too. But what does uses these bitrate fields?
> >
> > ur favourite p2p app might display them, they can also be used to decide
> > which stream to transmit (imagine some video encoded at different
> > bitrates ...)
>
> IMO it's stupid to store alternate encodings of the same content in
> the same file. If you want lq and hq copies for streaming, put them in
> separate files. I seem to recall this issue being discussed when mpcf
> (now nut) was first designed, and it didn't make any sense then
> either. 
hmm, maybe for nut, but its not true for scaleable codecs where its possible 
to drop some data and decode the remainder as lower quality version (mpeg4 
FGS, jpeg2000, tarkin), 3d wavelet codecs are especially interresting here as 
it is possible to choose spatial/temporal resolution & quality without 
reencoding by just dropping the right set of coefficients, but sadly noone 
has yet written a useable 3d wavelet codec with motion compensation, at least 
not AFAIK, even though it should be quite easy to combine MC with wavelets,  
just do MC of the sources used for the lifting transforms in temporal 
direction, the resulting lifting transform is quite similar to the 
bidirectional prediction used in b frames, except that its done several times 
over a set of frames and with possibly more then 2 source frames

> Let's keep metadata tags like this out of the main headers,
> and put them in optional info headers instead. Otherwise we make the
> same mistakes as matroska...
agree (avg_bitrate should be moved to the info packet)

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en