Pink & Green artefacts with xvid-1 beta3

[Dee]

video is 512x384, 2passes in grayscale mode (and also I used a grayscale() filter in my AVS script), with B-frames.
I don't remember other settings, but most probably they was default.

is this a known bug? (I remember something similar in old versions of xvid) and ow can I avoid problems in future?

samples were taken in VDub. both are keyframes:
frame 1 (http://dee.hotmail.ru/images/rh1.jpg)
frame 2 (http://dee.hotmail.ru/images/rh2.jpg)

there's no difference in decoding method: directshow decoder, divx 5.11 and ffdshow (with different IDCT settings) are all display the same pink/green blocks :(

[b00zed]

You don't have Chroma Motion turned on by any chance do you?

[Dee]

I think NO, because it's nothing to do with chroma in my double grayed video :-)

[Teegedeck]

b00zed asked because your problem looks exactly like what you get when you turn on chroma-motion and grayscale at the same time.

[aiataga]

Originally posted by Dee
there's no difference in decoding method: directshow decoder, divx 5.11 and ffdshow (with different IDCT settings) are all display the same pink/green blocks :( [/B]

try decode with xvid only and alone

[Dee]

after some additional test with greyscaled videos I found a cause of problem: LUMA MASKING.

chroma-related options (chroma optimizer & use chroma motion) do not destruct image...

[BiaTch 5.0]

This is a long time problem with XviD's luma masking I remember about 1 year ago I had the same problem with the movie From Hell.

[m0rtal]

Dee
i've already reported this strangeness (in time of beta2) and have a proposal to change GUI in such way, that when user turns on grayscale option, chroma optimizer unchecks automatically... but seems that developers have another idea :(

[b00zed]

Wasn't their idea "use your common sense," and to get all the critical issues sorted first?

[m0rtal]

b00zed
is it too difficult to make such cosmetic change?
ok, I have no pretensions to developers (rather otherwise), I just expound my thoughts

[Mug Funky]

aaaaaw! i love roman holiday... it's so sweet.

hehe.

sorry for the useless post... i should get some sleep.

[guilc]

I have the same problem using DivX 5.1.1 or ffdshow decoder.
But thoses problems disapears with XviD directShow filter or Nero Decoder...

[Dee]

Anyway, this is a real bug.

when I set encoder in "Greyscale" mode it MUST leave UV channels intact.

source frame -> [convert to grayscale] -> erase UV (to remove noise)

there's nothing to do at all: intra frames will contain constant encoded blocks in UV channels, all other P- & B-frames will be composed of 'skipped' blocks with minimal waste of bitrate and ideal quality. Do I get it right?

[m0rtal]

Originally posted by Dee
when I set encoder in "Greyscale" mode it MUST leave UV channels intact.
source frame -> [convert to grayscale] -> erase UV (to remove noise)
well, why do you need these useless UV channels if video is grayscale?

there's nothing to do at all: intra frames will contain constant encoded blocks in UV channels, all other P- & B-frames will be composed of 'skipped' blocks with minimal waste of bitrate and ideal quality. Do I get it right?
I don't think it's easy to leave I-frames with U&V channels, and remove them from other frames... IMO...

[Dee]

I don't think it's easy to leave I-frames with U&V channels,
and remove them from other frames... IMO...

the idea is: we don't need to do any computations in UV channels at all.
since they're filled with neutral gray (128) we can simply write
to output bitstream a predefined constant sequence of bits:

1. we don't need to do motion estimation - motion vectors for all blocks are (0,0)
2. we don't need to compute DCT every time. DCT on such a block gives only one highest coeff in position [0,0] (can be pre-computed), all others are zeros.
3. we don't need to do compute a quantization (also pre-computed)
4. in P- and B-frames we can mark all blocks as 'skipped' i.e. decoder gets corresponding blocks from previous (reference) frame w/o any additional computations.
5. as option we can also encode UV channels with 'reduced resolution' flag

finally, we have maximal increase in speed and ideal quality in UV channels :-)

[m0rtal]

Dee
it's really interesting!
let's see what developers say :)

[Lord_KiRon]

Exuse me for interrupting such an interesting descussion but what settings you would suggest to set/unset for encoding BW (greyscale) video ?

I already know that I have to set "greyscale" of cause, "chroma optimizer" and "use chroma motion" should be set off ...
what else ?

[sysKin]

Chroma motion is automatically off.

[m0rtal]

Originally posted by sysKin
Chroma motion is automatically off.
No, it is no. I've just tried - nothing turns off automatically, even in last Gam3r's build :(

[Koepi]

I think syskin meant:

it's disabled in core automatically then. You don't see that in the GUI therefore.

Regards
Koepi

[sysKin]

Originally posted by Koepi
I think syskin meant:
it's disabled in core automatically then. You don't see that in the GUI therefore.
Oh yes Koepi, you're right ;)
I meant the following piece of code:
if ((VopFlags & XVID_VOP_GREYSCALE) || (VopFlags & XVID_VOP_REDUCED))
Flags &= ~(XVID_ME_CHROMA_PVOP + XVID_ME_CHROMA_BVOP);
It's in the core ;)

In general it's core that is smart, VfW that is stupid and user that is smart again ;D

Radek

[m0rtal]

Originally posted by sysKin
Oh yes Koepi, you're right ;)
I meant the following piece of code:
if ((VopFlags & XVID_VOP_GREYSCALE) || (VopFlags & XVID_VOP_REDUCED))
Flags &= ~(XVID_ME_CHROMA_PVOP + XVID_ME_CHROMA_BVOP);
It's in the core ;)
kewl!
can you make same thing to chroma optimizer?

[Dee]

to sysKin and Koepi:

so, what do you think about my suggestions about B&W videos encoding posted on page [1] 20th January 2004 14:13? is it possible to implement it? or at least do I think in right direction?