H265/HEVC samples

[deadrats]

i found some h265 samples and thought you guys might want to see what all the fuzz is about:

http://www.elecard.com/en/download/videos.html

how to view them - first of all none of the current media players have decode support for HEVC, you have to use the Elecard player alpha; the link is under the listing "player" and you have to save the video file to your hard drive by choose "save target as", choose all file types and manually add a .ts extension, then launch the player and add the video file.

i have to say, impressive is not the word, mind blowing is more accurate, compare the Big Buck Bunny encode done with 1713 kbs at 1920x1080 with the ones done using x264 on the Big Buck Bunny page and HEVC blows x264 away, you want to see detail retention at low bit rates, it's like holy sh*t.

i believe Elecard licenses main concept's sdk so if this is a sign of what we can expect from sony vegas, tmpg and all the other MC licensees or out of the free Divx encoder, i'd say within the year no one will be using avc for anything other than legacy application.

check out the samples and post your thoughts.

[aedipuss]

well if they don't get the cpu usage down there will be lots of unhappy users. 30-50% cpu usage on a 4GHZ i7.

[deadrats]

yeah, i noticed that too, my i7 3770k is saying 58% usage across all 8 threads, still one has to believe that there is ample room for optimization.

[jagabo]

My mind wasn't blown. They appear to misrepresent the bitrates they achieved in their encoding. They report 1038 kbps for their 720p Big Buck Bunny video but I calculate it's around 1350 (by file size, subtracting audio and TS container overhead). They reduced the gamma to give their versions more contrast. And lastly, they used and overly sharp resize filter that created a lot of buzzing edges and flickering detail. These are obviously tricks to make their encodings look better.

I have a 9 Mb/s AVC 1080p .MOV of Big Buck Bunny. I reencoded it at 1280x720 (LanczosResize()) with x264 at approximately the same bitrate (1366 kbps, veryfast preset, CRF=23) as their 720p h.265 file. It's a bit hard to compare since the only way I can view the h.265 file is by using their player. But the two files looked very close in quality. Using a a screen magnifier often showed the x264 encoding to have less blocking artifacts. Maybe there's something wrong with their deblocker.

[deadrats]

try a similar test against their 1080p sample, i tried creating a x264 1080p Big Buck Bunny with just 1700 kbs and i thought the results were crap.

[aedipuss]

the 1080 version seems mis-represented also. it's over 2200kbps with a vbr 2ch aac audio track. the video is most likely over 2000kbps, not 1700.

[jagabo]

the 1080 version seems mis-represented also. it's over 2200kbps with a vbr 2ch aac audio track. the video is most likely over 2000kbps, not 1700.

I agree, it's a little over 2000 kbps.

A similar x264 encode at CRF 25 gave about 2000 kbps and didn't look a whole lot different on quick inspection. I'll take a closer look tomorrow.

[Mephesto]

Sigh... leave it to these lying sacks of shit to destroy the credibility of a new, awesome technology and feed the change-resistant dipshits who will be disappointed when testing the new standard for themselves.

I'll post real, actual H.265 screenshots/samples sometime and show you guys what it really looks like which isn't really impressive but does retain grain/noise better. Better H.265 codecs will come about but right now they just barely hover above the quality of x264 so I wouldn't get my hopes up.

Adapt to the new standard intelligently. Wait until a good codec is released. Don't risk compatibility and future decoding problems for an implementation that'll only achieve 5% better quality but don't take a decade to move on like the Xvid guys either.

[deadrats]

ok, i found this free hevc decoder with hevc samples as well as x264 equivalents but i can't figure out how to get the decoder to work, anyone have any ideas?

http://xhevc.com/en/hevc/decoder/download.jsp

http://xhevc.com/en/hevc/encoder/videoShow.jsp

[aedipuss]

it appears to be a 32bit only codec. you'd have to install, reboot and use a 32 bit program to open a h265. i can't even try it as my antivirus lit up and deleted it.

[jagabo]

I had a closer look at the 1080p encodes mentioned in post #7. This was very hard to compare because I could only see one video at a time. I had to resort to screen caps of the h.265 video since the player couldn't save frames (jeez, it doesn't even have trans port controls). The faults in the two videos (h.265 vs x264 at about the same bitrate) were different in nature so that was hard to compare too. The h.265 video retained more detail but had more blocky artifacts (again, I think the deblocker wasn't working right). Overall, the h.265 video did look better. So there's some hope for the future.

