On Mon, Jan 25, 2016 at 1:28 PM, Ronald S. Bultje <rsbul...@gmail.com> wrote: > Hi, > > On Mon, Jan 25, 2016 at 4:01 AM, wm4 <nfx...@googlemail.com> wrote: > >> On Sun, 24 Jan 2016 20:03:01 -0500 >> "Ronald S. Bultje" <rsbul...@gmail.com> wrote: >> >> > Hi, >> > >> > On Sun, Jan 24, 2016 at 6:49 PM, Hendrik Leppkes <h.lepp...@gmail.com> >> > wrote: >> >> >> > > Unfortunately that doesn't alleviate the other issues, like the >> > > complexity needed in the decoders during frame threading, or the extra >> > > resources needed (extra image surfaces for every thread). >> > > >> > >> > So, the extra code is just in the decoders, which already need it anyway >> > (because they implement frame-mt), right? Or do hwaccels need extra code >> > also? >> > >> > The extra resources aren't a big deal IMO. Memory use isn't typically a >> big >> > issue, we're adding a fw kb extra for contexts but practically all memory >> > is in framebuffers regardless. >> >> It's can be a big deal for hardware decoding, because hw surfaces >> might be a more constrained resource than system RAM. Also, you often >> have to preallocate _all_ surfaces you're going to use, so you'll have >> to add the exact number of additionally needed surfaces to the >> preallocation. > > > If only one thread is active, the rest never has to be inited and thus > contains no surfaces (or framebuffers, or anything), right? If not, that > should be a trivial win. >
If you can implement it like this, ie. only make one single thread do the work, that would also avoid a bunch of the complexity with copying contexts around and avoiding multiple init calls of the hwaccel. On top of that, avoid the extra resource requirements and the delay inherent to frame threading otherwise, since no extra frames are "cached" inside the other worker threads. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
