PDA

View Full Version : VERY messed up video with GMC in 5.0.1


Monkey
8th May 2002, 07:49
I was trying to encode Neon Genesis Evangelion Episode 1 when this happened. I'm not sure what to say about it, but the pictures speak for themselves. I follow Doom9's guides for my encodes, so I was using GMC and Bidirectional Encoding. I'm using Gordian Knot 0.23, 320x240 resolution. The screens have been doubled in size and taken from VirtualDub. They are from frame 6513 of the R1 box set DVD.

My first encode was at a very low bitrate (200kbit)... I was just messing around to see how it would look when trying to fit 13 eps on 1 CD. It looked terrible, but mostly because of this problem. I thought at first it was because of the bitrate, but just to be sure, I encoded it again with 1-pass quality based with the quantizer set to 2. That is where this first screen shot was taken from. My next thought was maybe the deinterlacer is just doing a really terrible job. So then I checked the same frames in the .avs and found that it looks pretty flawless as you can see in the next screenshot.

Next, I did 3 more 1-pass q2 encodes, one with neither GMC or BiDir, one with GMC only, and one with BiDir only. Both the GMC-free encodes were flawless, just like the .avs. Has anyone else run across this before? Is it a known bug? It's a pretty damn bad one...

Edit: Just thought I'd make it clear that this problem wasn't just with this frame or scene, but almost every scene looked like this... it's awful... I'm trying a 640x480 encode w/GMC right now to see if the same thing happens, or whether the problem is with 320x240 only.

Monkey
8th May 2002, 08:20
Here's pic #1... the shot WITH GMC

Monkey
8th May 2002, 08:20
Here's pic #2... the shot of the original .avs...

DmitryR
8th May 2002, 10:22
I think that it is the result of combining low resolution, improper deinterlacing and GMC. First to problems can be clearly seen on the second frame.

Try to use 512*384 resolution. It will give reasonable balance in quality and bitrate. Use deinterlace before resizing.

DJ Bobo
8th May 2002, 11:43
@ Monkey
Just a thought: I hope you are using IVTC, not deinterlacing.
Well, you may use IVTC 2.2 with the following parameters:

ivtc(32,11,110)

Do not use the recommended settings in the help file, they aren't good.

Tester
8th May 2002, 18:16
I'm ripping eva (all 26 series) at the moment, too.