Also, my x264 encode was starting with an already compressed h.264 video (~9000 kbps) that I downloaded previously. I don't know if the h.265 encode was made from a similar h.264 video or from the individual source image files. That may have put x264 at a slight disadvantage. I was never able to get the colors to match quite right. The differences weren't as simple as rec601 vs rec709.

[deadrats]

any idea how to get the other decoder i linked to working?

[jagabo]

It looked like a DirectShow decoder. Did you run the batch file to register the decoder? It should then be available to any player that supports DirectShow decoders. I didn't install it since I don't really have any interest in h.265 at this time.

[aedipuss]

it's interesting the elecard player won't play the lentoid samples. you'd think h265 would be fairly standardized now with encoder/decoder releases. norton a/v insists the .ax and .dll are infected from lentoid, make sure yours didn't delete them.

[jagabo]

you'd think h265 would be fairly standardized now with encoder/decoder releases.

I wouldn't think that. Any complex documentation has many ambiguities. Things like (highly simplified):

 You can do A.  Or you can do B.  Then do C.

Does that mean

You can do A, then do C.  Or you can do B then do C.

Or does it mean:

You can do A.  Or you can do B, then do C.

It's usually quite a while before people agree on what was intended.

Then you have problems with options:

You can do A or B or C.

One group may decide to implement A and B, but leave C for later. Another group may decide to do B and C, but leave A for later. These are alpha releases after all. The two groups are now incompatible.

Then you have oversights:

 You can do A, B, or C.  Then you can do X, Y, or Z.

But they forgot to mention that Z is incompatible with A. And X is incompatible with C.

Welcome to the real world of computer programming.

[vhelp]

Also, my x264 encode was starting with an already compressed h.264 video (~9000 kbps) that I downloaded previously. I don't know if the h.265 encode was made from a similar h.264 video or from the individual source image files. That may have put x264 at a slight disadvantage. I was never able to get the colors to match quite right. The differences weren't as simple as rec601 vs rec709.

i believe to have found the actual raw clips used in all these encoder test samples:

http://media.xiph.org/

any idea how to get the other decoder i linked to working?

i've been searching on this myself..so far, haven't found anything. however, i did find this interesting piece..i believe its the source to compile the h265 encoder, c++ code.

http://www.cnx-software.com/2012/12/30/h-265hevc-high-efficiency-video-coding-status-a...deos-to-h-265/

First, checkout the code, and build the reference software:
 svn co https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/trunk cd  trunk/build/linux/ make The build should complete within a short time,  and you’ll have 8 binaries in ../../bin directory, but we’ll only use 2:
 
TAppEncoderStatic – The release version of the H.265 / HEVC encoder
TAppDecoderStatic - The release version of the H.265 / HEVC decoder
  Before we can use the tools, we need a video file in YUV format. If   you don’t have one, you can convert any video file (I’ll use   big_buck_bunny_480p_H264_AAC_25fps_1800K_short.MP4) to YUV with ffmpeg   avconv (ffmpeg is deprecated, and we should use avconv instead).
 First, install the package containing ffmpeg/avconv, if you don’t have it already:
 sudo apt-get install libav-tools Convert the file to YUV, and get the  width, height, framerate and number of frames with avconv:
avconv -i big_buck_bunny_480p_H264_AAC_25fps_1800K_short.MP4 big_buck_bunny_480p_25fps_short.yuv
Now let’s encode this yuv file to h.265:
./TAppEncoderStatic -i big_buck_bunny_480p_25fps_short.yuv -wdt 856 -hgt 480 -fr 25 -f 100 -c ../cfg/encoder_intra_main.cfg

Read more: http://www.cnx-software.com/2012/12/30/h-265hevc-high-efficiency-video-coding-status-a...#ixzz2RvBeyRsN

can someone build the tappencoderstatic.exe tool so we can at least test it out here?

[vhelp]

unfortunately i was not able to test the installation player since it wanted .net, and i still have some mutiple versions (1.1, 2.0, 3.0, and 3.5 sp1) of .net still hogging (400mb) space on my system but for some reason this installation process bailed out saying that i don't have the version (v4.0.30319) it wants which i don't have. sheesh, i'm sick of these .net requirements. the install didn't mention a d/l offering either. oh well..i did try.

[deadrats]

ok folks, for all of you that are either following this thread or who happen to stumble upon it by accident, either via a google search or a forum search, i intend to update this thread on a regular basis as i find more information on hvec encoders and decoders from various vendors.

