<blockquote>
<p>Is there a benefit to go back to the original file and reencode it at 40Mb/sec bitrate, vs. using the already reduced 50Mb/sec file and reencoding that one at 40Mb/sec?</p>
</blockquote>
<p>Every single time you reencode you will lose quality. If you reencode twice you will lose more quality than if you reencode once. There is absolutely no benefit for not using the original. If you tune for SSIM and then measure the SSIM you can get some idea of how much has been lost.</p>
<p>You're using hevc_nvenc which has about 50% worse quality for the same bitrate compared to libx265. Unless you are streaming this in real time I would strongly recommend using libx265. It is slower because it is CPU-only but it produces a much higher quality bitstream. A 30Mbps video encoded with libx265 will have quality similar to a 50Mbps video encoded with hevc_nvenc.</p>
<p>You might also want to perform 2 pass encoding. This will reduce quality fluctuations that you will get when using 1 pass ABR as you are doing now. Unlike x264, x265 does not use a fast first pass by default. You can make it do that manually with <code>slow-firstpass=0</code>, although it will reduce quality (not nearly as much as using hevc_nvenc though). If &quot;slow&quot; is too slow then you can use a faster preset, or you can use a slower preset if you want better quality at the expense of time:</p>
<pre><code>-c:v libx265 -preset slow -b:v 40M -x265-params &quot;pass=1:slow-firstpass=0&quot;
-c:v libx265 -preset slow -b:v 40M -x265-params &quot;pass=2&quot;
</code></pre>
<p>Other options you might want to pass to <code>-x265-params</code> (remember to delimit them with a <code>:</code>):</p>
<ul>
<li><code>multi-pass-opt-distortion=1</code> can improve quality</li>
<li><code>multi-pass-opt-analysis=1</code> will speed up the second pass</li>
<li><code>hme=1</code> changes the motion estimation algorithm and can improve performance for 8k</li>
<li><code>aq-mode=4</code> improves quality for dark areas and edges (but useless for HDR)</li>
</ul>
<blockquote>
<p>If there's indeed such a benefit, can we quantify it in comparison to the intermediate bitrate version of the file?</p>
</blockquote>
<p>We can use SSIM to quantify the benefit. I'm doing a scale model of what you did (with 10, 5, and 4Mbps instead of 100, 50, and 40):</p>
<ul>
<li>The SSIM for 10Mbps -&gt; 5Mbps is 0.989959</li>
<li>The SSIM for 10Mbps -&gt; 4Mbps is 0.988408</li>
<li>The SSIM for 10Mbps -&gt; 5Mbps -&gt; 4Mbps is 0.987522</li>
</ul>
<p>There are lots of online guides for how to interpret these results, but basically higher is better, and an SSIM of 1.0 means lossless (no change). Btw, even if you INCREASE the bitrate, you'll lose quality (10Mbps -&gt; 15Mbps is 0.997411, and 10Mbps -&gt; 20Mbps is 0.998323)! To not lose quality requires putting the encoder in lossless mode, which increased the bitrate to 70Mbps, for an SSIM of 1.0.</p>
<p>For info, here is the test I did:</p>
<pre><code># create 10Mbps sample
ffmpeg -f lavfi -i &quot;testsrc2=1920x1080:r=60:d=30&quot; -c:v libx265 -preset faster -tune ssim -b:v 10M 10.mkv

# convert 10Mbps to 5Mbps
ffmpeg -i 10.mkv -c:v libx265 -preset faster -tune ssim -b:v 5M 5from10.mkv

# convert 10Mbps to 4Mbps
ffmpeg -i 10.mkv -c:v libx265 -preset faster -tune ssim -b:v 4M 4from10.mkv

# convert 5Mbps to 4Mbpss
ffmpeg -i 5from10.mkv -c:v libx265 -preset faster -tune ssim -b:v 4M 4from5from10.mkv

