x264 development

[rallymax]

As you should know, vbv-maxrate is not the maximum bitrate, but the bitrate at which the VBV buffer is filled.

The VBV model ensures that the VBV buffer won't underflow. And that's it. Consequently there may be short bitrate spikes higher than vbv-maxrate, as long as the buffer doesn't underflow.

x264 will ensure VBV compliance, if both, vbv-maxrate and vbv-bufsize are set. If the VBV buffer ever underflows, x264 will print out a fat warning. This usually doesn't happen.

Thx. yes that's as I understood it - I just wanted to check that for --crf that the vbv code wasn't bypassed.



There is no tuning that can help against artifacts already present in your source. Actually there is no way to magically make these artifacts go away, except for a better source.

Using the "psnr" tuning is a bad idea, except when you want to optimize for maximum PSNR score. It disables all the nice Psy optimizations. Better use "film" or "animation" for normal encodes.

Understood that I can't remove the damage - I was just wondering what tuning settings (with say --crf 10) would help it along the way to best replicate the source while taking advantage of the psycho-visualization optimiations that x264 is so good at.


Why not grab one of the various pre-compiled binaries?

Anyway, questions about libav that are not specific to x264 should go to the libav mailing list:
http://libav.org/contact.html

thx. I'm on that list but thought there might be a more forum based one like this is for the x264 dev mailing list. You are right though - it's very much appropriate for the dev list since it's crashing.

[dado023]

i need some advice.
How does this:
--min-keyint 0 --ref 8 --rc-lookahead 60 --bframes 6 --b-adapt 2 --direct auto --deblock -1:-1 --subme 10 --trellis 2 --psy-rd 1:0.15 --partitions all --me esa --merange 24 --aq-mode 2
compare to --preset veryslow ? I am interested in quality, but placebo is crazy slow, so i need your opinion for quality.

Question number two:
What will happen if i include --preset veryslow like this:
--preset veryslow --min-keyint 0 --ref 8 --rc-lookahead 60 --bframes 6 --b-adapt 2 --direct auto --deblock -1:-1 --subme 10 --trellis 2 --psy-rd 1:0.15 --partitions all --me esa --merange 24 --aq-mode 2

Thanks

[sneaker_ger]

Preset veryslow is this (see x264 --fullhelp):
--b-adapt 2 --bframes 8 --direct auto --me umh --merange 24 --partitions all --ref 16 --subme 10 --trellis 2 --rc-lookahead 60

Manual parameters override preset options.

[dado023]

@sneaker
thanks for the info regarding override, but what do you think about output quality between those two?

[sneaker_ger]

Should be almost identical, just like the parameters are. Stick to the preset, unless you really know what you are doing.

[jpsdr]

I've some questions.
- Is there different qmatrix in x264, and choice is selected by --tune or is there only one standard defined ?
- In what file(s) are the matrix defined and used/selected ? I want to see if i can "easely" implement (if not done) a tune of qmatrix according the selection of --tune.

:thanks:

[MasterNobody]

I've some questions.
- Is there different qmatrix in x264, and choice is selected by --tune or is there only one standard defined ?
- In what file(s) are the matrix defined and used/selected ? I want to see if i can "easely" implement (if not done) a tune of qmatrix according the selection of --tune.

:thanks:
As I understand you meaned CQMs by "qmatrix". --tune option doesn't change used CQM. There is 2 predifined CQMs: flat (default) and JVT. Also custom CQMs are possible with --cqmfile option.

P.S. Anything except flat CQM is rarely used in x264 because most features (like AQ) are tuned for using it.

[burfadel]

I was looking online and came across a patch for x264 for K-means weightp: https://github.com/astrataro/x264_tMod/commit/dbbd7a15b1c7f040f329cd9ec7d9a13a9e84bc89

Obviously the patch requires at least minor alterations for non-multipatched x264, but that is not the reason of my question. I was wondering what K-means Weightp is, and whether it is of any actual benefit?

On a separate note, do people find http://komisar.gin.by/old/2245/p/x264_aq3.2208.diff of any benefit in terms of AQ mode 3 over AQ mode 2?

