[ogg-dev] Storing RTP in Ogg

Ralph Giles giles at xiph.org
Tue Jan 2 23:04:20 PST 2007


On Wed, Jan 03, 2007 at 03:47:38PM +1300, Andrew Donkin wrote:

> My original plan was to store one RTP packet per ogg packet, one packet
> per page, with the granule position of the page to the arrival time
> of the RTP packet, and metadata in a custom format in the BOS packet.

That's fine. SSRC as stream serialno?

Note that by using arrival time as the granulepos you're making seeking 
for playback harder on other implementors. But as you say, it's just 
your application so far.

> [ Which reminds me of an early trap for young players I fell right into:
>   why on earth is the granule position part of the packet in the API
>   when it is actually part of a page? ]

The idea is that you read and write packets and let libogg worry about 
the pages. Writers set a granulepos on each packet they creat, readers 
don't panic if some packets have an unset (-1) granulepos.

I guess we kind of assume you know how Ogg works.

> But this naive design gnawed at my conscience.  Other ogg parsers would 
> make no sense of our files.  I should use liboggz and a skeleton stream. 
> But I like the simplicity of libogg and I would like to avoid depending 
> on a second external library.

You can use skeleton without using liboggz, just write your own. You can 
still use liboggz for compliance checks.

> Should I consider libogg2 for a commercial app due mid-year?

I wouldn't recommend it. It would be fine if you want to spend some time 
on qa and bug fixing, but it's not nearly as well tested as libogg. Not 
that it wouldn't be great to have an application developr pushing it 
along.

FWIW,
 -r


More information about the ogg-dev mailing list