July 2006 - NUT-devel - lists.mplayerhq.hu

libnut license
by Alex Beregszaszi 31 Jul '06

31 Jul '06

Hi, Are there any decisions on what the libnut license will be? -- Alex Beregszaszi | alex(a)fsn.hu | +36 70 3144424

3 4

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

30 Jul '06

Author: alex Date: Sun Jul 30 11:30:01 2006 New Revision: 123 Added: trunk/docs/draft-xiph-oggless-00.xml Log: 'Using Xiph codecs outside the Ogg container' RFC draft Added: trunk/docs/draft-xiph-oggless-00.xml ============================================================================== --- (empty file) +++ trunk/docs/draft-xiph-oggless-00.xml Sun Jul 30 11:30:01 2006 @@ -0,0 +1,286 @@ +<?xml version="1.0" encoding="UTF-8"?> + +<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ + <!ENTITY rfc2119 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> + <!ENTITY rfc2361 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2361.xml'> + <!ENTITY rfc3533 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3533.xml'> +]> + +<rfc category="std" ipr="full2026" docName="draft-xiph-oggless-00.xml"> + +<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> + +<?rfc toc="yes" ?> +<?rfc compact="yes" ?> +<?rfc symrefs="yes" ?> +<?rfc sortrefs="yes"?> +<?rfc iprnotified="no" ?> +<?rfc strict="no" ?> + +<front> + <title abbrev="Xiph codecs without Ogg"> + Using Xiph codecs outside the Ogg container + </title> + + <author initials="M." surname="Niedermayer" fullname="Michael Niedermayer"> + <organization>FFmpeg</organization> + <address> + <email>michaelni(a)gmx.at</email> + <uri>http://www.ffmpeg.org/</uri> + </address> + </author> + + <author initials="A." surname="Beregszaszi" fullname="Alex Beregszaszi"> + <organization>Siqon</organization> + <address> + <email>alex(a)siqon.com</email> + <uri>http://www.siqon.com/</uri> + </address> + </author> + + <date month="July" year="2006"/> + <abstract> + <t>This document describes a way for using codecs made by Xiph in + other container formats than their own Ogg format.</t> + </abstract> +</front> + +<middle> + <section title="Requirements notation"> + <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", + "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" in this document are to be interpreted as + described in <xref target="RFC2119"/>.</t> + </section> + + <section title="Security Considerations"> + <t>None.</t> + </section> + + <section title="Introduction"> + <t>The Xiph Foundation develops and maintains several audio and video + codecs. All of these codecs are bound technically to their container + format <xref target="RFC3533">Ogg</xref>.</t> + + <t>The Ogg container format organizes only data packets, but has no + knowledge of the content of these packets. Different codec outputs + are stored in these packets. It neither has a field for storing global + headers of these codecs, if they may present. Headers are just stored + the same way as other data packets, without any notation.</t> + + <t>Vorbis and Theora are designed to be stored in the Ogg container format + and FLAC and Speex have been adapted to it. All of them can have more + headers, at most three of them. These headers are stored in individual + packets.</t> + + <t>Other container formats have a global header section and packets only + contain frame data and never headers. Such formats include AVI, ASF, + Matroska, MPEG4 and NUT. Quicktime can be extended with support. MPEG + formats are lack of this hiearachy.</t> + + <t>With this proposal it will be possible to losslessly move codecs between + Ogg and the above mentioned formats which support global headers.</t> + </section> + + <section title="Other codecs"> + <t>Altought this document handles only Ogg codecs, the way of storing + 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> + </section> + + <section title="Minimum container requirements"> + <t>This appendix only explains how to store Vorbis in containers which + support at least one global header per stream, can seperate individual + Vorbis packets and support variable bitrate and variable number of + samples per packet.</t> + <t>Storage of Vorbis in other containers is outside the scope of this + appendix.</t> + </section> + +  + <section title="Storing global header"> + <t>If the container can store three headers per stream in an unambiguos + and ordered way then they shall be stored in that way. If on the other + hand the container is only capable to store a single global header + then the three Vorbis headers shall be concatenated without any + additional header, footer or seperator between them to recover the + three headers from such a global header the following procedure shall + be used: + <list style="numbers"> + <t>search for the first occurance of 01,'v','o','r','b','i','s' + <list style="none"><t>the found match and the following 23 bytes are the 1st header + packet</t></list> + </t> + <t>search for the 1st occurance of 03,'v','o','r','b','i','s' after here + <list style="symbols"> + <t>read an unsigned integer of 32 bits and skip that many bytes</t> + <t>[user_comment_list_length] = read an unsigned integer of 32 bits</t> + <t>iterate [user_comment_list_length] times {</t> + <t>read an unsigned integer of 32 bits and skip that many bytes</t> + <t>}</t> + <t>skip 1 byte</t> + </list> + </t> + <t>the match in 2. and what follows until here is the 2nd header packet</t> + <t>search for the 1st occurance of 05,'v','o','r','b','i','s' after here + <list style="none"><t>the matching part and what follows is the 3rd header packet</t></list> + </t> + </list> + </t> + </section> + + <section title="Storing packets"> + <t>Each Vorbis packet shall be stored in exactly one "container packet" + and one "container packet" must not contain more then one Vorbis packet.</t> + <t>A "container packet" here means the smallest seperateable unit of data + in the container</t> + </section> + + <section title="Codec identifier"> + <t>If the container uses four character codes (FOURCC; + <xref target="RFC2361">AVI</xref> and <xref target="FOURCC">Fourcc.org</xref>), + then the following identifiers shall be used: + <list style="symbols"> + <t>Vorbis: vrbs</t> + <t>Theora: theo</t> + <t>FLAC: flac</t> + <t>Speex: spex</t> + <t>Tarkin: trkn</t>  + </list></t> + + <t>If the container uses arbitrary length strings as identifiers, then + the following identifiers shall be used: + <list style="symbols"> + <t>Vorbis: vorbis</t> + <t>Theora: theora</t> + <t>FLAC: flac</t> + <t>Speex: speex</t> + <t>Tarkin: tarkin</t>  + </list></t> + </section> + + <section title="Example use in common containers"> + <t>What follows are some notes about specific containers. These notes + are just informative as they just repeat what is written above or in + the specification of the specific container.</t> + + <section title="AVI"> + <t>AVI supports everything needed to store Vorbis. This does not + mean that all application will support Vorbis in AVI, as Vorbis is + rather different from other audio codecs commonly stored in AVI.</t> + + <t>AVI supports a single global header like WAV does, the three + Vorbis headers shall be stored in it and only in it as described above</t> + + <t>dwSampleSize must be set to zero as Vorbis is VBR, many applications + do this incorrectly for other VBR codecs and consequently VBR audio + in avi becomes problematic</t> + + <t>AVI does not have timestamps, but each chunk has a constant duration, + while Vorbis packets can have one of two durations. If now the AVI header + is setup so that each AVI chunk has the same duration as the smaller + duration of the two possibilities in Vorbis, then simply inserting empty + AVI chunks will allow every AVI chunk to have the correct duration. This + is of course not the most beautifull solution, but it is the only way to + keep things exact. Additionally note, that empty chunks have been used + since ages in AVI to lengthen the duration of video chunks.</t> + </section> + + <section title="ASF"> + <t>ASF supports a single global header per stream and has timestamps so + storing Vorbis in it should be possible.</t> + </section> + + <section title="Matroska"> + <t><xref target="Matroska">Matroska</xref> supports storing three + headers using a Vorbis-Matroska specific format, which should be used.</t> + + <t>Note, the above procedure to split one header into three works + with the Vorbis-Matroska specific format too.</t> + </section> + + <section title="NUT"> + <t><xref target="NUT">NUT</xref> supports a single global header per + stream so the 3->1 merge and and the 1->3 split procedure above must be used.</t> + + <t>In addition to that, there is nothing special with storing Vorbis + in NUT.</t> + </section> + + <section title="MPEG-PS and MPEG-TS"> + <t>These containers neither support a global header, nor provide the + neccessary packet seperation or framing, so storing Vorbis in them is + outside the scope of this document.</t> + </section> + + <section title="WAV"> + <t>WAV does not provide the neccessary packet seperation or framing, + so storing Vorbis in it is outside the scope of this document.</t> + </section> + + <section title="Quicktime"> + <t>Quicktime currently lacks an unambigous place for a global header.</t> + + <t>A simple proposed way is storing a "glbl" chunk inside the track + header, containing the global headers. FIXME!</t> + </section> + + <section title="MPEG4"> + <t>MPEG4 is based on Quicktime and has an ESDS atom for the purpose. FIXME!</t> + </section> + </section> +</middle> + +<back> + <references> + &rfc2119; + &rfc2361; + &rfc3533; + + <reference anchor="ASF"> + <front> + <title>Advanced Systems Format (ASF) by Microsoft. http://www.microsoft.com/windows/windowsmedia/forpros/format/asfspec.aspx</title> + </front> + </reference> + + <reference anchor="FOURCC"> + <front> + <title>Fourcc.org, a collection of four character codes. http://www.fourcc.org/</title> + </front> + </reference> + + <reference anchor="Matroska"> + <front> + <title>Matroska, the extensible open standard Audio/Video container. + http://www.matroska.org/</title> + </front> + </reference> + + <reference anchor="MPEG4"> + <front> + <title>MPEG-4 Part 14: MPEG-4 File Format: The designated + container file format for MPEG-4 content, which is based on + Part 12.</title> + </front> + <seriesInfo name="ISO/IEC" value="14496-14:2003" /> + </reference> + + <reference anchor="NUT"> + <front> + <title>NUT, an efficient container format. http://www.nut.hu/</title> + </front> + </reference> + + <reference anchor="Quicktime"> + <front> + <title>QuickTime File Format by Apple. http://www.digitalpreservation.gov/formats/fdd/fdd000052.shtml</title> + </front> + </reference> + </references> +</back> + +</rfc>

