Any quality compromises in one pass encoding?

[lchiu7]

I am in the process of backing up my HD-DVD titles so that in case my Toshiba drive dies, I can still watch the titles :-)

I am not concerned about encoding to a specific size since anything from 4-7G would be fine for me. Using two pass and the Xbox306/PS3 profile it takes almost 20 hours to to an encode (to be sure this is a modest AMD64 X2 3600).

I have taken that profile and changed it from two pass to ABR 5000bps and now the encodes take about 6-7 hours with the final titles ranging as noted from 4-7G. What am I losing by not running an analysis pass first apart from space efficiency (which I don't really mind)? Much prefer to get some time back!

Basically this is the x264 command line that is being executed

program --bitrate 4500 --level 4.1 --bframes 3 --weightb --direct auto --subme 5 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 24000 --vbv-maxrate 24000 --qcomp 0.5 --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input"

Thanks for any ideas on this

Larry

[Atak_Snajpera]

You have chosen the worst options among all. You should use CRF!!!! I would start with 22.

[Dark Shikari]

I have taken that profile and changed it from two pass to ABR 5000bps and now the encodes take about 6-7 hours with the final titles ranging as noted from 4-7G. What am I losing by not running an analysis pass first apart from space efficiency (which I don't really mind)? Much prefer to get some time back!One-pass VBV quality is vastly inferior to twopass VBV.

program --bitrate 4500 --level 4.1 --bframes 3 --weightb --direct auto --subme 5 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 24000 --vbv-maxrate 24000 --qcomp 0.5 --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input" If the first pass was taking that long, your settings for the first pass were way too slow. Also, stop messing with things; leave ipratio, pbratio, and qcomp on the defaults.

If you need a fast first-pass, try

--bitrate 4500 --bframes 3 --subme 1 --partitions none --vbv-bufsize 24000 --vbv-maxrate 24000 --threads auto --me dia --progress --no-psnr --no-ssim --output "output" "input"

You have chosen the worst options among all. You should use CRF!!!! I would start with 22.Please stop recommending CRF with VBV.

[Guest]

One-pass VBV quality is vastly inferior to twopass VBV. Amen, bro! I discovered that the hard way. :)

[lchiu7]

One-pass VBV quality is vastly inferior to twopass VBV.

If the first pass was taking that long, your settings for the first pass were way too slow. Also, stop messing with things; leave ipratio, pbratio, and qcomp on the defaults.

If you need a fast first-pass, try

--bitrate 4500 --bframes 3 --subme 1 --partitions none --vbv-bufsize 24000 --vbv-maxrate 24000 --threads auto --me dia --progress --no-psnr --no-ssim --output "output" "input"

Please stop recommending CRF with VBV.

Actually all I did was initially use the default profile Standalone-PS3-Xbox360_Fast profile. This is for something to be played on a Popcorn Hour. That took about 5-6 hours pass one and 15+ hours pass 2. I then just modified the profile from automated two pass and changed the bit rate to 4500. Now that runs in about 8 hours. Have I compromised something there?

The command line you have provided above - is that one pass or a fast one pass for a two pass encode?

[Guest]

When he talks about first pass, you can assume he intends a second pass.

[lchiu7]

When he talks about first pass, you can assume he intends a second pass.

I guess so given the points made about VBV one pass is vastly inferior to VBV two pass. Just have to work out how to that in a megui profile

[Guest]

Use CLI. It's trivially easy. Or make your own profile based on it.

[Esurnir]

Use CLI. It's trivially easy. Or make your own profile based on it.

What he said, in my case I still use megui... I put up a configuration, tweak it and copy and paste the resulting commandline.

[lchiu7]

OK - I get it but I am stymied by one thing. I choose a profile which has two pass. Then for 2pass - 1st pass I turn off the macroblock options as suggested --partitions none. I can see that reflected in the command line. Then choose 2pass - 2nd pass and choose say --partitions p8x8,b8x8,i4x4 The command line reflects the options but the change has also been been made to 2pass - 1st pass. Not entirely sure how to use Megui to run two different command lines, one for each pass

[audyovydeo]

passes

the only good reason for doing two passes is to target a final size. And you said in your first post that size isn't important to you.


but, most importantly, have you checked if any of your HD-DVD titles are already in H.264 ? In that case you could spare yourself the reencoding time.


cheers
audyovydeo

[lchiu7]

the only good reason for doing to passes is to target a final size. And you said in your first post that size isn't important to you.


but, most importantly, have you checked if any of your HD-DVD titles are already in H.264 ? In that case you could spare yourself the reencoding time.


cheers
audyovydeo

That's what I thought about passes. If I have a generous bit rate like 5000bps and I reduce the AR to 1280x720 then one pass should do the trick.

Some of my HD-DVD titles do have H.264 but most seem to be VC1. AVC, H.264 and VC1 all play fine on the Popcorn Hour so the only processing required is to re-encode the audio to AC3 (from DD+ or Dolby TrueHD). since the Popcorn can't play those formats (well it could play them as PCM but that means another 6G of audio data!)

But since I want to put them on a server and stream over a wireless network, I need to get them down from 1080p to 720p and from 15-20G to about 6-7G. Hence the compression. Don't mind a slight quality loss since after all, I do still have the original disks but I am not obsessed with a target size, like a DVD5.

[Sagittaire]

Amen, bro! I discovered that the hard way. :)

