[Ffmpeg-devel] Re: [RFC] mpeg2 422 encoding.

[Michael Niedermayer]

Hi

On Wed, May 03, 2006 at 06:51:35PM +0200, Baptiste COUDURIER wrote:
> Hi,
> 
> Michael Niedermayer wrote:
> > [...]
> > 
> >> Btw, I still have a bug with -mbd bits, and it's a bit annoying (green
> >> bottom chroma macroblock in P frames, if using -bf > 8 the bug vanish).
> >> Since you best know mpegvideo.c, do you see where it could be located ?
> > 
> > maybe its caused by:
> > 
> >         s->dest[0] = s->rd_scratchpad;
> >         s->dest[1] = s->rd_scratchpad + 16*s->linesize;
> >         s->dest[2] = s->rd_scratchpad + 16*s->linesize + 8;
> > 
> > the + 8 would cause some overlap ...
> > 
> > it could also be something else
> > 
> > [...]
> 
> I did not give up and still digging to hunt that bug (-mbd bits). Im
> however kinda miss the basics, but Im not discouraged.
> 
> What I found:
> using "-me zero", is worst than using "-me x1".
> The more B frames I am using, the less green blocks I get. If B frame
> count is high (> 8) I get no artefacts at all.
> 
> I reread the specs and I found out that:
> 7.6.3.7  Motion vectors for chrominance components
> The motion vectors calculated in the previous clauses refer to the
> luminance component where:
>           vector[r][s][t] = vector'[r][s][t]   (for all r, s and t)
> For each of the two chrominance components the motion vectors shall be
> scaled as follows:
>           4:2:0
>                   vector[r][s][0] = vector'[r][s][0] / 2;
>                   vector[r][s][1] = vector'[r][s][1] / 2;
>           4:2:2
>                   vector[r][s][0] = vector'[r][s][0] / 2;
>                   vector[r][s][1] = vector'[r][s][1];
> 
> Michael, you previously replied that motion estimation did not take
> chroma in count.
> The question might be stupid but, does that mean that motion vectors for
> chroma component are set to 0,

no, there are no motion vectors for chroma the chroma vectors are the same
as the luma vactors (ignoring scaling & rounding ...)

and i dont think that theres a relation between -me xyz, the number of b
frames and the (-mbd bits) bug its probably just a "coincidence"
you should rather look at the mb_decision != 0 specific code, i also
think that the mbd bits bug isnt critical and could be dealt with after
422 encoding support has been added

[...]

-- 
Michael

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is