# calculate SSIMs between 10Mbps and the converted videos
ffmpeg -i 10.mkv -i 5from10.mkv -lavfi ssim -f null -
ffmpeg -i 10.mkv -i 4from10.mkv -lavfi ssim -f null -
ffmpeg -i 10.mkv -i 4from5from10.mkv -lavfi ssim -f null -
</code></pre>
<p>Note that reencoded videos can only be compared using SSIM if it is encoded with <code>-tune ssim</code>, otherwise the comparison will be inaccurate. Also keep in mind that this runs the SSIM algorithm on each frame and averages the results. It does not take into account motion. Tuning for SSIM disables some psychovisual optimizations though, so you should never distribute a video tuned for that. Other popular objective quality comparison algorithms are PSNR and VMAF.</p>
<blockquote>
<p>If there was a follow-up requirement to further reduce the bitrate to 30Mb/sec, what would be the benefit of going with the 40, 50, or the 100Mb/sec versions?</p>
</blockquote>
<p>Converting from 100 is better than converting from 50, and converting from 50 is better than converting from 40. Every time you reencode a lossy codec, you suffer generation loss. You should always always try to minimize the number of reencoding stages (generations) you go through.</p>
<p>There are special codecs called mezzanine codecs (also called intermediate codecs) which are designed to resist generation loss. However they are very high bitrate (200Mbps easy) and they aren't intended for distribution, just for editing. Examples of mezzanines are ProRes, DNxHD, and Cineform. There are also lossless mezzanines which are completely immune to generation loss, such as FFV1 and HuffYUV, but their bitrates are even higher. Unlike a regular codec, you don't usually specify the bitrate of a mezzanine. The bitrate is only dependent on bit depth, resolution, frame rate, and spacial video complexity (not temporal because these are usually intra-only codecs anyway, i.e. each frame is compressed individually without referencing previous frames).</p>

CC BY-SA 4.0
2024-05-13T21:57:12.053Z
Thank you. I didn't even know about SSIM and similar metrics, and this is a great comprehensive answer.
Cahit
CC BY-SA 4.0
2024-05-04T21:26:51.610Z
2024-05-05T21:02:52.747Z
2024-05-05T21:02:52.747Z
veppy
<p>My scenario is as follows:</p>
<ul>
<li>Working with large original 8K file, captured at 100Mb/sec with hvec (h265) codec</li>
<li>The file was reencoded at 50Mb/sec for a reasonable balance between size and quality</li>
</ul>
<p>Now there's a requirement is to lower the bitrate for space savings, going to 40Mb/sec.</p>
<p>My questions are:</p>
<ul>
<li>Is there a benefit to go back to the original file and reencode it at 40Mb/sec bitrate, vs. using the already reduced 50Mb/sec file and reencoding that one at 40Mb/sec?</li>
<li>If there's indeed such a benefit, can we quantify it in comparison to the intermediate bitrate version of the file?</li>
<li>If there was a follow-up requirement to further reduce the bitrate to 30Mb/sec, what would be the benefit of going with the 40, 50, or the 100Mb/sec versions?</li>
</ul>
<p>For reference, ffmpeg would be the encoding tool, using similar options to those listed below:</p>
<pre><code>-c:v hevc_nvenc -preset p6 -tune hq -b:v 40M
</code></pre>

<ffmpeg><encoding><bitrate><hevc>
Impact of reencoding an HEVC file: How much loss if I do it in two steps, vs. going directly to a lower bitrate?
Cahit
# Impact of reencoding an HEVC file: How much loss if I do it in two steps, vs. going directly to a lower bitrate?

(Asked by: username_0 on 2024-03-19)

My scenario is as follows:

Working with large original 8K file, captured at 100Mb/sec with hvec (h265) codec
The file was reencoded at 50Mb/sec for a reasonable balance between size and quality

Now there's a requirement is to lower the bitrate for space savings, going to 40Mb/sec.
My questions are:

Is there a benefit to go back to the original file and reencode it at 40Mb/sec bitrate, vs. using the already reduced 50Mb/sec file and reencoding that one at 40Mb/sec?
If there's indeed such a benefit, can we quantify it in comparison to the intermediate bitrate version of the file?
If there was a follow-up requirement to further reduce the bitrate to 30Mb/sec, what would be the benefit of going with the 40, 50, or the 100Mb/sec versions?

For reference, ffmpeg would be the encoding tool, using similar options to those listed below:
-c:v hevc_nvenc -preset p6 -tune hq -b:v 40M

**Tags:** ffmpeg, encoding, bitrate, hevc


---

## 1 answers

### Answer by username_1 on 2024-05-04. Score: 2 | Accepted answer

Is there a benefit to go back to the original file and reencode it at 40Mb/sec bitrate, vs. using the already reduced 50Mb/sec file and reencoding that one at 40Mb/sec?

