OggIssues - Revision history

DOS386: /* See also */

2012-03-11T16:22:40Z

Vinipsmaker: /* A successor to Ogg */

2009-07-05T23:39:40Z

A successor to Ogg

← Older revision		Revision as of 23:39, 5 July 2009
Line 78:		Line 78:
	== A successor to Ogg ==		== A successor to Ogg ==

	* It should be called (Ogg2\|Ogg3\|Ogg++\|OggNG\|Ogh\|Foo\|Dumplings\|AdvancedOgg\|Ogg+m\|ggo)		* It should be called (Ogg2\|Ogg3\|Ogg++\|OggNG\|Ogh\|Foo\|Dumplings\|AdvancedOgg or AOgg or Ogg+A\|ggo\|SOgg)
	* The design should be done from desired capabilities and desired properties		* The design should be done from desired capabilities and desired properties
	* These capabilities and properties should come from AV experts, web-page designers, system administrators, and users		* These capabilities and properties should come from AV experts, web-page designers, system administrators, and users

Vinipsmaker: /* A successor to Ogg */

2009-07-05T23:32:06Z

A successor to Ogg

← Older revision		Revision as of 23:32, 5 July 2009
Line 78:		Line 78:
	== A successor to Ogg ==		== A successor to Ogg ==

	* It should be called (Ogg2\|Ogg3\|Ogg++\|OggNG\|Ogh\|Foo\|Dumplings)		* It should be called (Ogg2\|Ogg3\|Ogg++\|OggNG\|Ogh\|Foo\|Dumplings\|AdvancedOgg\|Ogg+m\|ggo)
	* The design should be done from desired capabilities and desired properties		* The design should be done from desired capabilities and desired properties
	* These capabilities and properties should come from AV experts, web-page designers, system administrators, and users		* These capabilities and properties should come from AV experts, web-page designers, system administrators, and users

Xiphmont: /* Seeking and Editing Problems */

2008-02-15T21:00:16Z

Seeking and Editing Problems

Xiphmont: /* Seeking and Editing Problems */

2008-02-15T20:44:54Z

Seeking and Editing Problems

