Saturday, 11 September 2021

How to encode anime episodes to the smallest size, best quality, faster thank? Truth Is Nearer Than You Know

One of the main concerns here is that X265 drinks up a lot of your CPU in exchange for giving a very good clear video file.

I have done a lot, and when I say a lot, literally months (4 months =  ~120 days) of comparison with different types of x265 and x264 settings.

And at the end what software do I use to encode episodes? FFMPEG

Yup, it's as simple as that. Though older versions won't work out, the recent one's have latest x265 features after all. Just download it from google.

Look, I'm not going to waste your time to read all the stuff I want to say and I'll just give you the settings.

Here is the settings that I wrote on my python script:

{ 'c:a': 'aac', 'c:v': 'libx265', 'b:a': '192k', 'profile:v': 'main', 'x265-params': ':'.join([ 'me=2', 'rd=4', 'subme=7', 'aq-mode=3', f'aq-strength=1', f'deblock=1,1', f'psy-rd=1', f'psy-rdoq=1', 'rdoq-level=2', 'merange=57', 'bframes=8', 'b-adapt=2', 'limit-sao=1', 'frame-threads=3', 'no-info=1', ]), 'crf': 24.2, 'preset': 'slow', 'pix_fmt': 'yuv420p', 'vf': ','.join([ 'smartblur=1.5:-0.35:-3.5:0.65:0.25:2.0', 'scale=1920:1080:spline16+accurate_rnd+full_chroma_int' ]), 'metadata': 'Encoder Settings=Redacted, CPU - 2xAMD EPYC 7282 32 cores/64 threads, GPU - None used', 'color_range': 1, 'color_primaries': 1, 'colorspace': 1, 'color_trc': 1, }

And converting it into command line arguments:

ffmpeg -i input.mkv -map 0:v -map 0:a -b:a 192k -c:a aac -c:v libx265 -color_primaries 1 -color_range 1 -color_trc 1 -colorspace 1 -crf 24.2 -map 0:s? -pix_fmt yuv420p -preset slow -profile:v main -vf smartblur=1.5:-0.35:-3.5:0.65:0.25:2.0,scale=1920:1080:spline16+accurate_rnd+full_chroma_int -x265-params me=2:rd=4:subme=7:aq-mode=3:aq-strength=1:deblock=1,1:psy-rd=1:psy-rdoq=1:rdoq-level=2:merange=57:bframes=8:b-adapt=2:limit-sao=1:frame-threads=3:no-info=1 output.mp4 -y

Now if you have spare time to read my rantings about what I found when I was researching.

First of all you see that frame-threads over there? If you are running only one instance of ffmpeg command on your pc then no need of that. But yea having frame-threads to 3 gives you extra space threads/cores to encode more episodes parallelly (if you have equal or more than 16 total threads and on linux) if you have enough free threads/cores available. With the CPU I was using 2 x AMD EPYC 7282, 32 cores 2.8GHz 64 threads (I swear it was $260 when I bought it, during Covid rate changes in a blink of an eye) most of the time 90% of CPU was taken by FFMPEG when it was encoding 5 episodes at the same time. Others were for NGINX and Webserver.

You probably didn't notice it

But every average ~25 minute episode was taking almost 20 minutes to 1+ hours to encode depending on how many episodes were encoded in parallel. As I was hard following SubsPlease release, you can see the time difference.



Also please remember not to convert 480p or 720p of theirs into x265, instead use the 1080p and downscale it as needed for best results. Upscaling is not at all recommended in case you have only 720p source but yet want 1080p. But in case you do want to, spline16 is not recommended. You'll have to google it.

About the parameters inside x265-params, you can study it here:

Although that docs is for x265 cli and not for ffmpeg directly, those parameters are what is converted into ffmpeg x265-params. So instead of giving --param you give it under x265-params separating each by a colon(:). Do remember that not all parameters in that cli documentation are applicable for ffmpeg.

To make the encoding faster:

You can reduce merange=57 to something lesser like merange=32 or even lesser merange=16 and not any lesser than 16. Then why use 57? I have seen that on an overall comparison, there are some loss in line sharpness when merange is decreased. Most of the anime's it's fine to have 32 but I was aiming for all possible anime's. Also file size is slightly bigger (about ~1MB to 6MB) the lesser the merange is.
Remember that merange max value is 57 and also default value defined by encoder even without mention.

Hiding Information about encoding parameters:

no-info=1 hides the encoding parameters when writing the output file. Just remove it if you don't intend to hide it.

What about the other parameters inside x265-params?

