[XviD-devel] [BUG] Pink Frames (still lacks fix)

[Radoslaw Czyz]

> Sorry for posting this bug again  but i think it's rather important to
> fix it very soon. I'll try to explain why.

Yes, there is a bug. Somewhere within bitstream writer.
I'm trying to debug my ME code for b-frames and I'm pretty sure that
the problems I'm having are not my fault.
For example, when I try to force only one mode (MODE_FORWARD or
BACKWARD) and a vector of (0,0) (that's the easiest to debug - vectors
are zero, predictions are zero, vectors to be written to bitstream are
zero) I have some strange effects - vectors are zero indeed, but DCT
data (which are quite visible and big in the circumstances) are
_usually_ several macroblocks _before_ the place they should be.

It seems like encoder 'forgets' to write some of them, or decoder
'skips' some of them when it reads the bitstream (both ffdshow and
divx5 checked). And no, this is not a problem with skipped macroblocks
in backward reference.

Also, encoding crashes from time to time and the last frame written
(by virtualdub) is so big that the resulting avi is exactly 16 777 216
bytes big (well if the avi was bigger before the crash, the avi would
probably be 32MBs or something. Didn't check because encoder crashes
when the avi is about 1MB).
This crash happens at the very first frame (first bframe I think,
hard to check) if packed_bitstream is on.

Of course all the crashes happen with my own build of current CVS,
using MS VC++ and Virtualdub.

> In my opinion the red and blue dc coefficients are saturated
> by  a bug in  the bitstream  writer or  a MB  coding bug  (remainder :
> blue+red give pink :-) because pink MBs have an pink average color and
> the dc coefficient is the average chroma value of MB so...

Nono, pink is not red+blue (that's RGB mode, forget it). Pink is the
channel with "pink vs. green" (which is either U or V, I don't
remember; the other is "blue vs. yellow". I hope.)


Radek