2-pass internal or external?

[Head Hunter]

Is there any difference in quality between 2-pass encoding with XviD using the built in curve calculation or Gknot only unchecking motion correction and luma masking?

[-h]

Nope, all they do is linearly scale the bitrate curve to reach the desired file size. I don't believe GKnot does anything differently during this stage.

With GKnot, however, you get an option to specify a different bitrate for the credits, giving more bits to the main movie. I'll add another text box to XviD today probably, that lets you enter a desired size or something for the credits.

The only problem with letting people specify a different bitrate for the credits is that, if the codec can't actually compress the movie as small as the person wants, you're going to see bitrate overflow, and the finished encode will be larger than expected (through no fault of the codec - you just can't fit the credits into 50 KB).

We'll see. I personally think the codec's main tab is getting far too crowded / multipurpose as well. But I just don't know where to put everything.

-h

[Head Hunter]

Why not just let have people use 2 frameservers and join them together like Gknot does? That way you don't have to worry about bitrate overflow. They just have to remember to subtract the credits size from the total video size. I did this last night and my movie came out to 700 megs.

P.S. Thanks for clarifying that there is no difference, now I can let both passes run overnight instead of waiting to wake up to start a second one.

[-h]

Quite a few people seem interested in an integrated system, and coding it would make me "fix" the hacky Int. code I made so that it'd be easier to include any future tweaks. Currently, the codec doesn't even know what frame it's up to.

Plus it's a good way to ignore other things I should be working on.

-h

[Teegedeck]

If you compare the debugview .logs of the internal and GKnot's 2nd pass, you realize that there are differences, but they aren't crucial. In fact, the internal 2nd pass works much better than I expected (Xiphrom produced some gross errors for me, don't know why). First difference, the int.2-pass doesn't care about a minimum bitrate the way GKnot does (GKnot won't downsize a very small frame at all). In contrast to DivX3.11, this doesn't seem to hurt XviD in any way. Second difference, some frames that receive quants, say, 9-8-8-7 in GKnot will get 10-7-7-7 in int.2-pass and vice versa. I don't see any general rules here - the main thing is that none of the 2 methods makes bad quant-decisions (1-22-5-5-...). So, as I always use a separate .avs for the credits, I'm thinking of using the internal 2-pass more often from now on.

[Teegedeck]

Would be kind of a mock solution, but anyway:
- credits get encoded in 1st pass at a user-defined quant
- a credits.avi is produced in 1st pass
- credits' filesize gets substracted from desired filesize in 2nd pass automatically
- credits' bitstream is discarded in 2nd pass

It would save some time and be a bit easier than encoding credits separately, but the user would have to join the .avis manually.

[-h]

Hmm that's odd. I can only guess that the scaling GKnot does is being skewed by the minumum bitrate decision, and any curve smoothing it does?

Internally, all the codec does is use the difference between the 1st pass frame size and the desired frame size to decide on a quantizer (taking under/overflow into account) - that decision is the same whether the desired size was decided by GKnot, or the internal scaler.

The integrated system does appear to behave itself, though GKnot is always there for using bells and whistles.

Re: credits - that'd save encoding time, but joining avis that large is still a royal pain ;) Having that in the codec might take the user just as long as using a pair of .avs scripts, considering the join afterwards.

-h

[Teegedeck]

Hm? Oh, I didn't even think the codec could auto-join the files.

But do you, too, think it makes sense to have fixed quant for the credits in both passes?

[-h]

Oh my intention was to allow the user to specfify the desired size or percentage for the credits, and the codec would switch to the increased compression as soon as it hit the credits in the second pass.

Seems it'd make more sense to allow the user to enter a fixed quantizer though - the codec could then use it in the first pass, and already know exactly how much size it'll be allocating in the second pass. Heck that'll make it much simpler! I'm still gonna have to stick these extra options somewhere. I should make a 2-pass tab.

-h

[Teegedeck]

All this is similar to one method suggested in GKnot's integrated help, no 'credit' I can take for it... ;)

[rui]

Regarding the 2 pass internal or external. If you guys say that there isn't any difference, I maybe start using the internal one, and do like Head Hunter says.
This way one can use the job feature in Vdub and, after doing the audio and credits parts, start the movie and only get back to it when it’s all done.
The credits feature would be nice, because as it is I must subtract from the 700Mb (for 1 cd), the size of the audio and the size of the credits.
Or I am just being lazy…;)

[Koepi]

Uh uh uh! I've to say something! ;)

When you're on to it anyways, can you make it a "full blown bitrate calculator"? Say, you can choose the filesize for the movie part now.
Why not make it so, that you just say "1 CD, 2 CD", "650MB, 700mb", "Audio filesize" or "Audio Bitrate"? Let's say, I used ogg at qual 0.01. The bitrate is 57kbps real, 64kbps nominal(well, nomial doesn't matter, but I was impressed ;) ). I'd like to fit the movie on 1 700 mb media...
Wouldn't be hard to implement I'd say, it's mostly GUI stuff.

