OggIssues

From XiphWiki
Revision as of 21:51, 7 February 2008 by Conrad (talk | contribs) (re-format in terms of design problems, proposed solutions etc.)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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