i found this pdf from a company i haven't heard of before:

http://www.acethought.com/AceThought_HEVC_Solutions.pdf

they claim that they will release a demo hvec encoder sept 1st and that they already have a demo version available of an hvec decoder that will be released on june 1st. unfortunately, i can't seem to find this demo anywhere.

in a related topic, they do have some interesting benchmarks for their hvec encoder, they claim that their encoder can do real time (30fps) encoding of 6mb/s 1920x1080 using an 8 core 16 thread xeon and a quad core 8 thread i7 can do 720x480 at 2mb/s at 30fps with only 45% cpu load. not bad, especially when you think back to the situation we were in when the first h264 encoders came out and encoding times could be measured with an hourglass.

[vhelp]

i found a x265.exe encoder here:

main source and bin download list here -> http://code.google.com/p/x265/downloads/list

x265.sp1 encoder d/l here -> http://code.google.com/p/x265/downloads/detail?name=x265-bin-201203-SP1.ZIP&can=2&q=

x264.201206-preview3 encoder d/l here -> http://code.google.com/p/x265/downloads/detail?name=x265-bin-201206-preview3.ZIP&can=2&q=

useage example: x265.exe -i foreman_cif.yuv -o test.bin -w 352 -h 288 -q 32 -f 300

i have not tried it since i have no player to test it.

instructions (param string) for encoding is in both the screen shot and link mentioned in post #16

[poisondeathray]

ok, i found this free hevc decoder with hevc samples as well as x264 equivalents but i can't figure out how to get the decoder to work, anyone have any ideas?

http://xhevc.com/en/hevc/decoder/download.jsp

http://xhevc.com/en/hevc/encoder/videoShow.jsp