[LoRd_MuldeR]

I was looking online and came across a patch for x264 for K-means weightp: https://github.com/astrataro/x264_tMod/commit/dbbd7a15b1c7f040f329cd9ec7d9a13a9e84bc89

Obviously the patch requires at least minor alterations for non-multipatched x264, but that is not the reason of my question. I was wondering what K-means Weightp is, and whether it is of any actual benefit?

AFAIK this was never really finished. At least it's still on the "TODO" list:
http://wiki.videolan.org/X264_TODO#Weighted_Prediction

On a separate note, do people find http://komisar.gin.by/old/2245/p/x264_aq3.2208.diff of any benefit in terms of AQ mode 3 over AQ mode 2?

See here:
http://forum.doom9.org/showpost.php?p=1607941&postcount=6

[burfadel]

About K-means, even thought it isn't finished, I am curious about what it actually is, and what it does in terms of quality improvement?!

I was thinking even if it's not part of x264, it doesn't mean aq-mode is any less as good as aq-mode 2. I believe it may somewhat overcome the shortcomings of aq-mode 2?

[JEEB]

About K-means, even thought it isn't finished, I am curious about what it actually is, and what it does in terms of quality improvement?!
K-means weightp was tried a few times, and this patch that f.ex. astrataro uses is an updated version of the k-means weightp feature that was started quite some time ago.

It was found out to be rather useless, results wise, by the original creator as well as the one who updated it to current x264 code if I recall correctly.
< dj_tjerk> JEEB > seems like it (is my patch).. not sure why anyone would be interested in Kmeans though
< dj_tjerk> odd indeed
< dj_tjerk> "must add extra features!" or something
< dj_tjerk> yet
< dj_tjerk> I will not support that patch :P
< dj_tjerk> anyhow, as I said before, I wanted it to be a stepping stone to explicit b-weighting... but with kmeans not really helping at all, and me finally getting something to do again at my job at the time, I didn't move on to that part of my 暇つぶし activities

Explicit b-weighting might be useful, but as such k-means weightp hasn't really shown any real results. I also added it on top of the patches on my patched x264 build for laughs, and it seems to break with no mbtree. Might be my mistake in something, but it clearly is just a patch created for testing/research, without support from its creator :) .

[burfadel]

Ah ok, thankyou! :)

[06_taro]

K-means weightp is not finished, and possibly would never be, since it seems that no one is working on it any more. Some people want its "magic" seriously, so it is served, without being mentioned in the blog because it's not for general use, and not even ready for tests. It crashes with no-mbtree, and in some (if not all) cases gives rubbish results in multi-pass encoding. However, one of those brave users, who in my personal opinion is quite addicted to transparent encoding with no tolerance for even a loss in noises and is keen on picking up several single frames to do frame-by-frame comparisons even in 2x size, claimed that it does avoid ruining lines and edges by current mbtree mechanism, such as hair in static animation scenes, while no one else has ever confirmed that. If you are also mbtree haters like him, feel free to take a try, with absolutely NO WARRANTY what it does.

[Stereodude]

Has the "veryslow" preset received the majority of the tuning and tweaking in x264 (or at least more than "placebo)? In my testing it seems to give lower bitrates than "placebo" at the same CRF and slightly better visual quality too.

[Dark Shikari]

Placebo is only marginally different if you look at the settings. Measuring a visual quality difference of the sort I'd expect between veryslow and placebo (under 1%) is for all intents and purposes physically impossible.

[Stereodude]

Placebo is only marginally different if you look at the settings. Measuring a visual quality difference of the sort I'd expect between veryslow and placebo (under 1%) is for all intents and purposes physically impossible.
Well there must be some infrequent circumstances where differences are visible otherwise it's a pointless setting to have right?

[Dark Shikari]

Well there must be some infrequent circumstances where differences are visible otherwise it's a pointless setting to have right?Placebo largely exists to give obsessive encoders something to waste CPU time on (hence the name! ;) )

But the idea that "1% isn't visible, so it doesn't matter" is a dangerous fallacy. By that logic, you could repeatedly lower the bitrate by 1%, and each time, it wouldn't be visible, so it wouldn't matter. Eventually, by induction, you could reach 0kbps and the video would look fine. Of course this doesn't actually work, since those little 1%s accumulate over time into something quite visible.

[xooyoozoo]

Placebo largely exists to give obsessive encoders something to waste CPU time on (hence the name! ;) )