Not in all case. In general case (work for all codec) 2 pass VBV is really better than 1 pass VBV only if average bitrate is close to max bitrate.

I have serious doubt here that 2 pass increase VBV compliance and quality with --bitrate 4500 --vbv-bufsize 24000 --vbv-maxrate 24000 simply because the RC will be probaly not constrained by VBV (ratio 1:5 for average/max with really large buffer).

[Dark Shikari]

Not in all case. In general case (work for all codec) 2 pass VBV is really better than 1 pass VBV only if average bitrate is close to max bitrate.

I have serious doubt here that 2 pass increase VBV compliance and quality with --bitrate 4500 --vbv-bufsize 24000 --vbv-maxrate 24000 simply because the RC will be probaly not constrained by VBV (ratio 1:5 for average/max with really large buffer).This is a good point--while 2pass VBV does guarantee avoidance of any localized hiccups, I'm not sure how much those would actually occur at this high a ratio of maxrate to bitrate.

[Guest]

For broadcast and streaming the average and maximum are close. There is not enough bandwidth to support a large maximum. If you have unlimited bandwidth, you might as well use CRF.

[Guest]

the only good reason for doing two passes is to target a final size Not true. You also need it when encoding for VBV compliance in broadcast and streaming applications.

[Dark Shikari]

Not true. You also need it when encoding for VBV compliance in broadcast and streaming applications.You don't need it for VBV compliance; x264 is perfectly capable of doing VBV in one-pass mode. However, it helps the quality of that VBV compliance.

[Guest]

Uh, yeah, if you don't care about getting crappy output, you can use one-pass in such cases. The thread *is* about quality compromises, but your nitpick is nevertheless appreciated.

[JohannesL]

the only good reason for doing two passes is to target a final size.
Please don't spread crude misinformation like this. A while ago, I did a 3-pass encode of a low motion SNES game and found 150kbps to be practically transparent. Now, I tested CRF, and CRF=22 came out 170kbps. To get the same bitrate as the 3-pass encode, I had to use CRF=24, and it looked MUCH worse than the 3-pass encode, especially the first second. Multipass does achieve a better quality to size ratio than CRF, even if it's not always important.
In case you're wondering, these are the command lines I used:

