<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:12pt"><div>>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.</div><div>><br clear="none"></div><div class="y_msg_container">>Note - this means you always have to run decode a few extra times with a null packet to >get the frames flushed out.<br><br>That explains it 100 percent. When I ran this code on a 6-core machine (12<br>virtual cores), it seemed to generate an extra 12 frames. When I ran on a 2-core<br>machine, it generated 4 extra frames. When I recoded things so I didn't compare<br>the frame I asked for and the frame that was returned, then the problem went away.<br><br>So the question becomes: How can I turn off this behavior? I want to run multiple<br>instances of my program so I don't want it using all the available cores anyway.<br>If I can't turn it off through the API, can I hack something in the code to turn this<br>off, or maybe limit it?<br><br><br><br></div><div style="display: block;" class="yahoo_quoted"><div
style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12pt;"><div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12pt;"> </div> </div> </div> </div></body></html>