Quoting James Almer (2020-06-09 14:45:33) > On 6/9/2020 6:06 AM, Anton Khirnov wrote: > > I don't think this needs to be visible externally, since it's only > > meaningful for internal use. I'm wondering if the presence of > > update_thread_context() callback won't be sufficient for this. > > True, it could be a caps_internal. But take for example the possibility > of an external library with a fully featured decoder getting a wrapper, > this being a public capability would let the user choose it over the > internal one, same as how it can choose a stable decoder over an > experimental one, or a software one over an hybrid/hw one.
I don't see why this should be a criterium for the user to base any decisions on. It's purely an internal implementation detail that's tied to the way frame threading is currently implemented and can potentially change later. So I don't see why it should be accessible through the API. Also, not sure if you saw but I have new patch fixing this problem in another manner. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
