[XviD-devel] mulithread rework

[Edouard Gomez]

Quoting Dark Sylinc <dark_sylinc at yahoo.com.ar>:

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

Because that's to be done outside XviD. You have already a few tools that do
over network also:
 - divide the source in independant large chunks
 - feed some encoder the chunk
 - merge the chunks
 - watch video :-)

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

But it's very easy to implement chunking in the upper layer, that is in
transcode/mencoder/avidemux/etc.

Moreover this approach is subvotimal bitrate control wise, unless you're
playing with CBR or Constant Q. It's due to the fact that you will allocate
the same amount of bits to each chunk, and this fails at delivering the
best quality.

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

Not good for at least three reasons:
 - frameworks calling xvid don't feed the codec with loat of frames
 - 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
 - IFrames suck as reference frames for BFrames because they don't bring
   motion vectors to interpolate motion (DIRECT mode iirc)
   great

> My apologies if this question is stupid.

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

-- 
Edouard Gomez