[Flac-dev] Can a libFLAC encoder be initialize and called from inside a libFLAC decoder callback?

[David Troendle]

Sorry for ambiguity.  Each thread does a decode followed by the encode.  The
threads are driven by a queue of files for recoding, and synced with a
critical section.  When the queue is empty the threads exit.

It is not all that bad of an approach, but  the technique does use a lot of
I/O and only drives the processor at about 25%.  I thought this change in
approach would reduce the I/O and increase processor usage.  It has also
been a good tool to get some experience using libFLAC.

Regards.

David

-----Original Message-----
From: Brian Willoughby [mailto:brianw at sounds.wa.com] 
Sent: Tuesday, May 24, 2011 2:31 PM
To: David Troendle
Cc: flac-dev at xiph.org
Subject: Re: [Flac-dev] Can a libFLAC encoder be initialize and called from
inside a libFLAC decoder callback?


On May 24, 2011, at 12:11, David Troendle wrote:
> Thanks for the tip, Brian.  I did have a version that does everything 
> in
> memory, but only had enough memory to get six threads going.   
> (Although my
> system has 16GB, I have not taken the time to create 64-bit libraries 
> for wxWidgets, TagLib, libFLAC, etc.)

What's wrong with only 6 threads?  Is that just 3 FLAC recodes (3 decode, 3
encode)?  With a queuing layer driving the threads, you could schedule
hundreds of file recodes and each one would start as soon as a thread opens
up.


> Based on the direction you are pointing me in, I assume that encoding 
> from within the decoder is not permitted.

I have no idea.  My assumption before your email would have been that the
individual encoder/decoder handles would allow reentrancy, but perhaps there
are pieces of libFLAC that are not reentrant even when working on separate
encoder/decoder objects.  The only way to know for sure is if Josh Coalson
pipes up, or someone takes the time to look at the source for a thorough
code review.  There's a possibility that your code has a bug, and what you
want to do may actually be possible.  But, again, I have no idea.


> I really like your idea of the FIFO, and will probably go in that 
> direction.
> What do you think of implementing the FIFO via a pipe?  That might 
> simplify the implementation.

You don't strictly need a FIFO.  A pipe might be a good choice - at the very
least it would allow you to link two processes instead of being limited to
two threads within a process.  The pipe could also allow you to decode on
one machine and encode on another over a network connection - assuming
that's of any use to you.

Brian Willoughby
Sound Consulting