[NUT-devel] r21189 - trunk/DOCS/tech/nut.txt

[Michael Niedermayer]

Hi

On Fri, Nov 24, 2006 at 12:37:31PM -0500, Rich Felker wrote:
> On Fri, Nov 24, 2006 at 09:05:31AM -0800, Ralph Giles wrote:
> > On Fri, Nov 24, 2006 at 01:51:34PM +0100, michael wrote:
> > 
> > > if anyone disagrees or has suggestions to improve it then shout
> > 
> > > +    codec_specific_data SHOULD contain exactly the essential global packets
> > > +    needed to decode a stream, more specifically it SHOULD NOT contain packets
> > > +    which contain only non essential metadata like author, title, ...
> > 
> > For codecs with required stream-embedded metadata like ours, I think 
> > this is just making work for the muxer. I'd allow such packets, and
> > instead say that implementations SHOULD maintain and prefer 
> > container-level metadata with NUT. The packet should be there, even
> > if it's minimal.
> 
> The packet can be there if it's required by the spec, but the metadata
> fields should all be blank, and should be completely ignored by any
> player. I would be in favor of a requirement that a compliant player
> MUST NOT present user-oriented metadata from codec bitstream 

hmm, i see 3 possibilities for xiph codecs
1. store the metadata packet as is
2. dont store the metadata packet
3. store a dummy (empty) metadata packet

the metadata has to be parsed and put in a common structure at some
point in all cases be it the ogg demuxer, vorbis parser, nut muxer or
whatever otherwise the metadata would be pretty much unavailable to a nut
player (we cannot require every nut player to be able to parse codec
specific metadata)

1. would cause the data to be duplicated, if one gets edited by the user
   we have contradicting data, thats very bad, also the stream headers
   would be larger then needed, and the stream headers get repeated ...
2. would need some dummy or correct metadata packet to be generated somewhere
   at the demuxer side together with the split global to xiph packets if 
   needed (muxing in ogg or vorbis, ... decoder needing it)
3. would need some dummy metadata packet to be generated somewhere at the
   muxer side, and then be replaced if needed by the correct metadata at
   the demuxer side, spliting still is needed for muxing in ogg or vorbis,
   ... decoders which need it

i dont like 1. at all, 2. and 3. are pretty much the same
if there is an established standard which requires all 3 packets to be
stored then no doubt we should follow that, thats also said in nut.txt
"the exact format is specified in the codec spec" but there is no such
thing, RTP says dont store metadata, other containers and APIs combine
the 3 packets in various ways ...
so if xiph "officially" says store all 3 with the following format
... in a single packet
then we will certainly do so, if not then i dont know what would be
best

also in a generic framework its likely that the metadata packet will
be parsed and the metadata be put into a common structure in the ogg
demxuer or some parser not the nut muxer, as other muxers also need
the metadata ...

similarely the reverse of this would be done in the ogg muxer or some
bitstream filter not the nut demuxer as other demuxers set metadata and
that should end up in the final ogg stream

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is