credits using GKnot and Xvid

[sierrafoxtrot]

i know that appending credits created through 1-pass quality Xvid encoding to the rest of the movie seems to give a lot of grief ... :confused: so, would it be possible to scale the credits frames using stats file editor in GKnot (ie give it 2% weighting or something)? i'll try this overnight and report lack laters ...

cheers

[Peters]

No pb for me using aviutl for joining movie to credits.

[Ripe73]

HI!
I did the endcredits with Xvid and used CBR quality(200KB) and low moton search precision=12MB:)
And i did the same credit with DivX 3.11(200KB)=28MB:scared:
Thats Good

[-h]

I did the endcredits with Xvid and used CBR quality(200KB) and low moton search precision=12MB:)

You'd get better looking credits if you set the motion search precision to the highest setting - the lower settings let the codec get away with 'worse results' - higher precision gives you smaller files, or better quality per unit of file size.

On another note - would people like a credits option in XviD itself?

-h

[sierrafoxtrot]

credits option?!! hell yes!

[-h]

Well credits will require a chunk of new code (i.e. not the hack that the internal 2-pass was ;)) - is there anything else 2-pass related that people would want? Remember I'm not looking to stick GKnot inside of XviD itself - extensive .stats mods should stay with external tools.

-h

[rui]

Here goes my vote for credits too :)

Regarding the join the movie avi with the credits avi question: i assume that, after reading all this posts, Vdub 1.4.8 can't join them, right? I didn't tried it yet myself. Only the AviUtil can do this?
And: in the Gnot stats file editor there is a box called credits: start frame. Is this of any use for the credits avs created using Gnot? Or am i way off ? :)
As you probably already noticed, i am not a divx guru ;)
In the guide -h posted (its very good, a newbie like me could understand it all) this credits stuff is missing. Maybe you could make an update? Just an idea.;)

[Head Hunter]

I don't know about joining the 1-pass constant quality credits in V-Dub, but Nandub does it just fine.

[Peters]

A little precision.

Last version of aviutl (0.97a) doesn't work for joining credits (just a 2k file in output)

0.96g or 0.96i is fine

[rui]

Originally posted by Head Hunter
I don't know about joining the 1-pass constant quality credits in V-Dub, but Nandub does it just fine.

Ok, so Nandub it will be

[sierrafoxtrot]

here's another pickle ... encoded credits for taxi driver (Constant quality 35% MinQ 5 MaxQ 25) so that i could append to the movie. did the 1st pass with VDub. and then one second pass with Gknot processed stats file, and the other with Xvid's internal stats encoding control. the wierd thing is that Nandub will append the credits to the Gknot second pass but not Xvid's internally generated one.

anyone else notice this sort of behaviour?

[rui]

One question about the second pass with credits using Gnot, just to be sure:
I must put in the Bitrate tab in Gnot the size of the audio file. I must also put in the little box that says “files” the size of the credits file, correct? Just then i should press calculate in the Stats File Editor, right?
I believe that this way Gnot calculates the curve taking in consideration both the audio size and credits size, correct?
Doom9's guide isn't clear about this.
Please correct me if i am wrong.

[Ripe73]

Originally posted by rui
One question about the second pass with credits using Gnot, just to be sure:
I must put in the Bitrate tab in Gnot the size of the audio file. I must also put in the little box that says “files” the size of the credits file, correct? Just then i should press calculate in the Stats File Editor, right?
I believe that this way Gnot calculates the curve taking in consideration both the audio size and credits size, correct?
Doom9's guide isn't clear about this.
Please correct me if i am wrong.
HI!
You must change the movieframes in GKnot too or when you load the statsfile in GKnot says"enter number of frames" answer yes:)

[rui]

Thanks! :)

[Foo]

"anyone else notice this sort of behaviour?"

Haven't noticed that specific one, but there seem to be some general issues in this arena :). For instance, I went back and ran Smart Deinterlace over a few frames to clean up a scene change. Original encode, and the little fix were done using the same settings. But neither Nandub nor Vdub would append the files, resulting in the "different formats" warning (which naturally isn't right). But Aviutl joined them perfectly :D .

[Koepi]

to -h:

anything else for 2-pass? ;)
I posted over at videocoging.de but never got any answer from the developers, but just from users telling me something like "use a player"...

Just in short:
Is it possible to add something like "lossless" stretch-y-by-2? So if i capture 640x240 (my cpu can handle that at max) that i tell the codec: instead of block size 16x16 ("input size") write 16x32 ("output size") now (should be possible on first pass already as well with no big cpu power needed).

Well, or at least try to answer me if that is possible at all or if the blocks in a fame are fixed-size 16x16 or 16x8 or anything?

Hell, I'm working with so much projects now that I don't find the time to take a closer look at XviD sources as well :-/

Please, please, please, do me the favor and try to consider this. I can't tell anyone else to "use this filter or that player and set aspect ratio blabla" since they won't understand what I'm talking about.

Sorry for this pleading :)

Best regards,
Koepi

[-h]

The problem is, there's nowhere in the (compliant) bitstream we can store such a flag (such block sizes are not standards-compliant). It wouldn't be a codec modification as such either, but a nearest neighbour filter tacked onto the end of the decode sequence, that copies the output buffer to the calling program. Since it couldn't be stored in the bitstream, the person would have to tick a checkbox in the XviD dshow properties to enable "post-decode resize y*2" or whatever it'd be called. Since it's another manual step, it might be easier to use a different player..

The only way it could be implemented "properly", is if (when) XviD supports field-based encoding - you could store the 640x240 frame as the first field, then set the 'not coded' flag for the second field - the codec would then do a block copy of the first field into the second field, and you'd have your 2*y resized image. This could be a simple "duplicate first field" checkbox.

Of course, field support is probably a while off, and I'm not even sure if the not-coded flag works between fields (as opposed to frames). So it's all up in the air really.

-h

[Koepi]

Thank you for the insights, -h :)

At least I now understand what I'm fiddling with. (Well, since the codec compresses blocks (motion blocks, keyblocks, ...) I thought there is such data stored as well - but I can admit that I didn't think enough in this case).

The field based attempt seems to exactly be what I want to do :) So I just have to wait ;))

Thanks again,

best regards,
Koepi