3 ms·

The original h264 file was likely optimized for write speed and not storage (which takes cpu time and can introduce lag in real time recording). Reencoding the

The original h264 file was likely optimized for write speed and not storage (which takes cpu time and can introduce lag in real time recording). Reencoding the same input file as h264 again but using FFmpeg defaults would probably yield similar file size reductions. This is just a bogus post without knowing what parameters were used to encode the original h264.

dylan604 6y ago
For science, I just took a 10 second screen recording of my Mac with nothing but my tiny mouse cursor moving around for a few seconds which means a very static shot. The recording came out at 7.5MB. There was no audio in the original recoding. I then used that as a source to transcode with x264 crf 23. New filesize 2.0M. ~26% ffmpeg -i input.mov -c:v libx264 -crf 23 x264.mp4 Next, I used the same 7.5MB source to transcode with x265 crf 28. New filesize 968KB. ~13% ffmpeg -i input.mov -c:v libx265 -crf 28 x265.mp4 CRF values were taken from [0] which states x265 crf28 should produce same visual quality of x264 crf23, but at half the size. That holds true. [0]https://trac.ffmpeg.org/wiki/Encode/H.265 https://trac.ffmpeg.org/wiki/Encode/H.265 Edit: forgot link So, I don't think the author's post is bogus. They just lose points for not showing their work (not that they did it, but you know). Edit 2: I have no idea what the author of the post used for encode settings. I picked 2 based on the vendor's claim the 2 settings should look the same at half the bit rate. I easily could have changed the values to lower the bitrate to get from 50% to 94%. I just assumed the reader would be able to make the mental leap
- qotgalaxy 6y ago
  Conflating a 50% reduction and 94% reduction is pretty bogus.
- bawolff 6y ago
  I'd still call the original bogus. Its not unexpected that H.265 is smaller than H.264, just that the article made an unfair comparision. As your comparision found, the majority of the size reduction relative to the original was related to encoding parameters, only 13% was related to codec choice. Of course if you start from the better encoded H.264 file things look better for H.265, but not 94% better.
- fireattack 6y ago
  Without at least some semi-objective compassions on the "visual quality", your data is meaningless. Like, how can you tell crf23 of x264 is closer to your x265-x265 version than, say, a crf24 x264 one? As a rule of thumb, x265 works better (compared to x264) at lower bitrate / worse quality. You won't be able to achieve "same quality, half size" at higher bitrate easily.
  - dylan604 6y ago
    Sure, we could runs some PSNR or SSIM comparisons. However, I've been doing this for a hot minute, and h.265 is pretty damn good. Getting 4K video filesize for VR to run on a phone based headset was never going to happen without it. h.264 encodes just were never going to make it in the real world for the frame size and TRTs. Once we knew the target devices could handle h.265, it was a game changer. That was way back in 2015 when live action VR was almost a thing. From years of real world experience, h.265 produces much smaller files by being able to use a lower bitrate to achieve the same visual quality has previous h.264. Guess what. H.264 did the same thing to MPEG2. Not really sure why this is so unbelievable.
    - fireattack 6y ago
      > Not really sure why this is so unbelievable No one is saying that. Everyone knows H265 is better than H264. Just saying your number is meaningless without either fixing the bitrate or the quality.
      - dylan604 6y ago
        Sure. Don't believe some random dude from the internet. But if you're not going to go through the hassle of running the tests on your own, your "meaningless" claims are meaningless. Have you spent time in your career as a compressionist? Have you encoded hundred of hours in various codecs looking at the best tweaks to get the highest visual quality for the smallest file sizes? The test files that I produced resulted in the h.264/crf23 with a bitrate of 970kbps while the h.264/crf28 result with a bitrate of 800kbps. The h.265 used less bitrate to achieve half the filesize. I have stacked the 2 videos and toggle between the two. There is no visible difference. I have done this experiment. It is up to you to do the same thing to see if you can replicate the results or not. That's science. But it is much easier to just post "no it doesn't" comments on the internet.

dylan604 6y ago

For science, I just took a 10 second screen recording of my Mac with nothing but my tiny mouse cursor moving around for a few seconds which means a very static shot. The recording came out at 7.5MB. There was no audio in the original recoding. I then used that as a source to transcode with x264 crf 23. New filesize 2.0M. ~26% ffmpeg -i input.mov -c:v libx264 -crf 23 x264.mp4 Next, I used the same 7.5MB source to transcode with x265 crf 28. New filesize 968KB. ~13% ffmpeg -i input.mov -c:v libx265 -crf 28 x265.mp4 CRF values were taken from [0] which states x265 crf28 should produce same visual quality of x264 crf23, but at half the size. That holds true. [0]https://trac.ffmpeg.org/wiki/Encode/H.265 https://trac.ffmpeg.org/wiki/Encode/H.265 Edit: forgot link So, I don't think the author's post is bogus. They just lose points for not showing their work (not that they did it, but you know). Edit 2: I have no idea what the author of the post used for encode settings. I picked 2 based on the vendor's claim the 2 settings should look the same at half the bit rate. I easily could have changed the values to lower the bitrate to get from 50% to 94%. I just assumed the reader would be able to make the mental leap

qotgalaxy 6y ago
Conflating a 50% reduction and 94% reduction is pretty bogus.
bawolff 6y ago
I'd still call the original bogus. Its not unexpected that H.265 is smaller than H.264, just that the article made an unfair comparision. As your comparision found, the majority of the size reduction relative to the original was related to encoding parameters, only 13% was related to codec choice. Of course if you start from the better encoded H.264 file things look better for H.265, but not 94% better.
fireattack 6y ago
Without at least some semi-objective compassions on the "visual quality", your data is meaningless. Like, how can you tell crf23 of x264 is closer to your x265-x265 version than, say, a crf24 x264 one? As a rule of thumb, x265 works better (compared to x264) at lower bitrate / worse quality. You won't be able to achieve "same quality, half size" at higher bitrate easily.
- dylan604 6y ago
  Sure, we could runs some PSNR or SSIM comparisons. However, I've been doing this for a hot minute, and h.265 is pretty damn good. Getting 4K video filesize for VR to run on a phone based headset was never going to happen without it. h.264 encodes just were never going to make it in the real world for the frame size and TRTs. Once we knew the target devices could handle h.265, it was a game changer. That was way back in 2015 when live action VR was almost a thing. From years of real world experience, h.265 produces much smaller files by being able to use a lower bitrate to achieve the same visual quality has previous h.264. Guess what. H.264 did the same thing to MPEG2. Not really sure why this is so unbelievable.
  - fireattack 6y ago
    > Not really sure why this is so unbelievable No one is saying that. Everyone knows H265 is better than H264. Just saying your number is meaningless without either fixing the bitrate or the quality.
    - dylan604 6y ago
      Sure. Don't believe some random dude from the internet. But if you're not going to go through the hassle of running the tests on your own, your "meaningless" claims are meaningless. Have you spent time in your career as a compressionist? Have you encoded hundred of hours in various codecs looking at the best tweaks to get the highest visual quality for the smallest file sizes? The test files that I produced resulted in the h.264/crf23 with a bitrate of 970kbps while the h.264/crf28 result with a bitrate of 800kbps. The h.265 used less bitrate to achieve half the filesize. I have stacked the 2 videos and toggle between the two. There is no visible difference. I have done this experiment. It is up to you to do the same thing to see if you can replicate the results or not. That's science. But it is much easier to just post "no it doesn't" comments on the internet.