SMP Support?
Locked
 
|
I am currently writing a very CPU-intensive gstreamer app that handles
4K video which get post-processed into multiple video output streams. During profiling it appears that very limited use is being made of the multiple processors in my server. I would love to be able to have my output stream tasks distributed among the CPU’s on the server. Is there currently any way to do something like that? -- Stirling Westrup Programmer, Entrepreneur. https://www.linkedin.com/e/fpf/77228 http://www.linkedin.com/in/swestrup http://technaut.livejournal.com http://sourceforge.net/users/stirlingwestrup _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
On 19 Dec 2012, at 19:37, Stirling Westrup wrote:
> I am currently writing a very CPU-intensive gstreamer app that handles > 4K video which get post-processed into multiple video output streams. > During profiling it appears that very limited use is being made of the > multiple processors in my server. I would love to be able to have my > output stream tasks distributed among the CPU’s on the server. Is > there currently any way to do something like that? That depends on what elements you are using. For example I use the OpenCV plugin's "templatematch" element, which happily distributes work across all available processors -- it keeps all 8 of my cores happily occupied. But that's the way the element is implemented (or in this case, the OpenCV library wrapped by the templatematch element); it doesn't happen automatically. If your pipeline uses tees (branches), then if you put a queue element in each branch you get a separate thread per queue. I'm not sure if putting extra queue elements in a serial pipeline will give you a separate thread for the elements after each queue -- try it! :-) Cheers Dave. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
In reply to this post by Stirling Westrup
> I am currently writing a very CPU-intensive gstreamer app that handles
> 4K video which get post-processed into multiple video output streams. > During profiling it appears that very limited use is being made of the > multiple processors in my server. I would love to be able to have my > output stream tasks distributed among the CPU’s on the server. Is > there currently any way to do something like that? You probably do some video de/encoding. Many codecs are only single threaded. You might want to look at X264, this codec handles multiple cpus gst-inspect x264enc _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
In reply to this post by David Röthlisberger
On Wed, Dec 19, 2012 at 3:25 PM, David Röthlisberger <[hidden email]> wrote:
> On 19 Dec 2012, at 19:37, Stirling Westrup wrote: >> I am currently writing a very CPU-intensive gstreamer app that handles >> 4K video which get post-processed into multiple video output streams. >> During profiling it appears that very limited use is being made of the >> multiple processors in my server. I would love to be able to have my >> output stream tasks distributed among the CPU’s on the server. Is >> there currently any way to do something like that? > > > That depends on what elements you are using. For example I use the > OpenCV plugin's "templatematch" element, which happily distributes work > across all available processors -- it keeps all 8 of my cores happily > occupied. But that's the way the element is implemented (or in this > case, the OpenCV library wrapped by the templatematch element); it > doesn't happen automatically. > > If your pipeline uses tees (branches), then if you put a queue element > in each branch you get a separate thread per queue. I'm not sure if > putting extra queue elements in a serial pipeline will give you a > separate thread for the elements after each queue -- try it! :-) I currently have a tee element that has N branches (depending on parameters) each of which feeds into a queue element before further processing. Right now those queue elements seem to give me one thread per output stream, but they are all on the same CPU. I'll look into OpenCV to see if it has any elements I can use. I hope it supports gstreamer 1.0 though, as that's what my application is written for. -- Stirling Westrup Programmer, Entrepreneur. https://www.linkedin.com/e/fpf/77228 http://www.linkedin.com/in/swestrup http://technaut.livejournal.com http://sourceforge.net/users/stirlingwestrup _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
In reply to this post by Stirling Westrup
On Wed, Dec 19, 2012 at 3:52 PM, Matthias Kattanek <[hidden email]> wrote:
>> I am currently writing a very CPU-intensive gstreamer app that handles >> 4K video which get post-processed into multiple video output streams. >> During profiling it appears that very limited use is being made of the >> multiple processors in my server. I would love to be able to have my >> output stream tasks distributed among the CPU’s on the server. Is >> there currently any way to do something like that? > > You probably do some video de/encoding. > Many codecs are only single threaded. > You might want to look at X264, this codec handles multiple cpus > > gst-inspect x264enc I video decoding but the encoding is done outside of my application, so x264enc doesn't help, and there doesn't seem to be an x264dec, but that doesn't really surprise me. -- Stirling Westrup Programmer, Entrepreneur. https://www.linkedin.com/e/fpf/77228 http://www.linkedin.com/in/swestrup http://technaut.livejournal.com http://sourceforge.net/users/stirlingwestrup _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |