XVID capture anomolies

[lar1r]

I am testing out XVID for realtime vid-capture. Works fast with these last few builds w/o dropped frames. Great job!

Now some issues I have noticed.

Source: Digital Satellite
Settings: Quality:98%, MPEG Quant, Motion Search=6, no luma

1) once in a while, i get a frame that is a collage (mosaic) of different bright colors). It fixes itself after a while (maybe next keyframe). I have not seen this when using the H.263 Quant.

2) The area around text starts sharp but then it starts to bleed, and looks like the image around the text is transforming into something else until the next keyframe corrects everything. Then the sequence repeats itself. Using H263 helps reduce this error but the it looks like this anomoly is simply smoothed out because the area around the text is still changing colors but the differences aren't as sharp as using MPEG quant)


3) Text sometimes has odd colors within it (grey blocks inside letters etc)


Now I don't tape news programs much and was just testing the codec across a wide range of video sources. I also would rather have B-frames than have these issues addressed but I wanted coders to know that these issues exist. I also use 98% quality because if I use any higher, I might as well use MJPEG at Q19.


-Lar1r

[wing1]

wow, someone is using mpeg4 to capture directly :)

I use it too to capture. What do you use for framesize resolution? and what do you get for data rate on the average?

[avih]

can u post (links to) images?

[lar1r]

Sure take at look at this quick page

http://www.stormpages.com/dv4home/

I can't really see any other need to use CBR though in XVID other than capturing as 2pass is superior when one has a saved source. In other words this really isn't a big deal to me right now but it does show some probs with the codec in its current development.

Note: the pixelizing on a CRT monitor is much harder to see than on a LCD. CRT tends to blur images.

[avih]

Originally posted by lar1r
..I can't really see any other need to use CBR though in XVID other than capturing..

from what i understand, it's quality mode, which is quite different from cbr.

after watching your images, makes me wonder, is the fourcc of the file DIVX?? (hence it's a known problem, read the faq) or XVID (shouldn't produce these effects)?

i also rarely noticed the dark blocks, but only in older builds ... :(

avi

[lar1r]

The fourcc is xvid.
I've tried every version of Xvid from 03-20-2002 and on.

I shouldn't have used the term CBR. I meant 1 pass.

[avih]

:(

[-h]

This seems to be (as Isibaar pointed out here (http://www.videocoding.de/forum/viewtopic.php?topic=404&forum=3&1) a problem with quantization-induced overflows.

Could you try H.263 and MPEG with MMX optimizations turned off? Or grab screenshots of H.263 with MMX on, exhibiting your point 2) ?

Tis an interesting one.

Oh and one more thing, you would probably get better results by using 1-pass quantizer mode, and setting the quantizer to 2. 98% quality is using quite a few quant=1 frames, which simply don't deliver viable benefits in MEPG4 (considering they're around 5 times the size).

-h

[primitive]

I too have seen the pixellation you are running to around the text. Encoding with the march 17th version of xvid, two-pass internal, quant=h.263 and motion search precision=6. Source is Now and Then, Here and There. A short test clip to demonstrate the fault can be provided upon request.

In the particular scene the blocking occurs in, there is absolutely no motion.

-p

[chemmajik]

As with most codecs the capture portion usually is the last part to be fixed or improved upon because of the 1pass less quality aspect.

[philippas]

While using Xvid for capture the only thing that the codec disappointed me was that bright red backrounds & bright red objects appeared bleeding and blockiness was very visible even at quant 1-1. Maybe i'll post some screenshots later on.

[Neo Neko]

I have been able to produce similar results myself. I was using the 03-23-02 compile from Nic's page. I ran acrost it with normal settings using a modulated quantizer. I tried doing it with with both H263 and MPEG with all CPU accelerations off and it was still there. I thought I would do better than post some pics. I will post the clips. It is a bit big to attach to a message here so get it at http://interface.darktech.org/files/Xvid Test.exe.

[wing1]

@neo neko

are these clips captured directly? or post processed to remove the interlace artifacts?

[Neo Neko]

It was a re-encode of a processed capture. :( But it definatly has what you are speaking of. It was a very high quality processed Divx encode to begin with. I simply was trying to cut the rez in half and output to Xvid when I noticed the problem real bad. So filtering did not cause it. MPEG and H263 quantization each display the problem but in a slightly different manner.

[-h]

Hm this is no fun at all.

I'll have a play with quant=1 today (among other things).

-h

[Neo Neko]

Well the work may be no fun. But at least the clip is easy on the eyes if you don't pay attention to the errors. Mmmmmmmm Mila Jovovich. ;)

[Aktan]

I don't know if this error still exist or aplies here but with an older build (around 03/20), when I tried 2-pass with second pass int. with MPEG at 6 for a short clip (like 1 min), and the set desired filesize at a crazy size (like 4 Gigs) (I wanted to see at what bitrate was REALLY needed by the clip :D ) with the rest of the settings defualt, I get a clip with nice I- Frames but seriously pixalized P- Frames.