Vorbis dev - Mar 2002 - What exactly is threadsafe

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?  

So here are the functions that would be called from many threads of with 
buffer = vorbis_analysis_buffer( &m_vorbisDsp, 4*DATA_CHUNK_SIZE );
vorbis_analysis_wrote( &m_vorbisDsp, dataLength/dataSize );

 while( vorbis_analysis_blockout( &m_vorbisDsp, &m_vorbisBlock ) == 1 )
{
    /* 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();
    }
}

**Write Page looks like this**:
int result;
  result = ogg_stream_pageout( &m_oggStream, &m_oggPage );
  
  while( result != 0 ) {
    m_sink->write( (char*)m_oggPage.header, m_oggPage.header_len );
    m_sink->write( (char*)m_oggPage.body, m_oggPage.body_len );
    result = ogg_stream_pageout( &m_oggStream, &m_oggPage );
  }

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

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();

Thanks in advance, Chris

--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.