[vorbis-dev] granulepos start/end revisited

[Arc Riley]

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 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA       
          BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB                            
                                                        CCCCCCCCCCCCCCCC

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.