<p>When decoding a file, the decoder attempts to recreate the source material with the information provided in the file. But it can not be a 100 percent accurate representation, so the decoder creates new pixels that are estimates of what was included in the source </p>

<p>When you encode for the second time with CRF 17, the encoder does not know these new pixels were generated by the decoder and were not necessarily faithful to the original material. But the encoder still does its job, and attempts to encode these new values accurately. </p>

<p>So it spends bits encoding pixels that were thrown away and recreated by the first encode, making the file larger. </p>

CC BY-SA 4.0
2019-03-26T07:09:42.550Z
The semantics of your answer seem weird. It suggests that the encoder stores a perfect representation of the source, but the decoder attempts and fails to restore a duplicate of that representation. Instead, the information-limiting happens at the encoding stage, based on encoder design and rate-control constraints. Decoders for modern codecs are expected to produce bitexact output (rounding errors may be still possible due to architecture limitations as well as skipping deblocking..etc).
Gyan
CC BY-SA 4.0
2019-03-26T07:16:21.877Z
I understand your logic, but in this context I am referring to the encoder output as the decoder. I simplified because I assumed the poster is not aware of the nuances and was attempting to be helpful more that accurate. The decoder output is bit exact across implementations. But my post is basically correct when round tripping between spacial and temporal domains, and after quantization and loop filters, new visual information is implied that was not part of the reference.
SlimSCSI
CC BY-SA 4.0
2019-03-25T16:44:18.640Z
2019-03-25T16:44:18.640Z
SlimSCSI
<p>If there is a h.264 video, and I use -crf 17 I sometimes I get a lower bitrate, but the weird thing is - most of the time get a higher ones. </p>

<p>I am trying to get this setting because I think some videos of mine are having a higher then needed bitrate and I have not figured a way (if it is possible at all) to determine what is the most appropriate way to do this and maybe playing with CRF will not help me at all, but I wondered what actually happens when you don't encode with libx264 for example, but actually use CRF values on a x264 file?</p>

CC BY-SA 4.0
2019-03-23T04:55:34.750Z
The bitrate depends on t he complexity of the video. For two videos with the same resolution and framerate, using the same CRF will give a higher bitrate for the video with more complexity.
Gyan
CC BY-SA 4.0
2019-03-23T12:43:38.537Z
But what actually happens when I give crf -17 and the new video is larger than the older one?
A. Newb
<ffmpeg><encoding><codec><compression><h.264>
What happens when you use a specific CRF value on a already encoded x264 video?
A. Newb
# What happens when you use a specific CRF value on a already encoded x264 video?

(Asked by: username_0 on 2019-03-23)

If there is a h.264 video, and I use -crf 17 I sometimes I get a lower bitrate, but the weird thing is - most of the time get a higher ones.

I am trying to get this setting because I think some videos of mine are having a higher then needed bitrate and I have not figured a way (if it is possible at all) to determine what is the most appropriate way to do this and maybe playing with CRF will not help me at all, but I wondered what actually happens when you don't encode with libx264 for example, but actually use CRF values on a x264 file?

**Tags:** ffmpeg, encoding, codec, compression, h.264

> **Comments:**
> **username_1**: The bitrate depends on t he complexity of the video. For two videos with the same resolution and framerate, using the same CRF will give a higher bitrate for the video with more complexity.  
> **username_0**: But what actually happens when I give crf -17 and the new video is larger than the older one?  

---

## 1 answers

### Answer by username_2 on 2019-03-25. Score: 1

When decoding a file, the decoder attempts to recreate the source material with the information provided in the file. But it can not be a 100 percent accurate representation, so the decoder creates new pixels that are estimates of what was included in the source

When you encode for the second time with CRF 17, the encoder does not know these new pixels were generated by the decoder and were not necessarily faithful to the original material. But the encoder still does its job, and attempts to encode these new values accurately.

So it spends bits encoding pixels that were thrown away and recreated by the first encode, making the file larger.

> **Comments:**
> **username_1**: The semantics of your answer seem weird. It suggests that the encoder stores a perfect representation of the source, but the decoder attempts and fails to restore a duplicate of that representation. Instead, the information-limiting happens at the encoding stage, based on encoder design and rate-control constraints. Decoders for modern codecs are expected to produce bitexact output (rounding errors may be still possible due to architecture limitations as well as skipping deblocking..etc).  
> **username_2**: I understand your logic, but in this context I am referring to the encoder output as the decoder. I simplified because I assumed the poster is not aware of the nuances and was attempting to be helpful more that accurate. The decoder output is bit exact across implementations. But my post is basically correct when round tripping between spacial and temporal domains, and after quantization and loop filters, new visual information is implied that was not part of the reference.  

---

