OggIssues

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 inefficient lacing values for video ad-hoc granulepos retrofitting for video, CMML seeking is hard pages, and libogg's behaviour when creating them

i don't know the answers

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?

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

What use are...

serial numbers? packet numbers? pages? checksums?

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