← Older revision		Revision as of 20:44, 15 February 2008
Line 11:		Line 11:
	* jagged edges [ie, coarse granularity]		* jagged edges [ie, coarse granularity]

	> In Ogg, a codec's frames (packets) are encapsulated into pages, either one at a time or in groups. It is typical, for instance, for an audio stream to store many packets on a single page and a video stream to store only one or possibly two packets on a page. The individual ['logical'] audio and video streams are multiplexed into a single 'physical' stream at the page level. This is done for two reasons: First, to make it easy to multiplex and demultiplex streams into new arrangements, and second to reduce the overhead of encapsulation. By grouping small packets into a larger page, the overhead of the page header is spread across the packets. A well-formed Ogg stream has a typical overhead of about 1%, regardless of the media types it encapsulates.		:In Ogg, a codec's frames (packets) are encapsulated into pages, either one at a time or in groups. It is typical, for instance, for an audio stream to store many packets on a single page and a video stream to store only one or possibly two packets on a page. The individual ['logical'] audio and video streams are multiplexed into a single 'physical' stream at the page level. This is done for two reasons: First, to make it easy to multiplex and demultiplex streams into new arrangements, and second to reduce the overhead of encapsulation. By grouping small packets into a larger page, the overhead of the page header is spread across the packets. A well-formed Ogg stream has a typical overhead of about 1%, regardless of the media types it encapsulates.

	> The 'jagged edges' complaint arises when pages are produced with a heavily skewed balance between pages of different stream types. For example, audio pages that contain a full second of audio packets but video pages that contain a single video frame. We would then see 20 or 30 video pages for each audio page.		:The 'jagged edges' complaint arises when pages are produced with a heavily skewed balance between pages of different stream types. For example, audio pages that contain a full second of audio packets but video pages that contain a single video frame. We would then see 20 or 30 video pages for each audio page.

	> This arrangement is not incorrect, it is merely suboptimal. In a well written stream handler, it would mean that packet or sample precision seeking takes longer and that buffering overhead is higher. However, in a poorly written stream handler that makes invalid assumptions about Ogg streams for convenience, it can trigger bugs. Either the Ogg stream or Ogg itself is blamed for allowing such 'stupid' streams. Note however that even such a 'broken' stream (it is not broken, it's simply suboptimal) can be repaginated into an optimal arrangement losslessly.		:This arrangement is not incorrect, it is merely suboptimal. In a well written stream handler, it would mean that packet or sample precision seeking takes longer and that buffering overhead is higher. However, in a poorly written stream handler that makes invalid assumptions about Ogg streams for convenience, it can trigger bugs. Either the Ogg stream or Ogg itself is blamed for allowing such 'stupid' streams. Note however that even such a 'broken' stream (it is not broken, it's simply suboptimal) can be repaginated into an optimal arrangement losslessly.

	> The root of the 'balancing' problem is a lack of functionality. By default, libogg always flushes pages at just over 4kB (rather than working by timestamp or some other better default). Changing this behavior requires manual intervention in stream building when it should be automatic to libogg. Chalk this one up to 'software flaw' not 'inadequacy in Ogg'.		:The root of the 'balancing' problem is a lack of functionality. By default, libogg always flushes pages at just over 4kB (rather than working by timestamp or some other better default). Changing this behavior requires manual intervention in stream building when it should be automatic to libogg. Chalk this one up to 'software flaw' not 'inadequacy in Ogg'.

	* wide variance in location of cotemporal data		* wide variance in location of cotemporal data

	> This is a different way of describing the 'jagged edges' problem above. Because a suboptimally chosen interleave can have low-bitrate pages spaced far apaprt, the audio frames for a given point in time may be physically located well away from the time-matching video data. This point is addressed above.		:This is a different way of describing the 'jagged edges' problem above. Because a suboptimally chosen interleave can have low-bitrate pages spaced far apaprt, the audio frames for a given point in time may be physically located well away from the time-matching video data. This point is addressed above.

	* impossible to reconstruct all granulepos values around holes		* impossible to reconstruct all granulepos values around holes

Xiphmont: /* Seeking and Editing Problems */

2008-02-15T20:24:02Z

Seeking and Editing Problems