2 1

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

30 Jul '06

Author: alex Date: Sun Jul 30 12:37:53 2006 New Revision: 126 Modified: trunk/docs/draft-xiph-oggless-00.xml Log: synchronize everything to michaels and baptistes comments 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 12:37:53 2006 @@ -139,7 +139,7 @@ </section> <section title="Theora"> - <t>Theora follows the same architecture than Vorbis.</t> + <t>Theora follows the same architecture as Vorbis:</t> <list style="symbols"> <t>The first header starts with 128,'t','h','e','o','r','a'.</t> <t>The second header starts with 129,'t','h','e','o','r','a' and @@ -250,12 +250,17 @@ <section title="Quicktime"> <t>Quicktime currently lacks an unambigous place for a global header.</t> - <t>A simple proposed way is storing a "glbl" chunk inside the track - header, containing the global headers. FIXME!</t> + <t>A simple proposed way is storing the global headers in a "glbl" + atom inside the "stsd" atom.</t> </section> <section title="MPEG4"> - <t>MPEG4 is based on Quicktime and has an ESDS atom for the purpose. FIXME!</t> + <t>The global header should be stored in the "stsd" atom the same way as + 'mp4a' does and object type shall be set correctly in esds.</t> + +  </section> </section> </middle>

1 0

minor Vorbis specification amendment proposal
by Michael Niedermayer 30 Jul '06

