[Ffmpeg-devel] Re: [RFC] mpeg2 422 encoding.
Baptiste COUDURIER
baptiste.coudurier
Wed May 3 18:51:35 CEST 2006
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,
or just copied from luma ? Does motion vectors needs to be adjusted in
the actual code ?
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A. http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
More information about the ffmpeg-devel
mailing list