[vorbis-dev] What exactly is threadsafe

Michael Smith msmith at labyrinth.net.au
Thu Mar 28 21:22:51 PST 2002



At 09:17 AM 3/27/02 -0500, you wrote:
>Hey I am playing with a LOT of threads right now, and I want to know if the 
>threads all need their own little vorbis encoders running in them or what 
>exactly is threadsafe in vorbis?

The vorbis libraries are all reentrant. However, they are not generally
threadsafe. Having multiple encoders running is fine, but they do need
to be independent (not sharing anything).

You can't have a single encoder with many threads calling encode functions
in it - doing so doesn't make much sense, anyway - you don't know what
order things go in.

>I would like to be able to call the initialization functions once per 
>compression run, and then have many threads compressing various sections of 
>data all at once (this is for a video capture system, I think ogg would be 
>cool in an AVI-like file). 

Ogg _is_ an AVI-like file format, in that it's a generic container format
(it doesn't have awful limitations like AVI, though). You can certainly
have multiple encoders encoding different things (like video and audio,
seperately) and feeding them into a single ogg stream through the ogg
framing functions (you'll need to do some external synchronization there,
though).

>
>Right now I am just going to have each thread own its own compressor, all of 
>them set at the same settings.
>
>Also, I want to keep the vbr code there, just not use some of it.  Would it 
>be OK if instead of this:
>    /* analysis, assume we want to use bitrate management */
>    vorbis_analysis( &m_vorbisBlock, NULL );
>    vorbis_bitrate_addblock( &m_vorbisBlock );
>    while( vorbis_bitrate_flushpacket( &m_vorbisDsp, &m_oggPacket ) ) {
>      /* weld the packet into the bitstream */
>      ogg_stream_packetin( &m_oggStream, &m_oggPacket );	  
>      writePage();
>I did this, while still using the vbr initialization functions and such:
>  /* analysis, assume we want to use bitrate management */
>    vorbis_analysis( &m_vorbisBlock, NULL );
>   /* Use the next line if we have the CPU for it */
>    // vorbis_bitrate_addblock( &m_vorbisBlock );
>    while( vorbis_bitrate_flushpacket( &m_vorbisDsp, &m_oggPacket ) ) {
>      /* weld the packet into the bitstream */
>      ogg_stream_packetin( &m_oggStream, &m_oggPacket );	  
>      writePage();
>

If you're using the VBR initialisation functions, the cpu usage
isn't increased by the bitrate management functions - they will have
zero measurable performance impact. You _can_ just do 
vorbis_analysis(&vb, &op) instead of vorbis_analysis(), 
vorbis_bitrate_addblock(), vorbis_bitrate_flushpacket(), but it's not
recommended as this means that the managed bitrate modes won't work - using
the management functions in non-managed modes has no effect.

Doing what you suggested above will likely not work at all (though
I didn't actually test that).

Michael

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



More information about the Vorbis-dev mailing list