x264 jump in file size

[Gregleto]

Hi all,

Below are the MediaInfos from two recent x.264 encodes. These are identical source files, both run at CRF 28, on the same server, but on two different version of our Telestream encoder. The first was created prior to upgrading the Telestream system. It has a file size of 13.8 MiB. The second was created immediately after an upgrade of the Telestream. It inexplicably has a file size of 19.2 MiB... a jump of nearly 40%. I'm assuming the jump in file size can be explained by changes Telestream in the default x.264 settings, which can be seen in the MediaInfos below. I'm hoping someone on the forum could look at those differences and let us know which changed settings are most likely contributing to the higher file size.

Thanks in advance for the help.

Gregleto


Prior to the upgrade (13.8 MiB
General
Complete name C:\Users\Greg Letourneau\Desktop\New Vantage testing\Test 360p\test_x264_vantage_28-crf_presets.mp4
Format MPEG-4
Format profile Base Media / Version 2
Codec ID mp42
File size 13.8 MiB
Duration 2mn 10s
Overall bit rate 887 Kbps
Encoded date UTC 2013-09-04 10:44:16
Tagged date UTC 2013-09-04 10:44:16

Video
ID 1
Format AVC
Format/Info Advanced Video Codec
Format profile Baseline@L3.0
Format settings, CABAC No
Format settings, ReFrames 2 frames
Codec ID avc1
Codec ID/Info Advanced Video Coding
Duration 2mn 10s
Bit rate 783 Kbps
Width 640 pixels
Height 360 pixels
Display aspect ratio 16:9
Frame rate mode Constant
Frame rate 29.970 fps
Color space YUV
Chroma subsampling 4:2:0
Bit depth 8 bits
Scan type Progressive
Bits/(Pixel*Frame) 0.113
Stream size 12.2 MiB (88%)
Writing library x264 core 129
Encoding settings cabac=0 / ref=2 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=28.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language English
Encoded date UTC 2013-09-04 10:44:16
Tagged date UTC 2013-09-04 10:44:16

Audio
ID 2
Format AAC
Format/Info Advanced Audio Codec
Format profile LC
Codec ID 40
Duration 2mn 10s
Bit rate mode Constant
Bit rate 93.6 Kbps
Nominal bit rate 128 Kbps
Channel(s) 2 channels
Channel positions Front: L R
Sampling rate 44.1 KHz
Compression mode Lossy
Stream size 1.46 MiB (11%)
Encoded date UTC 2013-09-04 10:44:16
Tagged date UTC 2013-09-04 10:44:16


 
After the upgrade (19.2 MiB)
General
Complete name C:\Users\Greg Letourneau\Desktop\New Vantage testing\Bad Vantage week\test_x264_28-crf_fast_02 (1).mp4
Format MPEG-4
Format profile Base Media / Version 2
Codec ID mp42
File size 19.2 MiB
Duration 2mn 10s
Overall bit rate 1 234 Kbps
Encoded date UTC 2013-09-09 14:43:56
Tagged date UTC 2013-09-09 14:43:56

Video
ID 1
Format AVC
Format/Info Advanced Video Codec
Format profile Baseline@L3.0
Format settings, CABAC No
Format settings, ReFrames 2 frames
Codec ID avc1
Codec ID/Info Advanced Video Coding
Duration 2mn 10s
Bit rate 1 129 Kbps
Width 640 pixels
Height 360 pixels
Display aspect ratio 16:9
Frame rate mode Constant
Frame rate 29.970 fps
Color space YUV
Chroma subsampling 4:2:0
Bit depth 8 bits
Scan type Progressive
Bits/(Pixel*Frame) 0.164
Stream size 17.6 MiB (92%)
Writing library x264 core 129
Encoding settings cabac=0 / ref=2 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=6 / psy=0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=32 / lookahead_threads=5 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=28.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:0.00
Language English
Encoded date UTC 2013-09-09 14:43:56
Tagged date UTC 2013-09-09 14:43:56

Audio
ID 2
Format AAC
Format/Info Advanced Audio Codec
Format profile LC
Codec ID 40
Duration 2mn 10s
Source duration 2mn 10s
Bit rate mode Constant
Bit rate 93.6 Kbps
Nominal bit rate 128 Kbps
Channel(s) 2 channels
Channel positions Front: L R
Sampling rate 44.1 KHz
Compression mode Lossy
Stream size 1.46 MiB (8%)
Source stream size 1.46 MiB (8%)
Encoded date UTC 2013-09-09 14:43:56
Tagged date UTC 2013-09-09 14:43:56

[Dark Shikari]

It looks like Telestream for some reason went out of the way to turn off all the psy optimizations in x264, completely destroying its compression and quality (or you somehow disabled it in their settings?). Without psy optimizations, x264's compression is going to be ~30-50%+ worse in many cases, and file sizes will be quite different.

If they intentionally did this, I suggest using a better x264 frontend.

[Gregleto]

We didn't make any changes. However, we can make changes in the command line. Can you tell us what commands we need to add back to get the psy optimizations back to their typical defaults?

Thanks again!

Gregleto

[Dark Shikari]

I'm not sure -- it depends how they disabled it; what is the current commandline?

[Selur]

here are the differences I see, based on the 'Encoding Settings' from the MediaInfo output:
1st file 2nd file
--psy-rd 1.00:0.00 --no-psy 0
--chroma-qp-offset -2 --chroma-qp-offset 0
--threads 6 --threads 32
--lookahead-threads 1 --lookahead-threads 5
--aq-strength 1.00 --aq-strength 0.00


Cu Selur

[Gregleto]

We aren't able to see the current command line settings per se, but we have a CLI that allows us to insert commands that override the current default settings. To see the current settings we run a MediaInfo on the output file. Those settings were provided in the previous post. Here they are again...

Prior to upgrade
cabac=0 / ref=2 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=28.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00


After the upgrade
cabac=0 / ref=2 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=6 / psy=0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=32 / lookahead_threads=5 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=28.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:0.00

[Blue_MiSfit]

Are you running the Vantage CLI directly via your own automation, or are you using Vantage watch folders?

If you're using Vantage watch folders, the GUI is very easy to adjust to whatever x264 settings you want. Last I checked, the defaults were quite similar to x264.exe's defaults of using --preset medium with psy enabled. Perhaps using the Vantage CLI directly has different defaults? In any case, just specify the settings you want :)

