Answers.Body: <p>The whole one day I dedicated to testing various scenarios. The following applies to this particular series in this particular quality, so <strong>I don't say it applies generally</strong>. So in this case the following applies:</p>
  
  <ul>
  <li><p><strong>file sizes</strong> at the very same settings with only <code>medium</code> and <code>veryslow</code> preset changed vary negligibly: ~ -10 MiB on average in favor of <code>veryslow</code> preset</p></li>
  <li><p><strong>visual quality</strong> at a very close look is rather the same in either <code>medium</code> or <code>veryslow</code> preset</p></li>
  </ul>
  
  <p>One thing solved. I have changed the preset to <code>medium</code>.</p>
  
  <hr>
  
  <ul>
  <li>at a very close look, <strong>the source videos are not in such a high quality as I thought</strong>, that explains why x265 compresses to almost 1/4 of the original size</li>
  </ul>
  
  <p>Another mystery solved.</p>
  
  <p>Provided I now transcode at 25 fps, I have raised the RF to 20.</p>
  
  <hr>
  
  <ul>
  <li><strong>RAMDisk</strong> does not provide benefit in this case, both for <code>medium</code> and <code>veryslow</code> preset; I ended up with RAID6 as the source and SSD as the output drive</li>
  </ul>
  
  <p>The inconvenience of moving files to RAMDisk solved.</p>
  
  <hr>
  
  <p>To answer the question, <strong>the CPU time was not spent well at all</strong>.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-09T01:09:13.157Z
Answers.LastActivityDate: 2016-12-09T01:09:13.157Z
Answers.UserDisplayName: Vlastimil Burián
Answers.Body: <p>In my experience, the <code>slow</code>-er presets make a difference when you have moving objects on the scene. AFAIK, the one of the main improvements area in x265 is the "prediction" and reuse of info about objects moving in the scene.</p>
  
  <p>The more computing power the encoder spends on finding these moving objects and the way to encode them, the better quality (or smaller bitrate) you get.</p>
  
  <p>So, the answer is: It depends on the content of your clips and what do you want to do with the result. Do you need a good quality of every single frame? (Security camera) Then it's worth encoding with <code>slow</code> and <code>-qb</code>. Is it just an informative recording? Then go with <code>medium</code> and <code>crf 28</code> and <code>-tune film</code>. </p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-03-31T04:53:36.167Z
