high quality mpeg-2 encoding

[creamyhorror]

I'll take your word for it, seeing how I'll probably never touch a $50k encoder.

I'm looking forward to whatever new ideas pop up. We already have that new AQ mode (AutoVAQ) from someone besides DS, and I was just trying out two modes by a Japanese builder (OreAQ and MixAQ). These might not actually be very useful in themselves, but reflect a growing interest in contributing to x264, which will hopefully help keep it pushing the boundaries.

[poisondeathray]

I'm looking forward to whatever new ideas pop up. We already have that new AQ mode (AutoVAQ) from someone besides DS, and I was just trying out two modes by a Japanese builder (OreAQ and MixAQ). These might not actually be very useful in themselves, but reflect a growing interest in contributing to x264, which will hopefully help keep it pushing the boundaries.

I haven't used those; If you find any interesting results keep us posted please D

[kazyn]

Its just ironic that something thats free, beats any other h264 hands down.

[lordsmurf]

I find the whole block-based encoding to be flawed anyway -- I want fractal-based encoding compression!!

The solution for block-based encoding, as always, is to up the bitrate allocation on videos that need it. That's the whole reason 2-hour movies are spread so wide across dual-layer media (be it SD or HD).

I'll look deeper into x264 encoding this winter, maybe, when I have more time.

[PuzZLeR]

Hi guys, can we continue this thread a bit (if still around)? Sorry I haven’t been around much the last few months with work, travel and all – I’ve honestly been very busy and away a lot.

I’ve originally found this thread rather boring, to be honest, and dismissed it as “fan-boy drivel” since I was constantly getting better encodes with CCE and MPEG-2 over x264 at the higher bitrates. Also, given that CCE doesn’t over-smooth, takes less encoding time, produces streams that are more decodable, can be edited and can play in every DvD player I could care less about x264 other than for low bitrate iPod stuff (of which I have been using x264 for, and adoring it as such, for years now).

But I’ve done some recent tests and found out why x264 was smearing and CCE MPEG-2 encodes came out so much better at higher bitrates.

This was due to two command lines option I was using with x264 in my testing, which were

--interlaced

and

--pulldown 32

Keep in mind, my comparison tests were in SD since CCE only does SD. At the same time with x264, anything other than blu-ray compatibility will not work for me for serious stuff – so I tested, and compared, with features that make it BD compliant in the SD spec.

An SD stream must be interlaced to be BD compliant. We all know that the gap closes in efficiency with interlaced x264 encodes (and did in my results).

However this was recently rectified (which was not available during my tests last year) with recent features like

--fake-interlaced

I can't say this enough - x264 NEEDED this.

Then there was the matter of pulldown. The only way my 23.976 fps encodes were accepted by Scenarist was by encoding with

--pulldown 32

(or now you can use DGAVCPulldown).

However, muxing this stream into MKV at 24/1001 reveals blurring. I, maybe carelessly, didn’t mux it to honor the pulldown flags and it instead smeared the video on playback. What was funny was that it didn’t overly smear it where it would be obvious something was wrong, but enough to determine a perceived problem with the encoder (see for yourself). Doing my testing as such put the favor heavily with MPEG-2.

I’ve recently muxed this stream into a TS transport stream instead and got different results. Yes, no smearing on pulldown (but some jitter). But the x264 encode certainly looked better, even at the higher bitrates.

I now have a question:

I still like the feel of the CCE/MPEG-2 encodes much more – I do admire that texture and cinematic quality. How can I get x264 encodes looking like this without the expense of too much bitrate? Although smaller in file size, the x264 encodes still look rather lifeless to me.

BTW – I can post a guide on creating blu-ray compatible streams, with the gray area, and stubborn, SD spec, with x264 if people are interested. I had it downpacked before but did not have the good conscious to post it till now.

[poisondeathray]

Why not stick with CCE for SD 24p blu-ray ?

My tests also show the advantage is minimal when using x264 for anything interlaced (still better than CCE SP2 in my tests), and even the 3:2 pulldown option for 24p content (either internal or dgavcpulldown) doesn't play correctly in many standalone blu-ray players (even with a good muxer like scenarist) . So for 24p SD blu-ray stuff I would still recommend CCE (only because of compatibility reasons) , for 60i/50i SD blu-ray I would use x264

