[theora-dev] bitstream versioning
hip245 at operamail.com
Sun Jun 8 22:30:37 PDT 2003
Might it be a good idea to decide what these future version of the
bitstream will include now and then implement the features later? This
way, we could make decoders today that are at least aware of what they
can't do, then finalize the bitstream later.
Let's say that Alpha 2 codec produces what is called a stream 3.2.0. We
could decide now that the 3.3.0 stream will be just 3.2.0 with interlaced
video support. The decoder would then be able to know that, so long as
a 3.3.0 stream doesn't have interlaced video, it can still decode it.
----- Original Message -----
From: "Dan Miller" <dan at on2.com>
Date: Sun, 8 Jun 2003 16:10:12 -0400
To: <theora-dev at xiph.org>
Subject: [theora-dev] bitstream versioning
> as per yesterday's discussion at #theora --
> It has been suggested that we devise a method such that we will be
able to add certain features to the bitstream (interlace, exotic color
subsampling, clip length flag for download, etc), in such a way as to not
obsolete streams encoded previously. Rillian's suggestion, which is
pretty much standard practice, is to add a bitstream revision number.
Another suggestion was to move to a tag structure, where parameters
are tagged with text ID's; this would allow additional parameters to be
added to the bitstream spec transparently to older bitstreams. These
two suggestions are not mutually exclusive, though I am suggesting we
not include an explicit revision number in the normal way.
> My objection to the typical revision number field is as follows. Take
for example Mau's request for a clip length field. To add that to the
spec in the traditional way would require a new rev number. Older
players would have to barf at any bitstream with the length field because
the rev number would be too high. That's unfortunate because in most
cases the older player could play the stream fine without knowing about
clip length. So I guess I'm saying it makes any kind of 'forward'
compatibility, where new bitstreams can play in older players in some
cases, impossible. That will inevitably create more of an impression that
Theora is unstable (fairly or not). Similar situations arise when thinking
about stuff like gamma correction, side data for improved post-filtering,
etc. There are many features that can improve quality or ease of use,
but don't really make the bitstream unplayable by older code.
> Another example: we add an interlace option in a new revision. Most
encoder apps will naturally upgrade to the new version, and always stick
the higher rev number in the bitstream. Older players are out of luck.
With the tag method, if interlace is not used, the file will still play. On
the other hand, if interlace is specified, the older player should have a
way of knowing it shouldn't try to play the stream.
> Here's my suggestion: Let's add one more field right now -- a tag-
style extended parameter field (ie a text string with ID's and values).
Initially, we implement exactly one extended parameter: "TH1.0-
COMPAT" 0|1. This way, future encoders can explicitly state whether the
bitstream they are producing can be played in a Theora 1.0 player (any
player based on our upcoming Beta 1 release). [note: "TH1.0" refers to
the bitstream, not the code release]
> In the future, we can add similar compatibility tags for new revisions
of the bitstream spec. In the meantime, anyone experimenting with new
features can set the compat flag to zero so old players won't crash.
Once we've got a new stable bitstream, we number it and add the new
> ___ Dan Miller
> (++,) Founder, On2 Technologies
> --- >8 ----
> List archives: http://www.xiph.org/archives/
> Ogg project homepage: http://www.xiph.org/ogg/
> To unsubscribe from this list, send a message to 'theora-dev-
request at xiph.org'
> containing only the word 'unsubscribe' in the body. No subject is
> Unsubscribe messages sent to the list will be ignored/filtered.
Get OperaMail Premium today - USD 29.99/year
<p>Powered by Outblaze
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'theora-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Theora-dev