[XviD-devel] mulithread rework

Radek Czyz radoslaw at syskin.cjb.net
Thu Apr 24 18:05:46 CEST 2008


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
> 
> 


More information about the XviD-devel mailing list