GKnot/XVID issues

[lam_das]

I have currently two issues with using XVID via Gordian Knot. And I am not sure if its XVID problem or GKnot problem.

1. Color depth is not always 24 bits on the resulting video. Its 12-bit most of the time as reported by XP file properties. VirtualDubMod prefs say its 24-bit by default.
2. The brightness of the resulting video has to be adjusted in WMP. Otherwise its always darker than normal.

I am new to GKnot and XVID. Can anybody explain these to me and suggest a remedy?

Thanks a lot, I appreciate your time.

[trance]

Search for "sample rate" and you'll find out that the number displayed doesn't affect the movie. Its just a number but the quality are the same.

As for the darkness, for me anyways, is because my monitor's brigthness is set to 50% (because setting it high can hurt your eyes).

[manono]

Hi-

1. XP is wrong-it's 24 bit.
2. If the movies come out too dark for your tastes, one remedy is to edit the .avs before encoding and add this line:

Tweak(Bright=10)

Adjust the number to suit yourself. 0 is no change, and 255 is max. Open the .avs in VDubMod before encoding and see if it's bright enough for you. Or you can just adjust the brightness permanently in the Overlay control for your video card.

[Koepi]

a) brightness is a matter of your drivers/overlay settings.
NVIDIA and S3 usually mess up there. Programs like WinDVD etc. compensate for that, windows media player 8and any directshow based player) don't care about that and leave the adjustment to the user.

(so it's your fault ;) ).

b) sorry to correct manono, but _every_ mpeg[1|2|4] codec stores data internally as YV12 data. This means it is 12 bits. If your winblows reports something else - stop complaining here, but contact microsoft to fix their buggy software.

Sorry, couldn't help the rude sound of this post, but these questions have been asked very often and are really simple to search for within 5 minutes.

regards
Koepi

[lam_das]

OK, thanks for your reply guys. Next time I will use the advanced search. sorry if I bothered anybody with my silly questions.

thanks again.

[manono]

Thanks Koepi-learn something new every day.

At least I got the overlay part right. :)

[sysKin]

Originally posted by Koepi
This means it is 12 bits. If your winblows reports something else - stop complaining here, but contact microsoft to fix their buggy software.
Actually, there is one more thing. What I discovered is that the bpp value is written to avi header. Most likely this is the value shown by winXP.
If virtualdub(mod) is set to 'full processing mode', it sets bpp to 24 bit. If VD uses 'fast recompress', it sets this value to 16 bit. Finally, VDM @fast sets it to 12 bits.

This causes problems - two identical video streams will be incompatible for appending because of it. IMHO it's plain stupid ;)

Regards,
Radek

[Nic]

Yup syskin is right, its problem that Avery Lee once discussed on his webpage.

And koepi is right its always YV12 (unless using some very high bitrate studio mpeg-2 where it could be 4:2:2) :)

Cheers,
-Nic

[lam_das]

>> If virtualdub(mod) is set to 'full processing mode', it sets bpp to 24 bit.
>>If VD uses 'fast recompress', it sets this value to 16 bit. Finally, VDM @fast sets it to 12 bits.

Actually according to GKnot log and lastjob VCF file, it says it had done mode 1 (fast recompress) and final bpp is 12. How does GKnot determine that it has to do fast recompress rather than full processing? There is no option to set that. My VDM settings are by default at mode 3.

Log file has:

...
...setDepth(24, 24);
...setMode(1);
...

for both passes.

Appreciate your time.

[sysKin]

Originally posted by lam_das
How does GKnot determine that it has to do fast recompress rather than full processing? There is no option to set that. My VDM settings are by default at mode 3.It's just common sense to use 'fast' whenever possible - it's much much faster, and gives higher quality. There is no reason fo GK to use anything else.

Radek

[Blueseb]

This causes problems - two identical video streams will be incompatible for appending because of it.

yeah, exactly the problem I have :angry:
does anybody knows a hack to resolve this without re-encoding one of the two streams?

[EDIT]
I found this thread (http://forum.doom9.org/showthread.php?s=&threadid=57221) then using vdubmod hex editor I changed the AVI header according to it, but still didn't work; analyzing the header i found that bSizeImage flags mismatched: changin' both bBitCount & bSizeImage flags resolved the problem :p