pass=1:bitrate=150:partitions=all:me=umh:me_range=24:subq=9:direct_pred=auto:frameref=16:bframes=8:b_pyramid:b_adapt=2:weight_b:mixed_refs:trellis=2:nofast_pskip:8x8dct:ratetol=30:aq_strength=0.7:psy-rd=0.6,0.1:threads=auto:turbo=2
pass=3:bitrate=150:partitions=all:me=umh:me_range=24:subq=9:direct_pred=auto:frameref=16:bframes=8:b_pyramid:b_adapt=2:weight_b:mixed_refs:trellis=2:nofast_pskip:8x8dct:ratetol=30:aq_strength=0.7:psy-rd=0.6,0.1:threads=auto
pass=3:bitrate=150:partitions=all:me=umh:me_range=24:subq=9:direct_pred=auto:frameref=16:bframes=8:b_pyramid:b_adapt=2:weight_b:mixed_refs:trellis=2:nofast_pskip:8x8dct:ratetol=30:aq_strength=0.7:psy-rd=0.6,0.1:threads=auto

crf=24:bitrate=150:partitions=all:me=umh:me_range=24:subq=9:direct_pred=auto:frameref=16:bframes=8:b_pyramid:b_adapt=2:weight_b:mixed_refs:trellis=2:nofast_pskip:8x8dct:cabac:ratetol=30:aq_strength=0.7:psy-rd=0.6,0.1:threads=auto

[Dark Shikari]

Multipass does achieve a better quality to size ratio than CRF, even if it's not always important.No, actually, it doesn't. If it does, it's a bug, because 2pass and CRF use identical ratecontrol algorithms.

[Manao]

If it does, it's a bug, because 2pass and CRF use identical ratecontrol algorithms.Huh ? I thought one used SATD and the other one used first pass size ?

[JohannesL]

It should also be noted that the third pass had a huge quality gain in that case. Every scene with motion looked horrible in the output of the second pass. Probably because of the turbo=2.

[Chengbin]

It should also be noted that the third pass had a huge quality gain in that case. Every scene with motion looked horrible in the output of the second pass. Probably because of the turbo=2.

I thought third pass has no quality improvements. It is only if you're looking to hit a specific file size.

[JohannesL]

I thought third pass has no quality improvements. It is only if you're looking to hit a specific file size.
You were wrong. It helps with very low bitrates. Even if it's high enough for the video to look good.

[audyovydeo]

Please don't spread crude misinformation like this. A while ago, I did a 3-pass encode of a low motion SNES game and found 150kbps to be practically transparent. Now, I tested CRF, and CRF=22 came out 170kbps. To get the same bitrate as the 3-pass encode, I had to use CRF=24, and it looked MUCH worse than the 3-pass encode, especially the first second. Multipass does achieve a better quality to size ratio than CRF, even if it's not always important.
In case you're wondering, these are the command lines I used:

you're a natural candidate for the State dept.

My own testing has long since shown me that it makes no measurable difference, which is why I dumped n-pass altogether.
I should point out that I measure quality by SSIM (having read any and all arguments about the limits of this). I consider the "visual check of a video clip by a handful of geographically dispersed people with different video cards, video card settings, players, monitors and monitor technologies" as an unscientific method of measuring video quality.

cheers
audyovydeo

[7oby]

One-pass VBV quality is vastly inferior to twopass VBV.
[...]
Please stop recommending CRF with VBV.
Thanks!

I think I can image where this often comes from: You select one of the DXVA compliant encoding profiles. Then you think: Well I know CRF ist great and put that into the command line.

What's the most efficient way of encoding DXVA compliant stuff when you are comfortable with a certain CRF level? And don't care that much about the target size.

[Sagittaire]

You were wrong. It helps with very low bitrates. Even if it's high enough for the video to look good.

at the same bitrate crf mode and Npass produce the same quality. Npass are just Rate Control refinement (with better prediction stat file) and not supplementary search (if you use same profil between pass).

IMO crf mode produce even better quality because the frame type decision is always optimal in this case (perhaps not always the case with first pass turbo mode in multipass).

[akupenguin]

