On Mon, Jan 25, 2016 at 04:39:49PM +0100, Hendrik Leppkes wrote: > 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.
is there no hwaccel that (can) work(s) with MT ? iam bringing that up here before code is unconditionally removed that might be needed for such case [....] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