But I use 10000 bits and only b-frames (the quality is quite well and 1 serie get's on one cd).
Can it be that dvd2avi does not do a good job??? Because when I look at the uncompressed .avs Frameserving file (createt with gordian knot), there are "pixel-errors".

Monkey
8th May 2002, 18:21
I tried a 640x480 encode and the same problem is still there. It's less noticable because of the higher resolution, but it's definitely still there. I really don't think this has anything to do with the deinterlacing because the lines aren't horizontal comb lines, they're vertical, and they're not on the source.

@ DmitryR

It's obviously a low resolution... like I said, I was shooting for about a 200kbit/s bitrate. It would be ridiculous to have the resolution at 512x384 or higher. Second, I don't really see what's wrong with the deinterlacing in the source. The source looks fine. I'm using the Smart Deinterlace in Gordian Knot. Even if it didn't look good though, the codec should accurately reproduce the source at quantizer 2 whether it looks bad or not. The problem is GMC is mutilating the source and making the output look nothing like the input.

@ bobotns

Why would I use IVTC? DVD2AVI says it's 95% NTSC. If it's not film, then IVTCing will make everything choppy...

Monkey
8th May 2002, 18:24
@ Tester

I think the .avs is fine. The problem is definitely introduced when GMC is enabled. Everything looks good until you turn on GMC and then this crap appears all over the place...

Taranli Maren
8th May 2002, 18:40
take a look at your cpu load when you go to play this. I'll bet you its pegged at 100%. GMC seems to take a LOT more cpu time to decode. and if it takes too much, the divx5 codec has this problem. There are several problems like this with k6-2 systems as well.

Monkey
8th May 2002, 19:32
I really don't think CPU speed is a factor... it's not encoding in real time, so it should just be taking longer, not messing things up.

Tester
8th May 2002, 20:06
with gmc you are right. I've the same problem, without it works better.

What DeInterlacing Routine do you use? The one of GKnot or the internal one of the divx5 codec? In my case, the routine of divx5 is better.

Mac Sidewinder
8th May 2002, 20:48
I have been following this prob in the other thread. Have you only noticed this problem with GMC in Anime or with everything you have done? I have done around 20 encodes using GMC (usual movies) and have not experienced this problem.

Mac

Tester
8th May 2002, 21:58
so far, I only expirienced this Problem with this anime-films,
in other movies I used gmc, the result was without problems...

But in my case, the frameserving file (created with dvd2avi) is very bad, so it does not seem to be a problem with the codec. In flaskmpeg e.g. all is fine!!!! strange...

Monkey
9th May 2002, 00:31
I've been using GKnot's Smart Deinterlacer for my encodes. I tried Divx's deinterlacer once and it looked terrible. To be honest I haven't done many big encoding projects since Divx 5 came out, but the few I have done (transcoding VCDs and other high bitrate Divx) haven't had any problems that I've noticed with GMC. Maybe I'll try a couple tests with Flask and see what happens. I'll be sure to post the results.

I guess I'm still wondering though, does anyone know _why_ this happens. I know it's easy to work around and all, but it it's a bug, it'd be nice to know so I can keep an eye out for other problems with GMC until the bug is fixed.

DJ Bobo
9th May 2002, 01:26
@ Monkey

YOU MUST IVTC!!!!!!!
Why don't you try it and then come with a statement, I have encoded lot of Animes, most of them are 100% NTSC interlaced, and using IVTC you get proper 23,976fps output.
If you use deinterlace, then you get choppy playback (stutter in panoramic camera views, and many blends)

Taranli Maren
9th May 2002, 02:25
I agree with bobotns, ivtc (or telecide) should always be used before deinterlacing. deinterlace should ONLY be used to clean up after the ivtc routine. I use decomb for ivtc, which works incredibly well with anime sources, and also includes a post ivtc smart deinterlacer built in.

The cpu problems with gmc are only in playback, not encode-time. Encodeing time doesn't make any difference in the quality of the output.

For all my anime encodes, I leave all the divx5 settings at default, except enabling bidirectional encoding (b-frames), they end up looking and playing very good.

Monkey
9th May 2002, 04:50
I don't understand why you'd IVTC and reduce the video to 24fps when it's intended to be 30. It's an NTSC source not a film source. You don't just go IVTCing everything whether it's film or not. Besides, just because you ivtc people wouldn't stop insisting that was the problem, I went back and did and IVTC anyways, and the same exact thing happened. It's obvious that isn't the problem anyways though if you actually look at the pictures. The deinterlaced source looks fine, it's only as soon as you introduce GMC into the encoding that the video gets messed up like that. The second pic is exactly what goes into the codec, and the top pic is what comes out. That is not supposed to happen. It doesn't have anything to do with deinterlacing or ivtc. Everything is set the way it should be and yet the problem remains. I don't know how many more times I can say it.

b0b0b0b
9th May 2002, 05:00
Maybe it's a problem converting from 4:2:2 to 4:2:0 that only gets triggered with GMC.

Can you try with full processing (I assume you're doing fast recompress).

theReal
9th May 2002, 05:47
Why are you using GMC anyways? It doesn't make the output much more compressible and errors with it have been reported from the beginning. B-frames is still the only 100% safe option - and it saves you a lot of bitrate (unlike gmc and/or q-pel)

Monkey
9th May 2002, 07:17
I just tried Full processing mode. No dice. Still the same problem.

@ theReal

That is true, thankfully. I guess I will just be continuing without GMC. The reason I was using it though, was because it was deemed safe enough to be included in Doom9's guide. He's usually pretty good about keeping options disabled that can mess stuff up.

DJ Bobo
9th May 2002, 12:00
@ Monkey
I can only repeat myself: YOU MUST IVTC (this has nothing to do with your problem I know!)

99% of Anime are film content, that means 24fps!!!! the DVD author makes what we call "telecining" so that he gets FAKE 30fps, to be conform to the NTSC norm.
So you *MUST* IVTC (Inverse Telecine), so you get the ORIGNAL 24fps!!!
No Deinterlacing!!

This is how your AVS-Script should look like:

LoadPlugin("...\mpeg2dec.dll")
LoadPlugin("...\ivtc.dll")
ivtc(32,11,110)
crop(...)
BicubicResize(...)
...

PLEASE COMPARE THE IVTC-Version & the deinterlacing-version SERIOUSLY, you'll see that the ivtc version is smooth and full quality, the deinterlaced one has stutter in long camera panoramics, and please see the frames, you'll notice much blends in the deinterlaced version, but not the ivtc version.

IT IS *NOT* INTENDED TO BE 30FPS, BUT 24FPS!!! please understand this and try it for yourself and you'll see that I'm right!

grug2k
9th May 2002, 14:34
original post

I just found this... http://www.inwards.com/woh/

Its talking about Wings of Honneamise and its terrible interlacing...but mentions that the problem was also exhibited with Evangelion 0:1 and several other ADV productions...

====

At first glance it looks like the inverse telecine worked. All of the obvious interlaced frames are gone, replaced with nice progressive images. But look closer. His hair is still interlaced. The jacket pockets and folds of his coat also exhibit strong interlacing artifacts. So what's going on here?

I have seen similar results of an IVTC before. Slayers The Motion Picture, Evangelion 0:1 and a few others (notably, all by ADV) all exhibit the same kind of interlacing patterns when the telecine is reversed. The cause for this is simple. Instead of starting with the original film print, Manga has taken some kind of video source that was already interlaced to begin with. This may have been an old VHS master or even (as some have speculated) a capture of the original laserdisc. There is no way to know for sure what the source was, but I highly doubt that it came directly from Gainax.

Anyway, this original source was then captured as 30fps interlaced. So now we've got another level of interlacing added to the already-interlaced source. Since an IVTC only removes the original interlace, we're left with artifacts of Manga's capture.

OUTPinged_
10th May 2002, 18:53
the problem on screenshots isnt because of interlacing. encoded at quant.2 content should be approx. identical to source frame. his problem occurs on a codec stage.


monkey, an issue "to ivtc or leave at 30fps" issue was discussed at doom's a million times already. in your ivtc'ing will produce 25% less frames (means 25% less bitrate) and more smooth playback in some cases.

ps. there was a topic that bobotns's ivtc string isnt working properly but he is still promoting it. wierd.

b0b0b0b
10th May 2002, 18:58
Forgetting about the nasty block artefacts for a minute, if you are interested in restoring the cartoon to its original frame rate (they would never draw 30fps), check out Donald Graft's DeComb. It has something built in called Decimate that will remove 1 out of every n frames. To figure out how many frames you need to remove, open your avs in virtualdub and step through it noting which frames are interlaced and which are progressive. After you discover the pattern it is easy to figure out what "n" to use. Don't cartoons get drawn at 12fps anyway?

DJ Bobo
11th May 2002, 01:07
@ outpinged
Some people here said that IVTC as a filter don't work properly with cowboy bepop (I don't have this one) and some other stuff, but they havn't try my combination (32,11,110) and just stated that IVTC isn't good, this is simply ridiculous.
If you have some stuff where my settings don't work well, please upload it some where and I'll try to find better settings.
If my settings were bad, I'll never promote them! but I have made and I continue to have very nice experience with them, and I wanna help people getting the same excellent results!

@ b0b0b0b
My IVTC settings have worked better than Decomb on the Animes I tested, that's why I wouldn't use Decomb.
And yes, Animes are drawn most of the time in 12fps, BUT still 24fps are required to display camera panoramics & zooms well.
Try for yourself, ivtc an anime to 24fps then decimate it by 2, so you get 12fps, you'll see, it's not smooth at all with 12fps.

KEEP SOMETHING IN MIND:
99% OF ANIME ARE 24FPS, the 1% left is 30FPS and is computer generated. If you ivtc an anime and get choppy playback, then there is one of 2 reasons:
1) you have the wrong ivtc settings
OR
2) you're unlucky and you got one of the very few animes produced in 30fps (I heard about them but never got something like this... well only once, and it was a very short trailer)
And I'm sure: Evangelion is 100% 24FPS!

