2

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.

Improve this question
3
  • 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.
    – user3643
    Jul 14, 2017 at 18:17
  • 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.
    – PunctualEmoticon
    Jul 15, 2017 at 2:09
  • 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.
    – user3643
    Jul 15, 2017 at 17:00

1 Answer 1

Reset to default
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.