[XviD-devel] mulithread rework

Dark Sylinc dark_sylinc at yahoo.com.ar
Thu Apr 24 15:18:03 CEST 2008


My apologies if this question is stupid. But how about trying to encode the first 50% of the stream in one thread, and the other 50% in the other core? If there's a quality loss/gain, it would be in just one frame.
Of course, the program using XviD should be sending two frames at a time instead of one.

Question 2:
On the other hand, I am told that 'I' frames are independent each other, thus we should be able to calculate them in different cores, short after we start computing B & P frames from the already obtained I frames. Is that correct? Or is any order dependency that I am not aware of?

i.e.:
Core 1: I       I              I
Core 2:      I            I
Core 3:  PPB   B   BBPPB....

Core 4:
Mixes everything:
IPPBIBIBBPPBI....I

Cheers
Dark Sylinc

IMPORTANT:
The information contained in this email may be commercially sensitive and/or legally privileged. It is intended solely for the person(s) to whom it is addressed. If the reader of this message is not the intended recipient, you are on notice of its status and hereby notified that your access is unauthorized, and any review, dissemination, distribution, disclose or copying of this message including any attachments is strictly prohibited. Please notify the sender immediately by reply e-mail and then delete this message from your system.


--- El jue 24-abr-08, Con Kolivas <kernel at kolivas.org> escribió:

> De: Con Kolivas <kernel at kolivas.org>
> Asunto: Re: [XviD-devel] mulithread rework
> Para: xvid-devel at xvid.org
> Fecha: jueves, 24 de abril de 2008, 7:48 am
> On Thu, 24 Apr 2008 20:41:50 iibot wrote:
> > Con Kolivas schrieb:
> > > On Wed, 23 Apr 2008 17:37:09 iibot wrote:
> > >> If possible you could try to change when a
> thread starts working again
> > >> by setting it to use larger sets of
> macroblocks, i.e. only start when
> > >> the above row has proceeded by k blocks (and
> not 1 as in current code).
> > >> This alone will make things worse but
> together with setting more threads
> > >> (at least 2x number of cores) I guess there
> will be enough additional
> > >> work for the CPUs to do.
> > >
> > > Unfortunately that's worse.
> >
> > Did you try it?
> 
> Yes I did. That's why I said "it's worse"
> rather than "I think that will be 
> worse".
> 
> No matter how many threads I throw at 4 cores with any
> change to this current 
> mode of parallelling the work, I cannot get more than about
> a 30% throughput 
> improvement over single threaded, which is what the
> original code does. A 
> different model for spreading work around is required; the
> dependence of each 
> thread effectively on the first thread progressing is the
> rate limiting 
> component.
> 
> I consider this experiment over. Thanks everyone for your
> replies, and I'm 
> sorry I couldn't find something useful.
> 
> -- 
> -ck
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel


      Yahoo! Encuentros.

Ahora encontrar pareja es mucho más fácil, probá el nuevo Yahoo! Encuentros http://yahoo.cupidovirtual.com/servlet/NewRegistration


More information about the XviD-devel mailing list