And another thing: there is NO interlaced Anime, this simply doesn't exist. There is only progressive anime (which would be telecined on DVDs if it's not real 30fps). Except for PAL countries, there is a crappy NTSC-PAL conversion method that produces 25fps PAL interlaced Anime, which is really shit, it even stutters on TV! (and there is no way to get it back to original 24fps progressive :()

Acaila
11th May 2002, 10:19
Except for PAL countries, there is a crappy NTSC-PAL conversion method that produces 25fps PAL interlaced Anime, which is really shit, it even stutters on TV! (and there is no way to get it back to original 24fps progressive )
Yup, I got me one of those, and am trying to sort out how to fix it. Not much luck so far (problem (http://forum.doom9.org/showthread.php?s=&threadid=24940)).

puffpio
12th May 2002, 00:38
botbotns:

So you are saying that most anime content that was drawn for TV is actually drawn for 23.976 and not for 29.97? I could understand if that was for anime movies, but this is anime tv. I'm not saying you're wrong or anything, just need some proof to back it up.

DJ Bobo
12th May 2002, 02:19
@ puffpio
I have nothing to proove here, you've gotta see this for yourself, I'm not throwing theories in the air here, I'm talking based on my experience, I have a lot of anime series, and they are ALL 24fps without exception: DB/DBZ/DBGT, Ranma 1/2, InuYasha, Hand Maid May, Love Hina, Arc The Lad, Noir, Lain, Saint Seiya, Golden Boy, Tales of Eternia, Angelic Layer, Vision of Escaflowne, etc

theReal
12th May 2002, 17:20
I guess any cartoon is made with as few as possible frames per second because every single frame takes a lot of time to draw. So it makes a big difference if 12 or 15 fps have to be drawn.

I'm only guessing here because a)I'm not a big fan of manga b)I live in a PAL country.