Re: Ogg encapsulation

On Fri, Apr 02, 2004 at 11:30:46AM +0200, Gerard Juyn wrote:

> > The design so far is outlined in http://wiki.xiph.org/OggMNG
> 
> Something I can't quite make out is how the synchronization between a MNG 
> and audio/video channel(s) is going to be done. Do you intend to fiddle with 
> the timing-mechanism in libmng or do you consider using the FRAM signals?

I planned to use MNG's internal playback timing. You generally have some 
clock that all the playback engines sync to (with libmng this is 
easy to do through the gettickcount and settimer callbacks); in a 
typical computer application, that's the sound hardware's audio playback 
clock, or the system clock if there's no audio. If you're interfacing 
with A/V hardware, there's generally a set of external clock signals you 
need to sync everything to.

I guess I don't know what you mean about using FRAM signals.

When overlaying a video stream, it's obvious how to maintain 
frame-to-frame sync between the video and the overlay with a VLC stream 
where the frame rates match. Otherwise (and probably the common case) 
I'd expect to just composit the nearest frames from each stream. We 
might want to be more explicit about the definition of 'nearest', though 
for most applications, it won't matter much.

> But since you most likely won't be depending on the proper framecount / 
> layercount / playtime inside libmng, you might as well put 1ms delays between 
> each frame and then stretch that delay inside OGG to whatever is needed at 
> the time. This would allow you to sync with the audio/video at your own turf. 
> And libmng will just be happily trying to catch up all the time which it will never 
> be able to do but that won't hurt either. But we can work that out as you're 
> coding along...

Ah. Well, the player in general needs logic to lead each of the 
stream decoders enough to compensate for the output latency. I'd planned 
to use that to monkey with the values returned to libmng in the timer 
callbacks, but otherwise use it's internal playback timing. Do you see 
any problems with that?

In Ogg, playback timestamps are an internal responsibility of the 
codecs, unlike many media containers. What the ogg layer does is accept 
opaque 'packets' of arbitrary size from the codec, segment them as it 
pleases, and pack the segments into 'pages' which are then multplexed 
together into a datastream. It's at the page level that timestamps are 
kept, and in a very general way: it's just a 64 bit field whose mapping 
to time is entirely defined by the codec, outside a restriction that it 
be monotonic. So while the Ogg layer could provide some context for 
setting a playback time, it won't be as accurate as what's in the MNG 
datastream.

Thanks for your questions; any discussion helps me with the design.

 -r

--
Send the message body "help" to [email protected]