Answers.LastActivityDate: 2020-03-31T04:53:36.167Z
Answers.UserDisplayName: Ondra Žižka
Body: <p>I am in a process of transcoding 100+ High <strike>Quality</strike> Bitrate 720p <a href="https://en.wikipedia.org/wiki/Matroska" rel="nofollow noreferrer">MKV</a>s containing <a href="https://en.wikipedia.org/wiki/X264" rel="nofollow noreferrer">H.264 (x264)</a> to <a href="https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding" rel="nofollow noreferrer">H.265 (x265 / HEVC)</a>.</p>
  
  <p>I do this with <a href="https://en.wikipedia.org/wiki/HandBrake" rel="nofollow noreferrer">HandBrake</a> software under Linux <a href="https://en.wikipedia.org/wiki/Debian" rel="nofollow noreferrer">Debian</a> 9 on <a href="https://ark.intel.com/products/75461/Intel-Xeon-Processor-E3-1225-v3-8M-Cache-3_20-GHz" rel="nofollow noreferrer">Intel Xeon E3-1225 v3 3.2GHz 4-core</a>.</p>
  
  <p>Various versions follow.</p>
  
  <p>Kernel:</p>
  
  <pre><code>4.8.0-1-amd64
  </code></pre>
  
  <p><a href="https://en.wikipedia.org/wiki/HandBrake" rel="nofollow noreferrer">HandBrake</a>:</p>
  
  <pre><code>0.10.5 (x86_64)
  </code></pre>
  
  <p><a href="https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding" rel="nofollow noreferrer">x265</a>:</p>
  
  <pre><code>2.1-2
  using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
  </code></pre>
  
  <p>I have these settings applied, according to <a href="https://en.wikipedia.org/wiki/MediaInfo" rel="nofollow noreferrer">mediainfo</a>:</p>
  
  <pre><code>Encoding settings: wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=3 / tu-inter-depth=3 / me=3 / subme=4 / merange=57 / rect / amp / max-merge=4 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=240 / min-keyint=24 / scenecut=40 / rc-lookahead=40 / lookahead-slices=0 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=5 / limit-refs=1 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / log2-max-poc-lsb=8 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=21.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30
  </code></pre>
  
  <p>In short I have applied Constant Quality RF21 and at <a href="https://x265.readthedocs.io/en/default/presets.html#presets" rel="nofollow noreferrer">veryslow preset</a>.</p>
  
  <p>Originals are all at fixed 2 GiB size. The sizes my encodes differ (you can deduce how much time it took too from the file list):</p>
  
  <pre><code>494M Dec  7 07:02 S05E16.mp4
  551M Dec  7 00:14 S05E17.mp4
  654M Dec  6 16:11 S05E18.mp4
  668M Dec  6 08:10 S05E19.mp4
  </code></pre>
  
  <p>The original files have these settings applied:</p>
  
  <pre><code>Encoding settings: cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=5670 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
  </code></pre>
  
  <p>The question is, is the CPU time <em>well spent</em>? I mean, can I do any obvious optimizations to speed things up without having lower quality and / or larger files as a result?</p>
  
  <p><strong>EDIT1</strong>:</p>
  
  <p>Citation from <a href="https://x265.readthedocs.io/en/default/presets.html#presets" rel="nofollow noreferrer">the official source</a>:</p>
  
  <blockquote>
    <p>x265 has ten predefined --preset options that optimize the trade-off between encoding speed (encoded frames per second) and compression efficiency (quality per bit in the bitstream). The default preset is medium. It does a reasonably good job of finding the best possible quality without spending excessive CPU cycles looking for the absolute most efficient way to achieve that quality. When you use faster presets, the encoder takes shortcuts to improve performance at the expense of quality and compression efficiency. When you use slower presets, x265 tests more encoding options, using more computations to achieve the best quality at your selected bit rate (or in the case of –crf rate control, the lowest bit rate at the selected quality).  </p>
  </blockquote>
  
  <p><strong>EDIT2</strong>:  </p>
  
  <p>Hardware configuration</p>
  
  <hr>
  
  <p>Type: Dedicated server of mine. Currently used only to transcode videos.</p>
  
  <p>CPU: <a href="https://ark.intel.com/products/75461/Intel-Xeon-Processor-E3-1225-v3-8M-Cache-3_20-GHz" rel="nofollow noreferrer">Intel Xeon E3-1225 v3 3.2GHz 4-core</a></p>
  
  <p>GPU: No dedicated card, only integrated</p>
  
  <p>RAM: 32GB ECC 1600MHz</p>
  
  <p>Disks:</p>
  
  <ol>
  <li><p>SSD; used for system</p></li>
  <li><p>HDDs in RAID6; used for writing the output videos</p></li>
  <li><p>RAMDisk 20GB; used for reading the source videos</p></li>
  </ol>
  
  <p><strong>EDIT3</strong>:</p>
  
  <p>With regard to the comment about swapping the memory, I have had set <a href="https://en.wikipedia.org/wiki/Swappiness" rel="nofollow noreferrer"><code>vm.swappiness</code></a> = 1.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-07T10:11:48.457Z
