[MPlayer-dev-eng] MPCF Draft/Discussion (MPlayer ContainerFormat)

[Michael Niedermayer]

Hi

On Friday 07 February 2003 15:54, michael c wrote:
> Hi,
>
> Michael Niedermayer wrote:
> >but whats the difference between a new fourcc & a new 64bit startcode?
> >its the same, except that the fourcc adds another layer which isnt
> >needed, and we should allso update the docs for a new fourcc if its
> >used in such a way as for new packet, or its an undocumented feature
> >and it would cause interoperability problems, i mean there are more
> >players then 1 so it must be documented or others have to guess /
> >reverse engeneer it, this isnt acceptable
>
> hmm, forget the details of the implementation for a second. the
> universal_packet could as well start with a different sort of id or so. or
> certain fourccs would be kept internal. the point is that the packet would
> be universal and could be used for anything (except video/audio/(subs)).
> and the type of the data is described by that id.
>
> i must disagree with the documentation part though. it makes absolutely no
> difference IMHO whether you document a whole new packet type, or the
> structure of the data section for a specific id.
didnt i say that? u said the universal packet would be better because we dont 
have to change the docs for a new fourcc, but for the uses u suggested (menu, 
chapters ...) it must be documented or noone can use it

> actually when you create a new packet type for more things to add, as you
> suggested could happen (menu? chapters? whatever), demuxers that don't know
> these yet might run into problems - it will probably be easier for them
>
> just to skip universal packets with ids they dont know. i call this
> (contrary to your statement) better interoperability, because the demuxer
> is prepared from the beginning on to face things (packet ids) he never
> heard of (possible extensions to the format), and knows how to handle them.
> and like i mentioned earlier, universal packets give you the power to add
> almost any kind of feature later, at almost no cost and remaining backwards
> compatible - still allowing players that never heard of those advanced
> features to play the file.
> i just think it would be a mistake to close the door on that. new features
> WILL be wanted sooner or later, it's always been like that :-) the format
> IS supposed to be extensible and flexible after all, isn't it?
i dont understand why u insist on demuxers to be unable to skip unknown 
packets, this is just plain stupid, the demuxer just compares the known 
startcodes with the current packet start and if none matches & it doesnt 
start with a 0 bit then its an unknown packet and it will skip to the next by 
following the forward pointer, if the forward pointer is damaged it will 
search for the next matching 2 pairs of matching pointers or a known 
startcode ...

[...]

Michael