← Older revision		Revision as of 20:24, 15 February 2008
Line 11:		Line 11:
	* jagged edges [ie, coarse granularity]		* jagged edges [ie, coarse granularity]

	In Ogg, a codec's frames (packets) are encapsulated into pages, either one at a time or in groups. It is typical, for instance, for an audio stream to store many packets on a single page and a video stream to store only one or possibly two packets on a page. The individual ['logical'] audio and video streams are multiplexed into a single 'physical' stream at the page level. This is done for two reasons: First, to make it easy to multiplex and demultiplex streams into new arrangements, and second to reduce the overhead of encapsulation. By grouping small packets into a larger page, the overhead of the page header is spread across the packets. A well-formed Ogg stream has a typical overhead of about 1%, regardless of the media types it encapsulates.		> In Ogg, a codec's frames (packets) are encapsulated into pages, either one at a time or in groups. It is typical, for instance, for an audio stream to store many packets on a single page and a video stream to store only one or possibly two packets on a page. The individual ['logical'] audio and video streams are multiplexed into a single 'physical' stream at the page level. This is done for two reasons: First, to make it easy to multiplex and demultiplex streams into new arrangements, and second to reduce the overhead of encapsulation. By grouping small packets into a larger page, the overhead of the page header is spread across the packets. A well-formed Ogg stream has a typical overhead of about 1%, regardless of the media types it encapsulates.

	The 'jagged edges' complaint arises when pages are produced with a heavily skewed balance between pages of different stream types. For example, audio pages that contain a full second of audio packets but video pages that contain a single video frame. We would then see 20 or 30 video pages for each audio page.		> The 'jagged edges' complaint arises when pages are produced with a heavily skewed balance between pages of different stream types. For example, audio pages that contain a full second of audio packets but video pages that contain a single video frame. We would then see 20 or 30 video pages for each audio page.

	This arrangement is not incorrect, it is merely suboptimal. In a well written stream handler, it would mean that packet or sample precision seeking takes longer and that buffering overhead is higher. However, in a poorly written stream handler that makes invalid assumptions about Ogg streams for convenience, it can trigger bugs. Either the Ogg stream or Ogg itself is blamed for allowing such 'stupid' streams. Note however that even such a 'broken' stream (it is not broken, it's simply suboptimal) can be repaginated into an optimal arrangement losslessly.		> This arrangement is not incorrect, it is merely suboptimal. In a well written stream handler, it would mean that packet or sample precision seeking takes longer and that buffering overhead is higher. However, in a poorly written stream handler that makes invalid assumptions about Ogg streams for convenience, it can trigger bugs. Either the Ogg stream or Ogg itself is blamed for allowing such 'stupid' streams. Note however that even such a 'broken' stream (it is not broken, it's simply suboptimal) can be repaginated into an optimal arrangement losslessly.

	The root of the 'balancing' problem is a lack of functionality. By default, libogg always flushes pages at just over 4kB (rather than working by timestamp or some other better default). Changing this behavior requires manual intervention in stream building when it should be automatic to libogg. Chalk this one up to 'software flaw' not 'inadequacy in Ogg'.		> The root of the 'balancing' problem is a lack of functionality. By default, libogg always flushes pages at just over 4kB (rather than working by timestamp or some other better default). Changing this behavior requires manual intervention in stream building when it should be automatic to libogg. Chalk this one up to 'software flaw' not 'inadequacy in Ogg'.

	* wide variance in location of cotemporal data		* wide variance in location of cotemporal data

	This is a different way of describing the 'jagged edges' problem above. Because a suboptimally chosen interleave can have low-bitrate pages spaced far apaprt, the audio frames for a given point in time may be physically located well away from the time-matching video data. This point is addressed above.		> This is a different way of describing the 'jagged edges' problem above. Because a suboptimally chosen interleave can have low-bitrate pages spaced far apaprt, the audio frames for a given point in time may be physically located well away from the time-matching video data. This point is addressed above.

	* impossible to reconstruct all granulepos values around holes		* impossible to reconstruct all granulepos values around holes

Xiphmont: /* Seeking and Editing Problems */

2008-02-15T20:21:13Z

Seeking and Editing Problems

