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