[theora-dev] bitstream versioning

[Ralph Giles]

On Sunday, June 8, 2003, at 09:10 pm, Dan Miller wrote:

> Rillian's suggestion, which is pretty much standard practice, is to 
> add a bitstream revision number.

Note that we already have one of these.

> 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.

I agree, that's the major advantage of a generalized parameter encoding.

> That will inevitably create more of an impression that Theora is 
> unstable (fairly or not).

Only if we add stupid features. :)

> 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.

I guess I remain unconvinced. We have, as you say, experienced serious 
feature creep already and I don't see any compelling additions that 
would require this, except it avoids overloading the comment packet 
with machinable bits.

As a counter argument, the current idea with gamma correction is that 
it's implicit in the selected colorspace, so that's already handled in 
the sense that it was part of the design decision.

Likewise, interlacing requires a version increment anyway because the 
format of the actual video data packets has changed. Unless there are 
other incompatible changes encoders want to add at the same time, 
progressive streams can stay with the earlier rev number. That's as 
compatible as adding a new feature can be; the tag idea is no 
improvement.

Only something optional like post-processing hints or mau's duration 
field are motivating examples. The filtering stuff could be added to 
the tables packet as well.

> 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]

I think we should wait for a compelling application and add it then. 
The version number can serve the same purpose for actual 
bitstream-changing improvements. I expect those will be the more 
interesting ones anyway.

  -r

--- >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.