[Libav-user] Problems with ffvhuff and huvvyuv
jpboard2 at yahoo.com
Thu Oct 17 21:31:21 CEST 2013
>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...
More information about the Libav-user