It's winter around here. Might as well make your heater multipurpose :D.

By the way, AVX2 should be out and about in several months. Are there any hypothetical estimations on how beneficial that would be to x264's performance in the medium run (once the obvious optimizations are done with)? I'm just mulling over potential upgrades.

[Dark Shikari]

Let's try some proper math here (read: slightly informed guessing) instead of my usual total guessing.

In a quick test on preset medium on a Sandy Bridge, about 2.5% of x264's time is spent in CABAC asm (not SIMD), 5% in trellis asm (largely not SIMD), and ~40% in C code. So that rules out roughly 47.5% of x264 for speed improvements.

For the sake of clarity here, "50% faster" is defined to mean "takes 50% less time" (i.e. "twice as fast").
Keep in mind these numbers are high estimates: AVX2's badly designed "way" system might make it more difficult than expected to get reasonable speed increases. I'm also assuming that AVX2 can actually do every single 32-byte op we care about just as fast as a 16-byte op; if there are some where it simply splits it into 2 16-byte ops internally, we obviously won't get any more speed out of it.

52.5% remains:
8.0%: qpel functions. These may get faster due to faster unaligned loads, but AVX2 itself isn't useful here because the functions are purely load-bound.
7.0%: width 8 SATDs and Hadamard AC: ~25-35% faster
6.5%: width-16 SADs. If Haswell can do 2x16-byte unaligned loads per cycle, width-16 SADs could probably get ~30-40% faster.
4.5%: chroma MC. Thanks to the NV12 changes giving us twice the width to work with, we can probably get this ~30-40% faster.
4.0%: width-8 SADs. AVX2 won't help us here; there's just not enough width.
3.5%: width 16 SATDs: ~30-40% faster
2.0%: quant/dequant: ~20-30% faster

Everything else is mixed; AVX2 will probably help quite a bit on hpel filter for example but probably not on zigzags. So let's say it helps 15% on all the other assembly code combined.

This puts the overall gain, optimistically, at ~10% from AVX. Keep in mind though that Haswell itself may be quite a bit faster even before any AVX2 code is written.

[rallymax]

Hi Dark,
seeing as 40% of the code is in C land that would suggest that the quality of the C compiler could make a significant difference.

Do you have any metrics between the speed quality output by Intel C Compiler (ICC) vs GNU (gcc)?

[Dark Shikari]

Pretty much zero difference as far as I know, possibly ICL being worse, since it can't handle any of the inline assembly.

[Boulder]

Is there still no performance difference between the various GCC releases (4.x)?

[LigH]

