Hi, On Sat, Apr 1, 2017 at 6:15 AM, Michael Niedermayer <mich...@niedermayer.cc> wrote: [.] > > about the patch itself, the changes done to indexing seem not to > change anything, it makes it possible for the variables to overflow > though. >
That's intentional, they're both unsigned and the one is guaranteed to be larger than the other so the difference after subtract would still be guaranteed to be <= n_threads. So although the indices overflow, the subtraction will always be correct. > IIUC the only change your patch does is to remove the outdata check > from the quoted warning > Yes, because if you change the delay to be fixed (and equal to n_threads), you no longer need the check. If the difference between indices is smaller than n_threads, you don't return a packet. If it's equal, you do return a packet. its a while ago that i worked n this code but isnt this just "missing" > a finished_task_mutex lock over the access ? I don't know, it depends on what you're trying to accomplish. If you want a fixed-frame delay, you don't need the access and so no mutex is needed. I haven't thought much about what you need to get a variable-frame delay. To me, a fixed-frame delay for intra-only codecs (which is what this API currently accomplishes in practice) is exactly what you would expect, variable-frame delay implies you're not actually using all threads. But maybe I misunderstand. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel