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

D Richard Felker III dalias at aerifal.cx
Mon Sep 8 04:40:51 CEST 2003


On Sun, Sep 07, 2003 at 11:21:59PM +0200, Michael Niedermayer wrote:
> > 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 

This is a neat idea, but imo the container shouldn't have to know
about this. It complicates things too much for the player. A streaming
server wanting to take advantage of codec features like this probably
needs to be aware of the specific codec being used, demux the nut
file, process the encoded video frames to cut it down to the desired
bitrate, and then remux for each client. In any case, I don't think
multiple stream id's in the container (nut) should be used for such a
purpose...

> > 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)

:)

BTW, a general design principle IMO should be that the actual
main/stream headers only contain information that's useful to the
player app for playing the file. Anything that's only useful to a
human for getting info/metadata about the file should go in info
packets.

Rich



More information about the MPlayer-cvslog mailing list