<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 29/04/2010 10:21 p.m., <a class="moz-txt-link-abbreviated" href="mailto:xiphmont@xiph.org">xiphmont@xiph.org</a> wrote:
<blockquote
cite="mid:m2w806dafc21004290321me07d5cfao150deba41606be2@mail.gmail.com"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I assume that the streams with and without 'keyframes' are clearly
distinguished, correct?
</pre>
</blockquote>
<pre wrap="">
A client which mapped serialnos to codecs could make this distinction. Why
would you need to?
</pre>
</blockquote>
<pre wrap="">
Just to have it in Skeleton somewhere so that you wouldn't necessarily
need a list of codec mappings. There's the tension of the original
design (always ask the codec programmatically) and the Skeleton
(replicate the data when encoded so there's no need to ask the codec),
so it seemed sensible to have this declared in the skeleton as well.
<small><small></small></small>
</pre>
</blockquote>
<br>
<br>
An index-assisted seek algorithm doesn't need to distinguish between a
keypoint which references a keyframe and one which references or a
non-keyframe. Why would you need this? Purely for the purposes of
providing more metadata? Would we want to also include flags for
discontinuous streams as well?<br>
<br>
<br>
<blockquote
cite="mid:m2w806dafc21004290321me07d5cfao150deba41606be2@mail.gmail.com"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Is the rational timebase required to have any relation to the timebase
of the granulepos itself?</pre>
</blockquote>
<pre wrap="">
Not explicitly. I imagine an indexer would do so in order to preserve
accuracy though.
</pre>
</blockquote>
<pre wrap="">
OK. I'm not actually a fan of there being several ways to do things
and just leaving it up to the implementor to figure out. Is there a
reason not to just use the stream timebase?
</pre>
</blockquote>
<br>
Then we'd run into the Skeleton metadata vs codec tension above while
decoding.<br>
<br>
<blockquote
cite="mid:m2w806dafc21004290321me07d5cfao150deba41606be2@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">Beginning of bitstream, so 0 for the first segment, and from the start of
each fisbone packet in each subsequent segment/link in a chained ogg.
</pre>
</blockquote>
<pre wrap="">
This means you need to know how long the index will be before encoding
any offsets. But the offsets are variable-length-encoded... How are
you predicting index size?
</pre>
</blockquote>
<br>
So note that you don't need to fill the index packet, so if you
over-estimate the space needed for the index, provided you've not
overestimated too much, it's not a huge loss. If you do under estimate,
you can just start dropping keypoints out of your indexes until they
fit.<br>
<br>
My current approach in ffmpeg2theora is to estimate the number of
keypoints required as duration/keypoint_interval, and the size is then
5.1 * num_keypoints. This has seemed to work for me. There are probably
smarter approaches to estimating this, but I've not had the chance to
it yet. It's probably a function of the bitrate.<br>
<br>
<br>
Chris P.<br>
</body>
</html>