[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