Also, it's "x264", not "x.264". Telestream's marketing material and sales / tech people are wrong :devil:

For those who are interested, Vantage is a very cool pro encoder that uses x264 as part of a large workflow. You can do interesting things like build a watch folder that can accept all sorts of media, and sort it based on header values or actual content. For example, you could detect 29.97 fps content that is actually interlaced, and handle that via simple deinterlacing. Alternatively, you can detect 3:2 cadence patterns, and apply IVTC. These workflows can all feed into x264, but with some neat tricks, like doing scaling to multiple resolutions on the GPU, and encoding all versions in parallel with OpenCL acceleration. They also do some decode on the GPU, and can do things like deinterlacing there as well, though any GPU acceleration requires that you buy turnkey hardware from them. Finally, it can cluster and load balance across multiple Vantage servers, which makes scaling out encoding easy.

It's NOT cheap, but all this combined with Telestream's broadcast pedigree makes it a pretty great product IMO.

[Gregleto]

We are running Vantage using watch folders. The problem is that previous versions of Vantage had most x264 settings set at their recommended defaults. Once we upgraded the transcoder to the latest version (two weeks ago) we found the some of the defaults were set differently. They had psy shut off altogether, and that's what led to the big jump in file sizes.

Regarding your observations of Vantage, we agree that it enables some very creative workflows. That's why we use it. However, their implementation of x264 is really crippled. They did not enable Constant Quality or Constant Rate Factor through their GUI. So you can only use ABR unless you modify the command line yourself. To make matters worse, it's not possible to use 2-pass encoding at all with the Vantage base x264 implementation... even through the command line.

Having said all that, we need it for it's workflows, so I'd really love to figure out precisely what we need to put in the command line to turn the psy optimizations back on.

Thanks for everyone's comments.

Gregleto

[Gregleto]

