I'm hoping this is a new proposal, and not a rehash of something that's
already been discussed and shot down. Without logs of the recent IRC
discussion there's no way for me to know without asking. When I
suggested it in #theora earlier derf_ or AndrewBachmann said that it had
already been discussed, so I'm under the belief that this is a new idea.
<p>Ok so we've firmly resolved at this point that there is no
"perfect"
solution. We compromise something important in any solution; with
start-time granulepos specifically we compromise the ability to easily
find the total length of a stream, possibly some other stuff too. Even
with the requirement of an empty EOS page (which is a hack IMHO) there
is still the issue of trunctated streams, and it's less than optimal to
require the codecs to decode the last page in order to find the total
length.
But I'm going to suggest that this is a really good time for such a
discussion to take place, and really, the optimal time for this proposal
to be evaluated (and prehaps) implemented.
Ogg's been around for a long time, and almost exclusivly, has been used
for Vorbis. That's why the recent discussions have resolved that other
codecs could be changed but Vorbis's framing would have to remain with
end-time granulepos.
So since we're about to unleash an array of new tools for dealing with
muxed codecs, and with OggFile/etc open up this new world of multicodec
Ogg, and older tools (those which use VorbisFile) won't be able to
decode these new bitstreams anyways..
Why don't we just design a new version of Ogg? The current version, 0,
has worked great for so long.. but with the addition of a new (prehaps)
four-byte field for granule-duration, or granules, or whatever.. we
could have both the start-time granulepos and the total decodable
granules in each page header. This has two advantages; first it allows
us to have the best of both worlds as far as the start-time/end-time
discussion, it allows us to *CLEANLY* implement discontinuous streams,
more clean than start-time alone, and it would also give us a clean way
to do granule-accurate trunctation of a stream.
The overhead added by four additional bytes per page is reletivly
insignifigant. The new version also allows us to cleanly upgrade Vorbis
to this new style without the "what happens when someone demuxes a mixed
stream and has an otherwise legal Ogg Vorbis file?" issue since, to
create a traditional Ogg Vorbis stream, one would also have to change
the encapsulation. Tools to port Ogg Vorbis from Ogg1 to Ogg0 would be
fairly trivial, as it'd just take the two granule fields of the page
header and add them together to get the Ogg0 granulepos.
If this proposal is sound, then there should probobally be a discussion
about potential other improvements which could be made at the same time,
tho I think we should keep in mind that Ogg0 has proven to be damned
stable and useable over several years now. IMHO, this is the first case
I've seen where Ogg0 has not been an optimal container format.
I'm making this proposal by email so everyone gets a chance to read it,
but lets discuss it on IRC where things move faster. Can everyone be on
IRC this evening?
--- >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.