The criterion is not the size of the source, but the time the code is executed. Most of the C code is only executed once, to make it an application at all (you wouldn't want to write a user interface, even for the command line, in Assembler). The really relevant code – which is executed over and over in loops for possibly hours – is highly CPU optimized Assembler code. No C compiler could optimize the execution of these routines any further.

[Dark Shikari]

The criterion is not the size of the source, but the time the code is executed. Most of the C code is only executed once, to make it an application at all (you wouldn't want to write a user interface, even for the command line, in Assembler). The really relevant code – which is executed over and over in loops for possibly hours – is highly CPU optimized Assembler code. No C compiler could optimize the execution of these routines any further.Where are you getting this from? This isn't true at all. Again, 40% of x264's time is spent in C code that is run billions of times, whether it's motion estimation, RDO, or a host of other things.

[LigH]

:o You winnel... (Hot Shots 2 - walnut scene) — I'll better leave that topic to those who know what they are talking about.

[Groucho2004]

Is there still no performance difference between the various GCC releases (4.x)?
I was bored a while ago and compared the speed of 4.5x and 4.6x. It turns out that you get about 2-3% more speed with 4.6x. However, this is not representative at all since I had only one CPU at my disposal (i5 2500k). With other processors, results may vary.

Edit: To avoid confusion: "Speed" refers to the encoding speed of the x264 binary, not the compilation process.

[xooyoozoo]

Is there still no performance difference between the various GCC releases (4.x)?

I think phoronix.com had a comparison using GCC 4.2-4.7.x some time ago. x264's performance barely drifted, regardless of compiler.

I prefer that over apps such as GraphicsMagick, where binary performance drifts by several factors if you so much as sneeze the wrong way.

[Stereodude]

Back in March of 2012 I did a speed benchmark of the 64bit and 32bit versions of x264 (2164) using the following command lines:

x264 --bitrate 25000 --fps 24000/1001 --preset veryslow --tune film --weightp 1 --bframes 3 --ref 4 --bluray-compat --b-adapt 2 --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o NUL "park_joy_1080p50.y4m"
x264 --bitrate 25000 --fps 24000/1001 --preset veryslow --tune film --weightp 1 --bframes 3 --ref 4 --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o PJx86.264 "park_joy_1080p50.y4m"

I found that while the 64bit version was much faster the QP's were very close:

2164 x86:[info]: frame I:23 Avg QP:25.04 size:561813
[info]: frame P:126 Avg QP:26.88 size:246702
[info]: frame B:351 Avg QP:31.26 size: 60159
2164 x64:[info]: frame I:23 Avg QP:25.09 size:558465
[info]: frame P:126 Avg QP:26.88 size:247294
[info]: frame B:351 Avg QP:31.25 size: 60392

I reran the same test today with 2245 and found the QP's for both are lower than they were with 2164. I guess x264 still continues to get more efficient with bitrate.

2245 x86x264 [info]: frame I:23 Avg QP:23.98 size:621297
x264 [info]: frame P:128 Avg QP:27.08 size:238940
x264 [info]: frame B:349 Avg QP:31.26 size: 58993

2245 x64[info]: frame I:23 Avg QP:23.99 size:620797
[info]: frame P:128 Avg QP:27.07 size:238938
[info]: frame B:349 Avg QP:31.27 size: 58793

[Dark Shikari]

If the output between the 32-bit and 64-bit versions is different at all, something is wrong.

[Stereodude]

If the output between the 32-bit and 64-bit versions is different at all, something is wrong.
Ooops, I found my mistake. I had accidentally copied the first pass data. I'll edit my post as to not mislead anyone

[pokazene_maslo]

I'm watching x264 development closely for quite some time now. Lately it seems like x264 development is pretty much dormant. Dark Shikari, are there any new features that are you working on? Or are you working on something else than x264.
Best regards.

[Dark Shikari]

I have a few nice patches coming up, but in general, there is far less low-hanging fruit than there used to be. It takes a lot more work to find something that can be improved relatively easily. One can also work on a larger project for something harder -- but as always, such ideas can take a lot of time and have a good chance of failing. And sometimes, even though we know the place where x264 is weak, we don't know any good solutions, or if one even exists.

I do have something else I'm working on, but it's rather personal and not programming-related.

[Atak_Snajpera]

does this mean that opencl will finally be avaliable in "official" builds?

[Dark Shikari]

OpenCL is still stalled because of a driver bug caused by AMD/Intel OpenCL drivers interacting, which caused it to silently break (and produce horribly wrong results) on machines that use AMD Enduro. I'm not involved in this, so I don't really know beyond that.

[pokazene_maslo]

I'm dreaming about cabac <-> cavlc converter for a long time. Is there any chance that someone from x264 development will implement this? This might be the low-hanging fruit you are looking for :-)

[jdobbs]

I looked a little and didn't see anything related to this. But I thought it odd so I thought I'd post it.

I'm doing some testing on r2245 (downloaded from www.x264.nl) with BD Rebuilder and got a failure when I tried to run it. I stepped back to r2230 and it worked again. So I pulled the command line and ran it from a DOS window. The error was "ratecontrol_init: can't open stats file". After a couple of tries I found that when running the command from a DOS window that was run as administrator, r2245 would run fine. A rights issue -- I guess -- but I don't see why. Why is it a rights issue with the new version but not with any of the older ones? The output folder has no special privileges.

Any help would be appreciated.

[Edit] Exact same peculiarity with the Komisar version

[LoRd_MuldeR]

If you are one Windows, I would suggest to use ProcessMonintor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) and check which file/path exactly it tries to access and what operation exactly fails... (with what error)

BTW: Should be clear that if you install x264 to %PROGRAMFILES% or %PROGRAMFILES(X86)% (or a sub-folder thereof) you cannot create the stats files directly in the x264 "install" directory, unless you elevate the process (which is a bad idea). Instead you have to use %TMP% or %APPDATA% to store any "work" data.

[jdobbs]

If you are one Windows, I would suggest to use ProcessMonintor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) and check which file/path exactly it tries to access and what operation exactly fails... (with what error)

