[x264] Why did this encode start off bad? I don't see what I set wrong.

[Redsandro]

x264 core:94 r1564 a927654

I am trying to get high quality in exchange for patience, but my overnight encode failed. I mean, in the end it was awesome, but it starts off with terrible seconds.
Then I tried again with slightly different parameters, and then it succeeds. Why?


Fail:
(I was trying to save time on the first pass)

avs2yuv.exe source.avs -o - | x264x64.exe --pass 1 --level 4.1 --no-8x8dct --me dia --partitions none --rc-lookahead 75 --ref 1 --subme 2 --trellis 0 --fast-pskip --output NUL - --demuxer y4m --b-pyramid 2 --keyint 24 --weightp 2 --direct auto

avs2yuv.exe source.avs -o - | x264x64.exe --pass 2 --level 4.1 --bitrate 8000 --preset placebo --tune grain --merange 32 --vbv-maxrate 40000 --vbv-bufsize 30000 --slices 4 --b-pyramid strict --keyint 24 --ref 4 --bframes 3 --nal-hrd vbr --aud --colormatrix "bt709" --sar 1:1 - --demuxer y4m --output out.264 --b-pyramid 2 --weightp 2

Win:

avs2yuv.exe source.avs -o - | x264x64.exe --pass 1 --level 4.1 --preset placebo --bitrate 8000 --b-pyramid strict --keyint 24 --min-keyint 2 --slices 4 --aud --nal-hrd vbr --output NUL - --demuxer y4m --me dia trellis 0 no-8x8dct --fast-pskip

avs2yuv.exe source.avs -o - | x264x64.exe --pass 2 --level 4.1 --preset placebo --bitrate 8000 --b-pyramid strict --keyint 24 --min-keyint 2 --slices 4 --aud --nal-hrd vbr --tune grain --merange 32 --vbv-maxrate 40000 --vbv-bufsize 30000 --colormatrix "bt709" --sar 1:1 - --demuxer y4m --output out.264

Which option is "mess up the first couple of seconds"?

[Dark Shikari]

Hard to say.  Messing with first pass options can cause mispredictions at the start of the second pass.

[misterh]

Just use the same settings for the first pass, only this time without placebo.
Should still be pretty darn fast.

[Redsandro]

But the missing of preset placebo in the fail example might suggest that it should be there in the first pass to fix those second pass prediction errors.

[JEEB]

Well, d'uh -- yes, you should use similar-as-possible settings and then add the fast-firstpass settings in case of --preset placebo. That way your encode should come up as intended instead of having completely different data and needs and measures to go by.

At least you know now. The main reason for me not to answer in that other thread was that because you could've just looked at the git shortlog and other stuff I linked for the answers (other than someone telling you explicitly to use as close as possible settings for both passes). I have no idea why you would just keep to some random 1st pass settings. But yeah, at least you know now :V

[foxyshadis]

I remember a commit from way back that fixed this issue in 1-pass abr mode, but there's no reason it should exist in 2-pass mode unless the stats file itself is incorrect, especially with rc-lookahead in there. AQ error perhaps? Default crf is 23, that might have something to do with it, but it was changes to ratetol and qcomp default settings that fixed ABR.

[JEEB]

I remember a commit from way back that fixed this issue in 1-pass abr mode, but there's no reason it should exist in 2-pass mode unless the stats file itself is incorrect, especially with rc-lookahead in there. AQ error perhaps? Default crf is 23, that might have something to do with it, but it was changes to ratetol and qcomp default settings that fixed ABR.

In my opinion this is just a case of settings differing enough to set x264 onto wrong tracks at first, which then get fixed with time, I guess. Of course not a perfect piece of reasoning, but he did go somewhat off tracks with his settings.

[Dark Shikari]

I remember a commit from way back that fixed this issue in 1-pass abr mode, but there's no reason it should exist in 2-pass mode unless the stats file itself is incorrect, especially with rc-lookahead in there. AQ error perhaps? Default crf is 23, that might have something to do with it, but it was changes to ratetol and qcomp default settings that fixed ABR.

If your first pass settings result in 0.8x the bitrate at the same quantizer than second pass, then at the start of the second pass, the encoder will jump up the quantizer accordingly.  This can be much more dramatic if you have, for example, a grainy scene right at the start that gets decimated on the first pass but not on the second, resulting in a much more insane multiplier.

This rarely causes problems, but that doesn't mean that it never does.

[Redsandro]

Not random! Specifying my needs (keyint 24) and trying to make 1st pass faster.
But okay, at least I know now to keep them as similar as possible to prevent this. Thanks for that.

