Cannot start video compression

[trodas]

Cannot start video compression:
The source image format is not acceptable. (error code -2)

This i get trying to start compression to latest Xvid with latest VirtualDubMod. The source video is pretty standard uncompressed 24bit AVI crap, well, v2 of the AVI container format.
2,3G big
This is a problem for Xvid? That suxx, since i can compress it using for example Cinepak compression, but not Xvid?!
WTF is going on?!?! :mad:

[Koepi]

Make sure to use "full recompression" instead "fast recompression", it should work then.

Koepi

[trodas]

Thanks Koepi for hint, but i already have selected "Full processing mode"... :rolleyes:
Damn. So, i tried change it to "Normal recompress" and "Fast recompress" too, but sadly W/O any sucess...

Frankly, i converted using EXACTLY same way many and many movies, and i never get this message so far. No idea what it can cause.

So, i used the file AviC and tried to load the video only source. Message "Cannot open file". So, i opened it using Virtual Dum Mod and selecting "Direct stream copy" i saved it as old AVI 1.0 format. (dunno how it can work, the file is over 2G) That file i can open into the AviC, it says Four CC description code: DIB (WTH is this?!) and FourCC Used Coec: (nothing, just empty space)

I know its uncompressed 24bit AVI. What can i do???

...another try i tried using AVIsynth. So far i understand that it can work as source of data, so - i created a simple "script":

AviSource("d:Matrix Revolutions Trailer.avi")
FlipVertical

...witch worked well into MS Medial Player. Okay, but trying to open it either using open video file did not change a thing (except the video get flipped - just a test it worked... When i trying to save it, i get the "The source image format is not acceptable. (error code -2)" message again. DAMN!!!

So, i try to open it using more "right" way - Open Video file via AVIsynth - but in both cases i give me error:
Failed to create script.

...amazing. Anything what i can do to move trought this and debug, where the problem is? :confused:

Thanks for any advice, tip or idea.

PS. i recompressed the file using Cinepak jsut well. Tough, it have 180MB instead of orginal 50MB and the quality sometimes looking like 256colors... :rolleyes:

[Koepi]

Well, this problem isn't at all xvid related. Maybe you should try some intermediate step using huffyuv - gives a little smaller file and maybe your problems are gone.

Koepi

[trodas]

Well, when i can encode the file into many other formats and only Xvid give an error, are you sure that the problem is not Xvid related at all? :rolleyes:
I would like this, but...

And into list of my codecs i find only IYUV - no settings, so i used it and we see... Where to get huffyuv ? (I suppose that this is loseless codec, right?)

...ah, there: http://www.slashcam.com/news/single/news1329.html

Hmmm, small & effecive. Meanwhile IYUV finished the job, file are 1.1Gby big (whoa, nice) and seems also loseless - but i don't checked it very cerefully, so, let's see...

Compression to Xvid works!

Now the Huff YUV finished its job, 800MB size (not bad for loseless!) - but hell, this one can't get encoded - again.

Are you SURE the problem is not into Xvid, when i can the damn file encode to what i wish - except Xvid? :confused:

...i try it again, just to be sure that i can't encode it... Yes, verified. Need and infos to debug this problem??? Just tell me what i can do... I save both the big files to be able to test them later... :(

[Koepi]

Well, it would be useful if you'd follow the rules in our "READ THIS! When posting bugs!" sticky thread. You'll see that you might have given _way_ too little information for a good analysis.


Which xvid-build are you using?
Which options are checked?
What's your processing chain?

etc etc

With those infos we might be able to track that thing down easier and faster.

Koepi

[trodas]

Okay, you are obviously right, so, let's start:

Using latest build from 24. 06. 03 and your site.

Options? Trying to save from Virtual Dub Mod 1.5.4.1 animation, like Save As... and as Xvid.
Xvid options? First pass from 2nd pass compression, and the rest did nto matter at all. Bug striges even W/O custom matrix.
6- Ulra High search precision
MPEG - Custom guantization
Four CC - XVID
VHQ mode 4- wide search
rest is disabled, like brames 0 (but i tried -1 (default) and other options too, W/O luck to start compression), disabled also DX50 B-VOB compatilibity and Disabled discarding first pass.
Rest of settings untouched.

Processing chain? None, just load and trying to save, that's all. Not even including sound stream and so on - just trying to save...

...about the rest, that used DirectShow filter is irelevant there (latest FFD show), because i can't encode, not a problem with decoding...

Machine - Abit ST6R Tualatin 1300Mhz, 512MB SDRAM, FX GF5200, Win2k SP3, SB Live 5.1, 120G Maxtor primary drive... nothing special, installed onyl MS crappy player and BSplayer. And WinDVD and that it is.

Briefly problem already specified...

...and no AVIsynth used, and trying to encode into avi, ofcourse ;)

[Koepi]

You have to make sure that the path to the stats-file (setup within the xvid codec) exists and that there is enough space for it.

Regards
Koepi

[trodas]

