Content Creators // YouTubers - x265 Rendering Corner

Arts & Media Visual Arts & Design
1

Hello fellow Level 1 Techies! Roughly a week ago I discovered YouTube is now accepting the x265/HEVC codec for uploads (I’m a little late to the party, I know). Anyway, that’s where I went into full nerd mode. I studied up on x265 through lots of google searches but I never found a good discussion thread talking about x265 for regular content creators. I’ve learned a ton over the last week, but I don’t have my FFmpeg settings perfected like I did using old fashioned x264.

I’m hoping by sharing setting, tips and observations on this thread we all could probably dial in our render settings a little better for the best x265 performance.

The CarryTrainer.Editor Workflow

My videos start in Davinci Resolve. Although Resolve is awesome, I’ve never been happy with the h.264 options and output…. So my finished videos are rendered out of Resolve in 2160p Uncompressed 8-bit YUV422 or Cineform 10-bit 422 with “Best” if HDD space is an issue.

Next, the big un-molested video files are fed into FFmpeg with something like the following settings:

ffmpeg -i input.mov -c:v libx264 -preset slow -tune film -g 12 -bf 2 -crf 17 -pix_fmt yuv420p -c:a aac -b:a 384k -movflags faststart A:\RENDERS_BIN\output.mp4

As a yardstick of comparison my Ryzen 1700X was generally rendering this around 25% of real-time speed… not awesome speed wise, but the video image quality was awesome. I would move the CRF between 16-18 depending on the content and how much time I had for uploading.

Moving over to x265… although the command line is very similar using libx265 is a different animal. The Slow Preset of x265 on my machine is an understatement… 8 cores is not enough for the slow preset. On my machine I was getting around 5-8% speed. Scanning various blog posts and tech articles I got the impression actually MEDIUM lives up to its name as the best balanced choice for rendering time vs. compression.

Anyway, these are my current x265 render settings:

ffmpeg -i input.mov -c:v libx265 -preset medium -g 12 -bf 2 -crf 17 -pix_fmt yuv420p -c:a pcm_s16le -movflags faststart A:\RENDERS_BIN\output.mov

(aside from using x265, I figured out how to copy uncompressed audio from my Davinci Resolve source file in the line above)

Having said all that I have a few questions to through out there.

  1. Has anyone gotten a good sense of how speed presets for Fast and Medium compare in terms of speed and compression?

  2. According to x265.org a CRF rating of 28 in x265 is equal to CRF 23 in x264 in terms of perceptual quality… Not everyone seems to believe that and I’ve seen SSIM measurements posted that suggest otherwise. I’m frankly not sure what to think yet so CRF 18 feels safe.

  3. Got any tips on how I can optimize my x265 render settings for talking heads and action/gun footage?

I look forward to your responses.

Cheers,

-CarryTrainer.Editor

2 Likes
2

Handy FFmpeg Tips… because x265 can take a while…

HOW TO PAUSE FFMPEG - if you’re doing big renders and need to pause it, in windows with command window selected hit the “Pause/Break” key. That will stop it. Then hit enter to resume rendering.

Also, you set FFmpeg to low priority in the windows task manager on the details tab for happier multi-tasking. For example, I’ve got a monster 3 hour video rendering in FFmpeg while I’ve got After Effects open doing a slow single threaded render

1 Like
3

I added code ticks to your post so it would be easier to read.

4

@Dynamic_Gravity thanks, for the code ticks. I didn’t know how to do that, Meanwhile…


Here’s the latest news I’ve found on x265 development from the recent VLC Developers Days Conference. I’m jealous of the AVX512 implementation (20% boost) for intel processors.
5

You’re welcome.

This platform supports markdown.

There are also editing tools when you do make a post.

6

I found a blog article with some great charts on CRF // preset speed and how that can impact files size and encoding time with a short 4k clip.

https://stevens.li/guides/video/hevc-x265-encoding-guide/

He is using the 2.5 version of HEVC, not the current 2.8 encoder version, but this is the best recent study I’ve come across.

Looking at the speed preset graphs, it’s worth noting that files sizes seem relatively equal at any given CRF level between veryfast to placebo speed. Conversely, ultrafast and super fast produce notably smaller files, which I assume is at the loss of video image quality.

7

Also, I found a massive x265 encoding thread on Doom9 with plenty of detailed info.

https://forum.doom9.org/showthread.php?t=168814

8
9

Sweet! Thanks @anon25377527. This is awesome news.

I just tried the command and got a no hvec_amf error… It looks like I can do this with with my R9 390 graphics card though…

I need to add this AMF-1.4 library to my FFmpeg program with Visual Studio solutions. This is a little over my head but I’ll figure it out.

It’s time for me to watch a compiling for dummies training video.

Thanks again @anon25377527!