Every single time you reencode you will lose quality. If you reencode twice you will lose more quality than if you reencode once. There is absolutely no benefit for not using the original. If you tune for SSIM and then measure the SSIM you can get some idea of how much has been lost.
You're using hevc_nvenc which has about 50% worse quality for the same bitrate compared to libx265. Unless you are streaming this in real time I would strongly recommend using libx265. It is slower because it is CPU-only but it produces a much higher quality bitstream. A 30Mbps video encoded with libx265 will have quality similar to a 50Mbps video encoded with hevc_nvenc.
You might also want to perform 2 pass encoding. This will reduce quality fluctuations that you will get when using 1 pass ABR as you are doing now. Unlike x264, x265 does not use a fast first pass by default. You can make it do that manually with slow-firstpass=0, although it will reduce quality (not nearly as much as using hevc_nvenc though). If "slow" is too slow then you can use a faster preset, or you can use a slower preset if you want better quality at the expense of time:
-c:v libx265 -preset slow -b:v 40M -x265-params "pass=1:slow-firstpass=0"
-c:v libx265 -preset slow -b:v 40M -x265-params "pass=2"

Other options you might want to pass to -x265-params (remember to delimit them with a :):

multi-pass-opt-distortion=1 can improve quality
multi-pass-opt-analysis=1 will speed up the second pass
hme=1 changes the motion estimation algorithm and can improve performance for 8k
aq-mode=4 improves quality for dark areas and edges (but useless for HDR)


If there's indeed such a benefit, can we quantify it in comparison to the intermediate bitrate version of the file?

We can use SSIM to quantify the benefit. I'm doing a scale model of what you did (with 10, 5, and 4Mbps instead of 100, 50, and 40):

The SSIM for 10Mbps -> 5Mbps is 0.989959
The SSIM for 10Mbps -> 4Mbps is 0.988408
The SSIM for 10Mbps -> 5Mbps -> 4Mbps is 0.987522

There are lots of online guides for how to interpret these results, but basically higher is better, and an SSIM of 1.0 means lossless (no change). Btw, even if you INCREASE the bitrate, you'll lose quality (10Mbps -> 15Mbps is 0.997411, and 10Mbps -> 20Mbps is 0.998323)! To not lose quality requires putting the encoder in lossless mode, which increased the bitrate to 70Mbps, for an SSIM of 1.0.
For info, here is the test I did:
# create 10Mbps sample
ffmpeg -f lavfi -i "testsrc2=1920x1080:r=60:d=30" -c:v libx265 -preset faster -tune ssim -b:v 10M 10.mkv

# convert 10Mbps to 5Mbps
ffmpeg -i 10.mkv -c:v libx265 -preset faster -tune ssim -b:v 5M 5from10.mkv

# convert 10Mbps to 4Mbps
ffmpeg -i 10.mkv -c:v libx265 -preset faster -tune ssim -b:v 4M 4from10.mkv

# convert 5Mbps to 4Mbpss
ffmpeg -i 5from10.mkv -c:v libx265 -preset faster -tune ssim -b:v 4M 4from5from10.mkv

# calculate SSIMs between 10Mbps and the converted videos
ffmpeg -i 10.mkv -i 5from10.mkv -lavfi ssim -f null -
ffmpeg -i 10.mkv -i 4from10.mkv -lavfi ssim -f null -
ffmpeg -i 10.mkv -i 4from5from10.mkv -lavfi ssim -f null -

Note that reencoded videos can only be compared using SSIM if it is encoded with -tune ssim, otherwise the comparison will be inaccurate. Also keep in mind that this runs the SSIM algorithm on each frame and averages the results. It does not take into account motion. Tuning for SSIM disables some psychovisual optimizations though, so you should never distribute a video tuned for that. Other popular objective quality comparison algorithms are PSNR and VMAF.

If there was a follow-up requirement to further reduce the bitrate to 30Mb/sec, what would be the benefit of going with the 40, 50, or the 100Mb/sec versions?

Converting from 100 is better than converting from 50, and converting from 50 is better than converting from 40. Every time you reencode a lossy codec, you suffer generation loss. You should always always try to minimize the number of reencoding stages (generations) you go through.
There are special codecs called mezzanine codecs (also called intermediate codecs) which are designed to resist generation loss. However they are very high bitrate (200Mbps easy) and they aren't intended for distribution, just for editing. Examples of mezzanines are ProRes, DNxHD, and Cineform. There are also lossless mezzanines which are completely immune to generation loss, such as FFV1 and HuffYUV, but their bitrates are even higher. Unlike a regular codec, you don't usually specify the bitrate of a mezzanine. The bitrate is only dependent on bit depth, resolution, frame rate, and spacial video complexity (not temporal because these are usually intra-only codecs anyway, i.e. each frame is compressed individually without referencing previous frames).

> **Comments:**
> **username_0**: Thank you. I didn't even know about SSIM and similar metrics, and this is a great comprehensive answer.  

---

