>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?
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