If you prefer MPEG2, then use it

[El Heggunte]

^ @ PuzZLeR:

1) could you please specify the settings you chose for your x264 encodes

2) what player / DirectShow splitter do you use for transport streams
FWIW, && IMHO, the ArcSoft demuxer is much better than Haali's or MPC's mpeg splitters.

Anyway, keep in mnd that the whole MPEG-4 standards were designed for, fundamentally,

"not to suck «too much» at (relatively-)lower bitrates".

BTW – I can post a guide on creating blu-ray compatible streams, with the gray area, and stubborn, SD spec, with x264 if people are interested.

[PuzZLeR]

Hey Poison, thanks for your reply.

Why not stick with CCE for SD 24p blu-ray ?

The smaller file size of x264, or H.264 in general, is appealing since you don’t have to stick with MPEG-2 like on DvD. And the fact that you, now, no longer have to encode visually progressive content with x264’s interlaced feature…. (that was bad)… but, as you say...

and even the 3:2 pulldown option for 24p content (either internal or dgavcpulldown) doesn't play correctly in many standalone blu-ray players (even with a good muxer like scenarist).

You get that jitter huh? I think it’s a flaw inherent, not only with x264 but, in the H.264 standard in general in that it was not designed for pulldown (or it was overlooked with the Powers That Be back in 2003 upon conception of the standard). This is disappointing.

My tests also show the advantage is minimal when using x264 for anything interlaced

It was worse yet when you needed this feature (--interlaced), particularly on older builds of x264, even with progressive content to play on blu-ray – smear, smear, smear, …

still better than CCE SP2 in my tests

It’s definitely gotten better in recent years. But is the advantage worth it as you say here following?

for 60i/50i SD blu-ray I would use x264

Only if you’re talking retaining the interlacing for an interlaced-friendly display, but even with, likely, a slightly better compression advantage with x264 the trade-off, I believe, is not worth it. Can you elaborate? If you’re talking deinterlaced, or visually progressive "interlaced", content, then yes, I can agree, especially since --fake-interlaced makes a world of difference today.

If you prefer MPEG2, then use it

Using the right script, I adore CCE’s yields tremendously, even better than many sources it comes from. I will use it for some time yet. But, nevertheless, I’m still tempted to explore the BD SD spec with x264, even post a guide as a “work-in-progress”.

[PuzZLeR]

what player / DirectShow splitter do you use for transport streams

I use tsMuxer, nice tool. It automatically honors the pulldown flags in the stream without need for an extra commandline option like MKV would need (of which I have yet to try). However, muxing a pulldown stream, as is, into MKV with only the 24/1001 option smears. Try it.

could you please specify the settings you chose for your x264 encode

I would love to, but can it wait until I put together another upcoming thread where I can demonstrate how to achieve BD compatiblity with the SD spec? I have some time now to do so. It won't be perfect though, but unfortunately that's my only interest with H.264 at the serious level (with SD and HD).

Anyway, keep in mnd that the whole MPEG-4 standards were designed for, fundamentally,

"not to suck «too much» at (relatively-)lower bitrates".

I agree totally and that's what I've been saying x264 is good for - mobiles and "distributed online content". It's optimized only for "watchable" low-bitrate content and quickly loses its compression advantage at higher bitrates when compared with MPEG-2. It was very true at one point, but changes in recent years are convincing me to take another look. Hey, I'm not a close minded doorknob that will stick to a concept if things change.

[poisondeathray]

Why not stick with CCE for SD 24p blu-ray ?

The smaller file size of x264, or H.264 in general, is appealing since you don’t have to stick with MPEG-2 like on DvD. And the fact that you, now, no longer have to encode visually progressive content with x264’s interlaced feature…. (that was bad)… but, as you say...

You can use higher than DVD bitrates using MPEG for blu-ray. I would argue smaller filesize isn't that big of a concern with BD25/50

and even the 3:2 pulldown option for 24p content (either internal or dgavcpulldown) doesn't play correctly in many standalone blu-ray players (even with a good muxer like scenarist).

You get that jitter huh? I think it’s a flaw inherent, not only with x264 but, in the H.264 standard in general in that it was not designed for pulldown (or it was overlooked with the Powers That Be back in 2003 upon conception of the standard). This is disappointing.

