Weird x264 result

[PurpleMan]

Hello.

I wonder if anyone can shed light on this.
I recently encoded a movie from a Blu-ray source using the 64bit 10bit-color version of x264. The avisynth script's content was:

DirectshowSource("00800.m2ts", fps=23.976, framecount=205953, audio=false)
LoadPlugin("autocrop.dll")
Autocrop(mode=0)
ConvertToYV12().AssumeFPS(24000,1001)

I used the following command line:
"avs2yuv.exe" "VIDEO.AVS" -o - | "x264-10bit-x64.exe" --profile high10 --frames 205953 --preset veryslow --crf 17 --threads auto --thread-input --stdin y4m --output "VIDEO.264" -

The file encoded successfully and the resulting bitrate was 7268 kbit/sec (7,803,717,303 bytes).

However, when viewing the result I realized that the AutoCrop filter I was using cropped the video to 1916x800 instead of 1920x800 (because there were 2 pixels of a vertical black bar on the left). I then decided to re-encode, and altered the .avs for manual cropping:

DirectshowSource("00800.m2ts", fps=23.976, framecount=205953, audio=false)
crop(0,140,0,-140)
ConvertToYV12().AssumeFPS(24000,1001)

I then ran the exact same command as the first encode which ended successfully with the resulting bitrate of 7951 kbit/sec (8,537,333,752 bytes).

For the life of me, I can't understand how the addition of 4 pixels on the width (2 of them black bars) resulted in almost 700 more kbits per second on the same CRF value!

Any insight would greatly appreciated.

[Groucho2004]

It could well be that this is because x264 is more efficient with frame sizes that are mod16. Although I would not expect that much of a difference.

[LoRd_MuldeR]

Internally, a width of 1916 pixels gets padded to 1920 pixels anyway.

Though in the 1920 version, there will be a rather "sharp" edge (between the content and the "black area"), which might not be that easy to encode. At the same time, in the 1916 version, the video is padded in a way that is "cheap" to encode, i.e. there will be no such "sharp" edge.

[PurpleMan]

It could well be that this is because x264 is more efficient with frame sizes that are mod16. Although I would not expect that much of a difference.

I am aware of that, but we have the opposite case. Following that logic I'd expect the second encode to require LESS bits (1920 is a multiple of 16 while 1916 isn't), not almost 700 kbit/sec more.

[PurpleMan]

Internally, a width of 1916 pixels gets padded to 1920 pixels anyway.

I'm also aware of that. Unfortunately, this does not explain the need for so many additional bits.

[Groucho2004]

I am aware of that, but we have the opposite case. Following that logic I'd expect the second encode to require LESS bits (1920 is a multiple of 16 while 1916 isn't), not almost 700 kbit/sec more.
You're right. Not enough sleep last night. :)

[nhakobian]

Internally, a width of 1916 pixels gets padded to 1920 pixels anyway.

Though in the 1920 version, there will be a rather "sharp" edge (between the content and the "black area"), which might not be that easy to encode. At the same time, in the 1916 version, the video is padded in a way that is "cheap" to encode, i.e. there will be no such "sharp" edge.

This is exactly the reason the version with the black pixels left in has a larger bitrate.

I believe H.264 (and other similar formats) repeat pixels internally to pad to a mod16 width/height. This makes it "easy" to encode since there isn't as much high spatial frequency information to store (per block). When you leave the two pixels of black in, this creates a hard edge. Edges like this have information at very high spatial frequencies, and to maintain your requested quality, it must dedicate more bits to repesenting these high spatial frequencies.

Unless you have a specific necessity for keeping the resolution an exact value, I'd just stick with your first encode.

[Brother John]

Sticking with the first one might not be the best idea.

The 1920×1080 resolution is a special case because especially modern TV displays have the same resolution. I.e. when you crop only one dimension no scaling whatsoever is required for fullscreen playback. If you crop both dimensions the player will scale to the full 1920 width or 1080 height – whichever is reached first. The quality penalty (mainly loss of sharpness) can be quite noticable under these circumstances.

[PurpleMan]

This is exactly the reason the version with the black pixels left in has a larger bitrate.

I believe H.264 (and other similar formats) repeat pixels internally to pad to a mod16 width/height. This makes it "easy" to encode since there isn't as much high spatial frequency information to store (per block). When you leave the two pixels of black in, this creates a hard edge. Edges like this have information at very high spatial frequencies, and to maintain your requested quality, it must dedicate more bits to repesenting these high spatial frequencies.

Unless you have a specific necessity for keeping the resolution an exact value, I'd just stick with your first encode.

This, actually, makes sense. But still, 10% more bits?

[nhakobian]

This, actually, makes sense. But still, 10% more bits?

I do agree that this sounds like a lot, especially since you already are at a decently high bitrate. My intuition says something like this would increase the bitrate by a few percent, but I don't have any data to back this up.

Even if you included the non-deterministic nature of multithreading in x264 it shouldnt make this much of a difference. (You can encode very watchable SD material in the bitrate difference between the two versions!)

I'm just coming up with random ideas here, but maybe autocrop is doing something else besides just cropping. Maybe there is a colorspace shift between using DSS and autocrop and is being converted back to YV12 at the end that isn't occuring when using manual cropping?

These are just random ideas of course. Most likely everything is being done correctly. Maybe someone else who has run into this before can comment.

[ajp_anton]

The black bar likely changed slightly how CRF defines quality, and the quality of the whole image increased slightly in the higher-bitrate version.