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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Sunday, June 8, 2003, at 09:10 pm, Dan Miller wrote:> as per yesterday's discussion at #theora --Another thing derf and I discussed is adding additional (optional) header packets. Monty used a nice scheme where header packets being with a 1 bit, and data begin with a 0. Thus it would be easy to have the codec ignore unexpected headers. The hard part with this idea is the api design. Currently the client knows it has to pass exactly three packets before decoding can start. Furthermore, it is a very nice simplicity of the theora codec that it's one decoded frame per packet for the rest of the stream. So we could change that and make decode_packetin() ignore extra headers. The best we could come up with at the time was that the client had to peek at the first byte of the packets and terminate the header decode loop on the first data packet. Given that we're planning to write an 'OggFile' convenience layer to handle the demux and and decode, either of those might be ok if we want to go that direction. FWIW, -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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> From: Ralph Giles [mailto:giles@xiph.org] > > > 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 we do. It's set to 3.1.0 right now, which I guess was inherited from VP3. I suggest we bump that number on release (we haven't been doing so, which we should). I like the extra header packets, I certainly think our initial release should not barf if there is some extra header stuff in there. In the interest of moving forward, I'll agree we won't add anything else now. ___ 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
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@on2.com> Date: Sun, 8 Jun 2003 16:10:12 -0400 To: <theora-dev@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 beable 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. Takefor 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. Mostencoder 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 revisionsof 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@xiph.org'> containing only the word 'unsubscribe' in the body. No subject isneeded.> Unsubscribe messages sent to the list will be ignored/filtered.-- ____________________________________________ http://www.operamail.com 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
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@operamail.com] > Sent: Monday, June 09, 2003 12:31 AM > To: theora-dev@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@on2.com> > Date: Sun, 8 Jun 2003 16:10:12 -0400 > To: <theora-dev@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@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@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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.