Comments.Text: `veryslow` takes a lot more time for a marginal improvement. I would suggest `medium` preset with a lower CRF.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-08T05:19:01.213Z
Comments.Text: Remember too that the files will have the same quality regardless of the speed setting, using veryslow will just spend more time making it (as Mulvya said, marginally) smaller. So you can prioritise any two out of: speed, quality or file size.
Comments.UserDisplayName: stib
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-08T05:22:56.780Z
Comments.Text: Have you tried running more than one encode in parallel? With multiprocessor machines this can sometimes lead to dramatic reduction in the overall time. Not sure if you can run more than one instance of Handbrake, but you certainly can with ffmpeg. Two or more parallel encodes means that while one is not using the CPU, e.g. during disk i/o, the other will soak up the spare cycles. As long as you don't use all the memory on your system, because then it will start swapping to disk and things will go way slower. I'd suggest monitoring the CPU, disk I/O and memory usage during the encodes to see.
Comments.UserDisplayName: stib
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-08T05:37:13.517Z
Comments.Text: no, see the last sentence: (or in the case of –crf rate control, the lowest bit rate at the selected quality). IOW if you use crf the quality is constant, just the size or encoding speed varies.
Comments.UserDisplayName: stib
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-08T05:42:46.757Z
Comments.Text: Well then you need to prioritise size over time, given that quality is constant. Just BTW how long term are you talking?
Comments.UserDisplayName: stib
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-08T05:44:31.423Z
Comments.Text: @stib ~ 10 years
Comments.UserDisplayName: Vlastimil Burián
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-08T05:51:21.787Z
Comments.Text: You should be right with h.265 then. If you were talking 100+ years I'd be suggesting an open source codec/container.
Comments.UserDisplayName: stib
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-08T07:43:21.330Z
Comments.Text: You could check https://software.intel.com/en-us/intel-media-server-studio/try-buy if you want an encoder that is faster. It's not intended for end user like handbrake, but ships with example code.
Comments.UserDisplayName: dnigmig
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-08T08:03:45.013Z
Comments.Text: To the OP, you cut out the relevant clause of the sentence you bolded " *to achieve the best quality at your selected bit rate* ". But since you are using CRF mode, the next part is the actual relevant part: "*or in the case of –crf rate control, the lowest bit rate at the selected quality*". And with slow presets, the difference in bitrate is small but the time spent is much more.
Comments.UserDisplayName: Gyan
Tags: <transcoding><h.264><performance><handbrake><h.265>
Title: Transcoding 100+ files from H.264 to H.265
UserDisplayName: Vlastimil Burián
ThreadText: # Transcoding 100+ files from H.264 to H.265
  
  (Asked by: username_0 on 2016-12-07)
  
  I am in a process of transcoding 100+ High Quality Bitrate 720p [MKV](https://en.wikipedia.org/wiki/Matroska)s containing [H.264 (x264)](https://en.wikipedia.org/wiki/X264) to [H.265 (x265 / HEVC)](https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding).
  
  I do this with [HandBrake](https://en.wikipedia.org/wiki/HandBrake) software under Linux [Debian](https://en.wikipedia.org/wiki/Debian) 9 on [Intel Xeon E3-1225 v3 3.2GHz 4-core](https://ark.intel.com/products/75461/Intel-Xeon-Processor-E3-1225-v3-8M-Cache-3_20-GHz).
  
  Various versions follow.
  
  Kernel:
  
  ```
  4.8.0-1-amd64
  
  ```
  
  [HandBrake](https://en.wikipedia.org/wiki/HandBrake):
  
  ```
  0.10.5 (x86_64)
  
  ```
  
  [x265](https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding):
  
  ```
  2.1-2
  using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
  
  ```
  
  I have these settings applied, according to [mediainfo](https://en.wikipedia.org/wiki/MediaInfo):
  
  ```
  Encoding settings: wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=3 / tu-inter-depth=3 / me=3 / subme=4 / merange=57 / rect / amp / max-merge=4 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=240 / min-keyint=24 / scenecut=40 / rc-lookahead=40 / lookahead-slices=0 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=5 / limit-refs=1 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / log2-max-poc-lsb=8 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=21.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30
  
  ```
  
  In short I have applied Constant Quality RF21 and at [veryslow preset](https://x265.readthedocs.io/en/default/presets.html#presets).
  
  Originals are all at fixed 2 GiB size. The sizes my encodes differ (you can deduce how much time it took too from the file list):
  
  ```
  494M Dec  7 07:02 S05E16.mp4
  551M Dec  7 00:14 S05E17.mp4
  654M Dec  6 16:11 S05E18.mp4
  668M Dec  6 08:10 S05E19.mp4
  
  ```
  
  The original files have these settings applied:
  
  ```
  Encoding settings: cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=5670 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
  
  ```
  
  The question is, is the CPU time *well spent*? I mean, can I do any obvious optimizations to speed things up without having lower quality and / or larger files as a result?
  
  **EDIT1**:
  
  Citation from [the official source](https://x265.readthedocs.io/en/default/presets.html#presets):
  
  > x265 has ten predefined --preset options that optimize the trade-off between encoding speed (encoded frames per second) and compression efficiency (quality per bit in the bitstream). The default preset is medium. It does a reasonably good job of finding the best possible quality without spending excessive CPU cycles looking for the absolute most efficient way to achieve that quality. When you use faster presets, the encoder takes shortcuts to improve performance at the expense of quality and compression efficiency. When you use slower presets, x265 tests more encoding options, using more computations to achieve the best quality at your selected bit rate (or in the case of –crf rate control, the lowest bit rate at the selected quality).
  
  **EDIT2**:
  
  Hardware configuration
  
  ---
  
  Type: Dedicated server of mine. Currently used only to transcode videos.
  
  CPU: [Intel Xeon E3-1225 v3 3.2GHz 4-core](https://ark.intel.com/products/75461/Intel-Xeon-Processor-E3-1225-v3-8M-Cache-3_20-GHz)
  
  GPU: No dedicated card, only integrated
  
  RAM: 32GB ECC 1600MHz
  
  Disks:
  
  1. SSD; used for system
  2. HDDs in RAID6; used for writing the output videos
  3. RAMDisk 20GB; used for reading the source videos
  
  **EDIT3**:
  
  With regard to the comment about swapping the memory, I have had set [`vm.swappiness`](https://en.wikipedia.org/wiki/Swappiness) = 1.
  
  **Tags:** transcoding, h.264, performance, handbrake, h.265
  
  > **Comments:**
  > **username_1**: `veryslow` takes a lot more time for a marginal improvement. I would suggest `medium` preset with a lower CRF.  
  > **username_2**: Remember too that the files will have the same quality regardless of the speed setting, using veryslow will just spend more time making it (as Mulvya said, marginally) smaller. So you can prioritise any two out of: speed, quality or file size.  
  > **username_2**: Have you tried running more than one encode in parallel? With multiprocessor machines this can sometimes lead to dramatic reduction in the overall time. Not sure if you can run more than one instance of Handbrake, but you certainly can with ffmpeg. Two or more parallel encodes means that while one is not using the CPU, e.g. during disk i/o, the other will soak up the spare cycles. As long as you don't use all the memory on your system, because then it will start swapping to disk and things will go way slower. I'd suggest monitoring the CPU, disk I/O and memory usage during the encodes to see.  
  > **username_2**: no, see the last sentence: (or in the case of –crf rate control, the lowest bit rate at the selected quality). IOW if you use crf the quality is constant, just the size or encoding speed varies.  
  > **username_2**: Well then you need to prioritise size over time, given that quality is constant. Just BTW how long term are you talking?  
  > **username_0**: @username_2 ~ 10 years  
  > **username_2**: You should be right with h.265 then. If you were talking 100+ years I'd be suggesting an open source codec/container.  
  > **username_3**: You could check https://software.intel.com/en-us/intel-media-server-studio/try-buy if you want an encoder that is faster. It's not intended for end user like handbrake, but ships with example code.  
  > **username_1**: To the OP, you cut out the relevant clause of the sentence you bolded " *to achieve the best quality at your selected bit rate* ". But since you are using CRF mode, the next part is the actual relevant part: "*or in the case of –crf rate control, the lowest bit rate at the selected quality*". And with slow presets, the difference in bitrate is small but the time spent is much more.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2016-12-09. Score: 0 | Accepted answer
  
  The whole one day I dedicated to testing various scenarios. The following applies to this particular series in this particular quality, so **I don't say it applies generally**. So in this case the following applies:
  
  * **file sizes** at the very same settings with only `medium` and `veryslow` preset changed vary negligibly: ~ -10 MiB on average in favor of `veryslow` preset
  * **visual quality** at a very close look is rather the same in either `medium` or `veryslow` preset
  
  One thing solved. I have changed the preset to `medium`.
  
  ---
  
  * at a very close look, **the source videos are not in such a high quality as I thought**, that explains why x265 compresses to almost 1/4 of the original size
  
  Another mystery solved.
  
  Provided I now transcode at 25 fps, I have raised the RF to 20.
  
  ---
  
  * **RAMDisk** does not provide benefit in this case, both for `medium` and `veryslow` preset; I ended up with RAID6 as the source and SSD as the output drive
  
  The inconvenience of moving files to RAMDisk solved.
  
  ---
  
  To answer the question, **the CPU time was not spent well at all**.
  
  
  ---
  
  ### Answer by username_4 on 2020-03-31. Score: 0
  
  In my experience, the `slow`-er presets make a difference when you have moving objects on the scene. AFAIK, the one of the main improvements area in x265 is the "prediction" and reuse of info about objects moving in the scene.
  
  The more computing power the encoder spends on finding these moving objects and the way to encode them, the better quality (or smaller bitrate) you get.
  
  So, the answer is: It depends on the content of your clips and what do you want to do with the result. Do you need a good quality of every single frame? (Security camera) Then it's worth encoding with `slow` and `-qb`. Is it just an informative recording? Then go with `medium` and `crf 28` and `-tune film`.
  
  
  ---
  
  