[Libav-user] Problems with ffvhuff and huvvyuv

[Paul B Mahol]

On 10/17/13, James Board <jpboard2 at yahoo.com> wrote:
>>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?

IIRC:
        av_opt_set_int(YourAVCodecContext, "threads", 1, 0);