OggIssues
From XiphWiki
(Difference between revisions)
(re-format in terms of design problems, proposed solutions etc.) |
|||
| Line 1: | Line 1: | ||
| + | = Problems resulting from design of Ogg = | ||
| + | |||
== Seeking and Editing Problems == | == Seeking and Editing Problems == | ||
| Line 18: | Line 20: | ||
* pages, and libogg's behaviour when creating them | * pages, and libogg's behaviour when creating them | ||
| + | == What use are... == | ||
| + | |||
| + | * serial numbers? | ||
| + | * packet numbers? | ||
| + | * pages? | ||
| + | * checksums? | ||
| + | ** Useful for audio (preventing ear damage), but could be optional for video | ||
| + | |||
| + | == Cleaner Abstractions == | ||
| + | |||
| + | * We should not need to know the type of a stream if we are not decoding the stream | ||
| + | * granulepos interpretations | ||
| + | * headers | ||
| + | * seeking | ||
| + | * cutting | ||
| + | * Skeleton goes some way towards fixing this | ||
| + | |||
| + | == Libogg issues == | ||
| + | |||
| + | * Stupid decision for flushing pages | ||
| + | * Makes it generally easy to build broken files. | ||
| + | |||
| + | = Proposed solutions = | ||
| + | |||
| + | == Short-term workarounds (Ogg1-compatible) == | ||
| + | * Don't use partial packets unless absolutely necessary | ||
| + | * If absolutely necessary, don't share the pages with other packets | ||
| + | * Specify that pages should not contain more than X ms of data (let's say 250-500 ms) | ||
| + | * Put Theora keyframes alone on their page?? | ||
| - | == | + | == Successor to Ogg == |
* We need to design a successor to Ogg | * We need to design a successor to Ogg | ||
| Line 59: | Line 90: | ||
* Would an up-front index be better? | * Would an up-front index be better? | ||
| - | == | + | = Rebuttal = |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
== Devil's Advocate == | == Devil's Advocate == | ||
| Line 83: | Line 99: | ||
* 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 | ||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
Revision as of 04:51, 8 February 2008
Contents |
Problems resulting from design of Ogg
Seeking and Editing Problems
- jagged edges
- wide variance in location of cotemporal data
- impossible to reconstruct all granulepos values around holes
- granulepos / timeval mapping inconsistencies
- poorly sorted streams are rife
- impossible to efficiently seek with noncontinuous data
Other Niggles
- end-time ordering
- except when we have non-continuous data
- Ordering isn't only an issue for non-continuous data. In theory, an idiot can fit up to ~30 minutes of Speex audio (silence) in a single page (or 4 minutes of actual speech).
- inefficient lacing values for video
- ad-hoc granulepos retrofitting for video, CMML
- seeking is hard
- pages, and libogg's behaviour when creating them
What use are...
- serial numbers?
- packet numbers?
- pages?
- checksums?
- Useful for audio (preventing ear damage), but could be optional for video
Cleaner Abstractions
- We should not need to know the type of a stream if we are not decoding the stream
- granulepos interpretations
- headers
- seeking
- cutting
- Skeleton goes some way towards fixing this
Libogg issues
- Stupid decision for flushing pages
- Makes it generally easy to build broken files.
Proposed solutions
Short-term workarounds (Ogg1-compatible)
- Don't use partial packets unless absolutely necessary
- If absolutely necessary, don't share the pages with other packets
- Specify that pages should not contain more than X ms of data (let's say 250-500 ms)
- Put Theora keyframes alone on their page??
Successor to Ogg
- We need to design a successor to Ogg
- It should be called (Ogg2|Ogg3|Ogg++|OggNG|Ogh|Foo|Dumplings)
- 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
Desired Capabilities
- Simple seeking
- Cleanly cuttable
- Robust to errors
- Composable
- Supports arbitrary stream types
- Low bit cost
- Streamable
- Easy to chunk
- Low decode cost
- Supports multiple streams of each type
Untied We Stand
- Can cotemporal data be colocated?
- streams & bundles
- great for cutting
- OK for demultiplexing
- “should” cut down on bit overhead
- hugely simplifies seeking
Gimme a Hint
- Can we add seeking hints to the stream?
- these can be tiny and infrequent
- awesome for standalone files
- what do we do when streaming?
- hint correction packets?
- is this turtles all the way down?
- Would an up-front index be better?
Rebuttal
Devil's Advocate
- These problems aren't unsurmountable
- but we're only finding some of them now, and we've been working around others for years
- Nobody will adopt another container format
- 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
