Video hesitates/jerks (r4r-GK-xvid)

pojke · 16th February 2006, 10:01

I've encoded a movie in Xvid using Robot4rip and Gordian Knot according to the guide. The video output is slightly jerky, as if frames have gotten stuck and suddenly jump 2 or 3 frames ahead. It's not always noticeable but with motion it usually happens.

I've tried it with "auto force film" checked/unchecked and it seems to make no difference. In GK, under Field Operations the Inverse Telecine option is available in both instances. If I uncheck Inverse Telecine the video runs smoothly but there is no audio. Hopefully that's a clue to the solution since it solved the video issue.

With the first encode, the log gave a warning: "Number of counted frames differs from settings!" Difference = 11

This isn't my first time with GK. I've used it many times with good results. Never anything like this.

jggimi · 19th February 2006, 18:03

pojke · 19th February 2006, 23:32

Update:
I've been experimenting with FF, IVTC, FPS and deinterlacing. I found that using IVTC results in the jerking problem I mentioned above, no matter the other settings. I also tried encoding it with Deinterlace checked. This resulted in a file where the audio only exists for the first 10 seconds or so and is virtually unplayable because it freezes when you try to scroll. HOWEVER.... the video-only file that's produced in the same folder is flawless (unlike the muxed version).

I may have been in error above when I said there was no audio with the non-ivtc version. I did another encode with Force Film unchecked and Field Operations set to None -- and produced the best output so far. The audio is fine and the video plays smoothly. The only problem is that it appears to be interlaced. It's not that noticeable except with still frames, so I may just live with it. But there appears no perfect solution at this point.

I'm guessing that the original source was video tape with 29fps, which may be the problem.

In the Robot4rip log it said:
"Source is 0% film, threshold is 95%"
"Force Film not activated, IVTC or deinterlacing is still necesary"

Non-IVTC log is here.
Here's the log from the deinterlaced encode. As you can see, there are far fewer frame problems (difference =11) but the the resulting output has much more severe problems than the non-ivtc version where the difference was 37024.

jggimi · 20th February 2006, 18:54

Your log you describe as deinterlaced has a filename of ivtc-log.txt. It starts with a source which is 23.976 -- Force FILM was applied. You're going to get "jerky" motion with only 17.976 fps, if you're applying IVTC filters.

When I see logs that contain things like this:

Code:

3:55:57 PM: WARNING: Settings:      148148
3:55:57 PM: WARNING: Counted:       148137
3:55:57 PM: WARNING: Difference:    11

I always wonder if VdubMod ended early due to a failure. Check your System Log and Application Log in your Event Viewer -- see if there were any problems noted at times when VdubMod completed 1st or 2nd passes.

pojke · 20th February 2006, 21:09

The file was mislabeled. It actually is the deinterlaced log as noted in the post. Force film may have been applied.

From what you wrote, I'm assuming that no force film and deinterlaced are the best options? I'll try another encode with those settings and pay attention to the logs.

I wasn't able to find the 17.976 fps that you mentioned in the above logs.

pojke · 21st February 2006, 01:19

Success!

Unchecking Force Film and using Kernel Deinterlace seems to have solved all the issues.

Thanks for the help.

Below are the logs from the process that worked. Maybe it can help if anyone is having similar issues. One thing in the log stands out: There are still warnings that the counted frames differed from settings. The difference was 37024. Seems strange, but it worked, and that's what's important.

GK log
robot4rip log

jggimi · 21st February 2006, 02:43

In this latest GK log, it appears that settings are still not right:

Code:

Frames:             148148
FPS:                23.976

Either Force FILM was in use, or you improperly altered the framerate in the calculator. I'm guessing think its the latter, because further down in the log:

Code:

4:14:22 PM: WARNING: Settings:      148148
4:14:22 PM: WARNING: Counted:       185172
4:14:22 PM: WARNING: Difference:    37024

