From XiphWiki
Jump to navigation Jump to search

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


  • 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??

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?


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