BTW: Should be clear that if you install x264 to %PROGRAMFILES% or %PROGRAMFILES(X86)% (or a sub-folder thereof) you cannot create the stats files directly in the x264 "install" directory, unless you elevate the process (which is a bad idea). Instead you have to use %TMP% or %APPDATA% to store any "work" data. The stats file is in a user created folder. In fact BD Rebuilder creates it and creates several files in it just before it executes X264.EXE.

The important point is that the exact same command line works in that same folder without any additional privileges simply by renaming any of several previous versions of X264 to X264.EXE... so it's reasonable to assume that something in this version has changed that creates the issue.

[Dark Shikari]

Did you build both x264s in an identical build environment, with the same compiler and libraries?

[jdobbs]

Did you build both x264s in an identical build environment, with the same compiler and libraries? I didn't build them. I downloaded the builds from x264.nl and from the komisar site. Same for the older versions.

[jdobbs]

I looked a little and didn't see anything related to this. But I thought it odd so I thought I'd post it.

I'm doing some testing on r2245 (downloaded from www.x264.nl) with BD Rebuilder and got a failure when I tried to run it. I stepped back to r2230 and it worked again. So I pulled the command line and ran it from a DOS window. The error was "ratecontrol_init: can't open stats file". After a couple of tries I found that when running the command from a DOS window that was run as administrator, r2245 would run fine. A rights issue -- I guess -- but I don't see why. Why is it a rights issue with the new version but not with any of the older ones? The output folder has no special privileges.

Any help would be appreciated.

[Edit] Exact same peculiarity with the Komisar versionMark this up to voodoo. I downloaded again today after reinstalling the O/S. The new one ran, the old one failed. I did a compare, and it matched bit-for-bit. Anyway, I deleted the old copy and it works fine now.

[Selur]

I encoded a clip using "--ouput-csp rgb" and another using "--output-csp i444" and MediaInfo both times reports:
Color space : YUV
Chroma subsampling : 4:4:4

