[vorbis-dev] granulepos start/end revisited

[André Pang]

On 19/05/2004, at 12:14 AM, Arc Riley wrote:

> Then this Writ thing came along and smashed all the rules.  With Writ,
> the granules provided by one page may *GASP* overlap with the granules
> of the next!  What's more, a single page may span in time several
> minutes into the future!  If we order by end time, we'd have two
> choices; we would either need to read ahead some absurd amount to make
> sure we have enough data from the Writ stream to start displaying the
> subtitles on time, or we would need to break Ogg by ordering the pages
> by start-time while storing them with end-time granulepos (this is what
> OggMIDI currently does).

I see the reason now for the start-time granulepos (thanks Monty, 
Ralph!), but for Writ, I think that if you handle subtitles as state 
changes (rather than using durations), it would simplify things quite a 
bit.

Say you have this:

     | subtitle A (0-10 seconds) |
                 | subtitle B (5-13 seconds) |

So, in Writ, I'm guessing that would look like two packets: A starts at 
0 seconds and has a duration of 10 seconds, and B starts at 5 seconds 
and has a duration of 8 seconds.  If, instead, you handled it with 
state changes:

     | A turns on (0)            | A turns off (10)
                 | B turns on (5)       | B turns off (13)

You now have four packets: A turns on (time 0), B turns on (5 seconds), 
A turns off (10 seconds), B turns off (13) seconds.

One disadvantage of this approach is that you need to assign some sort 
of identifier for each subtitle, because to "turn off" a subtitle, you 
need to refer to which subtitle you want to turn off (A or B).  You can 
re-use identifiers, of course, but if you make the identifier a simple 
32-bit integer, that's plenty of IDs available.  You also get a bit 
more overhead because you have extra packets.

The big advantage is that you don't have overlapping granulepos's, 
which greatly simplifies a player implementation: you don't have to 
maintain an internal table where you need to track when something turns 
on or off, you just turn off when you receive the packet that tells you 
to turn off.  You probably simplify seeking and buffering code greatly, 
too (though I haven't thought about this greatly).  You also don't have 
to use a start-time granulepos, an end-time granulepos will do just 
fine, so this scheme will work right now, as opposed to whenever 
start-time granulepos code gets implemented.

<p>
-- 
% Andre Pang : trust.in.love.to.save

--- >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.