<div dir="ltr">Hi Michael,<br><div class="gmail_extra"><br><div class="gmail_quote">On 5 October 2017 at 15:41, Michael Maurus <span dir="ltr"><<a href="mailto:michael.maurus@web.de" target="_blank">michael.maurus@web.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This was actually a nice hint.<br>
Only one of my CPUs was working at full capacity.<br></blockquote><div><br></div><div>I haven't looked at the code recently so I'm a bit cold on the ffmpeg implementation side.  I don't recall any external way to control the threads that the ffmpeg creates.  <br></div><div><br></div><div>From what it sounds like is the threads that the ffmpeg plugin is creating is inheriting the affinity of the thread that created them.  In OSG master there is finer grained control over the affinity setting behaviour, in your case it might be appropriate to disable the default setting of affinity.</div><div><br></div><div>In an ideal world you want to decided which threads you want to run on what threads, but this reques knowledge of all the threads, their needs, and the hardware you are working on.<br></div><div><br></div><div>FYI, the OSG by default tries to make a best guess based on your the number of CPU cores the OS says the machine has and the configuration of your viewer, this scheme doesn't know about any extra threads that plugins might create though.  This scheme is more hardwired in OSG-3.4 and prior releases, so master might be the thing to use if you do end up needing more control.<br></div><div><br></div><div>Robert.<br></div><div> </div><div><br></div><div> </div></div></div></div>