These are directshow components . You need to register them manually , or with the .bat file, or through something like graphstudio. The HEVC samples from that page are wrapped in FLV, so you need a HEVC FLV splitter (there is a link on the bottom of the page with the samples, it's actually from MPCHC project "FLVSplitter.ax") . Once you register the filters you can construct a directshow graph in graphedit / graphstudio / graphstudio next . The correct source filter will be "MPC FLV Source (HEVC)". Connect the video output pin of the splitter/source filter to the decoder . If you want to view them in graphstudio, connect a renderer to the output pin of the decoder and push play . (If you want audio you need to connect the appropriate pins to decoder and renderers as well)



I find it easier to do comparisons in avspmod . You would leave the output pin for the video decoder unconnected (instead of adding a renderer), safe the .grf (e.g. "video.grf"). Create a 1 line script

DirectShowSource("video.grf", fps=23.976, audio=false)

Then you can open that .avs in vdub, avspmod etc. Much easer to do frame by frame comparisons and/or take screenshots

e.g interleave(a,b) in avisynth , or stackhorizontal(a,b), stackvertical(a,b), or use tabs in avspmod (flip back & forth with number keys)




BTW there are other comparisons, links samples, decoders, compiled encoders at Doom9 (not sure if you were aware or put on "vacation" for some reason )

[poisondeathray]

can someone build the tappencoderstatic.exe tool so we can at least test it out here?

jeeb compiled a win32 binary (hm 10.1) available here
http://x264.fushizen.eu/builds/hevc-hm/hm_10.1_r3419_release.7z

At this point, the only encoder and decoder I would trust for testing is the hm reference .

It looks like some of the other encoders are missing some elements , or can't use config files from the reference

[vhelp]

eggcellent, ty.

i see no one created a forum discussion (here) yet, where official questions likes prepping, scripting, encoding, etc., can be asked.

i assume at this stage, it is still in c++ and no asm/speed add yet..what can i expect (fps) on a dual core only system ?

and, is there an avs script avail to open these .yuv and other video type files ?

sorry, but somebody's got to ask these dumb questions.

[poisondeathray]

i see no one created a forum discussion (here) yet, where official questions likes prepping, scripting, encoding, etc., can be asked.

There is more discussion at doom9

i assume at this stage, it is still in c++ and no asm/speed add yet..what can i expect (fps) on a dual core only system ?

Almost no optimizations so far, so it's crazy slow for encoding and decoding

and, is there an avs script avail to open these .yuv and other video type files ?

You can use RawSource()

e.g.
RawSource("video.yuv", width=x, height=y, fps=x, pixel_type="IYUV")

[jagabo]

and, is there an avs script avail to open these .yuv and other video type files ?

I haven't seen the YUV files but look at the RawSource() filter for AviSynth.
http://avisynth.org.ru/docs/english/externalfilters/rawsource.htm

[deadrats]

BTW there are other comparisons, links samples, decoders, compiled encoders at Doom9 (not sure if you were aware or put on "vacation" for some reason )

i've only been "put on vacation" once by that self righteous prick nueron2 for having the balls to go against his darkness.

i can't wait until those x264 CSers lose clout and prestige once their over-rated piece of garbage encoder is no longer widely used and they can't make any real money from it anymore.

you get the feeling that they really annoy me?

[vhelp]

not sure how everyone else made out with this process. i struggled most of the day and through the night with this until i finally met up with some success. i could not get the graph working to decode or play an encoded video. but i did finally get to see the encoded video. so, considering how much trouble i spent with this i decided to make a small basic recipe of the process to Encode and Decode (play) a video. there must be a better way to feed a (new) video into the encoding part, step 2, but i have'nt figured that one out, yet, maybe through another avisynth script.

one thing i came to realize.. is if you keep the filenames the same, it makes (the process below) that much easier/faster to process the video. so keep that in mind.

to help minimize debugging times, i used a short 352x288 size video for testing. this helps tame your sanity until you become familar with the encoding settings and other things, until a utility comes about to help streamline the process in one or two steps.

perhaps saving this list as a batch file, could help some-what.

(1). avisynth script to prep for x265 encoding
* file "rawsource.avs"

  x = "h:\FOREMAN_2003-10-10.1116am_352x288_30_orig_01.yuv"
  LoadPlugin("c:\plugins\rawsource.dll")
  RawSource(x, width=352, height=288, pixel_type="YV12") 
  assumefps(30)

(2). x265 encoding
D:\tools\x265\TAppEncoder.exe
-c "D:\tools\x265\cfg\encoder_intra_main.cfg" -i "h:\FOREMAN_2003-10-10.1116am_352x288_30_orig_01.yuv" -q 10 -fr 30 -wdt 352 -hgt 288 -f 300 

(3). x265 decoding (to a yuv file--requires the *.bin file from the encode)
D:\tools\x265\TAppDecoder.exe
-b c:str.bin -o "h:\reconstructed_rec.yuv"

(4). avisynth script to play/review
* file "rawsource_reconstructed.avs"

  x = "h:\reconstructed_rec.yuv"
  LoadPlugin("c:\plugins\rawsource.dll")
  RawSource(x, width=352, height=288, pixel_type="YV12") 
  assumefps(30)

(5). opening/playing video
two options: 
a) open the raw encoded .yuv file using YUVplayer, or
b) open via avisynth script, step 4, through virtualdub

YUVplayer --> http://sourceforge.net/projects/raw-yuvplayer/?source=dlp

some notes
it took 12 minutes to encode a 300 frame test clip on my dual core, but 10 seconds to decode to the reconstructed yuv file. i will look into seeing if there is a better way to improve the process.
also, i'm not familiar with all the settings/commands, but if you use the -q setting, this will improve the quality. lowest value, 1, is highest quality, i forget what the max limit is, maybe 30.

[Mephesto]

BTW there are other comparisons, links samples, decoders, compiled encoders at Doom9 (not sure if you were aware or put on "vacation" for some reason )

i've only been "put on vacation" once by that self righteous prick nueron2 for having the balls to go against his darkness.

i can't wait until those x264 CSers lose clout and prestige once their over-rated piece of garbage encoder is no longer widely used and they can't make any real money from it anymore.

you get the feeling that they really annoy me?

Calm down Ratzinator, "over-rated piece of garbage"? You're talking about XviD and OGG right? x264 is the best quality codec out there, so don't shit on it. I don't care for doom9 and its nuthouse of uberdorks but some of them did write x264 which happened to be an awesome codec that finally made the technology's superiority to XviD ******* obvious enough for your average change-resistant moron to move on.

Don't shit on the children of the Nazis.

[deadrats]

Calm down Ratzinator, "over-rated piece of garbage"? You're talking about XviD and OGG right? x264 is the best quality codec out there, so don't shit on it. I don't care for doom9 and its nuthouse of uberdorks but some of them did write x264 which happened to be an awesome codec that finally made the technology's superiority to XviD ******* obvious enough for your average change-resistant moron to move on.

