View Full Version : Dealing with fades.
McQuaid
6th February 2003, 16:50
I usually encode mpeg, but I'm taking a crack at xvid. My firsts tests are very promising except for fades.
Any time there is a fade to black or fade to another scene, it becomes somewhat blocky and an almost mosaic pattern is evident. This is more evident on the fades to/from black.
I'm doing tv caps, using picvideo19, capping at 352x480. I'm using umaniac's stable build (27.11.2002). I'm using stable builds as I want to ensure they are mpeg4 compliant. Is Koepi's better at handling fades? Since I'm new to xvid, I've been following iago's guide.
Is this something statsreader would help with? I'm just using the internal 2nd pass, from reading the thread on statsreader, I'm not sure if it's still beneficial over int 2nd pass, or was this only from a time when the int 2nd pass was lacking.
Teegedeck
6th February 2003, 18:22
Just wanted to say you're not imagining things; XviD doesn't do too great on fades. :(
It's an unresolved problem.
Prettz
6th February 2003, 18:53
Is there a way to have xvid detect frames where the video is fading in or out, and have it deal with it specially, maybe by just upping quantizers? If that would work, it seems like it would be worth the trouble as fades occur very frequently in all types of video.
Zarxrax
6th February 2003, 22:48
I think GMC is supposed to handle this, if I'm not mistaken.
Teegedeck
6th February 2003, 23:10
I think fades can hardly be described with motion-vectors, so GMC shouldn't help, either.
cult
6th February 2003, 23:26
why I never see these problems??is it my vga card perhaps?
Teegedeck
6th February 2003, 23:30
If it was that obvious it would be really nauseating. But very rarely only (slow fades from black for example) and at low bitrates one can see that there's room for improvement. Nothing serious.
Morbo
7th February 2003, 03:47
The intro to Catch-22,noticed that to day......
Weird their was a post about it:sly:
Cheers!!
Prettz
7th February 2003, 18:33
there was a thread on GMC a while ago where someone mentioned that the standard for GMC isn't supposed to handle fades and why GMC wouldn't work them anyway.
trbarry
7th February 2003, 18:46
Lighting is always changing.
So I've wondered for awhile why motion compensating codecs like MPEG4 don't have this built into the motion search functions to just find the best match that allows adding a constant to each pixel in a block. It would really just be a change in the DC component of the DCT and would probably make motion search take 2-3 times as long.
But it seems to me it would be worth it. You could just find the best match where the sum over the block of abs(X[i,j] - Y[i,j] + C) was minimal. And C would just = the average difference between corresponding pixels in the 2 blocks. At least thats the answer I get when I calculate the least squares fit for C. (edit: SSE instead of SAD)
But maybe there is no way to shoe horn this into MPEG-4 or something.
- Tom
hayami
9th February 2003, 08:03
Maybe other than Chroma ME, we can have something like Luminance ME? ;)
trbarry
9th February 2003, 14:41
Thinking about this a bit more it seems that normal DCT block based compression should already deal with linear fades quite well. If every pixel in an 8x8 block decreased by 10 then in the DCT only the top left pixel would decrease by 10. In a DCT of the differences the other 63 values in the block would be 0.
But using normal motion search might not find the correct block to let this happen without some scheme like I mentioned above.
- Tom
sam_b
9th February 2003, 16:01
I believe most fades make pixels fade in proportion to their intensity. This will require all DCT co-efficients to be changed. I think. I'm sure it would be possible to make it only update the AC co-efficients every few frames, and update only the DC co-efficients every frame. Would have thought it would be codable. What I don't understand is why it looks bad, rather than just using up lots of bits.
trbarry
9th February 2003, 17:32
I believe most fades make pixels fade in proportion to their intensity. This will require all DCT co-efficients to be changed. I think.
You are probably right, and I worried about that. These could be recognized too but I don't think there is any good MPEG4 way to store them.
But if Xvid could handle simple fades like X=Y-C nicely then I bet it would be possible to write an Avisynth filter like one of those Dup() filters that changed some X=A*Y-C fades to just a simple X=Y-C' type, at least for fading still scenes. But I can't envision what the results would look like.
- Tom
sam_b
10th February 2003, 14:33
Now that's a good idea.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.