UPDATE: Just found out my dated R9 390 can only encode x264, so no dice. :persevere:

10

CC: @FurryJackman

11

You guys called?

NVENC H265 is more than often better on Linux cause AMD VA-API stuff isn’t really used as much, since OBS didn’t use it until a very recent commit in the Git verison.

However, NVENC H265 crashes OBS on Windows, so I don’t recommend it for live encoding. For transcoding, it’s really damn fast on Pascal.

Some services though, if they take in H265, only take it in at 0-255 luminance levels. Vimeo suffers from this because it has to transcode back to H264.

12

Thanks @FurryJackman, good info. Any idea what the quality is like with NVENC HEVC encoding?

I generally hear software encoding is better using the CPU, albeit a lot slower. I’m still curious what the quality gap is though… and how that might very between cards. I’m guessing they use something like the “very fast” speed preset and strict bit-rates rather than CRF.

Meanwhile, I haven’t touched OBS in a year or so… is GoPro Cineform a capture option on there? Cineform went open source fairly recently. I’ve been really impressed with it’s speed and size outputing from Davinci Resolve.

13

Here’s a slide I pulled from a recent Multicoreware presentation on h265:

x265_presets
x265_presets.png1352x755 140 KB

14

DNxHD is far more standardized in terms of OBS capture. If you have the right parameters set, you can capture DNxHD MOV files directly from OBS.

Big thing about NVENC is Hardware implementations only use I and P frames out of the Group of Pictures, B-frames are absent, and that’s where x264 and x265 take advantage of B-frames.

15

Right on, DNxHD for OBS is even better for recording… and it’s no B-frames on NVENC. Interesting, I see.

16

Real World H265 vs H264 Encoding Case Study

I’ve got a good rendering case study to share. I have a very large medical training video I’m working on for Carry Trainer… 3 hours and 12 minutes of 2160p video. I’ve rendered the video in both codecs with a Ryzen 1700X clocked at a flat 4 ghz… the video source is a 1.1 TB 10-bit 422YUV Cineform file with 16-bit pcm uncompressed audio.

  • x264 (CRF 18, YUV420 & Slow Preset with uncompressed pcm audio) - The average encoding speed was about 7 fps and the finished file size was 99 GB.

  • x265 (CRF 18, YUV420 & Medium Preset with uncompressed pcm audio) - The average encoding speed here was about half, at 3.5 fps, with a finished file size of 51 GB

I don’t have anything scientific, but quality wise both finished files look really good as you’d expect.

YOUTUBE X265 X265 & X264 PROCESSING PROBLEMS

Meanwhile, and more importantly, it seems like YouTube may not be able to process x265 videos this big! I’ve uploaded the x265 video twice.

  • The first one was a slightly larger CRF 17 video and YouTube failed to process it at all over 24 hours… The processing time estimates suggested it was stuck going in processing loop every four hours. After a day I deleted it and decided to try again with a fresh CRF 18 file… I wasn’t sure if it was randomly bad luck or really the x265 codec.
  • The second upload was the 51 GB file mentioned above. That one finished uploading yesterday around midnight. Although that video did process, it hasn’t moved past 360p so far… https://youtu.be/OjM8TtgAXp0

To cover my ass I’ve had the huge x264 version uploading as well. Although a pain to upload, that should definitely work once it’s finally up there. [Ack! this isn’t working either. Earlier this year in Jan. I successfully uploaded a three and a half hour 83 GB h264 video. That must have been close to the limit.]

Getting back to YouTube and x265… I’ve uploaded three smaller videos (all under 4 GB) so far without any problems. One was even higher quality, CRF 17 and 422.

17

Gamers Nexus got around huge file sizes by just getting Google Fiber in Cary, NC.

1 Like
18

Oh no… the x264 version of the giant TCCC video is stuck at 360p too! I think I’m hitting the YouTube Video processing wall…

h264 Ver: https://youtu.be/UJ7Lcybe2ww (Deleted after staying at 360p for over 24 hours)
h265 Ver: https://youtu.be/OjM8TtgAXp0 (Deleted after staying at 360p for over 48 hours)

I didn’t expect this! Now I’m scrambling to make a good 1440p version.

[Update: I found another YouTuber having this same problem with 1080p videos. See below.]

19

How More CPU Cores Scales for x265 4k HDR Encoding

I can across this good blog post showing the benefits of lots of cpu cores on a “veryslow” 4k HDR encode:

With HEVC 2.8 the gains start to diminish somewhat moving beyond 32 cores. This is good information if your shopping for a threadripper!

20

Is it too out of topic to mention that google and almost all other companies touching media formats have created AV1 to avoid h265 licensing fees? and are doing their best not to use h265? while AV1 encoders are not yet ready and hardware support doesn’t exist yet all major browsers now support AV1 for that reason, the MPEG Group have pushed too hard this time

1 Like