crf=24:bitrate=150
There's your problem. You used 1pass ABR, not CRF. (Later options on the commandline override earlier conflicting options).
You should also have noticed something was wrong if you thought that CRF22 was 170kbit while CRF24 was 150kbit. Because 170/150 = 1.13 = 2^(1/6), which is 1 point of CRF not 2.

[Dark Shikari]

Huh ? I thought one used SATD and the other one used first pass size ?Yes, but both are input to the same overall algorithm.

[JohannesL]

There's your problem. You used 1pass ABR, not CRF. (Later options on the commandline override earlier conflicting options).

Wow, how the hell did I miss that?!
I feel like an idiot now..
Will update when the (actual) CRF encode finishes.
Edit: CRF=22 is 111kbps with ugly fades. In particular, after the fades, the image is really blurry for some frames, and then suddenly sharpens. This is not present at all in the 150kbps 3-pass. I thought the CRF value didn't need content dependent altering.

[Manao]

Yes, but both are input to the same overall algorithm. The same stands true for SAD and RD in an exhaustive ME, yet they give different quality.

[Dark Shikari]

The same stands true for SAD and RD in an exhaustive ME, yet they give different quality.But those are for a single block. In practice, with a whole frame, I find there is no significant difference between SATD and real bit cost. If anything, SATD might be better.

Remember the law of large numbers--the larger the block, the smaller the % difference between RD and other metrics.

[nurbs]

Edit: CRF=22 is 111kbps with ugly fades. In particular, after the fades, the image is really blurry for some frames, and then suddenly sharpens. This is not present at all in the 150kbps 3-pass. I thought the CRF value didn't need content dependent altering.

If crf 22 gives you 111kbps then 150 kbps is somewhere between crf 19 and crf 20. Not saying that multipass encodes can't look better under those conditions, but if you want a fair comparision you have to compair at the same bitrate. Generally you can get away with a higher crf if you encode higher resolution or more detailed content.

[JohannesL]

CRF=18 is 137 kbps, and just enough.
I'll do a 3-pass at 137 kbps now.

[lchiu7]

Getting back to the original topic I asked, while the discussion has been very educational, it sounds like with a sufficiently high bitrate (4500-5000), and setting vbv_muxsize and vbv_maxrate to say 24000 I can get a decent encode in one pass (without caring about hitting a specific target size). I tried it last night and I got a very good encode (to my eyes anyway) in about 5 hours (on the AM2 64 3500). Comparing the encode (which is 1280x720) with the original (1080p) but on a 1366x768 TV, there are slight differences in quality but they are slight (mainly sharpness - no evidence of macroblocking I can see) and for me good enough for viewing and saving my HD-DVD drive :-)

[JohannesL]

You guys were right. CRF > multipass in terms of quality to filesize ratio. Sorry for my stupidity.

[ncahammer]

Some probably stupid thought.
Suppose a CRF encode reaches a *very* complex scene which finally encodes using a bitrate 10 times the final (average) bitrate of the video.
If we start for the same video a first pass encode specifying as bitrate, the previus average, will this also give 10 times the specified bitrate for the same scene or it will cut it down ?
If the answer is the latter, will the 2nd pass correct this ?

[Comatose]

crf=24:bitrate=150
You're specifying CRF *and* bitrate?

[JohannesL]

You're specifying CRF *and* bitrate?
Too late. :)

Some probably stupid thought.
Suppose a CRF encode reaches a *very* complex scene which finally encodes using a bitrate 10 times the final (average) bitrate of the video.
If we start for the same video a first pass encode specifying as bitrate, the previus average, will this also give 10 times the specified bitrate for the same scene or it will cut it down ?
If the answer is the latter, will the 2nd pass correct this ?
Didn't really read, but two passes will give good results. CRF at a value between 18 and 22 will give the best results, but if you're aiming for a specific bitrate, you have to use 2-pass. Never use 1-pass bitrate mode.