185172 / 29.97 = 6178 seconds, and 148148 / 23.976 = 6179 seconds.

Manually altering the framerate in GKnot's calculator from 29.97 to 23.976 would cause this type of warning message.

Even though the software discussed is old releases, I strongly recommend you read www.doom9.org/ivtc-tut.htm before experimenting further.

pojke · 21st February 2006, 04:12

Force Film was not checked in r4r.

If by the calculator you mean the drop-down box beside the project Open button, yes I changed it to 23.976 because of the Gordian Knot guide instructions.

When I was experimenting a few days ago I tried leaving it at 29, but got horrible results. I don't remember what other settings I used, however, so it's possible that was caused by an FF issue or something.

Are you suggesting that because of the frame warnings, the encode is of lower quality than it could be otherwise?

I will study the article.

jggimi · 21st February 2006, 14:57

Quote:

Are you suggesting that because of the frame warnings, the encode is of lower quality than it could be otherwise?

No, I'm saying your manual change is the reason for your warnings, and to stop doing it.

Your manual change affects calculations -- which will include b/p*f calculations and possibly the resulting bitrate -- but will not affect the framerate of the resulting encoding.

pojke · 21st February 2006, 23:52

OK, I encoded again, this time using no FF, 29fps, and deinterlace. There were no warnings, so apparently this is how it should have been done. Quality seems identical to the previous encode, so I'm not sure if it made much of a difference. The only oddity was that the %/quality box in the bits/(pixel*frame) section showed a lower number before encoding (turned red actually - 37.9) than when I had frames set to 23.976. I never encode when its red but I wanted the resolution the same as the previous encode. So the 37.9% seems to have worked as well as the 48%.

I think I've learned quite a bit from this. I just wish there were more definite and concise "if-then" instructions based on the various sources and how to know the source.

16th February 2006, 10:01	#1 \| Link
pojke Registered User Join Date: May 2004 Posts: 47	Video hesitates/jerks (r4r-GK-xvid) I've encoded a movie in Xvid using Robot4rip and Gordian Knot according to the guide. The video output is slightly jerky, as if frames have gotten stuck and suddenly jump 2 or 3 frames ahead. It's not always noticeable but with motion it usually happens. I've tried it with "auto force film" checked/unchecked and it seems to make no difference. In GK, under Field Operations the Inverse Telecine option is available in both instances. If I uncheck Inverse Telecine the video runs smoothly but there is no audio. Hopefully that's a clue to the solution since it solved the video issue. With the first encode, the log gave a warning: "Number of counted frames differs from settings!" Difference = 11 This isn't my first time with GK. I've used it many times with good results. Never anything like this.

20th February 2006, 18:54	#4 \| Link
jggimi Moderator Emeritus Join Date: Dec 2001 Location: The NW corner of Lake Erie Posts: 5,552	Your log you describe as deinterlaced has a filename of ivtc-log.txt. It starts with a source which is 23.976 -- Force FILM was applied. You're going to get "jerky" motion with only 17.976 fps, if you're applying IVTC filters. When I see logs that contain things like this: Code: 3:55:57 PM: WARNING: Settings: 148148 3:55:57 PM: WARNING: Counted: 148137 3:55:57 PM: WARNING: Difference: 11 I always wonder if VdubMod ended early due to a failure. Check your System Log and Application Log in your Event Viewer -- see if there were any problems noted at times when VdubMod completed 1st or 2nd passes.

21st February 2006, 02:43	#7 \| Link
jggimi Moderator Emeritus Join Date: Dec 2001 Location: The NW corner of Lake Erie Posts: 5,552	In this latest GK log, it appears that settings are still not right: Code: Frames: 148148 FPS: 23.976 Either Force FILM was in use, or you improperly altered the framerate in the calculator. I'm guessing think its the latter, because further down in the log: Code: 4:14:22 PM: WARNING: Settings: 148148 4:14:22 PM: WARNING: Counted: 185172 4:14:22 PM: WARNING: Difference: 37024 185172 / 29.97 = 6178 seconds, and 148148 / 23.976 = 6179 seconds. Manually altering the framerate in GKnot's calculator from 29.97 to 23.976 would cause this type of warning message. Even though the software discussed is old releases, I strongly recommend you read www.doom9.org/ivtc-tut.htm before experimenting further.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

