- NUT-devel - lists.mplayerhq.hu

[nut]: r124 - trunk/docs/draft-xiph-oggless-00.xml
by alex 30 Jul '06

30 Jul '06

Author: alex Date: Sun Jul 30 11:34:18 2006 New Revision: 124 Modified: trunk/docs/draft-xiph-oggless-00.xml Log: add cmml and new codec devs hint Modified: trunk/docs/draft-xiph-oggless-00.xml ============================================================================== --- trunk/docs/draft-xiph-oggless-00.xml (original) +++ trunk/docs/draft-xiph-oggless-00.xml Sun Jul 30 11:34:18 2006 @@ -90,6 +90,9 @@ global headers described here is suggested to be used in every future codec. Developers should not interchange the two distinct concepts of codec and container.</t> + + <t>New codec developers for maximal interoperability, shall design + with one global header in mind.</t> </section> <section title="Minimum container requirements"> @@ -150,6 +153,7 @@ <t>FLAC: flac</t> <t>Speex: spex</t> <t>Tarkin: trkn</t>  + <t>CMML: cmml</t> </list></t> <t>If the container uses arbitrary length strings as identifiers, then @@ -160,6 +164,7 @@ <t>FLAC: flac</t> <t>Speex: speex</t> <t>Tarkin: tarkin</t>  + <t>CMML: cmml</t> </list></t> </section>

1 0

[nut]: r122 - trunk/docs
by alex 30 Jul '06

30 Jul '06

Author: alex Date: Sun Jul 30 00:03:41 2006 New Revision: 122 Added: trunk/docs/ Log: directory for various documentation

1 0

specs clarifications
by Baptiste Coudurier 24 Jul '06

24 Jul '06

Hi I just read the specs again, and I read that: " dts is calculated by using a decode_delay+1 sized buffer for each stream, into which the current pts is inserted and the element with the smallest value is removed, this is then the current dts this buffer is initalized with decode_delay -1 elements " Does that mean with (decode_delay - 1) elements, or with decode_delay elements, of value -1 ? IMHO that sentence is a bit ambiguous. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312

2 1

vorbis global 3 to 1 header mess
by Michael Niedermayer 19 Jul '06

19 Jul '06

Hi ive looked at the vorbis spec and it seems like its trivial to split the 3 header packets if they are simply blindly concatenated the first packet has fixed length the comment header looks like: 1) [vendor_length] = read an unsigned integer of 32 bits 2) [vendor_string] = read a UTF-8 vector as [vendor_length] octets 3) [user_comment_list_length] = read an unsigned integer of 32 bits 4) iterate [user_comment_list_length] times { 5) [length] = read an unsigned integer of 32 bits 6) this iteration's user comment = read a UTF-8 vector as [length] octets } 7) [framing_bit] = read a single bit as boolean 8) if ( [framing_bit] unset or end-of-packet ) then ERROR an they all have a "vorbis" in front of them ... -- 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

4 6

r19110 - trunk/DOCS/tech/nut.txt
by michael 19 Jul '06

19 Jul '06

Author: michael Date: Sat Jul 15 23:49:47 2006 New Revision: 19110 Modified: trunk/DOCS/tech/nut.txt Log: clarify "extradata" comments welcome! if anyone disagrees ill reverse this and we can disscuss it, i just thought there wont be any disagreement and was too lazy to send a patch ... Modified: trunk/DOCS/tech/nut.txt ============================================================================== --- trunk/DOCS/tech/nut.txt (original) +++ trunk/DOCS/tech/nut.txt Sat Jul 15 23:49:47 2006 @@ -512,6 +512,19 @@ codec_specific_data private global data for a codec (could be huffman tables or ...) + if a codec has a global header it SHOULD be placed in here instead of + at the start of every keyframe + the exact format is specified in the codec spec + codecs which dont specify it in their spec are specified below + for ogg based codecs (vorbis, theora) the following format shall be used + number_of_headers_minus_1 u(8) + for(i=0; i<number_of_headers; i++){ + -1 u(8*(size[i]/255)) + size[i] % 255 u(8) + } + for(i=0; i<number_of_headers; i++) + header[i] + Note, this is the same format these codecs use in matroska frame_code the meaning of this byte is stored in the main header

8 33

codec_specific_data
by Michael Niedermayer 18 Jul '06

18 Jul '06

Hi each stream has one global header in nut, matroska and avi too have exactly one global header APIs like the ones from mplayer and ffmpeg and directshow AFAIK are also designed based on a single global header but a very small number of codecs are designed so that they have several global headers but no standarized way (that i know of) of converting them to a single header, the "ogg codecs" fall in this category several solutions exist: 1. store several headers at nut level 2. leave it unspecified 3. specify how these multi packet codecs should be stored be it in nut.txt or in a seperate file if we do specify how these codecs should be stored then we can either A. invent our own system (this is for all practical proposes is identical to storing them at nut level) B. borrow the system from another container format leaving it unspecified will lead to a mess of different systems used by different muxers storing them at nut level will need them to be converted to a single packet format during demuxing and to a multi packet format during nut muxing in most cases borrowing another system and using that throughout an application will lead to the least converting around -- 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