I think it's a decoding problem with most retail blu-ray chips (they don't IVTC correctly for avc streams), because some players it works ok (with the same stream). The problem is the inconsistency . I think the spec itself is fine

It was worse yet when you needed this feature (--interlaced), particularly on older builds of x264, even with progressive content to play on blu-ray – smear, smear, smear, …

still better than CCE SP2 in my tests

It’s definitely gotten better in recent years. But is the advantage worth it as you say here following?

for 60i/50i SD blu-ray I would use x264

Only if you’re talking retaining the interlacing for an interlaced-friendly display, but even with, likely, a slightly better compression advantage with x264 the trade-off, I believe, is not worth it. Can you elaborate? If you’re talking deinterlaced, or visually progressive "interlaced", content, then yes, I can agree, especially since --fake-interlaced makes a world of difference today.

I'm not seeing the smear. I know you mentioned this awhile back. Maybe you can clarify or provide examples, and settings used? was this progressive SD content for blu-ray with pulldown ? or HD progressive content ?

I was saying for true interlaced sources (e.g. 60i/50i video content from a DV-AVI source) , interlaced encoding is slightly better when using x264 to encode than CCE at similar bitrates. I find same relationship holds for HD interlaced content (e.g. from a camcorder) , when comparing to other MPEG2 interlaced encoding (e.g. HCenc, or Mainconcpet MPEG2).

If the playback of 3:2 pulldown avc streams was fixed, I would use x264 for everything

Using the right script, I adore CCE’s yields tremendously, even better than many sources it comes from. I will use it for some time yet. But, nevertheless, I’m still tempted to explore the BD SD spec with x264, even post a guide as a “work-in-progress”.

I think it's the best MPEG2 encoder.

[PuzZLeR]

You can use higher than DVD bitrates using MPEG for blu-ray. I would argue smaller filesize isn't that big of a concern with BD25/50

I have a collection of over 10,000 music videos as a hobby, with a mass majority in SD source as are most only available in, of which I'd like to play in a home theater setup. If I can get similar quality with 30%-40% less space it can help.

I think it's a decoding problem with most retail blu-ray chips (they don't IVTC correctly for avc streams), because some players it works ok (with the same stream). The problem is the inconsistency . I think the spec itself is fine

This problem occurs even with VLC - try muxing an x264 encode, with --pulldown 32 applied into a transport stream and it will jitter. Nevertheless, if, as you say, it's just a simple matter of bad decoding of certain playback units, not any limitation on the spec to begin with, then this is encouraging as I believe it should get better.

I'm not seeing the smear. I know you mentioned this awhile back. Maybe you can clarify or provide examples, and settings used? was this progressive SD content for blu-ray with pulldown ? or HD progressive content ?

Well alot of it was older stuff, from older builds under the hood of the GUI with those versions of HandBrake and MeGUI no longer installed today. I can still upload some older blurry encodes, but most of us are aware of the older "Plastic Face Syndrome" of x264's past, so why bother? As well, after the format war ended Feb' of 2008, I was experimenting with blu-ray compatibility, and in those x264 builds back then, the --interlaced option that I needed for compatibility for SD source was, well, not efficient. Smears and blurs would reveal when encoding visually progressive - I even had to use interlaced encoding for content that had inverse telecine applied to it. It wasn't working for me.

But that was then. What I'm talking about today though is something you can try now. Encode a small source, preferably one with hard telecine, down to 24p with x264.

Use --pulldown 32 with one, and do the same with the other without it.

If you mux both into a TS, with tsMuxer, and use Avisynth's Interleave() command to compare you should not see much difference. However the TS with pulldown will play with jitter in VLC.

However, if you mux both into separate MKVs, such as with MKVMerge, as is as I was doing back then, using 24/1001 fps you will notice a smearing in many frames on the stream with pulldown when comparing with Interleave(). It is apparent as "jaggies" as well on diagonal lines, kind of like an old Atari 2600 game. The MKV will not honor the pulldown, smear it, but not play it with jitter. (I can provide a sample if you like but this should be easy for you. )

