6 ms·

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 t

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.

radicality 2y ago
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).
- rebeccaskinner 2y ago
  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.
Osiris 2y ago
Is GPU accelerated encoding not an option?
- rebeccaskinner 2y ago
  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.
  - a_wild_dandan 2y ago
    Wait, why does GPU encoding affect the output quality? Is that common in transcoding stuff?
    - dawidpotocki 2y ago
      GPU video encoding is pretty much always optimised for real-time encoding, meaning that it can't run certain optimisations as it would increase the time to encode. Compare x264 veryfast and veryslow presets. There is a quality difference at the same bitrate. Additionally, GPU encoders don't have as many psychovisual options as CPU encoders as they would need to be included in the hardware and adding extra options to CPU encoders is much faster, easier and cheaper. You could build a non-realtime GPU encoder, but there is not much point.
    - ksec 2y ago
      >why does GPU encoding affect the output quality Every single encoder, regardless or hardware or software will output different output quality. Video Encoding is a lossy encoding, not lossless like ZIP or RAR. That is the same with Audio that is why people test different audio encoder. It seems more people knows this about Audio than Video. At least on HN. GPU encoding quality has always been lower quality than Software. Primary because they trade off quality for speed. It is good enough once you hit certain bitrate, but at low bitrate where absolutely encoding efficiency is required Hardware Encoding just dont compare to software. Even with Software you could have multiple encoder with different results. It is not like H.266 / HEVC only has x266 as encoder, example Netflix uses BEAMR. And Broadcasting TV station uses other encoder that better suits their needs. And it is one reason why I dislike all these AV1 discussion, whenever people said it is slow they said use SVT-AV1, well yes SVT-AV1 is faster but dont produce the best AV1 quality encode. So what is the point. It is like every time these discussions about AV1 AOM supporters will just move the goal post.
      - charrondev 2y ago
        I mean the thing with something like SVT-AV1 is, even if it doesn’t give you the best efficiency encode, does it do a more efficient encode than your alternatives in a reasonable timeframe.
- SomeoneFromCA 2y ago
  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.
sgbeal 2y ago
> 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.
- rebeccaskinner 2y ago
  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.

radicality 2y ago

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).

rebeccaskinner 2y ago
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.

Osiris 2y ago

Is GPU accelerated encoding not an option?

rebeccaskinner 2y ago
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.
- a_wild_dandan 2y ago
  Wait, why does GPU encoding affect the output quality? Is that common in transcoding stuff?
  - dawidpotocki 2y ago
    GPU video encoding is pretty much always optimised for real-time encoding, meaning that it can't run certain optimisations as it would increase the time to encode. Compare x264 veryfast and veryslow presets. There is a quality difference at the same bitrate. Additionally, GPU encoders don't have as many psychovisual options as CPU encoders as they would need to be included in the hardware and adding extra options to CPU encoders is much faster, easier and cheaper. You could build a non-realtime GPU encoder, but there is not much point.
  - ksec 2y ago
    >why does GPU encoding affect the output quality Every single encoder, regardless or hardware or software will output different output quality. Video Encoding is a lossy encoding, not lossless like ZIP or RAR. That is the same with Audio that is why people test different audio encoder. It seems more people knows this about Audio than Video. At least on HN. GPU encoding quality has always been lower quality than Software. Primary because they trade off quality for speed. It is good enough once you hit certain bitrate, but at low bitrate where absolutely encoding efficiency is required Hardware Encoding just dont compare to software. Even with Software you could have multiple encoder with different results. It is not like H.266 / HEVC only has x266 as encoder, example Netflix uses BEAMR. And Broadcasting TV station uses other encoder that better suits their needs. And it is one reason why I dislike all these AV1 discussion, whenever people said it is slow they said use SVT-AV1, well yes SVT-AV1 is faster but dont produce the best AV1 quality encode. So what is the point. It is like every time these discussions about AV1 AOM supporters will just move the goal post.
    - charrondev 2y ago
      I mean the thing with something like SVT-AV1 is, even if it doesn’t give you the best efficiency encode, does it do a more efficient encode than your alternatives in a reasonable timeframe.
SomeoneFromCA 2y ago
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.

sgbeal 2y ago

> 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.

rebeccaskinner 2y ago
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.