[theora-dev] bitstream versioning

Mon Jun 9 12:59:45 PDT 2003

there was some talk of implementing this sort of forward compatibility (old players playing  new bitstreams), but it was decided not to tackle that for the initial release.  However we did agree that the code should ignore extra header packets.  This leaves open some possibility of future encoders producing 'enhanced' streams that intentionally leave the version number unchanged, so older players will continue to be able to play them.  One could say that the version number in the original header is really just a declaration that players of that generation will be able to play the stream; further information, including the 'real' version number, could be in the extra header packets.

Just a thought.

<p> ___  Dan Miller
(++,) Founder, On2 Technologies

<p>> -----Original Message-----
> From: Henry Mason [mailto:hip245 at operamail.com]
> Sent: Monday, June 09, 2003 12:31 AM
> To: theora-dev at xiph.org
> Subject: Re: [theora-dev] bitstream versioning
> 
> 
> 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.
> 
> -Henry    
> 
> ----- 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 
> compatibility flag.
> > 
> > Thoughts?
> > 
> >  ___  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 
> needed.
> > Unsubscribe messages sent to the list will be ignored/filtered.
> 
>     
> -- 
> ____________________________________________
> http://www.operamail.com
> Get OperaMail Premium today - USD 29.99/year
> 
> 
> 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.
> 
--- >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.