Is this a bug in x264, MediaInfo or am I missing something? (shouldn't the color space for the first one be RGB ?)

Cu Selur

[MasterNobody]

I encoded a clip using "--ouput-csp rgb" and another using "--output-csp i444" and MediaInfo both times reports:
Color space : YUV
Chroma subsampling : 4:4:4

Is this a bug in x264, MediaInfo or am I missing something? (shouldn't the color space for the first one be RGB ?)

Cu Selur
Both YUV 4:4:4 and RGB use same encoding tools in H.264 and the only difference are actual component values (GBR or YUV) and specified colormatrix in VUI. For RGB one mediainfo will report also:
Matrix coefficients : RGB

[Selur]

Ah, okay totally overlooked the 'Matrix coefficients', thanks for clearing that up. :)

[sl1pkn07]

one little question (i dont know is answer before), why not enabled make 8 and 10 depth bit in the same executable?

greetings

[Selur]

why not enabled make 8 and 10 depth bit in the same executable?
Because there is no option to compile x264 with 8 and 10bit support at the same time.
I asked quite some time ago about this and from what I remember one of the x64 developer replied (from memory) that the code paths are quite different and that it a would be a hassle to build a binary that supports both. (it would basically be a wrapper around the two versions)

[sl1pkn07]

I already knew it the flag, without flags (or --bit-depth=8) to 8 bits, or --bit-depth=10 for 10 bits

but did not know what the code paths you comment

and anhoter question, if build ffmpeg with x264 support (shared/static linked), need build ffmpeg two times, one enable for 8bits and other for 10bits?

[Selur]

afaik: yes (not sure if for a dynamically linked version just switching the x264 library would work)

[xooyoozoo]

I'm getting 'lossless' 10bit files that are larger than the 8bit version. Maybe I have a fundamental misunderstanding of qp=0 or 8 vs 10 bit x264, but shouldn't it be the other way around, or shouldn't the difference be at least closer to the 25% gap in channel information between 8b and 10b?

veryslow qp0 8bit:
yuv [info]: 1024x768p 0:0 @ 30/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High 4:4:4 Predictive, level 5.0, 4:2:0 8-bit
x264 [info]: frame I:2 Avg QP: 0.00 size:303568
x264 [info]: frame P:498 Avg QP: 0.00 size:186531
x264 [info]: mb I I16..4..PCM: 39.4% 13.1% 47.4% 0.0%
x264 [info]: mb P I16..4..PCM: 25.0% 7.5% 9.0% 0.0% P16..4: 29.3% 7.0% 11.0% 2.4% 1.3% skip: 7.5%
x264 [info]: 8x8 transform intra:18.0% inter:43.6%
x264 [info]: coded y,uvDC,uvAC intra: 98.2% 66.9% 66.2% inter: 74.2% 60.4% 60.1%
x264 [info]: i16 v,h,dc,p: 14% 86% 0% 0%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 25% 69% 2% 1% 1% 0% 1% 0% 0%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 59% 2% 3% 3% 2% 3% 1% 1%
x264 [info]: i8c dc,h,v,p: 25% 55% 20% 0%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 63.1% 7.1% 14.3% 4.6% 4.5% 1.6% 1.4% 0.6% 0.9% 0.3% 0.4% 0.3% 0.3% 0.2% 0.3% 0.2%
x264 [info]: kb/s:44879.78

veryslow qp0 10bit:
yuv [info]: 1024x768p 0:0 @ 30/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High 4:4:4 Predictive, level 5.0, 4:2:0 10-bit
x264 [info]: frame I:2 Avg QP: 0.00 size:450184
x264 [info]: frame P:498 Avg QP: 0.00 size:299578
x264 [info]: mb I I16..4..PCM: 42.9% 15.6% 41.2% 0.3%
x264 [info]: mb P I16..4..PCM: 23.8% 8.7% 9.6% 0.0% P16..4: 23.8% 4.9% 13.0% 5.0% 3.7% skip: 7.5%
x264 [info]: 8x8 transform intra:20.5% inter:33.2%
x264 [info]: coded y,uvDC,uvAC intra: 98.0% 68.2% 67.4% inter: 73.5% 63.1% 62.9%
x264 [info]: i16 v,h,dc,p: 12% 88% 0% 0%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 28% 70% 1% 0% 0% 0% 0% 0% 0%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 34% 59% 1% 1% 1% 1% 1% 0% 1%
x264 [info]: i8c dc,h,v,p: 20% 58% 22% 0%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 63.5% 15.8% 6.2% 5.3% 2.1% 1.8% 0.9% 1.2% 0.5% 0.6% 0.4% 0.4% 0.3% 0.3% 0.3% 0.3%
x264 [info]: kb/s:72043.18

x264 r2245. Source is yuv420 8 bit.

[kypec]

I'm getting 'lossless' 10bit files that are larger than the 8bit version. Maybe I have a fundamental misunderstanding of qp=0 or 8 vs 10 bit x264, but shouldn't it be the other way around, or shouldn't the difference be at least closer to the 25% gap in channel information between 8b and 10b?
x264 r2245. Source is yuv420 8 bit.

You have artificially expanded 8-bit data into 10-bit (without any meaningful information added) and then want to have those 10-bit stored losslessly in video stream. It's pretty obvious to me that the result of 10-bit lossless storage space occupation must be larger than the space that the same original occupies at 8-bit data width.