6 ms·

This is compressing video recordings of a computer desktop. The frames don't change much so this isn't surprising.

boomboomsubban 6y ago
Can you clarify this please? Does h.265 have some better deduplication compression or does reencoding apply something that the original recording could not, meaning h.264 would have the same benefit.
- azernik 6y ago
  A compression algorithm allows multiple different encodings of the same underlying data - spend more CPU time finding redundancies in the data, and you can make the file smaller. I strongly suspect that the difference here is between real-time compression that runs while capturing the screen recording, and less time-constrained offline compression during transcoding.
  - Dylan16807 6y ago
    I'm willing to bet it's not about CPU time constraints. My guess is that it's bitrate settings and/or keyframe interval settings. And that you could get similar results by tweaking those, even if you're encoding at veryfast.
- userbinator 6y ago
  Although I have not worked with '265 or any of the other newer codecs past '263, I suspect it's the latter --- encoders running in realtime tend to aim for a constant bitrate rather than maximum compression.
- dylan604 6y ago
  h.265 makes files smaller than h.264 for a given bit rate. So an h.265 I-frame will be smaller than an h.264 I-frame. If it's a mostly static computer screen, then you can get even better encoding effeciency by using a longer GOP structure so the I-frames are spread out even futher. Of course, the trade of is seeking gets worse, but works out great for push play and watch type of deliverables. h.264 can do this as well, but it still goes back to the purpose of h.265 is to be better than h.264
  - boomboomsubban 6y ago
    Is there any reason to suspect that they used a longer GOP structure? Is the default one for ffmpeg longer than the recording software?
    - dylan604 6y ago
      I didn't see ffmpeg command to compare. I was talking in general. Usually, it is just a value you modify. A typical GOP is 1 second. That allows decent seeking within the file. On something static, you could push it to 10 seconds. If you use ffmpeg, you can fiddle with the switches until the cows come home. For homework, you can use the same methods and use MediaInfo or ffprobe to see the GOP sizes. My money would be on 1 second GOPs from both.
    - dylan604 6y ago
      From my specific tests from elsewhere in this thread, I did further analysis of the files that were run based on the examples listed in the comment. The original screen capture H.264 files did have a 1 second GOP size. However, the very simplistic ffmpeg commands to make the h.265 & h.264 files that I made used the default GOP settings from ffmpeg. Turns out, the default is 4 seconds. That would easily help get the final file size down.
      - boomboomsubban 6y ago
        You have went far beyond what I expected, thank you. And yet the original post I replied to is still a bit of a mystery. A recording of a desktop played a role, but h.265 still seems like a large part.
  - astrange 6y ago
    > h.265 makes files smaller than h.264 for a given bit rate. You mean for a given CRF ("crf" isn't an official term, it's what x264/x265 call their fixed quality mode). "Bitrate" is literally how big the file is.
    - 6y ago
- bawolff 6y ago
  If you re-encoded to h.264 with ffmpeg it would also probably get smaller. Video codecs have lots of options and trade-offs. Its not just quality and file size, but also cpu usage. I suspect the original was encoded in minimize cpu usage while keeping quality constant, and the new one was minimize file size while keeping quality constant and use as much cpu as you want.
  - dylan604 6y ago
    challenge accepted. see reply to sibling comment
- stevenhuang 6y ago
  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.
blibble 6y ago
zipping the raw avi would probably get most of the way to 95%
- chii 6y ago
  but can you stream a zip file compressed this way to play the video on a streaming protocol?
  - Dylan16807 6y ago
    Yes. No commonly-used compression formats lack streaming capabilities.
    - mayli 6y ago
      Kodi even supports playback from multi part rars.
    - bawolff 6y ago
      Don't zip files store the directory structure/index info at the end? I would assume that's pretty important for decompressing.
      - Dylan16807 6y ago
        If you assume there's only one file you could probably skip it. But the question was about using the zip file as a source for streaming, and that will work fine even if you have to spend an extra read to load the directory first.
        bawolff 6y ago
        I don't think you can safely assume random reads if you are streaming. Usually the point of a stream is you have to process the file in-order. Regardless, if for some weird reason you really liked the zip compression algorithm (DEFLATE), you would probably just use gzip instead (same compression algorithm, no weird file format with critical metadata at the end). Its also the compression algo used by PNGs.
dylan604 6y ago
H.264 would be able to take advantage of the same non-changing/static in the hands of a compressionist. Realtime encoding is always subpar compared to that due to the trade-offs required. What this is telling me is that the default settings of the OS screen capture are not optimized. To be expected though, as they have no idea what you may be attempting to encode so a safe setting that is less efficient on static images but performs reasonably well for higher action would be acceptable.
- spenczar5 6y ago
  Also, screen capture software usually needs to minimize CPU usage so you can actually, yknow, do the stuff you are trying to record. The blog post mentions that the transcode caused his laptop to heat way up. It was almost certainly a way different encoder profile.

