OggIssues
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 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
- 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
Synchronization
- no absolute clock (no presentation timestamps)
- no way to correct for clock skew between audio/video encoding
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??
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