[XviD-devel] mulithread rework

Dark Sylinc dark_sylinc at yahoo.com.ar
Fri Apr 25 00:25:20 CEST 2008


> This idea is already implemented in ELDER. 
> http://www.funknmary.de/bergdichter/projekte/index.php?page=ELDER
> 
> If you want to break "one frame in, mostly one frame
> out" (== no VfW) 
> you might as well implement x264's encoding method
> instead :) It's 
> pretty awesome.

That's what I was talking about!
I gotta try it myself later. Thanks for the info!
On of the forums, it claims to be very scalable (almost 100%). Let's see if it's true. (Although being really scalable doesn't mean that it goes faster than regular encoding method, if it is slower, It'll outperform the older method by having more cores)

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, Radek Czyz <radoslaw at syskin.cjb.net> escribió:

> De: Radek Czyz <radoslaw at syskin.cjb.net>
> Asunto: Re: [XviD-devel] mulithread rework
> Para: xvid-devel at xvid.org
> Fecha: jueves, 24 de abril de 2008, 1:05 pm
> Hi,
> 
> This idea is already implemented in ELDER. 
> http://www.funknmary.de/bergdichter/projekte/index.php?page=ELDER
> 
> If you want to break "one frame in, mostly one frame
> out" (== no VfW) 
> you might as well implement x264's encoding method
> instead :) It's 
> pretty awesome.
> 
> Radek
> 
> Dark Sylinc wrote:
> >> The problem with this is that it cannot be dealt
> directly
> >> in the core because
> >> xvidcore is used in more traditional ways like in
> VFW (eat
> >> one frame, give one
> >> frame), mencoder/transcode/avidemux/etc (eat one
> frame,
> >> give one frame if
> >> possible).
> > 
> > Yep (I'm thinking about the 2nd question), I was
> thinking in pherhaps tricking the high level app by
> returning that it already encoded the image (when we did
> not), so he sends us the next one. This might broke some
> apps. The simple solution is to turn off multithreading for
> those apps.
> > Also some programs (AFAIK, like mencoder) use directly
> xvid, so they could be able to adapt to the new interface
> > 
> >> Not good for at least three reasons:
> >>  - frameworks calling xvid don't feed the
> codec with
> >> loat of frames
> > 
> > Like I said before, that should change.
> > 
> >>  - Even if we can trick the framework doing our
> own
> >> buffering, Iframes are
> >>    way bigger than P or B frames, this would
> result in
> >> smaller budget for P
> >>    and B frames -> bad quality
> > 
> > Huh? I'm aware I frames would consume more memory
> and resources, but how could splitting the process cause
> worse quality?
> > 
> >>  - IFrames suck as reference frames for BFrames
> because
> >> they don't bring
> >>    motion vectors to interpolate motion (DIRECT
> mode iirc)
> >>    great
> > 
> > mmm.. that sorts breaks the whole "my new great
> (but-someone-obviously already-thought-of-that) idea"
> > I was thinking in a sort of linked list, where the
> struct should be as follows:
> > 
> > struct FramesQueue
> > {
> >  union
> >  {
> >      Iframes *iframe;
> >      Pframes *iframe;
> >      Bframes *iframe;
> >  }
> > 
> >  FramesQueue* next;
> >  FramesQueue* before;
> > 
> >  int Time; //Place where we are standing.
> > 
> >  //Other data here that can be needed
> >  //to calculate the frames (like the motion vectors
> you describe)
> > }
> > 
> > Frames should be placed in between when calculating.
> > There's no reason for split up the B & P
> frames generation. That would be linearly made from the
> very beggining to the end in one thread, skipping the
> process of generating the I frames because they were
> already done in another thread. (Now that I think of this,
> this would make the task of Core 4 unnecessary)
> > 
> >> Your questions weren't stupid. I'd say
> it's
> >> very hard to know the whole MPEG4
> >> ASP standard and usual encoding frameworks. And
> without
> >> that knowledge it's
> >> nearly impossible to have ideas that can
> eventually be
> >> implemented.
> >>
> >> You're forgiven :-)
> > 
> > Thanks! It just like you said, my knowledge about the
> MPEG4 standard is vague and mixed from code and various
> resources/forums, without actually understanding the whole
> XviD process.
> > But like they say, ideas are for free. Finding one
> that that works is another thing....
> > 
> > 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.
> > 
> > 
> > 
> >       Los referentes más importantes en compra/ venta
> de autos se juntaron:
> > Demotores y Yahoo!
> > Ahora comprar o vender tu auto es más fácil. Vistá
> ar.autos.yahoo.com/
> > _______________________________________________
> > XviD-devel mailing list
> > XviD-devel at xvid.org
> > http://list.xvid.org/mailman/listinfo/xvid-devel
> > 
> > 
> _______________________________________________
> 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