[Libav-user] Problems with ffvhuff and huvvyuv

[James Board]

>What you're describing 
sounds like the multithreading approach that ffmpeg uses. My 
>understanding: The first decode call starts a decode action which spawns a thread to >decode that frame. Each subsequent decode call starts a new action/thread, until you run >out of threads, at which point the next 
decode action will return the frame that you started >decoding in the 
first call. That's why you have to look at the frame number of the 
decoded >frame, not of the packet you passed in. Maybe you also get a 
frame back if it's 'ready' - >not sure.
>

>Note - this means you always have to run decode a few extra times with a null packet to >get the frames flushed out.

That explains it 100 percent.  When I ran this code on a 6-core machine (12
virtual cores), it seemed to generate an extra 12 frames.  When I ran on a 2-core
machine, it generated 4 extra frames.  When I recoded things so I didn't compare
the frame I asked for and the frame that was returned, then the problem went away.

So the question becomes: How can I turn off this behavior?  I want to run multiple
instances of my program so I don't want it using all the available cores anyway.
If I can't turn it off through the API, can I hack something in the code to turn this
off, or maybe limit it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20131017/2f222677/attachment.html>