[vorbis-dev] Status of thread-safeness of libvorbis?

Michael Smith msmith at xiph.org
Fri Feb 7 00:51:59 PST 2003



On Friday 07 February 2003 19:09, Ronald Bos wrote:
> I have spent quite some hours in the archives of this mailinglist and read
> a few threads mainly by Jeff Squyres and Monty about making oggenc
> multithreaded. Those threads all are dated around January 2001, quite a
> time ago.
> For my work experience period I have to implement a parallel (threaded) ogg
> encoder (If this is possible, of course.) If it can be done, the code will
> be given back to the community.
>
> I have already done some profiling on oggenc and found out that >98% of the
> cpu time is spent in the call tree under vorbis_analysis (in encode.c).
> This point was also mentioned at that time.
>
> Now my question is: how is the current state of thread-safeness of
> vorbis_analysis? Has anyone else had succes or failures in creating a
> threaded ogg encoder?
>
> Greetings,
>
> Ronald Bos

The situation is precisely as it has always been. libvorbis is fully reentrant 
(i.e. you can run more than one encode in a single process at once, possibly 
using different threads), but it is not threadsafe (you can't have multiple 
threads doing the _same_ encode at the same time), nor is there any 
straightforward way to make it threadable (since the encoding process is very 
stateful). 

The threads from a couple of years ago cover pretty much all there is to 
discuss on the topic. Whilst theoretically possible, it would be very 
difficult to do usefully (i.e. in such a way that you gain performance if you 
have multiple cpus, but don't break the encoder), and for very limited gains. 

On modern cpus, vorbis encoding is not particularly slow (i.e. typically an 
order of magnitude or more better than realtime), and it's rare to have a 
need to encode really long samples (other than in streaming environments, 
when you can't go faster than realtime anyway) - realistically, I can't see 
this being worthwhile unless you frequently need to do encodes of > 10 hours 
in length very quickly. 

For the much more common case where you have many hours of encoding to do, but 
not in a single file (many tracks, for instance), you can easily run multiple 
encoders - either in seperate processes (easy - just run multiple instances 
of oggenc), or in a single process (you'd have to write an encoder for that 
purpose, but that's not a huge task - I've done it for streaming software). 
The latter does not require thread-safeness, only reentrancy.

Mike

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