OggMNG - Revision history

Saoshyant at 23:27, 15 February 2008

2008-02-15T23:27:07Z

← Older revision		Revision as of 23:27, 15 February 2008
Line 42:		Line 42:

	For the presentation slides use case, the streaming server will want to cache the current frame and send it on connect to new listeners. This is a new requirement over just caching the initial headers that are required by the Vorbis and Theora codecs.		For the presentation slides use case, the streaming server will want to cache the current frame and send it on connect to new listeners. This is a new requirement over just caching the initial headers that are required by the Vorbis and Theora codecs.
		+
		+	[[Category:Ogg Mappings]]

Rillian: /* Speculation */ I agree with Conrad now :)

2008-02-14T02:28:52Z

Speculation: I agree with Conrad now :)

← Older revision		Revision as of 02:28, 14 February 2008
Line 31:		Line 31:
	We have two uses of MNG in Ogg that need to be distinguished. The MNG stream can be a separate 'video' stream all on its own, e.g. presentation slides that should be displayed in parallel with the other streams, and as an overlay on another video stream. This could be done with heuristics (an overlay must be transparent, and match the video in frame dimensions), conventions (a tEXt chuck could include a "ROLE:Overlay" definition, or through a separate metastream header.		We have two uses of MNG in Ogg that need to be distinguished. The MNG stream can be a separate 'video' stream all on its own, e.g. presentation slides that should be displayed in parallel with the other streams, and as an overlay on another video stream. This could be done with heuristics (an overlay must be transparent, and match the video in frame dimensions), conventions (a tEXt chuck could include a "ROLE:Overlay" definition, or through a separate metastream header.

-	~~Conrad suggested~~ a ~~design where processing instructions could~~ in ~~included~~ in the ~~Fishbone metadata~~ packet~~, but Ralph thinks this needs some refinement~~.	+	Since this is a general requirement for overlay streams, the plan is to define standard entries in the Skeleton message headers (placed in the fishbone packet corresponding to the MNG stream) to make these determinations. The heuristics described above can be used as fallbacks in the absence of Skeleton information.
-		+
-	~~We recommend~~ the ~~heuristic approach for now~~.	+

	== Contra ==		== Contra ==

Rillian: Try to state the argument against MNG on a more objective basis.

2008-02-14T02:21:18Z

Try to state the argument against MNG on a more objective basis.

← Older revision		Revision as of 02:21, 14 February 2008
Line 35:		Line 35:
	We recommend the heuristic approach for now.		We recommend the heuristic approach for now.

-	== ~~Further Speculation~~ ==	+	== Contra ==

-	~~Some people, including staff members of Mozilla, believe~~ MNG ~~should be replaced~~ by ~~APNG~~, ~~a superset extension of PNG~~ with ~~multi-image support, but that should still~~ be ~~backwards-compatibilite with old PNG agents.~~	+	The MNG format has seen little adoption. The niche it was targeted at (animated web graphics) has been filled by flash, with SVG being the competing free format. The full profile is very complex while missing obvious features like general scale and rotation for sprite animation. Wouldn't something simpler or more popular be a better choice?

-	~~I, a non-Xiph member, wonder on other hand if OggMNG should become OggAPNG or actually keep the project as MNG.~~	+	See also [[OggSpots]] and [http://wiki.mozilla.org/APNG_Specification APNG].
-		+
-	See also [[OggSpots]].	+

	== Implementation Notes ==		== Implementation Notes ==

	For the presentation slides use case, the streaming server will want to cache the current frame and send it on connect to new listeners. This is a new requirement over just caching the initial headers that are required by the Vorbis and Theora codecs.		For the presentation slides use case, the streaming server will want to cache the current frame and send it on connect to new listeners. This is a new requirement over just caching the initial headers that are required by the Vorbis and Theora codecs.

Martin.leese: /* Implementation Notes */ Moved discussion to Discussion

2008-02-13T21:42:35Z

Implementation Notes: Moved discussion to Discussion

← Older revision		Revision as of 21:42, 13 February 2008
Line 46:		Line 46:

	For the presentation slides use case, the streaming server will want to cache the current frame and send it on connect to new listeners. This is a new requirement over just caching the initial headers that are required by the Vorbis and Theora codecs.		For the presentation slides use case, the streaming server will want to cache the current frame and send it on connect to new listeners. This is a new requirement over just caching the initial headers that are required by the Vorbis and Theora codecs.
-	~~:Because of oggSPOT's an extra presentational format for presentation slide like stuff isn't needed in :MNG and would like that MNG stays MNG anddoesn't changes to APNG~~
-	~~:In a presentation, you can also just pause the video for showing things.~~

Ogg.k.ogg.k: typo fixes

2008-02-12T13:53:25Z

typo fixes

← Older revision		Revision as of 13:53, 12 February 2008
Line 13:		Line 13:
	== Specification ==		== Specification ==

-	Native [http://libpng.org/pub/mng/spec/ MNG] is a chunk-based file format. Each coded element (header, compressed images data, control information, etc.) is wrapped in a 'chunk' structure consisting of a 4-byte data length, a 4-byte type field, the actual data, and a 4-byte CRC. These chunks are simply ~~contatentated~~ to form the MNG bytestream. There are some ordering rules for the chunks, and an initial 8 byte magic sequence for recognition.	+	Native [http://libpng.org/pub/mng/spec/ MNG] is a chunk-based file format. Each coded element (header, compressed images data, control information, etc.) is wrapped in a 'chunk' structure consisting of a 4-byte data length, a 4-byte type field, the actual data, and a 4-byte CRC. These chunks are simply concatenated to form the MNG bytestream. There are some ordering rules for the chunks, and an initial 8 byte magic sequence for recognition.

-	The most straightforward encapsulation is to make an Ogg packet of each chunk, and then apply some familiar conventions for pagination to assist with streaming and seekability. We complicate this by including only the chunk type and data fields, and not the length and checksum which are ~~redudant~~ in Ogg. This increases complexity, but the bitrate savings are valuable in some cases. libmng (v1.0.8 and later) has special support for this. Granulepos would be the presentation time of the mng frame (in "ticks" as defined in the MHDR chunk) in variable framerate schemes, or the frame count in fixed-framerate streams, analogous to the treatment in MNG itself.	+	The most straightforward encapsulation is to make an Ogg packet of each chunk, and then apply some familiar conventions for pagination to assist with streaming and seekability. We complicate this by including only the chunk type and data fields, and not the length and checksum which are redundant in Ogg. This increases complexity, but the bitrate savings are valuable in some cases. libmng (v1.0.8 and later) has special support for this. Granulepos would be the presentation time of the mng frame (in "ticks" as defined in the MHDR chunk) in variable framerate schemes, or the frame count in fixed-framerate streams, analogous to the treatment in MNG itself.

-	The beginning-of-stream packet thus consists on the 8 byte MNG file magic followed by the MHDR chunk type and data. This satisfies the design requirements of having the initial packet provide both codec identification and ~~relevent~~ information about the stream, such as the granulepos scheme. This must appear on a page by itself as usual. All other packets consist of individual chunk type+body as described above. The end-of-stream packet will be the MEND chunk (which has no body and so consists of only the 4 byte type) and need not be on a page by itself, nor must that page appear at the end of a grouped Ogg segment.	+	The beginning-of-stream packet thus consists on the 8 byte MNG file magic followed by the MHDR chunk type and data. This satisfies the design requirements of having the initial packet provide both codec identification and relevant information about the stream, such as the granulepos scheme. This must appear on a page by itself as usual. All other packets consist of individual chunk type+body as described above. The end-of-stream packet will be the MEND chunk (which has no body and so consists of only the 4 byte type) and need not be on a page by itself, nor must that page appear at the end of a grouped Ogg segment.

	For the sake of streaming, complex MNG streams should divide their referenced data into a section at the beginning of the logical stream, or associated within some trivial time with the actual display, so seeking works without having to search beyond the beginning of the stream for referenced objects, as is already required by vorbis and theora. For simple sequence-of-frames data, things are more straightforward of course. Likewise, if there is a tEXt (or zTXt or iTXt) chunk with metadata describing the whole stream, it should appear at the beginning of the stream after the MHDR but before any image data.		For the sake of streaming, complex MNG streams should divide their referenced data into a section at the beginning of the logical stream, or associated within some trivial time with the actual display, so seeking works without having to search beyond the beginning of the stream for referenced objects, as is already required by vorbis and theora. For simple sequence-of-frames data, things are more straightforward of course. Likewise, if there is a tEXt (or zTXt or iTXt) chunk with metadata describing the whole stream, it should appear at the beginning of the stream after the MHDR but before any image data.

Xpete: /* Implementation Notes */

2008-01-29T18:01:40Z

Implementation Notes

← Older revision		Revision as of 18:01, 29 January 2008
Line 46:		Line 46:

	For the presentation slides use case, the streaming server will want to cache the current frame and send it on connect to new listeners. This is a new requirement over just caching the initial headers that are required by the Vorbis and Theora codecs.		For the presentation slides use case, the streaming server will want to cache the current frame and send it on connect to new listeners. This is a new requirement over just caching the initial headers that are required by the Vorbis and Theora codecs.
-	:oggSPOT's ~~and~~ presentation slide like stuff isn't needed in MNG and would like that MNG stays MNG anddoesn't changes to APNG	+	:Because of oggSPOT's an extra presentational format for presentation slide like stuff isn't needed in :MNG and would like that MNG stays MNG anddoesn't changes to APNG
		+	:In a presentation, you can also just pause the video for showing things.

Xpete: /* Implementation Notes */

2008-01-29T18:00:49Z

Implementation Notes

← Older revision		Revision as of 18:00, 29 January 2008
Line 46:		Line 46:

	For the presentation slides use case, the streaming server will want to cache the current frame and send it on connect to new listeners. This is a new requirement over just caching the initial headers that are required by the Vorbis and Theora codecs.		For the presentation slides use case, the streaming server will want to cache the current frame and send it on connect to new listeners. This is a new requirement over just caching the initial headers that are required by the Vorbis and Theora codecs.
		+	:oggSPOT's and presentation slide like stuff isn't needed in MNG and would like that MNG stays MNG anddoesn't changes to APNG

Rillian: /* Specification */ some cleanup

2007-08-28T19:22:47Z

Specification: some cleanup

← Older revision		Revision as of 19:22, 28 August 2007
Line 15:		Line 15:
	Native [http://libpng.org/pub/mng/spec/ MNG] is a chunk-based file format. Each coded element (header, compressed images data, control information, etc.) is wrapped in a 'chunk' structure consisting of a 4-byte data length, a 4-byte type field, the actual data, and a 4-byte CRC. These chunks are simply contatentated to form the MNG bytestream. There are some ordering rules for the chunks, and an initial 8 byte magic sequence for recognition.		Native [http://libpng.org/pub/mng/spec/ MNG] is a chunk-based file format. Each coded element (header, compressed images data, control information, etc.) is wrapped in a 'chunk' structure consisting of a 4-byte data length, a 4-byte type field, the actual data, and a 4-byte CRC. These chunks are simply contatentated to form the MNG bytestream. There are some ordering rules for the chunks, and an initial 8 byte magic sequence for recognition.

-	The most straightforward encapsulation is to make an Ogg packet of each chunk, and then apply some familiar conventions for pagination to assist with streaming and seekability. We complicate this by including only the chunk type and data fields, and not the length and checksum which are redudant in Ogg. This increases complexity ~~a bit~~, but the bitrate savings ~~can be~~ valuable in some cases. libmng (v1.0.8 and later) has special support for this. Granulepos would be the presentation time of the mng frame (in "ticks" as defined in the MHDR chunk) in variable framerate schemes, or the frame count in fixed-framerate streams, analogous to the treatment in MNG itself.	+	The most straightforward encapsulation is to make an Ogg packet of each chunk, and then apply some familiar conventions for pagination to assist with streaming and seekability. We complicate this by including only the chunk type and data fields, and not the length and checksum which are redudant in Ogg. This increases complexity, but the bitrate savings are valuable in some cases. libmng (v1.0.8 and later) has special support for this. Granulepos would be the presentation time of the mng frame (in "ticks" as defined in the MHDR chunk) in variable framerate schemes, or the frame count in fixed-framerate streams, analogous to the treatment in MNG itself.

-	The beginning-of-stream packet thus consists on the 8 byte MNG file magic followed by the MHDR chunk type and data. This must appear on a page by itself ~~for codec id~~ as usual. ~~Other~~ packets consist of individual chunk type+body as described above. The end-of-stream packet will be the MEND chunk (which has no body and so consists of only the 4 byte type) and need not be on a page by itself, nor must that page appear at the end of a grouped Ogg segment.	+	The beginning-of-stream packet thus consists on the 8 byte MNG file magic followed by the MHDR chunk type and data. This satisfies the design requirements of having the initial packet provide both codec identification and relevent information about the stream, such as the granulepos scheme. This must appear on a page by itself as usual. All other packets consist of individual chunk type+body as described above. The end-of-stream packet will be the MEND chunk (which has no body and so consists of only the 4 byte type) and need not be on a page by itself, nor must that page appear at the end of a grouped Ogg segment.

-	For the sake of streaming, complex MNG streams should divide their referenced data into a section at the beginning of the logical stream, or associated within some trivial time with the actual display, so seeking works without having to search ~~for referenced objects~~ beyond the beginning of stream, as is already required by vorbis and theora. For simple sequence-of-frames data, things are more straightforward of course. Likewise, if there is a tEXt (or zTXt or iTXt) chunk with metadata describing the whole stream, it should appear at the beginning of the stream after the MHDR but before any image data.	+	For the sake of streaming, complex MNG streams should divide their referenced data into a section at the beginning of the logical stream, or associated within some trivial time with the actual display, so seeking works without having to search beyond the beginning of the stream for referenced objects, as is already required by vorbis and theora. For simple sequence-of-frames data, things are more straightforward of course. Likewise, if there is a tEXt (or zTXt or iTXt) chunk with metadata describing the whole stream, it should appear at the beginning of the stream after the MHDR but before any image data.

-	~~The obvious extension could be made to including~~ still ~~images as~~ PNG or JNG (png-style file format encapsulating jpeg image data with an optional alpha mask) e.g for album art. In that case the same stripped chunk to packet mapping ~~works~~, with the beginning-of-stream packet being the 8 byte PNG or JNG signature followed by the IHDR or JHDR chunk type and body, respectively.	+	Since the still image formats PNG or JNG (png-style file format encapsulating jpeg image data with an optional alpha mask) are also by specification valid MNG files, we make the same extension to allow their encapsulation in Ogg, e.g. for album art. In that case the same stripped chunk to packet mapping is used, with the beginning-of-stream packet being the 8 byte PNG or JNG signature followed by the IHDR or JHDR chunk type and body, respectively. Encoders should set the granulepos of any pages containing still image data to 0. Decoders should ignore the granulepos and display the still image in whatever association with the other data it deems appropriate.

	== Speculation ==		== Speculation ==

Rillian: /* Further Speculation */ link to Ogg Spots page

2006-05-01T21:53:37Z

Further Speculation: link to Ogg Spots page

← Older revision		Revision as of 21:53, 1 May 2006
Line 40:		Line 40:

	I, a non-Xiph member, wonder on other hand if OggMNG should become OggAPNG or actually keep the project as MNG.		I, a non-Xiph member, wonder on other hand if OggMNG should become OggAPNG or actually keep the project as MNG.
		+
		+	See also [[OggSpots]].

	== Implementation Notes ==		== Implementation Notes ==

	For the presentation slides use case, the streaming server will want to cache the current frame and send it on connect to new listeners. This is a new requirement over just caching the initial headers that are required by the Vorbis and Theora codecs.		For the presentation slides use case, the streaming server will want to cache the current frame and send it on connect to new listeners. This is a new requirement over just caching the initial headers that are required by the Vorbis and Theora codecs.

Rillian: /* Specification */ base fixed framerate granulepos on count, not index, to match other codecs

2006-04-04T22:29:27Z

Specification: base fixed framerate granulepos on count, not index, to match other codecs

← Older revision		Revision as of 22:29, 4 April 2006
Line 15:		Line 15:
	Native [http://libpng.org/pub/mng/spec/ MNG] is a chunk-based file format. Each coded element (header, compressed images data, control information, etc.) is wrapped in a 'chunk' structure consisting of a 4-byte data length, a 4-byte type field, the actual data, and a 4-byte CRC. These chunks are simply contatentated to form the MNG bytestream. There are some ordering rules for the chunks, and an initial 8 byte magic sequence for recognition.		Native [http://libpng.org/pub/mng/spec/ MNG] is a chunk-based file format. Each coded element (header, compressed images data, control information, etc.) is wrapped in a 'chunk' structure consisting of a 4-byte data length, a 4-byte type field, the actual data, and a 4-byte CRC. These chunks are simply contatentated to form the MNG bytestream. There are some ordering rules for the chunks, and an initial 8 byte magic sequence for recognition.

-	The most straightforward encapsulation is to make an Ogg packet of each chunk, and then apply some familiar conventions for pagination to assist with streaming and seekability. We complicate this by including only the chunk type and data fields, and not the length and checksum which are redudant in Ogg. This increases complexity a bit, but the bitrate savings can be valuable in some cases. libmng (v1.0.8 and later) has special support for this. Granulepos would be the presentation time of the mng frame (in "ticks" as defined in the MHDR chunk) in variable framerate schemes, or the frame ~~number~~ in fixed-framerate streams, analogous to the treatment in MNG itself.	+	The most straightforward encapsulation is to make an Ogg packet of each chunk, and then apply some familiar conventions for pagination to assist with streaming and seekability. We complicate this by including only the chunk type and data fields, and not the length and checksum which are redudant in Ogg. This increases complexity a bit, but the bitrate savings can be valuable in some cases. libmng (v1.0.8 and later) has special support for this. Granulepos would be the presentation time of the mng frame (in "ticks" as defined in the MHDR chunk) in variable framerate schemes, or the frame count in fixed-framerate streams, analogous to the treatment in MNG itself.

	The beginning-of-stream packet thus consists on the 8 byte MNG file magic followed by the MHDR chunk type and data. This must appear on a page by itself for codec id as usual. Other packets consist of individual chunk type+body as described above. The end-of-stream packet will be the MEND chunk (which has no body and so consists of only the 4 byte type) and need not be on a page by itself, nor must that page appear at the end of a grouped Ogg segment.		The beginning-of-stream packet thus consists on the 8 byte MNG file magic followed by the MHDR chunk type and data. This must appear on a page by itself for codec id as usual. Other packets consist of individual chunk type+body as described above. The end-of-stream packet will be the MEND chunk (which has no body and so consists of only the 4 byte type) and need not be on a page by itself, nor must that page appear at the end of a grouped Ogg segment.