From: Mark H. <mj...@si...> - 2011-09-23 00:23:18
|
Thanks for the input. I did read up about the Thread Pool (Boss/worker) Pattern and implemented something along these lines. I was thinking about the most likely places to divide a file. * time range based * Frame based * Slice based (range of lines) * line based * pixel based Time range is not possible with y4m streams. Frame based has the problem that we have to wait for the threads finish in order. Before assigning the next frame to the worker. Slice based might be too course, if one cpu is tied up doing other tasks, one thread may take significantly longer than the others. All threads must finish before moving onto the next frame. I thought for slow filters (I've written an NL-Means filter and it takes about 15 seconds per frame) that line based would probably be the most suited. Any suggestions on these methods? Here is my worker thread code; it locks and reads the global threadline, then processes that line. void *filterline (void *p) { int thisline=0; int startx; int stopx; int x; struct threadarg *ptharg = (struct threadarg *)p; //mjpeg_debug("trace filterline in"); while (thisline < ptharg->height) { pthread_mutex_lock (&linemutex); thisline = threadline++; pthread_mutex_unlock (&linemutex); if (thisline < ptharg->height) { startx = thisline * ptharg->width; stopx = ptharg->width + startx; for (x=startx; x < stopx; x++) { filterpixel(ptharg->outBuf,ptharg->inBuf,x); } } } //mjpeg_debug("trace filterline out"); } Mark On 23/09/2011, at 10:00 AM, Steven Boswell II wrote: > y4mdenoise does that sort of threading internally. It'll denoise > the intensity plane and color plane separately, plus it has reader > threads and writer threads. I wrote a small thread-related class > hierarchy that should be reusable. If nothing else, it should be > inspirational. > > BTW, you probably don't want to literally assign a thread to each > individual line -- the system-call overhead of the semaphores would > more than outweigh your processing time. Mutexes are by no means > free. > > Hope that helps. > > Steven Boswell > > From: Mark Heath <mj...@si...> > To: MJPEG-tools user list <mjp...@li...> > Sent: Wednesday, September 21, 2011 3:21 PM > Subject: [Mjpeg-users] writing multi threaded code > > Hi Guys, > > I'm wondering if anyone has some skeleton C code for writing > multithreaded filters. > > Similar to this kind of pseudo code; > > while not end of file { > > read frame > > create threads (number of CPUs) > > for y = 1 to height { > > while no available threads { wait for a thread to finish; } > > run in thread { for x = 1 to width { process pixel} } > } > write frame > } > > I've written a temporal bilateral filter and an nl-means filter and > they are slow, so was looking to speed things up on my multi cpu > machines. > > If not, I'll see if I can generate my own skeleton. > > Thanks > Mark > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and > makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Mjpeg-users mailing list > Mjp...@li... > https://lists.sourceforge.net/lists/listinfo/mjpeg-users > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously > valuable. > Why? It contains a definitive record of application performance, > security > threats, fraudulent activity, and more. Splunk takes this data and > makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2dcopy2_______________________________________________ > Mjpeg-users mailing list > Mjp...@li... > https://lists.sourceforge.net/lists/listinfo/mjpeg-users |