On Sun, 9 Jan 2005, CK wrote:

anybody has an idea why [pix_write] looks like this[0] over here ? this is Gem-0.90 on debian/ppc ... not that I don't like it but it's not quite what I expected. [0] http://test.pilot.fm/nolink/gem.pix.write.jpg

I don't know anything about your situation, but:

i see the screenshot is 322 wide 241 high, and the left side of the video stops at the middle of the bottom, that is, about column 160.

so the slippage is about 160/240 = 2/3 of pixel per row. this confirms the weird color bar pattern on it.

furthermore, there ought to be 966 bytes/row, but with the slippage that makes it 968 bytes/row, which is 966 rounded to the closest multiple of eight.

then, whether it's the fault of [pix_write] or of the codec, I don't know. i just know that _my_ code doesn't "cut corners" like that in sake of alignment. however, it's still recommended to use multiple-of-eight bytes/row whenever you can, because it's faster than otherwise.

using colormodels RGBA (4 chans) or YUV422 (2 chans, sort of), there are less restrictions on width, because the pixel sizes are divisors of eight.

Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju

hi,

except for some strange aspect problems when mencoding the snapshots to avi I now get good results when I don't use the auto message to pix_write but use a metro to send out bangs at my desired frame rate.

regards,

x