Pick your poison (no pun intended) - jitter, blur or broken compatibility. It's so unfortunate that --pulldown 32, a problematic feature with many decoders, is so essential to blu-ray compatibility at the SD spec.

I think it's [CCE] the best MPEG2 encoder

It's pure gold to me. Worth every penny.

[poisondeathray]

I think it's broken compatibility. Most decoders (even software) do not support on the fly IVTC (hard or soft) of AVC streams.

You mkv observations don't surpise me. It doesn't handle interlaced content very well either, when transport streams work fine . But if you're doing this for blu-ray, then you should be using mkv anyway...

Another option is to get a media box (e.g. wdtv, popcorn hour, asus oplay etc...) , many are <$100 USD . They will play almost anything you throw at it, and you have huge storage capacity with USB/HDD . This way you can use native progressive content.

[El Heggunte]

what player / DirectShow splitter do you use for transport streams

I use tsMuxer, nice tool. It automatically honors the pulldown flags in the stream without need for an extra commandline option like MKV would need (of which I have yet to try). However, muxing a pulldown stream, as is, into MKV with only the 24/1001 option smears.

Nah, you misunderstood what I wrote. TSMuxer is great ( even though it doesn't support "DTS-Express" ), but it's not a DirectShow filter. And as I said, ArcSoft is good because it does allow fast seeking on transport streams.

could you please specify the settings you chose for your x264 encode

I would love to, but can it wait until I put together another upcoming thread where I can demonstrate how to achieve BD compatiblity with the SD spec? I have some time now to do so.

Great!

...

and that's what I've been saying x264 is good for - mobiles and "distributed online content". It's optimized only for "watchable" low-bitrate content and quickly loses its compression advantage at higher bitrates when compared with MPEG-2. It was very true at one point, but changes in recent years are convincing me to take another look.

That's it --- never underestimate the programming skills of akupenguin, Trahald, and Dark Shikari.

[poisondeathray]

There are some guides already developed for BD encoding using x264 , HD and SD . If you want to add anything PM "kieranrk" at doom9 or doom10 forums

http://sites.google.com/site/x264bluray/

http://forum.doom9.org/showthread.php?t=154533

The only thing I would add is you would rarely use --vbv-maxrate 40000 --vbv-bufsize 30000 for SD content as depicted in the guide (those are ginormous bitrates for SD) . And you would get better efficiency by using L4.0 (this way you wouldn't need to use 4 slices, which reduces coding efficiency). If you use 15000/15000 you can use 2sec GOPs instead of 1sec GOPs which will also improve compression .

Also, --sar 40:33 and 10:11 are the offical SAR values from the blu-ray spec, but they use 704width, so the aspect ratio may slightly be off. I would use those value if you were replicating. However, the 8:9 and 32:27 (based on 720width) seem to also work on several blu-ray players that I have tested

[PuzZLeR]

Well, you can use progressive encodes now without penalty as long as you include --fake-interlaced in your command line.

Another option is to get a media box (e.g. wdtv, popcorn hour, asus oplay etc...) , many are <$100 USD . They will play almost anything you throw at it, and you have huge storage capacity with USB/HDD . This way you can use native progressive content.

Well, few encode to MPEG-2 SD without DvD compatibility, and even DivX/Xvid, without messing around with stuff like Qpel/GMC/etc, have established a common-place standard in their own way.

So, no disrespect, and this is only opinion - perpetual references to “pirate boxes” by x264 users as a rebuttal to any lack of compatibility diminish x264’s worth in my eyes.

Any low price for them is immaterial to me - I say the true least common denominator of compatibility, especially after all those mega-processing resources, for high quality H.264, SD or HD, is blu-ray compatibility. Everything else is bull-spit.

Like I said, it's only opinion.

Nah, you misunderstood what I wrote. TSMuxer is great ( even though it doesn't support "DTS-Express" ), but it's not a DirectShow filter. And as I said, ArcSoft is good because it does allow fast seeking on transport streams.

Ah, I see. I am at the office at the same time, so it's difficult to concentrate ... Your answer then is Haali.

could you please specify the settings you chose for your x264 encode
I would love to, but can it wait until I put together another upcoming thread where I can demonstrate how to achieve BD compatiblity with the SD spec? I have some time now to do so.
Great!

Coming to thread near you - stay tuned.

That's it --- never underestimate the programming skills of akupenguin, Trahald, and Dark Shikari.

Well, x264 will surely benefit now that it's based in a real Forum, with it's own better home. I also believe it escaped, both, a stifling on its development and a knock on its image, as well from its previous association.

The only thing I would add is you would rarely use --vbv-maxrate 40000 --vbv-bufsize 30000 for SD content as depicted in the guide (those are ginormous bitrates for SD) . And you would get better efficiency by using L4.0 (this way you wouldn't need to use 4 slices, which reduces coding efficiency). If you use 15000/15000 you can use 2sec GOPs instead of 1sec GOPs which will also improve compression .

Also, --sar 40:33 and 10:11 are the offical SAR values from the blu-ray spec, but they use 704width, so the aspect ratio may slightly be off. I would use those value if you were replicating. However, the 8:9 and 32:27 (based on 720width) seem to also work on several blu-ray players that I have tested

You are quite correct here, although you don't have to use the cropped value of 704 where 720 works fine with those PAR values.

I think I figured it out myself for SD and will post my results. Of course, they will be up for debate from the Forum. Tune in.

[poisondeathray]

Also, --sar 40:33 and 10:11 are the offical SAR values from the blu-ray spec, but they use 704width, so the aspect ratio may slightly be off. I would use those value if you were replicating. However, the 8:9 and 32:27 (based on 720width) seem to also work on several blu-ray players that I have tested

You are quite correct here, although you don't have to use the cropped value of 704 where 720 works fine with those PAR values.

Actually you can't use 704w framesize - it isn't blu-ray compliant . What I was trying to say is the "textbook" valid sar values were based on 704width . So if you use 720 width framesize (as you should) , you will get 1.81 AR instead of 1.78 if you use the spec values, unless you add 8px black borders to left and right . If you use non-spec values 8:9, 32:27, they are mathemateially correct for full 720 width (without black borders) and you will get proper 1.78 AR

[PuzZLeR]

Actually you can't use 704w framesize - it isn't blu-ray compliant . What I was trying to say is the "textbook" valid sar values were based on 704width . So if you use 720 width framesize (as you should) , you will get 1.81 AR instead of 1.78 if you use the spec values, unless you add 8px black borders to left and right . If you use non-spec values 8:9, 32:27, they are mathemateially correct for full 720 width (without black borders) and you will get proper 1.78 AR

Ah, ok.

I agree, a value of 8:9 is indeed mathematically valid for a width of 720 but not blu-ray compliant with that resolution, even though 720 is compliant (not 704) - oh, this is just one of the uncanny discoveries I've unearthed on this journey.

Yes, 10:11 is consistent with a 704 width as you mentioned, and does throw the aspect ratio off to some distortion when using 720 (without borders). But mercifully, it is a minor shortcoming. The delta factor here is rather negligible to most naked eyes.

Edit: Forgot to mention to others reading. I too have had success with valid PAR values, like 8:9, in my hands-on tests among some players (I work in A/V and bribed a local person at a certain "chain"). However, they are not accepted by Sonic Scenarist, so I would stick with the "uncanny ones".

[rallymax]

I used x264.exe to make a .264 raw file with the BluRay settings from the Google Doc http://sites.google.com/site/x264bluray/ page on Blu Ray settings:

720p59.94
x264 --bitrate XXXXX --preset veryslow --tune film --weightp 0 --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 60 --b-pyramid strict --slices 4 --ref 6 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o out.264 input.file
x264 --bitrate XXXXX --preset veryslow --tune film --weightp 0 --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 60 --b-pyramid strict --slices 4 --ref 6 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o out.264 input.file

...and dropped the resulting out.264 into Adobe Encore CS3 and it wouldn't open (it actually caused an internal error). The app engineer at Adobe dropped it into CS5 for me and it wouldn't open there either. In fact he said that this is the error message from Encore CS5:

“Video files for this project must have a frame rate between 1 and 60 frames per second.”

So perhaps the variable frame rate mode isn’t allowed by our importer plug-in.

It seems that it can't open a stream that has variable frame rate (confirmed by MediaInfo). Does that make any sense to you all?

General
Complete name                    : out.264
Format                           : AVC
Format/Info                      : Advanced Video Codec
File size                        : 1.14 MiB
 
Video
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : High@L4.1
Format settings, CABAC           : Yes
Format settings, ReFrames        : 5 frames
Bit rate mode                    : Variable
Bit rate                         : 20.0 Mbps
Maximum bit rate                 : 40.0 Mbps
Width                            : 1 280 pixels
Height                           : 720 pixels
Display aspect ratio             : 16:9
Frame rate mode                  : Variable
Color space                      : YUV
Chroma subsampling               : 4:2:0
Bit depth                        : 8 bits
Scan type                        : Progressive
Color primaries                  : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
...

thanks for pointers.
btw, I'm seeing the smearing too with the --fake_interlaced settings (my source is made using the FFmpeg libavcodec/output-example.c that is making a lossless UYUV422 AVI "720p59.94_UYUV422.yuv" file. x264 is built with libav* support to be able to open it.
I can post both if you like. just give me a pointer to a free large file upload site.

regards,
Rallymax.

[El Heggunte]

“Video files for this project must have a frame rate between 1 and 60 frames per second.”

So perhaps the variable frame rate mode isn’t allowed by our importer plug-in.

It seems that it can't open a stream that has variable frame rate (confirmed by MediaInfo). Does that make any sense to you all?

Yes . Blu-Ray video has nothing to do with Variable Frame Rate.
BTW, the ones who wrote the "recommended settings" above did forget to include the switch
--force-cfr.

[poisondeathray]

btw, I'm seeing the smearing too with the --fake_interlaced settings (my source is made using the FFmpeg libavcodec/output-example.c that is making a lossless UYUV422 AVI "720p59.94_UYUV422.yuv" file. x264 is built with libav* support to be able to open it.
I can post both if you like. just give me a pointer to a free large file upload site.

Q. Why are you using fake interlaced settings if it's a 720p59.94 source? (assuming that the name of the file indicates the resolution and framerate) , and how are you determining the "smearing" (what are you using to playback, and is the stream authored or wrapped) ?

[rallymax]

Thanks the -force-cfr fixed it (and looks GORGOUS). You're right I shouldn't have the fake interlaced. thanks for catching that.

[PuzZLeR]

You don't need --fake-interlaced or any pulldown flags for 720p blu-ray content - Scenarist gobbles up compliant progressive 1280x720 24p streams streams easily. Those features apply more to the (stubborn) SD spec.

Glad you solved your problem, but regardless, even though several things have caused smearing in my x264 encodes over the years, --fake-interlaced was never one of them. It's virtually zero difference in quality. All this feature does is only include some minor info in the stream to signal "interlaced" to professional authoring programs that will only accept them as such (when interlaced encoding "for real" may be undesirable).

As well, why are you using 6 reference frames? To be "safe" you shouldn't be using more than 3/4 for blu-ray.

Just a note: I don't use Encore, but nevertheless, personally, I've read lots of stuff on "blu-ray compliance" and you'd be surprised how much of it is annoyingly WRONG and IGNORANT. Even software developers don't get it many times - they just put something together to cash in.

When I put my post together (for SD content) I assure you it will work.

[rallymax]

I can't believe it's been 3 years since seeing this dramatic difference - a difference so good that I started a company so that non technical video post people can take advantage of x264's amazing AQ abilities.

thx once again.

This is a short AVCHD 1080i30 camcorder clip, yadif, lanczosresized 720x400, encoded at 1000kbps. You can find the original here for your own testing and learning: http://www.megaupload.com/?d=9B84U1II

It's a good clip to illustrate what x264's AQ does. Now there is no model here to distract you . Pay attention to the shadow detail, and details in the water (and under the water). After examining this clip, go back to the FFV1 clip and re-examine that one. If you still can't see the differences clearly, I'll post cropped image to highlight some of the bigger differences.

Not to sound like a broken record, but again this is a single frame just to illlustrate a point, and you should be looking temporally at the whole clip, different frames, different quality measures, etc. etc....blah blah blah....you get the point. Note I only posted AME , but every encoder that doesn't have AQ like functions has similar results (I tested about 20 different ones)

Original


Adobe Media Encoder CS4 (based on MC)


x264 AQ=0


x264 AQ=0.5


x264 AQ=1.0


x264 AQ=1.5