30 Jul '06

Hi Vorbis has 3 "global" header packets, while generic containers generally have only a single global header per stream my proposal to solve this, would be to add a few lines to the vorbis specification to clarify how to convert between the 3 headers and the single header needed for non ogg containers currently (without any standarized way) various groups simply use their own self-invented method to store vorbis in non ogg and consequently either merge the 3 headers as they see fit or just dump them into the file like normal packets leading to problems with random access (seeking) ... all that leads to many problems and incompatibilites Proposed amendment------------ To split a global header from a non ogg container: 1) search for the 1st occurance of 01,'v','o','r','b','i','s' the found match and the following 23 bytes are the 1st header packet 2) search for the 1st occurance of 03,'v','o','r','b','i','s' after here 3) read an unsigned integer of 32 bits and skip that many bytes 4) [user_comment_list_length] = read an unsigned integer of 32 bits 5) iterate [user_comment_list_length] times { 6) read an unsigned integer of 32 bits and skip that many bytes } 7) skip 1 byte 8) the match in 2) and what follows until here is the 2nd header packet 9) search for the 1st occurance of 05,'v','o','r','b','i','s' after here the matching part and what follows is the 3rd header packet To convert the 3 header packets to a single one for storege in a non ogg container, simple concatenate the 3 header packets without anything before, after or between them ------------------------------- the proposed spliting method will work with pretty much any way the packets can be merged, it will specifically work with 1. simple concatenation 2. the format in matroska (2<p1 size><p2 size><p1><p2><p3>, sizes stored like packet sizes in ogg) 3. 16/32bit size for packet 0, packet 0, 16/32bit size for packet 1, ... 4. 16bit size for packet 0, 16bit size for packet 1, ..., packet 0, ... 5. 16/32bit size for packet 0, 16/32bit size for packet 1, packet 0, ... one format it could fail with is if the 3 32bit sizes are put infront of the 3 packets, though that would require the packets to be large (giga bytes) for it to fail -- 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

