[vorbis-dev] granulepos start/end revisited
arc at xiph.org
Fri May 21 07:53:45 PDT 2004
On Fri, May 21, 2004 at 04:27:08PM +1000, Andr? Pang wrote:
> for a description of how to implement SMIL's durations. I'm not
> implying that the Writ's implementation will end up being that complex,
> of course: my point is that there's more logic needed just to make sure
> that your table, which tells you when to turn off subtitles, is
> correct, especially once seeking comes into play. How is this any
> simpler than turning subtitles off/on via state changes?
I think you're confused, so here's a walk-through..
Subtitle A lasts 0 to 31
Subtitle B lasts 5 to 20
Subtitle C lasts 28 to 35
Putting this on a chart:
00 02 04 06 08 10 12 14 16 18 20 22 24 26 28 30 32 34
Long phrases are redefined every few seconds, so it's considered OK for
an unknown phrase to not be shown for a few seconds after seek.
However, if a phrase was already known before seek, it should still be
shown after seek if it's still valid.
Say you played the above stream until 10, then seeked to 25, in the
current method you would get A, know immediatly that A lasts until
granule 31, then get B and know immediatly that it lasts until granule
20. When you seek, the new granulepos will drop B (because it's
expired) but A is still valid for awhile so it's kept. C will be
received further down and display properly. Nice and tidy.
Now say this were to be replaced by the start-stop method you described.
A would "turn on" granule 0, then B would "turn on" granule 5, then you
seek. Uh-O! Did the seek skip A getting turned off? B getting turned
off? Better destroy all known phrases, just to be sure. When seeking
is completed, even tho we would have otherwise known that A is still
valid, A would not be shown. If it's especially long you may see it get
redefined later down the stream, but it wont be displayed until then.
No, it's FAR better to know when things are going to stop ahead of time.
In either case the decoder has to keep track of phrases, because in the
first you keep track of them so they're turned off at the right time, in
the second you keep track of them so they can be turned off when the
"off" packet for them is received. Complexity wise, within the code,
neither is really more complicated if we don't consider the seeking
issue. In the first the codec is responsible for clean-up, in the
second the stream is responsible for clean-up. The prior is much better
since you should never trust the Ogg stream to be without errors, and
once you throw the seeking issue in the way we're doing things now
becomes the obvious optimal solution.
--- >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 'vorbis-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.
More information about the Vorbis-dev