Can you clarify this please? Does h.265 have some better deduplication compression or does reencoding apply something that the original recording could not, meaning h.264 would have the same benefit.

azernik 6y ago
A compression algorithm allows multiple different encodings of the same underlying data - spend more CPU time finding redundancies in the data, and you can make the file smaller. I strongly suspect that the difference here is between real-time compression that runs while capturing the screen recording, and less time-constrained offline compression during transcoding.
- Dylan16807 6y ago
  I'm willing to bet it's not about CPU time constraints. My guess is that it's bitrate settings and/or keyframe interval settings. And that you could get similar results by tweaking those, even if you're encoding at veryfast.
userbinator 6y ago
Although I have not worked with '265 or any of the other newer codecs past '263, I suspect it's the latter --- encoders running in realtime tend to aim for a constant bitrate rather than maximum compression.
dylan604 6y ago
h.265 makes files smaller than h.264 for a given bit rate. So an h.265 I-frame will be smaller than an h.264 I-frame. If it's a mostly static computer screen, then you can get even better encoding effeciency by using a longer GOP structure so the I-frames are spread out even futher. Of course, the trade of is seeking gets worse, but works out great for push play and watch type of deliverables. h.264 can do this as well, but it still goes back to the purpose of h.265 is to be better than h.264
- boomboomsubban 6y ago
  Is there any reason to suspect that they used a longer GOP structure? Is the default one for ffmpeg longer than the recording software?
  - dylan604 6y ago
    I didn't see ffmpeg command to compare. I was talking in general. Usually, it is just a value you modify. A typical GOP is 1 second. That allows decent seeking within the file. On something static, you could push it to 10 seconds. If you use ffmpeg, you can fiddle with the switches until the cows come home. For homework, you can use the same methods and use MediaInfo or ffprobe to see the GOP sizes. My money would be on 1 second GOPs from both.
  - dylan604 6y ago
    From my specific tests from elsewhere in this thread, I did further analysis of the files that were run based on the examples listed in the comment. The original screen capture H.264 files did have a 1 second GOP size. However, the very simplistic ffmpeg commands to make the h.265 & h.264 files that I made used the default GOP settings from ffmpeg. Turns out, the default is 4 seconds. That would easily help get the final file size down.
    - boomboomsubban 6y ago
      You have went far beyond what I expected, thank you. And yet the original post I replied to is still a bit of a mystery. A recording of a desktop played a role, but h.265 still seems like a large part.
- astrange 6y ago
  > h.265 makes files smaller than h.264 for a given bit rate. You mean for a given CRF ("crf" isn't an official term, it's what x264/x265 call their fixed quality mode). "Bitrate" is literally how big the file is.
  - 6y ago
bawolff 6y ago
If you re-encoded to h.264 with ffmpeg it would also probably get smaller. Video codecs have lots of options and trade-offs. Its not just quality and file size, but also cpu usage. I suspect the original was encoded in minimize cpu usage while keeping quality constant, and the new one was minimize file size while keeping quality constant and use as much cpu as you want.
- dylan604 6y ago
  challenge accepted. see reply to sibling comment
stevenhuang 6y ago
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.

blibble 6y ago

zipping the raw avi would probably get most of the way to 95%

chii 6y ago
but can you stream a zip file compressed this way to play the video on a streaming protocol?
- Dylan16807 6y ago
  Yes. No commonly-used compression formats lack streaming capabilities.
  - mayli 6y ago
    Kodi even supports playback from multi part rars.
  - bawolff 6y ago
    Don't zip files store the directory structure/index info at the end? I would assume that's pretty important for decompressing.
    - Dylan16807 6y ago
      If you assume there's only one file you could probably skip it. But the question was about using the zip file as a source for streaming, and that will work fine even if you have to spend an extra read to load the directory first.
      - bawolff 6y ago
        I don't think you can safely assume random reads if you are streaming. Usually the point of a stream is you have to process the file in-order. Regardless, if for some weird reason you really liked the zip compression algorithm (DEFLATE), you would probably just use gzip instead (same compression algorithm, no weird file format with critical metadata at the end). Its also the compression algo used by PNGs.

dylan604 6y ago

H.264 would be able to take advantage of the same non-changing/static in the hands of a compressionist. Realtime encoding is always subpar compared to that due to the trade-offs required. What this is telling me is that the default settings of the OS screen capture are not optimized. To be expected though, as they have no idea what you may be attempting to encode so a safe setting that is less efficient on static images but performs reasonably well for higher action would be acceptable.

spenczar5 6y ago
Also, screen capture software usually needs to minimize CPU usage so you can actually, yknow, do the stuff you are trying to record. The blog post mentions that the transcode caused his laptop to heat way up. It was almost certainly a way different encoder profile.