5 13

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

30 Jul '06

Author: alex Date: Sun Jul 30 11:47:56 2006 New Revision: 125 Modified: trunk/docs/draft-xiph-oggless-00.xml Log: explain flac and theora too 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:47:56 2006 @@ -109,16 +109,19 @@ <t>If the container can store three headers per stream in an unambiguos and ordered way then they shall be stored in that way. If on the other hand the container is only capable to store a single global header - then the three Vorbis headers shall be concatenated without any - additional header, footer or seperator between them to recover the - three headers from such a global header the following procedure shall - be used: - <list style="numbers"> + then the multiple headers shall be concatenated without any additional + header, footer or separator between.</t> + + <t>To recover the three headers from such a global header, the following + procedures shall be used:</t> + + <section title="Vorbis"> + <t><list style="numbers"> <t>search for the first occurance of 01,'v','o','r','b','i','s' <list style="none"><t>the found match and the following 23 bytes are the 1st header packet</t></list> </t> - <t>search for the 1st occurance of 03,'v','o','r','b','i','s' after here + <t>search for the first occurance of 03,'v','o','r','b','i','s' after here <list style="symbols"> <t>read an unsigned integer of 32 bits and skip that many bytes</t> <t>[user_comment_list_length] = read an unsigned integer of 32 bits</t> @@ -129,18 +132,32 @@ </list> </t> <t>the match in 2. and what follows until here is the 2nd header packet</t> - <t>search for the 1st occurance of 05,'v','o','r','b','i','s' after here + <t>search for the first occurance of 05,'v','o','r','b','i','s' after here <list style="none"><t>the matching part and what follows is the 3rd header packet</t></list> </t> + </list></t> + </section> + + <section title="Theora"> + <t>Theora follows the same architecture than Vorbis.</t> + <list style="symbols"> + <t>The first header starts with 128,'t','h','e','o','r','a'.</t> + <t>The second header starts with 129,'t','h','e','o','r','a' and + contains comments in the same way as Vorbis.</t> + <t>The third header starts with 130,'t','h','e','o','r','a'.</t> </list> - </t> + </section> + + <section title="FLAC"> + <t>FLAC has only one global header packet, starting with the FOURCC fLaC</t> + </section> </section> <section title="Storing packets"> - <t>Each Vorbis packet shall be stored in exactly one "container packet" - and one "container packet" must not contain more then one Vorbis packet.</t> + <t>Each codec packet shall be stored in exactly one "container packet" + and one "container packet" must not contain more then one codec packet.</t> <t>A "container packet" here means the smallest seperateable unit of data - in the container</t> + in the container.</t> </section> <section title="Codec identifier"> @@ -168,11 +185,14 @@ </list></t> </section> - <section title="Example use in common containers"> + <section title="Preferred use in common containers"> <t>What follows are some notes about specific containers. These notes are just informative as they just repeat what is written above or in the specification of the specific container.</t> + <t>If a codec is not mentioned below, it does not have any special + requirements.</t> + <section title="AVI"> <t>AVI supports everything needed to store Vorbis. This does not mean that all application will support Vorbis in AVI, as Vorbis is

1 0

[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 29 Jul '06

29 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