Video Parameters:

  • libx265 obviously. Since NVENC encoder is not even an option to consider as it worsens quality.
  • Do not control the bitrate. Anime episodes should have variable bitrates, putting any kinds of limits will kill the colors in some awesome scenes, like I messed up SAO Alicization when I was encoding it on my local PC. It will also put banding on video.
  • slow is the best possible value for preset.
  • 24.2 is the overall best value for CRF. I have sometimes used 23 or 22 if the file size was too small and not of good quality. 25 or 25.4 if the file size was going too large. Higher than 25.4 is not recommended as it worsens the quality of the video at places you can't imagine.
  • main gave the best results for profile of video, I don't remember about other profiles.
  • yuv420p standard pixel format for any anime video.
  • Color Parameters: 
    • color_range, color_primaries, colorspace, color_trc was something I started using on a whim when I found out about it on an old anime forum, didn't see any significant differences but definitely felt like color loss after encoding was lesser when using it rather than when not using it.
  • Remove metadata, it's unrelated if you have any.
  • vf

Audio parameters:

So I'm using AAC - 192k bitrate for 1080p, 128k or 160k for 720p and 96k for 480p.

Very much recommended to use FDK_AAC rather than plain AAC. If you are on Windows, you can install personal use (non commercial) free version of FDK_AAC from here:

If you are going to use AAC and want the best results, remember to follow the below bitrates
  • Best Quality Lossless (recommended) - greater or equal to 192k
  • Better Quality - greater or equal to 160k and less than 192k
  • Above Average Quality - greater or equal to 128k and less than 160k
  • Average Quality - greater or equal to 112k and less than 128k
  • Low Quality (Small File Size) - greater or equal to 96k and less than 112k
  • Lowest Quality (Smaller File Size) - greater or equal to 64k and less than 96k
  • Worst Quality (File Size Negligible) - lesser or equal to 64k


1223 said...

Missing u SSA... Thanks for this

Hakase said...

Do you stop now making subs?

Unknown said...


Unknown said...

i dont understand anything, but thanks for your hardwork.

エース said...

I wonder who will be inheriting SSA's way of encoding...

Tsunami said...

I too will miss your subs. And also would like to know if you have ant recommendations for new groups to follow for subs?

Steven F said...

My PC isn't as beefy as it use to be and it takes about an hour to encode an episode, but the space savings are totally worth it.
Thank you so much for all the effort you've done over the months running SSAnime and for the magical script you've provided that does everything we need. My old re-encode setup required manually remuxing the new video back into the MKV �� and your way is infinitely preferable.

Once again, thank you so much and good luck in your future endeavours!

Maxlex said...

It seems there's an error in the command line - the option '-map 0:s?' shouldn't have the question mark - at least it only worked when I removed it. I too would like to thank SSAnime for all the hard work and great encodes, and I will miss you

floatpoint said...

Thank you for releasing your encoding technique (was thinking you would release the whole project including site and subsplease/nyaa torrent scraping, but beggars cant be choosers).

The encoding code above indeed works though I see why a powerful dedicated server is required. It took me 2h30m to do a single episode of reborn assassin averaging +/-5fps with my cores maxed out. Once again the fact you lasted so long popping out over $300 per month is admirable and I am greatful SSA even existed. Take of your self.

v2 said...

you will be greatly missed

Unknown said...

Have you really stopped uploading content? Can anyone else confirm this?

RiiKu said...

hey SSA What about boruto naruto net generations are you going to stop uploading it too since im downloading it from you and i can't stop at ep 220 whats wrong that he stop uploading? Jahy sama too its not finished yet

Unknown said...

Just wanna say thank you for doing this work & making how you encode public.

Unknown said...

Would you be willing to share the python script (for personal use)? Or will I have to try to do some coding by myself?

Unknown said...

Thanks for your hard work, the encoding info, and sorry to see you go. Best luck in the future!

why can't i post anonymously? said...

would've been best if subsplease learned from you and did small encodes

Sahbiot said...

youre a legend

エース said...

Sad that none of the present encoders ever took up SSA's way of encoding... :(

Duker said...

I'm a bit befuddled as to why you'd limit sao, in my experience it's detrimental to do so, and it's even specifically recommended in kokomin's article you link to to not limit it for high CRFs (which 24.2 absolutely qualifies as).

For my personal encodes I ended up adopting setting deblock, merange and the smartblur filter (though weaker, 1.5:-0.25:-3.5:0.65:0.20:2.0), that combined with rc-lookahead 250, crf 24 and using opus instead of aac gave me smaller size, slightly faster encodes and yet also better quality according to ssim and psnr. (b-frames, aq-mode and psy-rd was already the same)

PiggyPorky said...
This comment has been removed by the author.
PiggyPorky said...

I read FFMPEG encode faster using NVIDIA GPU. Anyone knows how to do that? The current SSA settings uses CPU

Tinosoft said...

I used your preset in HandBrake, 408 Mbytes output mkv from a 1.8 Gbytes input file from PuyaSubs, 1080p. Thank you.

Tinosoft said...

I made an Image Comparison

Post a Comment