View Full Version : pink blocks with croped video
kocha
24th October 2003, 11:27
if you crop a video with dvdx and you want to encode it with xvid make sure, that the croped width and height (shown in the top left corner) is a multiple of 16. :)
otherwise the video will have pink blocks in it.
the final avi size can be chosen freely.
(this happens with koepi_24062003-1 and nic_16072003)
the funny thing is, if your file is an avi (not ogm or mkv) divx player will show the movie without the pink blocks.
you also see the pink blocks if you use ffds.
kocha
27th October 2003, 18:09
argh. this was not the problem.
finally i found out, why i'm getting pink blocks:
the final width must be a multiple of 16. everything else doesn't seem to matter.
does somebody know, if the height should also be a multiply of 16 for good results?
Nibor
29th October 2003, 18:51
Yes, a rule of thumb is to use a width which is multiple of 32 and a height which is multiple of 16!
It has something to do with the block sizes, I can't remember it well enough to tell you for sure.
Width multiple of 16 also works, but it's not recommended because older graphic cards sometimes have problems with it.
..:: Nibor ::..
Assault
30th October 2003, 20:17
I think the reason why you should use multiples of 16 or at least of 8 is that XviD macroblocks can only have 16x16 or 8x8 pixels. (AFAIK DivX even supports only MBs of 16x16) So if you use a resolution which isn't a multiple of 8 some of your macroblocks will produce an overhead which will result in a worse compressibility for your movie. Please correct me if I'm wrong. ;)
Assault
mf
30th October 2003, 20:41
Originally posted by Assault
Please correct me if I'm wrong. ;)
Compliant MPEG4 codecs have a per-plane blocksize of 8x8 pixels. As the colorspace is YV12 8x8 pixels luma means 16x16 pixels chroma. Because chroma is less important than luma, being mod8 instead of mod16 isn't so bad. The only MPEG4-based codec that has a smaller blocksize is a particular version of the Angelpotion codec, which should be avoided at all costs. Mod32 being more effective than mod16 is merely a myth, as you can see that the total blocksize (luma+chroma) is 16x16. Getting more efficient than 100% is impossible :rolleyes:.
Assault
31st October 2003, 11:03
Originally posted by mf
As the colorspace is YV12 8x8 pixels chroma means 16x16 pixels luma. Because chroma is less important than luma, being mod8 instead of mod16 isn't so bad.
I don't understand that. Is that a typo and you meant 8x8 pixels means luma and 16x16 pixel means chroma? Otherwise I don't get why mod8 isn't so bad when luma really means 16x16 pixels.
Assault
mf
31st October 2003, 12:52
Originally posted by Assault
I don't understand that. Is that a typo and you meant 8x8 pixels means luma and 16x16 pixel means chroma? Otherwise I don't get why mod8 isn't so bad when luma really means 16x16 pixels.
Assault
Yes that was a typo. My mind said "luma" but my fingers said "chroma" :D.
Assault
31st October 2003, 13:09
@ mf
Ok, everything is clear now. Thanks for the explanation. :)
Assault
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.