I do a lot of video compression for hobby projects, and I stick with h264 for the most part because h265 encoding requires far too much extra compute relative to the space savings. I can spend an hour compressing a file down to 1gb with h264, or I can spend 12 hours compressing the same file to 850mb with h265. Depending on the use-case, I might still need the h264 version anyway since it's far more widely supported by clients. If I had a data center worth of compute to throw at encoding, or I were running a streaming service where the extra 150mb per video started to add up, then I'd definitely on-board with h265 but it's really hard to justify for a lot of practical use-cases.
> I stick with h264 for the most part because h265 encoding requires far too much extra compute relative to the space savings. I can spend an hour compressing a file down to 1gb with h264, or I can spend 12 hours compressing the same file to 850mb with h265.
FWIW, as someone who is a complete layman on this topic but has spent much of the past 6 months converting age-old videos to h265...
i have a pi5 where i queue up old videos into a RAM disk, it converts them to h265, and moves them back to the machine which uploaded them. It can take up to 2 days to compress any given video (depending mostly on the input format - old AVIs tend to compress in a few hours), but the space savings is _much_ higher than what you're reporting. The average size of my h265-encodes is anywhere from 1/3rd to 1/2 of the original, and 1/4th of the original is not terribly uncommon. That said: the input formats vary wildly, with possibly only a minority fraction being h264.
i've tried the same thing using a pi4 but it needs roughly 4-5x as long as the pi5. An 8-core intel-based laptop can do it in some 25% of the time of the pi5 but pulls a lot more electricity while doing so. So my otherwise idle pi5 gets the assignment.
My Firefly collection (14 tv episodes plus the movie) dropped from 8gb to 2.1gb. My Bob Ross collection (141 videos) went from 38gb to 7.4gb. 128 Futurama episodes/movies was cut from roughly 50gb to 21gb.
i was once asked why i didn't choose AV1 and the answer is simple: when i googled along the lines of "how to get the best video compression with ffmpeg" the most common answer was h265. Whether that's correct or not, i can't say, but it works for me and i've freed up the better part of a terabyte of space with it.
Interesting, your numbers look to be quite a bit better than the 30% improvement I've heard is the standard rule of thumb for how much improvement to expect with h.265, and on average for me it's been closer to 20%. I think h.265 starts to show much more meaningful improvements as you start using lower bitrates, and the specific type of media probably matters a bit as well.
I do most of my encoding on an i9-13900k. I've also noticed that h.265 seems to be quite a bit more likely to trigger the smt related crashes in ffmpeg, which makes it a pain when I've queued up a lot of things to encode over night.
What about when you’re recording (say your iPhone / android / standalone camera) - are you choosing h264 or h265 (or something else like an intra-frame only codec for easier editing).
Most of what I do is working with pre-recorded video, but for projects where I'm doing recording I tend to use h.264 since I don't have a lot of devices that support h.265 anyway, and picking one format with broad compatibility is generally more important to me than the efficiency gains I'd get using h.265 when I could.
I haven't actually done the comparison myself, but the common refrain is that the quality of the video suffers when you use GPU accelerated encoding. That's not a tradeoff I want to make, so I've just stuck with CPU encoding.
There two types of GPU acceleration: acceleration by a hardware codec bolted on a GPU, and actual GPU computational acceleration. the latter is not widely used but probably is not n gonna have any difference in terms of quality, and provides only modest acceleration.
I really like HEVC/h265. It's pretty much on par with VP9. but licensing trouble has made it difficult to get adopted everywhere even now. VVC/h266 seems to be having the same issues; AV1 is pretty much just as good and already seeing much more adoption.
Is it because they come with the codecs “jointly” with the MPEG organization, which is for profit?
If the group is part of a standards organization that’s part of the UN, I feel like they should come up with non-patent-encumbered “recommendations”.
There are multiple patent pools for H.265 wanting to be paid licensing fees (MPEG LA, HEVC Advance, Velos Media). HEVC Advance and Velos Media even want content distribution licensing fees.
And there are patent holders not in any pool who also want to be paid (Technicolor, Motorola, Nokia, etc.).
I've always felt like H.264 hit a great sweet spot of complexity vs compression. Newer codecs compress better, but they're increasingly complex in a nonlinear way.
Doesn't every state of the art codec do that, including H.264 versus previous?
Also I haven't seen charts of decode difficulty, but as far as encoding goes, codecs a generation more advanced can crush H.264 at any particular level of effort. The even newer codecs can probably get there too with more encoder work. https://engineering.fb.com/wp-content/uploads/2023/02/AV1-Co...
Generally yes, but I wasn't only talking about compute costs. Mentally grokking H.264's features and inner workings is a lot easier than newer, better codecs.
H.262 has a long future too. New DVDs and OTA broadcasts (at least for ATSC 1.0) will probably end at some point, but the discs won't go away for a long time, even if disc players are less and less popular.
This is true, but I think I settled on either VP8 or VP9 because it's already widely supported, and it's part of webm, so people will maintain support just for backwards compatibility.
It also benefits from the extremely optimized encoder x264, which has many easily approachable tunings and speed/compression presets.
I’m not sure I’d trust x265 to preserve film grain better than x264 —tune film unless I gave x265 much, much more time as well as pretty similar bitrate.
MPEG 5 EVC Baseline, arguably the improved / refined version of H.264, actually compress better while having the same complexity, Both in terms of mental model and computational cost.
> Well OK, but what about H.265? It's one louder, isn't it?
I had some old, gigantic, video footage (in a variety of old, inefficient, formats at a super high quality).
So I did some testing and, well, ended up re-encoding/transcoding everything to H.265. It makes for much smaller files than H.264. The standard is also ten years younger than H.264 (2013 for H.265 vs 2003 for H.264).
Years ago I was photographing a party in silicon valley (had just graduated college and was taking any job I could get). I take a nice photo of a couple and the wife looks at me and says " You know my husband invented H264? Do you know what that is?".
Ended up having a long conversation with the husband (the engineer) and he hinted many times that they were working currently on something even better. Years later now of course we have H265. Everytime I play something in H264 or H265 I think of that moment and how much work that guy and his colleagues must have put into coding such a widely used codec (and how proud his wife was!)
VVC is a generational improvement in compression ratio over AV1, which might make it the best for a lot of applications. Too bad it will probably languish in patent licensing hell.
Well people definitely had complaints about HEVC compared to H.264 and VP9, but it seems that HEVC did perfectly fine.
I deal with a lot of video and HEVC is by and far the most used codec that I see.
I am not sure why AV1 vs VVC will go any differently.
Just like HEVC was about a generation better than VP9, VVC is about a generation better than AV1.
I guess it depends on what streaming companies choose. Since they all chose HEVC, all the cheap player chips in TVs and boxes and sticks all have HEVC hardware decode. Even though YouTube chose VP9, it didn't really seem to make a difference in the grand scheme of things.
YouTube chose AV1 of course, but if all the streaming companies go VVC, well then I think it will proliferate similarly to HEVC.
Unless you need hardware acceleration. I’ve managed to implement live h265 encode and decode with Directx12 on Windows on Intel and Nvidia, but the driver crashes on AMD and they seem uninterested in fixing it, so there I have to fallback to h264.
Maybe I need to change some options, but I find whatever encoder I get when I ask ffmpeg to encode h265 takes a very long time. Then decoding 4k h265 is very slow on most of my PCs.
I do a lot of video compression for hobby projects, and I stick with h264 for the most part because h265 encoding requires far too much extra compute relative to the space savings. I can spend an hour compressing a file down to 1gb with h264, or I can spend 12 hours compressing the same file to 850mb with h265. Depending on the use-case, I might still need the h264 version anyway since it's far more widely supported by clients. If I had a data center worth of compute to throw at encoding, or I were running a streaming service where the extra 150mb per video started to add up, then I'd definitely on-board with h265 but it's really hard to justify for a lot of practical use-cases.
> I stick with h264 for the most part because h265 encoding requires far too much extra compute relative to the space savings. I can spend an hour compressing a file down to 1gb with h264, or I can spend 12 hours compressing the same file to 850mb with h265.
FWIW, as someone who is a complete layman on this topic but has spent much of the past 6 months converting age-old videos to h265...
i have a pi5 where i queue up old videos into a RAM disk, it converts them to h265, and moves them back to the machine which uploaded them. It can take up to 2 days to compress any given video (depending mostly on the input format - old AVIs tend to compress in a few hours), but the space savings is _much_ higher than what you're reporting. The average size of my h265-encodes is anywhere from 1/3rd to 1/2 of the original, and 1/4th of the original is not terribly uncommon. That said: the input formats vary wildly, with possibly only a minority fraction being h264.
i've tried the same thing using a pi4 but it needs roughly 4-5x as long as the pi5. An 8-core intel-based laptop can do it in some 25% of the time of the pi5 but pulls a lot more electricity while doing so. So my otherwise idle pi5 gets the assignment.
My Firefly collection (14 tv episodes plus the movie) dropped from 8gb to 2.1gb. My Bob Ross collection (141 videos) went from 38gb to 7.4gb. 128 Futurama episodes/movies was cut from roughly 50gb to 21gb.
i was once asked why i didn't choose AV1 and the answer is simple: when i googled along the lines of "how to get the best video compression with ffmpeg" the most common answer was h265. Whether that's correct or not, i can't say, but it works for me and i've freed up the better part of a terabyte of space with it.
Interesting, your numbers look to be quite a bit better than the 30% improvement I've heard is the standard rule of thumb for how much improvement to expect with h.265, and on average for me it's been closer to 20%. I think h.265 starts to show much more meaningful improvements as you start using lower bitrates, and the specific type of media probably matters a bit as well.
I do most of my encoding on an i9-13900k. I've also noticed that h.265 seems to be quite a bit more likely to trigger the smt related crashes in ffmpeg, which makes it a pain when I've queued up a lot of things to encode over night.
What about when you’re recording (say your iPhone / android / standalone camera) - are you choosing h264 or h265 (or something else like an intra-frame only codec for easier editing).
Most of what I do is working with pre-recorded video, but for projects where I'm doing recording I tend to use h.264 since I don't have a lot of devices that support h.265 anyway, and picking one format with broad compatibility is generally more important to me than the efficiency gains I'd get using h.265 when I could.
Is GPU accelerated encoding not an option?
I haven't actually done the comparison myself, but the common refrain is that the quality of the video suffers when you use GPU accelerated encoding. That's not a tradeoff I want to make, so I've just stuck with CPU encoding.
9 replies →
There two types of GPU acceleration: acceleration by a hardware codec bolted on a GPU, and actual GPU computational acceleration. the latter is not widely used but probably is not n gonna have any difference in terms of quality, and provides only modest acceleration.
I really like HEVC/h265. It's pretty much on par with VP9. but licensing trouble has made it difficult to get adopted everywhere even now. VVC/h266 seems to be having the same issues; AV1 is pretty much just as good and already seeing much more adoption.
What’s the tldr of the licensing problems?
I’ve started reading this article which list the various H.26x proposals - https://en.m.wikipedia.org/wiki/Video_Coding_Experts_Group
Seems like the group that comes with these is eventually part of the UN ? https://en.m.wikipedia.org/wiki/International_Telecommunicat...
Is it because they come with the codecs “jointly” with the MPEG organization, which is for profit? If the group is part of a standards organization that’s part of the UN, I feel like they should come up with non-patent-encumbered “recommendations”.
> What’s the tldr of the licensing problems?
There are multiple patent pools for H.265 wanting to be paid licensing fees (MPEG LA, HEVC Advance, Velos Media). HEVC Advance and Velos Media even want content distribution licensing fees.
And there are patent holders not in any pool who also want to be paid (Technicolor, Motorola, Nokia, etc.).
It's a mess.
16 replies →
iPhone, DJI, Cameras etc all use H.265 or RAW.
It's really like H.264 all over again where everyone claims the patent pools make a big difference but only on the periphery.
"Cameras all use H.265", curious , what cameras are you referring to?
While some cameras do support it, it's much more common to use ProRes, DNxHD/DNxHR or h264 in all-intra mode (as e.g. in XAVC-I and XAVC-S-I).
h265, or long-GOP codecs in general, are only really used for long talking head shots or lectures.
1 reply →
“Everyone” meaning the vocal minority of HN users trying to maintain the purity of their Gentoo installs.
1 reply →
I've always felt like H.264 hit a great sweet spot of complexity vs compression. Newer codecs compress better, but they're increasingly complex in a nonlinear way.
Doesn't every state of the art codec do that, including H.264 versus previous?
Also I haven't seen charts of decode difficulty, but as far as encoding goes, codecs a generation more advanced can crush H.264 at any particular level of effort. The even newer codecs can probably get there too with more encoder work. https://engineering.fb.com/wp-content/uploads/2023/02/AV1-Co...
Generally yes, but I wasn't only talking about compute costs. Mentally grokking H.264's features and inner workings is a lot easier than newer, better codecs.
H.264 will probably never die, especially once all the patents expire in a few years.
H.262 has a long future too. New DVDs and OTA broadcasts (at least for ATSC 1.0) will probably end at some point, but the discs won't go away for a long time, even if disc players are less and less popular.
2 replies →
This is true, but I think I settled on either VP8 or VP9 because it's already widely supported, and it's part of webm, so people will maintain support just for backwards compatibility.
When do they expire?
1 reply →
It also benefits from the extremely optimized encoder x264, which has many easily approachable tunings and speed/compression presets.
I’m not sure I’d trust x265 to preserve film grain better than x264 —tune film unless I gave x265 much, much more time as well as pretty similar bitrate.
x265 has a specific "--tune grain" mode specifically for video with a lot of film grain.
1 reply →
But with hardware acceleration for both encoding and decoding of HEVC it feels like less of a problem IMO.
Video piracy is pretty much all in HEVC
23 replies →
MPEG 5 EVC Baseline, arguably the improved / refined version of H.264, actually compress better while having the same complexity, Both in terms of mental model and computational cost.
Somewhat unfortunate that never became anything.
Twitch... I just had DiVX vs Xvid flashbacks
> Well OK, but what about H.265? It's one louder, isn't it?
I had some old, gigantic, video footage (in a variety of old, inefficient, formats at a super high quality).
So I did some testing and, well, ended up re-encoding/transcoding everything to H.265. It makes for much smaller files than H.264. The standard is also ten years younger than H.264 (2013 for H.265 vs 2003 for H.264).
Years ago I was photographing a party in silicon valley (had just graduated college and was taking any job I could get). I take a nice photo of a couple and the wife looks at me and says " You know my husband invented H264? Do you know what that is?".
Ended up having a long conversation with the husband (the engineer) and he hinted many times that they were working currently on something even better. Years later now of course we have H265. Everytime I play something in H264 or H265 I think of that moment and how much work that guy and his colleagues must have put into coding such a widely used codec (and how proud his wife was!)
She should say "helped to invent". Video codec standard development is most definitely a group effort.
3 replies →
What about VVC (H.266)?
https://en.wikipedia.org/wiki/Versatile_Video_Coding
VVC has a lot of the same issues that plagued HEVC adoption. There really isn't much reason to not use AV1 if you want the best codec currently.
VVC is a generational improvement in compression ratio over AV1, which might make it the best for a lot of applications. Too bad it will probably languish in patent licensing hell.
2 replies →
Well people definitely had complaints about HEVC compared to H.264 and VP9, but it seems that HEVC did perfectly fine.
I deal with a lot of video and HEVC is by and far the most used codec that I see.
I am not sure why AV1 vs VVC will go any differently.
Just like HEVC was about a generation better than VP9, VVC is about a generation better than AV1.
I guess it depends on what streaming companies choose. Since they all chose HEVC, all the cheap player chips in TVs and boxes and sticks all have HEVC hardware decode. Even though YouTube chose VP9, it didn't really seem to make a difference in the grand scheme of things.
YouTube chose AV1 of course, but if all the streaming companies go VVC, well then I think it will proliferate similarly to HEVC.
Unless you need hardware acceleration. I’ve managed to implement live h265 encode and decode with Directx12 on Windows on Intel and Nvidia, but the driver crashes on AMD and they seem uninterested in fixing it, so there I have to fallback to h264.
Well, it’s two louder, obviously.
Best in terms of compression efficiency. Although x266 has been delayed by 6 months and counting.
But it is currently being used in India and China already. So its usage is much bigger than a lot of people would imagine.
Have you experimented with it much? First I am hearing of it
HEVC and AV1 is twice more magic. It keep the same quality to human eyes while reducing the bitrate by 50%.
HEVC is patent encumbered. Users who use old hardware don't have hardware decoder. So both requires more time to be adopted.
Maybe I need to change some options, but I find whatever encoder I get when I ask ffmpeg to encode h265 takes a very long time. Then decoding 4k h265 is very slow on most of my PCs.
It sure gets the file size down though.