19th February 2006, 18:03	#2 \| Link
jggimi Moderator Emeritus Join Date: Dec 2001 Location: The NW corner of Lake Erie Posts: 5,552

19th February 2006, 23:32	#3 \| Link
pojke Registered User Join Date: May 2004 Posts: 47	Update: I've been experimenting with FF, IVTC, FPS and deinterlacing. I found that using IVTC results in the jerking problem I mentioned above, no matter the other settings. I also tried encoding it with Deinterlace checked. This resulted in a file where the audio only exists for the first 10 seconds or so and is virtually unplayable because it freezes when you try to scroll. HOWEVER.... the video-only file that's produced in the same folder is flawless (unlike the muxed version). I may have been in error above when I said there was no audio with the non-ivtc version. I did another encode with Force Film unchecked and Field Operations set to None -- and produced the best output so far. The audio is fine and the video plays smoothly. The only problem is that it appears to be interlaced. It's not that noticeable except with still frames, so I may just live with it. But there appears no perfect solution at this point. I'm guessing that the original source was video tape with 29fps, which may be the problem. In the Robot4rip log it said: "Source is 0% film, threshold is 95%" "Force Film not activated, IVTC or deinterlacing is still necesary" Non-IVTC log is here. Here's the log from the deinterlaced encode. As you can see, there are far fewer frame problems (difference =11) but the the resulting output has much more severe problems than the non-ivtc version where the difference was 37024.

20th February 2006, 21:09	#5 \| Link
pojke Registered User Join Date: May 2004 Posts: 47	The file was mislabeled. It actually is the deinterlaced log as noted in the post. Force film may have been applied. From what you wrote, I'm assuming that no force film and deinterlaced are the best options? I'll try another encode with those settings and pay attention to the logs. I wasn't able to find the 17.976 fps that you mentioned in the above logs.

21st February 2006, 01:19	#6 \| Link
pojke Registered User Join Date: May 2004 Posts: 47	Success! Unchecking Force Film and using Kernel Deinterlace seems to have solved all the issues. Thanks for the help. Below are the logs from the process that worked. Maybe it can help if anyone is having similar issues. One thing in the log stands out: There are still warnings that the counted frames differed from settings. The difference was 37024. Seems strange, but it worked, and that's what's important. GK log robot4rip log

21st February 2006, 04:12	#8 \| Link
pojke Registered User Join Date: May 2004 Posts: 47	Force Film was not checked in r4r. If by the calculator you mean the drop-down box beside the project Open button, yes I changed it to 23.976 because of the Gordian Knot guide instructions. When I was experimenting a few days ago I tried leaving it at 29, but got horrible results. I don't remember what other settings I used, however, so it's possible that was caused by an FF issue or something. Are you suggesting that because of the frame warnings, the encode is of lower quality than it could be otherwise? I will study the article.

21st February 2006, 23:52	#10 \| Link
pojke Registered User Join Date: May 2004 Posts: 47	OK, I encoded again, this time using no FF, 29fps, and deinterlace. There were no warnings, so apparently this is how it should have been done. Quality seems identical to the previous encode, so I'm not sure if it made much of a difference. The only oddity was that the %/quality box in the bits/(pixelframe)* section showed a lower number before encoding (turned red actually - 37.9) than when I had frames set to 23.976. I never encode when its red but I wanted the resolution the same as the previous encode. So the 37.9% seems to have worked as well as the 48%. I think I've learned quite a bit from this. I just wish there were more definite and concise "if-then" instructions based on the various sources and how to know the source.