nope, i'm talking about x264. x264 is not "awesome", as i have stated numerous times it's logistically impossible for any open source piece of software to be the absolute best in it's given segment. why? because it's open source, duh. assume someone does create some algorithm that really is innovative and unique and better than what anyone else has done before. with open source, you have just shared the code with the world, any competitor is free to look at how you did it and incorporate it into their product. even if x264 were superior at one point, that would only last for a few months at the most before everyone copied the code and started doing the same thing.

x264 is crap, pure and simple. the main face of the developing team, jason, has spent years spreading fud and flat out bullshit on forums and his idiotic blog promoting his little baby. i've communicated with him numerous times and he is a master of saying the most retarded things imaginable and he is helped by a number of forum members found on other forums.

want to see how crappy x264 is? disable all the psychovisual optimizations it has and compare the encoded quality against main concept's h264 encoder, which has no psychovisual optimizations. the job of an encoder is to achieve maximum compression while staying as close to the source image as possible, its job is not to enhance the image, that's the job of a filter. if the x264 developers where so concerned about improving image quality they should have not spent time coding psychovisual enhancements, they should have worked on getting the built in denoising filter, which they themselves say sucks, up to the quality of neat video, they should have coded a high quality in-loop sharpening filter and they should make sure that they have the best in-loop deblocker ever seen. instead they have spent countless hours writing code to make sure that what comes out does not look like what goes in and they proudly promote that achievement.

the proof is in the pudding, if x264 had a pricing and licensing structure similar to main concept's offering, do you still think that it would be the encoder of choice for most people? similarly if main concept were legally free with an eula similar to x264's, would x264 ever gotten the traction it has now.

i'll make a prediction, the x264 sheeple, those that worship at the alter of x264, will spend post after post in this and other forums denouncing every h265 encoder that ever comes out and will insist that x264 is better than those encoders, until the day the x264 developers create their own h265 encoder, something they have already said won't be happening anytime before hell freezes over.

i can't wait for h265 encoders to be available and never do another x264 encode again.

[Mephesto]

nope, i'm talking about x264. x264 is not "awesome", as i have stated numerous times it's logistically impossible for any open source piece of software to be the absolute best in it's given segment. why? because it's open source, duh. assume someone does create some algorithm that really is innovative and unique and better than what anyone else has done before. with open source, you have just shared the code with the world, any competitor is free to look at how you did it and incorporate it into their product.

That's kind of the point of open-source. What's the alternative? To have closed-source for-profit fags hoard crucial technology and depend on one bipolar fucktard's benevolence for the direction he'll take his technology? ...which most of the time is stolen from common open-source projects they slap a closed-source eye-candy UI on.

There's a basic philosophy people like the godfathers of the internet we're using propagated which was that all information must be free and accessible. And this WILL be reinforced. Freedom fighters always find a way. Closed-source software is eventually debugged.

even if x264 were superior at one point, that would only last for a few months at the most before everyone copied the code and started doing the same thing.

According to simple quality tests, other codecs failed to stay competitive with x264.

x264 is crap, pure and simple. the main face of the developing team, jason, has spent years spreading fud and flat out bullshit on forums and his idiotic blog promoting his little baby. i've communicated with him numerous times and he is a master of saying the most retarded things imaginable and he is helped by a number of forum members found on other forums.