As a side note, actually I did look at the links and I did think my first parameters weren't a problem. The problem is that I don't see the source code and litteral logic behind it every day. In fact, like most users, I haven't got a clue how x264 actually works apart from the basic ideas of prediction, compensation and GOP. And that first pass gives a rough encoding idea and second pass is where the grinding happens.

So where it seems completely and utterly logical for most coders where to use what setting, I find it weird that x264 --fullhelp doesn't specify what goes in first or second or must be in both. Where most documentation would not assume important stuff like this is just known, x264 let's you know only after you completed the first pass. For example, the first was my idea of quick pass and a grinding second pass:

--pass 1 --level 4.1 --no-8x8dct --me dia --partitions none --ref 1 --subme 2 --trellis 0 --fast-pskip --output NUL - --demuxer y4m
--pass 2 --level 4.1 --bitrate 8000 --preset placebo --tune film, grain --rc-lookahead 250 --merange 32 --vbv-maxrate 40000 --vbv-bufsize 30000 --slices 4 --b-pyramid strict --keyint 24 --ref 4 --bframes 3 --nal-hrd vbr --weightp 0 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 - --demuxer y4m --output out.264

x264 [error]: different wpredp setting than first pass (0 vs 2) (What's that? Never mentioned in documentation. (Patched by Dark Shikari now))

'' -wpredp 2

x264 [error]: invalid argument: pass = redp

'' -weightp 2

x264 [error]: different b_pyramid setting than first pass (1 vs 2) (I didn't specify)

'' --b-pyramid 2

x264 [warning]: only 1 psy tuning can be used: ignoring tune grain (My mistake, pretty much every tuning is a psy tuning, you can find this in the full help)

'' --tune grain

x264 [warning]: direct should be auto in first pass

And more of that, I didn't keep logs.

After all the errors and warnings, I decided to go to on #x264 to verify settings first.
The first 'fail' example, the one that made JEEB think that maybe this topic was a little bit too stupid for his reply, was actually what was suggested on IRC. Come on a guy can only be that stupid before he is unworthy of replies, right?

[Dark Shikari]

Not random! Specifying my needs (keyint 24) and trying to make 1st pass faster.
But okay, at least I know now to keep them as similar as possible to prevent this. Thanks for that.

As a side note, actually I did look at the links and I did think my first parameters weren't a problem. The problem is that I don't see the source code and litteral logic behind it every day. In fact, like most users, I haven't got a clue how x264 actually works apart from the basic ideas of prediction, compensation and GOP. And that first pass gives a rough encoding idea and second pass is where the grinding happens.

So where it seems completely and utterly logical for most coders where to use what setting, I find it weird that x264 --fullhelp doesn't specify what goes in first or second or must be in both. Where most documentation would not assume important stuff like this is just known, x264 let's you know only after you completed the first pass. For example, the first was my idea of quick pass and a grinding second pass:

There's a simple rule to avoid all this: stop varying settings between passes.  If you want the first pass to go faster, don't use placebo, period.

None of this causes any problems for users unless they try to mess with things they shouldn't be touching in the first place.  Messing with low-level options is intended for "coders" only: if you don't know what they do, don't touch them.

[Redsandro]

I've been using x264 since before there were all this presets tunings and stuff, when 'Low-level options' were just 'options'. It was never a problem. Only now I try to push things, ironically first time I try to use a preset. I made a mistake and I was wondering the exact cause. If you're not sure beyond the first reply, that's okay.

But please don't be all doom9 and draw a line between 'coders' and 'common people'. If we would all live by the idea of "if you don't know what they do, don't touch them", we would all still be monkeys.

Agreed to the bottom line:

stop varying settings between passes.  If you want the first pass to go faster, don't use placebo

[Redsandro]

This topic just gave me an idea.

Maybe there can be a non-psy tuning for BLURAY? It would add such settings as --b-pyramid strict --keyint 24 --min-keyint 2 --slices 4 --nal-hrd vbr, and common people can now also create blu-ray compliant streams without taking an interest in low-level options.

[Dark Shikari]

This topic just gave me an idea.

Maybe there can be a non-psy tuning for BLURAY? It would add such settings as --b-pyramid strict --keyint 24 --min-keyint 2 --slices 4 --nal-hrd vbr, and common people can now also create blu-ray compliant streams without taking an interest in low-level options.

This is an eventual plan.  We're going to add --device for this purpose; I'm busy with exams right now, but once summer comes around I'll finish work on it.

[Redsandro]

--device, I like it.
Good luck on your exams!