By the way, thanks for the tip on x264 vs x.264. I have hundreds of hours of research and use over the past couple of months and I never noticed the difference. Classic case of not seeing the forest for the trees :-)

[Blue_MiSfit]

Got it. Did you open a support ticket with Telstream? That sounds like a mistake to me :)! Psy should be enabled in basically every real-world use case (i.e. not doing PSNR or SSIM comparisons).

I'll have to bother them about supporting CRF in the GUI. I imagine they figured most users are using CBR, as this is required for many applications still.

Let us know what you hear back. They're pretty good folks.

[Gregleto]

We're working with them pretty closely. (I'm a former employee of Anystream, which was bought by Telestream a couple of years back), so I still have some contacts there. If you're using x264 with Telestream I wouldn't recommend upgrading until they bring the new version in line with the recommended default settings. If you look at the settings I provided above, not only are psy optimizations turned off, but I don't understand what they've done with threads either. It jumped from 6 threads (1 lookahead thread) prior to the upgrade, to 32 threads (5 lookahead threads) after the upgrade. I need to verify the configuration of the server this is running on, but it's a Dell R710 with no more than 6 cores (most likely 4 cores). I don't know why it's setting 32 cores in x264. I also don't know what the implications of running too many cores has on quality, file size, or speed (if any). If you have any insight into that I'd appreciate hearing it.

Thanks,

Gregleto

[Asmodian]

Using many threads does decrease quality a small amount, I believe Dark Shikari mentioned the point where it actually starts having a negative impact on quality is around 18 threads. 32 threads is too many.

[Gregleto]

Thanks. For some reason Telestream took the threads off auto and set them to 32 (for speed reasons according to them). I just met with them this afternoon and we're working closely to get as many settings as possible back to default.

Interestingly, we did some quick testing with different thread settings and found that 32 threads seems to decrease the file size slightly (7-10%). Can you think of any reason more threads would reduce file size? Admittedly, it wasn't a very rigorous test so we might not be comparing apples to apples, but I was surprised.

Thanks for you input.

Gregleto

[Atak_Snajpera]

most likely quality also dropped. like it was mentioned before too many threads is not good for quality.

[Blue_MiSfit]

Yeah, that's way too many :)

I'm not sure if this was ever improved / fixed, but I saw some really nasty VBV issues when using so many threads in conjunction with CBR with a 1 second buffer. Periodic explosive macroblocking is how I'd describe it. It was perfectly controllable if you limited threads to about 12.

[Gregleto]

I think Telestream may have been trying to optimize x264 for their Lightspeed server, which is a purpose-built server for transcoding. It has Dual Eight Core Intel Sandy Bridge CPUs and Two NVidia Tesla GPU cards. If that's the case, they left the 99% of us that don't use that server in the lurch. But again, we're working with them to fix that. I'm curious, however, if x264 would recognize the GPUs with the threads set to auto?

[Asmodian]

x264 doesn't use GPUs for anything but opencl lookahead, if enabled. GPUs are not recognized as such, threads auto or not. The GPU drivers do the opencl; it could actually be done on the CPU for all x264 knows.

I assume the Tesla's are used for non-x264 parts of their workflow.

P.S. My 18 threads was in the context of 1080p video with no VBV restrictions, I am not surprised a lot of factors influence where too many threads starts to cause problems.

[Gregleto]

Thanks! That makes perfect sense. They are probably using GPUs to accelerate some other part of the encoding process.

Anyway, regarding threads, I've read several references to the following... "The speed gain should be slightly less than linear until you start using more than 1 thread per 40px of vertical video, at which point the gain from additional threads sharply decreases."

With that in mind, would it not be more efficient to set threads according to the 40px guidance, rather than the available processor threads? In this case we'd set our 480x360 encodes to use 9 threads (360/40=9) or maybe something slightly higher like 12. We'd set our 720p encodes to 18 threads, etc. We're running dual 6-core xeons so we have plenty of headroom on available threads.

Or, am I not properly understanding the 40px guidance?

[Dark Shikari]

Yes, you shouldn't set the number of threads significantly higher than 1 per ~40 pixels of height; they just won't really do anything and will probably reduce efficiency.