← Older revision		Revision as of 20:21, 15 February 2008
Line 7:		Line 7:
	== Seeking and Editing Problems ==		== Seeking and Editing Problems ==

	* jagged edges		These mostly boil down to a lack of provided, reference library software to perform the tasks of seeking and tracking for the application developer. Libogg as it exists now is a very low-level library that provides only the rudimentary routines necessary to provide valid stream building blocks (pages and packets). It does not provide any higher-level or automatic stream handling functionality, and as such, each application developer has had to reinvent the higher level routines over and over again. This leads to the impression that Ogg is an overly complex and error-prone encapsulation as 100 different applications will each have their own homegrown stream handling routines, each with their own bugs and unimplemented functions. The chaos that reigns in the Ogg application space is not an idictment of Ogg. It's due to a lack of stable, documented, high-level stream handling libraries from the beginning.

			* jagged edges [ie, coarse granularity]

			In Ogg, a codec's frames (packets) are encapsulated into pages, either one at a time or in groups. It is typical, for instance, for an audio stream to store many packets on a single page and a video stream to store only one or possibly two packets on a page. The individual ['logical'] audio and video streams are multiplexed into a single 'physical' stream at the page level. This is done for two reasons: First, to make it easy to multiplex and demultiplex streams into new arrangements, and second to reduce the overhead of encapsulation. By grouping small packets into a larger page, the overhead of the page header is spread across the packets. A well-formed Ogg stream has a typical overhead of about 1%, regardless of the media types it encapsulates.

			The 'jagged edges' complaint arises when pages are produced with a heavily skewed balance between pages of different stream types. For example, audio pages that contain a full second of audio packets but video pages that contain a single video frame. We would then see 20 or 30 video pages for each audio page.

			This arrangement is not incorrect, it is merely suboptimal. In a well written stream handler, it would mean that packet or sample precision seeking takes longer and that buffering overhead is higher. However, in a poorly written stream handler that makes invalid assumptions about Ogg streams for convenience, it can trigger bugs. Either the Ogg stream or Ogg itself is blamed for allowing such 'stupid' streams. Note however that even such a 'broken' stream (it is not broken, it's simply suboptimal) can be repaginated into an optimal arrangement losslessly.

			The root of the 'balancing' problem is a lack of functionality. By default, libogg always flushes pages at just over 4kB (rather than working by timestamp or some other better default). Changing this behavior requires manual intervention in stream building when it should be automatic to libogg. Chalk this one up to 'software flaw' not 'inadequacy in Ogg'.

	* wide variance in location of cotemporal data		* wide variance in location of cotemporal data

			This is a different way of describing the 'jagged edges' problem above. Because a suboptimally chosen interleave can have low-bitrate pages spaced far apaprt, the audio frames for a given point in time may be physically located well away from the time-matching video data. This point is addressed above.

	* impossible to reconstruct all granulepos values around holes		* impossible to reconstruct all granulepos values around holes

	* granulepos / timeval mapping inconsistencies		* granulepos / timeval mapping inconsistencies

	* poorly sorted streams are rife		* poorly sorted streams are rife

	* impossible to efficiently seek with noncontinuous data		* impossible to efficiently seek with noncontinuous data

Xiphmont at 19:37, 15 February 2008

2008-02-15T19:37:23Z

← Older revision		Revision as of 19:37, 15 February 2008
Line 3:		Line 3:
	[work in progress]		[work in progress]

	The sections and bullet points on this page are a dump of slides from a Shane Stephens FOMS 2008 talk. They reflect a number of 'problems' developers regularly bring up with Ogg, both legitimately and erroneously. Because these points are brought up regularly and often incorrectly used in support of other formats [such as Matroska and NUT] we've added them to the Wiki here along with a response/discussion of each claimed problem. For the most part, they reflect either an inadequacy in existing software, an inadequacy in existing documentation and/or a misunderstanding of the Ogg encapsulation. Consider this Wiki ~~page~~ page a first step toward rectifying a legitimate lack of documentation.		The sections and bullet points on this page are a dump of slides from a Shane Stephens FOMS 2008 talk. They reflect a number of 'problems' developers regularly bring up with Ogg, both legitimately and erroneously. Because these points are brought up regularly and often incorrectly used in support of other formats [such as Matroska and NUT] we've added them to the Wiki here along with a response/discussion of each claimed problem. For the most part, they reflect either an inadequacy in existing software, an inadequacy in existing documentation and/or a misunderstanding of the Ogg encapsulation. Consider this Wiki page a first step toward rectifying a legitimate lack of documentation.

	== Seeking and Editing Problems ==		== Seeking and Editing Problems ==

Xiphmont at 19:36, 15 February 2008

2008-02-15T19:36:34Z

← Older revision		Revision as of 19:36, 15 February 2008
Line 3:		Line 3:
	[work in progress]		[work in progress]

	The sections and bullet points on this page are a dump of slides from a Shane ~~Stephen's~~ FOMS 2008 talk. They reflect a number of 'problems' developers regularly bring up with Ogg, both legitimately and erroneously. Because these points are brought up regularly and often incorrectly used in support of other formats [such as Matroska and NUT] we've added them to the Wiki here along with a response/discussion of each claimed problem. For the most part, they reflect either an inadequacy in existing software, an inadequacy in existing documentation and/or a misunderstanding of the Ogg encapsulation. Consider this Wiki page page a first step toward rectifying a legitimate lack of documentation.		The sections and bullet points on this page are a dump of slides from a Shane Stephens FOMS 2008 talk. They reflect a number of 'problems' developers regularly bring up with Ogg, both legitimately and erroneously. Because these points are brought up regularly and often incorrectly used in support of other formats [such as Matroska and NUT] we've added them to the Wiki here along with a response/discussion of each claimed problem. For the most part, they reflect either an inadequacy in existing software, an inadequacy in existing documentation and/or a misunderstanding of the Ogg encapsulation. Consider this Wiki page page a first step toward rectifying a legitimate lack of documentation.

	== Seeking and Editing Problems ==		== Seeking and Editing Problems ==

Xiphmont: Add a summary of what this page is about

2008-02-15T19:35:21Z

Add a summary of what this page is about

← Older revision		Revision as of 19:35, 15 February 2008
Line 1:		Line 1:
	= Problems resulting from design of Ogg =		= Problems resulting from design of Ogg =

			[work in progress]

			The sections and bullet points on this page are a dump of slides from a Shane Stephen's FOMS 2008 talk. They reflect a number of 'problems' developers regularly bring up with Ogg, both legitimately and erroneously. Because these points are brought up regularly and often incorrectly used in support of other formats [such as Matroska and NUT] we've added them to the Wiki here along with a response/discussion of each claimed problem. For the most part, they reflect either an inadequacy in existing software, an inadequacy in existing documentation and/or a misunderstanding of the Ogg encapsulation. Consider this Wiki page page a first step toward rectifying a legitimate lack of documentation.

	== Seeking and Editing Problems ==		== Seeking and Editing Problems ==

← Older revision		Revision as of 16:22, 11 March 2012
Line 124:		Line 124:
	* Nobody cares about <insert hated feature here> anyway		* Nobody cares about <insert hated feature here> anyway
	* Even if we have Ogg2, we'll still be stuck having to support Ogg1 and broken files		* Even if we have Ogg2, we'll still be stuck having to support Ogg1 and broken files

	~~== See also ==~~
	* [[NutIssues]]

	[[Category:Ogg]]		[[Category:Ogg]]

← Older revision		Revision as of 21:00, 15 February 2008
Line 9:		Line 9:
	These mostly boil down to a lack of provided, reference library software to perform the tasks of seeking and tracking for the application developer. Libogg as it exists now is a very low-level library that provides only the rudimentary routines necessary to provide valid stream building blocks (pages and packets). It does not provide any higher-level or automatic stream handling functionality, and as such, each application developer has had to reinvent the higher level routines over and over again. This leads to the impression that Ogg is an overly complex and error-prone encapsulation as 100 different applications will each have their own homegrown stream handling routines, each with their own bugs and unimplemented functions. The chaos that reigns in the Ogg application space is not an idictment of Ogg. It's due to a lack of stable, documented, high-level stream handling libraries from the beginning.		These mostly boil down to a lack of provided, reference library software to perform the tasks of seeking and tracking for the application developer. Libogg as it exists now is a very low-level library that provides only the rudimentary routines necessary to provide valid stream building blocks (pages and packets). It does not provide any higher-level or automatic stream handling functionality, and as such, each application developer has had to reinvent the higher level routines over and over again. This leads to the impression that Ogg is an overly complex and error-prone encapsulation as 100 different applications will each have their own homegrown stream handling routines, each with their own bugs and unimplemented functions. The chaos that reigns in the Ogg application space is not an idictment of Ogg. It's due to a lack of stable, documented, high-level stream handling libraries from the beginning.

	* jagged edges [ie, coarse granularity]		* '''jagged edges [ie, coarse granularity]'''

	:In Ogg, a codec's frames (packets) are encapsulated into pages, ~~either one at a time~~ or in groups. It is typical~~, for instance,~~ for an audio stream to store many packets on a single page and a video stream to store only one or possibly two packets on a page. The individual ['logical'] audio and video streams are multiplexed into a single 'physical' stream at the page level. This is done for two reasons: First, to make it easy to multiplex and demultiplex streams into new arrangements, and second to reduce the overhead of encapsulation. By grouping small packets into a larger page, the overhead of the page header is spread across the packets. A well-formed Ogg stream has a typical overhead of about 1%, regardless of the media types it encapsulates.		:In Ogg, a codec's frames (packets) are encapsulated into pages, singly or in groups. It is typical for an audio stream to store many packets on a single page and a video stream to store only one or possibly two packets on a page. The individual ['logical'] audio and video streams are multiplexed into a single 'physical' stream at the page level. This is done for two reasons: First, to make it easy to multiplex and demultiplex streams into new arrangements, and second to reduce the overhead of encapsulation. By grouping small packets into a larger page, the overhead of the page header is spread across the packets. A well-formed Ogg stream has a typical overhead of about 1%, regardless of the media types it encapsulates.

	:The 'jagged edges' complaint arises ~~when pages are produced with a heavily skewed balance between~~ pages of ~~different~~ stream ~~types~~. ~~For example,~~ audio ~~pages that~~ contain a full second of audio packets ~~but~~ video pages ~~that contain~~ a single video frame. We would then see 20 or 30 video pages for each audio page.		:The 'jagged edges' complaint arises because default libogg1 behavior fills all pages to ~ 4kB regardless of stream bitrate. A given audio page might contain a full second of audio packets while a video pages contains a single video frame. We would then see 20 or 30 video pages for each audio page.

	:This arrangement is not incorrect, it is merely suboptimal. ~~In a well written stream handler, it would mean that packet or~~ sample precision seeking takes longer and ~~that~~ buffering overhead is higher. However, in a poorly written stream handler that makes invalid assumptions about Ogg streams for convenience, it can trigger bugs. Either the Ogg stream or Ogg itself is blamed for allowing such 'stupid' streams. Note however that even such a 'broken' stream (it is not broken, it's simply suboptimal) can be repaginated into an optimal arrangement losslessly.		:This arrangement is not incorrect, it is merely suboptimal when optimizing for minimal buffering and seeking. Packet and sample precision seeking takes longer and buffering overhead is higher. However, in a poorly written stream handler that makes invalid assumptions about Ogg streams for convenience, it can trigger bugs. Either the Ogg stream or Ogg itself is blamed for allowing such 'stupid' streams. Note however that even such a 'broken' stream (it is not broken, it's simply suboptimal) can be repaginated into an optimal arrangement losslessly.

	:The root of the 'balancing' problem is a lack of functionality. By default, libogg always flushes pages at just over 4kB (rather than working by timestamp or some other better default). Changing this behavior requires manual intervention in stream building when it should be automatic to libogg. Chalk this one up to 'software flaw' not 'inadequacy in Ogg'.		:The root of the 'balancing' problem is a lack of functionality. By default, libogg always flushes pages at just over 4kB (rather than working by timestamp or some other better default). Changing this behavior requires manual intervention in stream building when it should be automatic to libogg. Chalk this one up to 'software flaw' not 'inadequacy in Ogg'.

	* wide variance in location of cotemporal data		* '''wide variance in location of cotemporal data'''

	:This is a different way of describing the 'jagged edges' problem above. Because a suboptimally chosen interleave can have low-bitrate pages spaced far apaprt, the audio frames for a given point in time may be physically located well away from the time-matching video data. This point is addressed above.		:This is a different way of describing the 'jagged edges' problem above. Because a suboptimally chosen interleave can have low-bitrate pages spaced far apaprt, the audio frames for a given point in time may be physically located well away from the time-matching video data. This point is addressed above.

	* impossible to reconstruct all granulepos values around holes		* '''impossible to reconstruct all granulepos values around holes'''

	* granulepos / timeval mapping inconsistencies		* '''granulepos / timeval mapping inconsistencies'''

	* poorly sorted streams are rife		* '''poorly sorted streams are rife'''

	* impossible to efficiently seek with noncontinuous data		* '''impossible to efficiently seek with noncontinuous data'''

	== Synchronization ==		== Synchronization ==