So have I (with Jeice), he's an autistic assgoblin but so are most of the gimps involved in projects like these. But they still created the most innovative h.264 encoder and that mb-tree feature that revolutionized the standard so much that H.265 can't keep up (I've done tests).

You don't throw out the baby when dumping the bathtub just because the water is shitty (or however that saying goes).
I don't admire Margaret Sanger either as she was a whorish, narcissistic racist who sought pro-abortion policies for black people and others to keep them from reproducing. Does this make her women's rights campaigns and gender equality movement she spawned worthless? Hell no.

Judge the x264 dev team's work, not their character.

want to see how crappy x264 is? disable all the psychovisual optimizations it has and compare the encoded quality against main concept's h264 encoder, which has no psychovisual optimizations. the job of an encoder is to achieve maximum compression while staying as close to the source image as possible, its job is not to enhance the image, that's the job of a filter. if the x264 developers where so concerned about improving image quality they should have not spent time coding psychovisual enhancements, they should have worked on getting the built in denoising filter, which they themselves say sucks, up to the quality of neat video, they should have coded a high quality in-loop sharpening filter and they should make sure that they have the best in-loop deblocker ever seen. instead they have spent countless hours writing code to make sure that what comes out does not look like what goes in and they proudly promote that achievement.

I don't use any form of psychovisuals, ever. Nobody should. It's the weakest god damn thing ever implemented in x264 and makes the quality worse if anything. And no they should not have implemented autodenoising/autosharpening. I do not want any form of pre-processing (except deblocking) done on my videos. I already have superior denoising/sharpening tools that I'll apply manually if I want to and any automated use of such methods could never match the quality a I can achieve manually guiding them.

the proof is in the pudding, if x264 had a pricing and licensing structure similar to main concept's offering, do you still think that it would be the encoder of choice for most people? similarly if main concept were legally free with an eula similar to x264's, would x264 ever gotten the traction it has now.

x264 has been tested against Mainconcept and Mainconcept lost.

i'll make a prediction, the x264 sheeple, those that worship at the alter of x264, will spend post after post in this and other forums denouncing every h265 encoder that ever comes out and will insist that x264 is better than those encoders, until the day the x264 developers create their own h265 encoder, something they have already said won't be happening anytime before hell freezes over.

i can't wait for h265 encoders to be available and never do another x264 encoder again.

I don't worship encoders, I worship quality which x264 is unmatched in.

I've dealt with plenty retards in the pedophile--err audiophile cliques that can't detach their micrococks from their OGGfish-shaped fleshlights and continue to unwarrantly flaunt Vorbis as a superior codec despite objective listening tests proving the contrary numerous times. Now they're plastering new opus-shaped dildos for their pasty white asses for the new crap open-source audio standard for no other reason than that it's not from MPEG.

I use x264 because it's the best of the best in terms of quality.
I use Nero AAC because it's the best of the best in terms of quality.

If anything surpassed it, I'd use it instead.

As you notice, I'm objective and don't give two shits whose royal ass it spawned from. You should be the same.
Discriminating codecs under emotional preferences will just turn you into the same kind of morons you complain about and you'll end up spreading untruths and FUD... just as you complained about. Don't become what you hate.

[deadrats]

But they still created the most innovative h.264 encoder and that mb-tree feature that revolutionized the standard so much that H.265 can't keep up (I've done tests).

two things:

1) the notion that h265 can't keep up with x264 is a flat out lie, there are samples i linked to where h265, a codec that is still in it's infancy walks all over x264, an h264 encoder that has been around for 10 years.

2) more importantly, mb-tree is not revolutionary, want to guess how mb-tree came about? it's because jason, aka dark shakari, aka lead x264 developer was testing x264 against main concept's h264 encoder and discovered that MC was producing much higher quality I frames than x264:

http://x264dev.multimedia.cx/archives/98

also, i hate to break this to you but main concept has had a features for years that x264 still can't match, such as:

Film Grain Optimization
Optimizes CineVision’s treatment of source material with significant film grain content. Indicate the heaviness of film grain in the source material by entering a number from 0 (for material with no film grain, such as animation) to 100 (for material with heavy film grain).

Brightness AQ Strength
Specifies whether and how much to increase or decrease the quantization level for areas with extremes of brightness. Negative strengths yield a finer (lower) quantization, and consequently a higher quality, for bright areas. Positive strengths yield a finer (lower) quantization for dark areas.

Contrast AQ Strength
Specifies whether and how much to increase or decrease the quantization level for areas with extremes of contrast. Negative strengths yield a finer (lower) quantization, and consequently a higher quality, in areas with high levels of contrast. Positive strengths yield a finer (lower) quantization in areas with low levels of contrast.

Detail AQ Strength
Specifies whether and how much to increase or decrease the quantization level for areas with extremes of detail. Negative strengths yield a finer (lower) quantization, and consequently a higher quality, in areas with low levels of detail. Positive strengths yield a finer (lower) quantization in areas with high levels of detail.

Black normalization level
Improves the appearance of black and very dark areas by mapping colors at or below the specified level to full black (16). This reduces graininess and noise in dark areas.

not all front ends expose all these options, the old Cinevison encoder did, as does Sorenson's encoder, but these cost big bucks. main concept also has featured a version of mb-tree for years, i think the old rhozet encoder used to call it "masking". there's nothing innovative about x264, they copied/stole other encoders features/ideas and reverse engineered those encoders in order to copy what they did.

ateme is another great example, they have had 4 different types of psychovisual optimizations for years, at least 3 or 4 before x264 brought theirs out.

but x264 is at least legally free, so at least they have that going for them.