The path is:
\video.stats
...and worked before and after W/O a glitch. And i assume that 27G of free space on primary drive could be enought. If not, i can set another one, but... :(
Hell, its only 2,2G file.

[JimiK]

is it a mod 2 resolution? I also have a question about this. When I select XviD as compressor in VDubMod, the box says 'no known restrictions'. As XviD works in YV12 colorspace, shouldn't it be restricted to resolutions modulo 2?
Best regards,
JimiK
Edit: btw Trodas, this way the stats will be written to the root directory of the drive where you save your video to. So if you wanted to save it to your 27Gb drive, there should be no space problem.

[trodas]

A VERY stupid question - hehe - waht the hell is mod2 resolution?! :rolleyes:
You mean that certain resolutions can't be encoded? Well, this is probably not the case, as the resolution is 640x332 pixels and 24fps - witch is IMHO pretty normal.

Also - converting the source to IYUV format cause its now compressable. Interesting. Also is interesting why compression canno't be started, when the source format is loseless Huff YUV... :rolleyes:

I have no idea... Koepi, want a piece from the start of the unencodable avi send to email? (let's say first 1MB)

About colorspace - as almost (?) all mpeg4 formats, Xvid use also more crappy, when come to color fidelity, but smaller YUV420. But the source is 24bit, and selecte is full processing, so it should not matter. (mpeg2 using YUV422, witch is no dubt much better, but also want more bitrate, so...)

And about the size - 27G is free, drive (first one) is 120G big. And i know, it don't matter, just Koepi are suspicious about it. No wonder, developer allways believe in his code as perfect and first must aliminate all possibilities, that this is just another PEKBAC error.

(for those not familiar with - PEBKAC menas "Problem Exist Between Keyboard And the Chair" :D )

[Koepi]

Trodas,

you're making assumptions here which aren't correct (and not funny IMO).

MPEG1|2|4 use YV12 colour space. There are _studio profiles_ defined for MPEG standards which can use other colour spaces (YUV 4:4:4, YUV 4:2:2), but all user-accessable codecs available (tmpegenc, cce, divx, xvid) use YV12 to encode the data in as they're not studio profile compliant but use simpler profiles.

I'd be accepting a small snippet from your file (1mb sounds fine), I'll send you my email adress via PM.

(And no: I don't assume xvid is perfect, I know it's buggy. And i'm just one out of hundreds people which contribute to xvid, so I can't assume the PEBKAC - I just don't have such troubles and want to exclude the "usual" errors which can be done to provoke that error you're experiencing.)

Regards
Koepi

[trodas]

Well, snippet sendt. Hope it helps :rolleyes:

About the buggy Xvid - whoa, most developers strongly believe, that his software are perfect and users are just, well, ehm, lamers :D

Anyway, about the mpeg and colorspace - that's what i heard and it sounds reasonable for me.
I don't checked the mpeg specifications, but im familiar with YUV colorspace (after all, im graphician, getting paid for my eyes :D ) and i see.
What i see convicing me the same way as i being (wrongly? :rolleyes: ) told - there is obviouc color difference between mpeg2 (DVD) and Xvid/DivX picture.
Two most extreme (i hope everyone see them, even the half-blind :p ) examples. Opening sequence of Abyss (underwatter shoot of submarine, apearing from the shadow of ocean) and sequence from U-571, where U-571 are shown closely under Nazi destroyer keel.
In both cases, DVD show very nice colors and very sharp picture. You can almost say you "are there"... But hell, into DivX/Xvid rip, things are far, far worser.
Frankly spoken - they are UGLY. Very ugly.
So, the reason why i believe what i was told - so, mpeg 1 and 4 using YUV420 color precision, while mpeg2 using YUV422 - delivering much wider and deeper picture.

If this is wrong, let me then come with another reason, why i believe in this - corect me, if im wrong, but, YUV420 is mostly mentiond on PCs as YV12, right? And YUV422 as YUY2, okay?

So, into BSplayer video prefs, these YV12 and YUY2 are idntified as Mode1 and Mode2. Well, so, then why when i use Mode1 and play a mpeg2 video, the colors are wrong?
I have switch to Mode2 to these are fine.
But hey, all mpeg1 and DivX/Xvid videos are fine into Mode1 (YV12), so does not this very unusually supporting the idea, that mpeg2 using different color mode?

Can you point me on some docs? :D

[trodas]

All i find about YUV colorspace is:

"Therefore the MPEG coding schemes first divide the images into YUV components (one luminance and two chrominance components). Next the chrominance components are subsampled relative to the luminance component with a Y:U:V ratio specific to particular applications (i.e. with the MPEG-2 standard a ratio of 4:1:1 or 4:2:2 is used)."

http://wwwam.hhi.de/mpeg-video/papers/sikora/mpeg1_2/mpeg1_2.htm

...witch, more or less, depend on how you look at this, support what i believed anyway...

[Koepi]

Ok, problem tracked down:

the input file you're using is 640x335 - like JimiK mentioned, you need to make the resolution at least "even" - 640x334 (cropping the bottom line) solved the issue.

I'd still recommand to use mod32 x mod16 resolution for VGA drivers overlay compatibility (i.e. 640x336).

Regards
Koepi

[trodas]

Well, true, i sadly don't figured it out sooner :(

Interesting is, that the IYVU format created a 332 pixels height file from the 335... interesting. That's why i mistaken the input/output sizes... Damn. Sorry for stupidos problemos :rolleyes:

...so, shall we debate about the YUV color formats used? :D I would really like to hear some answers ;)