Any chance to make it this way, when you do add a second pass tab? (I would even do the GUI stuff if you can't spare the time for that - but since I'm not familiar with the codec's code I think I can't implement the whole calculation stuff).

...just an idea :)

Thanks for your time,

best regards,
Koepi

[Head Hunter]

rui:
If you use Gknot to figure out the filesize, once the audio and credits are done you can select the actual MP3 file you made along with the overhead. Then look below total file size and average bitrate, you will see video size. Just subtract credits size from that number and you will get the most accurate/easiest way to calculate the main movie file size.

[-h]

When you're on to it anyways, can you make it a "full blown bitrate calculator"? Say, you can choose the filesize for the movie part now.
Why not make it so, that you just say "1 CD, 2 CD", "650MB, 700mb", "Audio filesize" or "Audio Bitrate"? Let's say, I used ogg at qual 0.01. The bitrate is 57kbps real, 64kbps nominal(well, nomial doesn't matter, but I was impressed ;) ). I'd like to fit the movie on 1 700 mb media...
Wouldn't be hard to implement I'd say, it's mostly GUI stuff.

Man.. that's so lazy ;)

At the moment the tab will have:

- desired file size
- quantizer for credits
- credits starting frame
- 1st/2nd pass stats files

I could add an audio field.. but then I'd have to worry about the overhead. And I am a lazy guy :)

-h

[Doom9]

I don't think audio has anything to do in the config dialogue of a video codec. Gknot will eventually do it all anyways..

[Head Hunter]

What quanitizer is similar to 50% quality?

[Foo]

Originally posted by -h
At the moment the tab will have:

- desired file size
- quantizer for credits
- credits starting frame
- 1st/2nd pass stats files

I could add an audio field.. but then I'd have to worry about the overhead. And I [i]am a lazy guy :)

-h

This would be excellent. I already really like certain choices that were made, like a target file size vs. an average bitrate. Same result, but more logical IMO :D . I'm with Doom about the (lack of) need for any audio conisderations here.

foo

[Koepi]

Why are the people always insisting on the use of GKnot? I don't want to use it :P

Regards,
Koepi

[rui]

Originally posted by Head Hunter
rui:
If you use Gknot to figure out the filesize, once the audio and credits are done you can select the actual MP3 file you made along with the overhead. Then look below total file size and average bitrate, you will see video size. Just subtract credits size from that number and you will get the most accurate/easiest way to calculate the main movie file size.

Thanks. I actually load in the bitrate tab of Gnot the credits file, so the video size Gnot gives me already takes in consideration both the audio and credits.

To Koepi: Gnot makes a lot less trouble this "encoding business". :)
I like to start the encoding and only return to it when its all done.
Of course right now this only works on divx3 or divx4. With XviD i am only using Gnot to prepare the avs, do the audio and give me the final video size.

[Head Hunter]

Thanks for the tip, saves me some extra work.