3 3

r19128 - trunk/DOCS/tech/nut.txt
by michael 17 Jul '06

17 Jul '06

Author: michael Date: Mon Jul 17 23:15:27 2006 New Revision: 19128 Modified: trunk/DOCS/tech/nut.txt Log: remove vorbis and theora support by request of ivan Modified: trunk/DOCS/tech/nut.txt ============================================================================== --- trunk/DOCS/tech/nut.txt (original) +++ trunk/DOCS/tech/nut.txt Mon Jul 17 23:15:27 2006 @@ -515,16 +515,6 @@ if a codec has a global header it SHOULD be placed in here instead of at the start of every keyframe the exact format is specified in the codec spec - codecs which dont specify it in their spec are specified below - for ogg based codecs (vorbis, theora) the following format shall be used - number_of_headers_minus_1 u(8) - for(i=0; i<number_of_headers; i++){ - -1 u(8*(size[i]/255)) - size[i] % 255 u(8) - } - for(i=0; i<number_of_headers; i++) - header[i] - Note, this is the same format these codecs use in matroska for H.264 the NAL units MUST be formated as in a bytestream (with 00 00 01 prefixes)

1 0

r19126 - trunk/DOCS/tech/nut.txt
by michael 17 Jul '06

17 Jul '06

Author: michael Date: Mon Jul 17 01:47:12 2006 New Revision: 19126 Modified: trunk/DOCS/tech/nut.txt Log: clarify H.264 global header format Modified: trunk/DOCS/tech/nut.txt ============================================================================== --- trunk/DOCS/tech/nut.txt (original) +++ trunk/DOCS/tech/nut.txt Mon Jul 17 01:47:12 2006 @@ -525,6 +525,8 @@ for(i=0; i<number_of_headers; i++) header[i] Note, this is the same format these codecs use in matroska + for H.264 the NAL units MUST be formated as in a bytestream + (with 00 00 01 prefixes) frame_code the meaning of this byte is stored in the main header

4 6

The codecs which have no fourcc in AVI
by Michael Niedermayer 16 Jul '06

16 Jul '06

Hi To make ivan happy, this thread is dedicated to the issue of what to do if our selected codec id system doesnt have a id for a specific codec an issue which many other container specs dont seem to care about ... so what can be done ... * IMO we should make a list of codec ids for codecs which are common but which arent stored in avi normally, well acually we already did make that list (see mailinglist, it was done with the sligtly different goal of avoiding implementation specific ids but when we drop these the rest is what we need here), also note my proposal here is just a small <10 entry list nothing bigger so whats left are "rare" codecs which arent stored in avi i think theres just one thing we can do here, and that is to tell people to contact us to discuss/ register a id for their codec whats the difference from that to a nut specific id system? makng and maintaining a list of all codecs-implementations-ids vs. maintaining a list of very few ids, just thouse which are not supported by avi and which people want to use in nut and where the designers of the codec didnt specify a recommanded fourcc already in their spec a few random notes ... * people dont contact microsoft/iso/apple to register their ids or did anyone? i dunno ... * thouse who will attempt to store codec X in nut for the first time will likely not be the ones who designed the codec and they will very likely not have read the nut spec and as such will not know how to select a codec id -> they will not contact us -- 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

2 2

Re: [Ffmpeg-devel] Re: integrating AVS decoding into MPlayer
by Michael Niedermayer 16 Jul '06

16 Jul '06

Hi On Sat, Jul 15, 2006 at 10:49:02PM +0200, Baptiste Coudurier wrote: [...] > > [...] > > > > Care to explain how these rules will cease to apply? > > Like they changed in those years, when compression appeared, then VBR, > who knows... > > NUT system is the best one around. Still I persist to say that wraping > specs are needed, and even more for ambiguous codecs wraping formats, > and a fourcc for each codec recognized must be written in the specs, > that means standardized. for ambiguous cases we certainly should say something in the spec but most arent ambiguous, if you follow the spec of a codec and the nut spec and use a little common sense ... [...] > > >> I persist to say that a container SHALL standardize a codec wraping > >> (even just saying "default wraping rule applies" and its fourcc is ...) > >> if it needs to support it. It should just be a matter of one line per > >> codec, as NUT is very generic ;) > > > > The one line would be the same for every codec so it's pointless. > > IMHO not for H264, what exactly is unclear in the h.264 spec? > > > What about timecode ? Subtitles ? > > There is no specifications in NUT specs about wraping those kind of > data. A stream type identifier is not sufficient IMHO. > > I just read the specs again and I also do not see and decent standard to > pack extradata for specific codec. Just put the MOV atoms in NUT ? which codec spec is unclear about how to store it? ogg based codecs yes, that needs a line to clarify > > Btw this thread now belongs to NUT devel IMHO. yes [...] -- 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

3 3