Answers.Body: <p>You are using a quality based variable bitrate compression factor on something that already has artifacts.  That means it is going to attempt to preserve the video exactly as it is, artifacts included and artifacts tend to not encode well.  This means you have a video input which is likely harder to encode than the original and you chose a quality based compression that is also likely higher quality than your original 12 Mbps could manage.  This means an overall higher data rate must be used to try to avoid additional loss from the second generation of encoding, even with the extra optimizations that a slower compression cycle can handle, you aren't able to overcome the added complexity of the first encoding and the quality setting being used.</p>
  
  <p>If this was any kind of HD stream that's not really that surprising as 12Mbps is a very heavily compressed end consumer level of compression for any HD formats.  It's not really a big surprise that it doesn't re-encode well.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-13T01:28:27.440Z
Answers.LastActivityDate: 2017-07-13T01:28:27.440Z
Answers.UserDisplayName: AJ Henderson
Body: <p>I've got some livestreamed footage (encoded with constant bitrate), and I've been trying to reduce the file size for long-term storage.  I figured that since encoding speed is no longer a constraint for me, I could let the encoder take more time and make a smaller file.</p>
  
  <p>The original footage was encoded at 12 Mbps, but when I tried reencoding it with FFmpeg (libx264, CRF 18, and preset veryslow), the result was at 17 Mbps.</p>
  
  <p>My question is, how can using these settings make a file so dramatically larger than the original?  As I understand it, the point of the veryslow preset is to take a long time and make the most compressed H.264 video possible (ignoring the placebo preset), but in this case I'd be far better off doing nothing!  I'd understand it being slightly bigger, because it has to encode some compression artifacts, but not a 40% increase.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-14T18:17:20.847Z
Comments.Text: CRF 18 is functionally lossless. You should have expected a big file. Bump it up to 20, or 22, or even 24 until you get the quality/size ratio you're looking for.
Comments.UserDisplayName: user3643
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-15T02:09:05.920Z
Comments.Text: I know that it's functionally lossless; that was my intention (though I'll try bumping it up and seeing how far I have to go). I just found it very strange that I could get something functionally lossless with a 40% size increase, but I could get something perfectly lossless with a 0% size increase.
Comments.UserDisplayName: PunctualEmoticon
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-15T17:00:45.130Z
Comments.Text: I personally wouldn't re-encode at all. I'd store the original. You won't get much more compression out of it without quality loss. Also, the tighter the compression the less you can work with the file in the future.
Comments.UserDisplayName: user3643
Tags: <ffmpeg><encoding><compression><h.264>
Title: Reencoding H.264 to H.264 made it 40% larger
UserDisplayName: PunctualEmoticon
ThreadText: # Reencoding H.264 to H.264 made it 40% larger
  
  (Asked by: username_0 on 2017-07-12)
  
  I've got some livestreamed footage (encoded with constant bitrate), and I've been trying to reduce the file size for long-term storage. I figured that since encoding speed is no longer a constraint for me, I could let the encoder take more time and make a smaller file.
  
  The original footage was encoded at 12 Mbps, but when I tried reencoding it with FFmpeg (libx264, CRF 18, and preset veryslow), the result was at 17 Mbps.
  
  My question is, how can using these settings make a file so dramatically larger than the original? As I understand it, the point of the veryslow preset is to take a long time and make the most compressed H.264 video possible (ignoring the placebo preset), but in this case I'd be far better off doing nothing! I'd understand it being slightly bigger, because it has to encode some compression artifacts, but not a 40% increase.
  
  **Tags:** ffmpeg, encoding, compression, h.264
  
  > **Comments:**
  > **username_1**: CRF 18 is functionally lossless. You should have expected a big file. Bump it up to 20, or 22, or even 24 until you get the quality/size ratio you're looking for.  
  > **username_0**: I know that it's functionally lossless; that was my intention (though I'll try bumping it up and seeing how far I have to go). I just found it very strange that I could get something functionally lossless with a 40% size increase, but I could get something perfectly lossless with a 0% size increase.  
  > **username_1**: I personally wouldn't re-encode at all. I'd store the original. You won't get much more compression out of it without quality loss. Also, the tighter the compression the less you can work with the file in the future.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2017-07-13. Score: 3
  
  You are using a quality based variable bitrate compression factor on something that already has artifacts. That means it is going to attempt to preserve the video exactly as it is, artifacts included and artifacts tend to not encode well. This means you have a video input which is likely harder to encode than the original and you chose a quality based compression that is also likely higher quality than your original 12 Mbps could manage. This means an overall higher data rate must be used to try to avoid additional loss from the second generation of encoding, even with the extra optimizations that a slower compression cycle can handle, you aren't able to overcome the added complexity of the first encoding and the quality setting being used.
  
  If this was any kind of HD stream that's not really that surprising as 12Mbps is a very heavily compressed end consumer level of compression for any HD formats. It's not really a big surprise that it doesn't re-encode well.
  
  
  ---
  
  