OggIssues

From XiphWiki

(Difference between revisions)
Jump to: navigation, search
(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??
-
== i don't know the answers ==
+
== 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?
-
== Cleaner Abstractions ==
+
= Rebuttal =
-
 
+
-
* 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
+
-
 
+
-
== What use are... ==
+
-
 
+
-
* serial numbers?
+
-
* packet numbers?
+
-
* pages?
+
-
* checksums?
+
-
** Useful for audio (preventing ear damage), but could be optional for video
+
== 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
-
 
-
== 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??
 
-
 
-
== Libogg issues ==
 
-
* Stupid decision for flushing pages
 
-
* Makes it generally easy to build 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
Personal tools


Main Page

Xiph.Org Projects

Audio—

Video—

Text—

Container—

Streaming—