I’ve tried encoding AV1 (1080 H264 BD sources) and it was ridiculously slow (we are talking days at the slowest preset, all on CPU of course).
It did not seem viable for DIY needs. That being said, I don’t have a Threadripper, I am assuming a 9975WX would bring it down to 4-8 hours depending on the movie length.
I would imagine AV2 is going to be exponentially slower in DIY environments. Not that streaming companies would care. They can easily buy a cluster of x64 top end Threadrippers or those dense 192 core EPYC CPUs and hire several people whose whole job is managing and optimizing this process.
For most applications I assume you want to leverage AV1 hardware encoding to use it, and I imagine it would be the same for AV2 etc. We might’ve been a bit spoilt by H.264 being literally >20 years old at this point (and even VP9 and H.265 being >10 years old).
It is my understanding that for archival/“close to transparent” encodes you want to use the CPU. With x264/x265 I get noticeably worse quality when using the GPU. For a video that I may use for the next ~10 years (I’ve started ripping, to Xvid, in the early 2000s), I would rather focus on quality.
There’s a balance since (at least in general) you can just accept slightly higher file size to offset the advantage of significantly faster encoding time. Some (most?) hardware encoders have “pretty good” quality levels so imo if you can get, say, 90% of the quality at same file size but then offset the loss with 110-120% file size to match “100%” quality, then that can be a pretty appealing tradeoff if it makes your encode an order of magnitude faster.
The tradeoffs aren’t just between quality vs encode time, they’re between quality vs encode time vs file size. Of course, where each person’s preferences are in making the tradeoffs will vary! But storage is cheap and it’s hard for me personally to justify saving what might even generously be a cent’s worth of storage costs by making an encode take a relative eternity for the sake of maximal compression efficiency.
Agreed, you can generally get acceptable quality with low file size (4-5 GB) with using x264 (~3 Mbps average) even without using the “very slow” preset.
I target “close to transparent” quality above all factors at the lowest file size possible. I am willing to do multiple rounds of encodes to targets this.
That being said there is source BD content (older movies mostly) that is difficult to encode and sometimes even cases when I don’t bother and simply mux in the raw x264/x265/VC1 stream.
One example is the Hornblower series from the late 90s, early 2000s. Lot’s of images of the sea, rain/storms, sailing ships out at sea. You can notice the lower quality with lower compression/file size at faster encoding presets.
For whatever reason, the Primer (2004) BD source encodes very badly even with x265 at high bitrate and the “very slow” preset. I just went with source BD stream and gave up on encodes with Primer.
Honestly if storage costs weren’t an issue, I would go with remuxes for older FHD/newer 4K content, with encodes only for newer FHD movies and DVD/MPEG2. But x5 20 TB HDDs and a good enclosure would work out to be about $2700 were I live. An SSD based system (arguably a pointless luxury for NAS media storage) would be much higher.
With GPU encodes, I also notice a quality differential for any given bitrate outside of “non competitive” option. Since quality is the key, this doesn’t work for me.
Funny how even with giant streaming services, there is still relatively large “market” for home DIY movie collections.
Wow, I don’t even get that level of speed with x264 1080p transcodes, although I guess it makes sense preset 9 on AV1 (I’ve only done “very slow” encodes with x264/x265).
80% compression is very low though. 40% - 60% is my target for x264/x265 for moderately complex content (x265 can achieve better “close to transparent” compression for newer content, made after 2005 or so).
cpu av1 is slow af, especially if you’re targeting ‘archival quality’. if you’re just after something ‘watchable’ (~ ‘dvd quality’), a lowly haswell i7 can do it at a ‘reasonable’ speed.
i would suggest trying a recent-gen (lovelace or newer) nvidia card with av1 support in hardware. a 4060 is running well here for what i’m currently doing. i also have a low-end alchemist (a380), but nvenc works better for me than qsv.
I only do CPU encodes at the slowest encoder preset possible (above placebo) as this is for my movies/series collection that I’ve been building for ~20 years.
I do actually watch the movies/series both by myself and with others, so this is not just OCD data hoarding. :)
I’ve tried it on a threadripper and it’s still way too slow. Hardware encoding is required for anything other than short clips. Use x265 for software encoding.
Which Threadripper? What preset (I am assuming this is for 1080p sources) and how much did it take to transcode 90 minutes.
I am sticking to x265 for HD content (x264 is fine for DVDRips), AV1 takes too long to encode and I didn’t see a noticeable improvement for size/quality ratio dynamics.
To be honest, I don’t even see a significant improvement with x265 (relative to x264) for content made before ~2005 or so. Grainy and older content generally requires file sizes comparable to x264 transcodes if you want to preserve grain and avoid smoothing.
It was a 1950x. I canceled the transcode after several hours and it only got though a couple minutes of 1080p video. I don’t remember the exact times, it was about 5 years ago. I haven’t bothered with AV1 since then.
Yeah, the first time I tried AV1 (on CPU) I also cancelled the transcode after 4 hours.
I was out for a few days, so I left the encode on. It was something stupid like over 50 hours for a 90 minute movie on a 5800X (this was on the slowest preset doe the AV1 encoder, since that’s what always use for x264/x265).
I would imagine Threadripper 9000 performance is notably better than the the 1950X even if you get a 16 core CPU. Going for a 32 core CPU should roughly halve the timing even further.
I’ve tried encoding AV1 (1080 H264 BD sources) and it was ridiculously slow (we are talking days at the slowest preset, all on CPU of course).
It did not seem viable for DIY needs. That being said, I don’t have a Threadripper, I am assuming a 9975WX would bring it down to 4-8 hours depending on the movie length.
I would imagine AV2 is going to be exponentially slower in DIY environments. Not that streaming companies would care. They can easily buy a cluster of x64 top end Threadrippers or those dense 192 core EPYC CPUs and hire several people whose whole job is managing and optimizing this process.
For most applications I assume you want to leverage AV1 hardware encoding to use it, and I imagine it would be the same for AV2 etc. We might’ve been a bit spoilt by H.264 being literally >20 years old at this point (and even VP9 and H.265 being >10 years old).
It is my understanding that for archival/“close to transparent” encodes you want to use the CPU. With x264/x265 I get noticeably worse quality when using the GPU. For a video that I may use for the next ~10 years (I’ve started ripping, to Xvid, in the early 2000s), I would rather focus on quality.
There’s a balance since (at least in general) you can just accept slightly higher file size to offset the advantage of significantly faster encoding time. Some (most?) hardware encoders have “pretty good” quality levels so imo if you can get, say, 90% of the quality at same file size but then offset the loss with 110-120% file size to match “100%” quality, then that can be a pretty appealing tradeoff if it makes your encode an order of magnitude faster.
The tradeoffs aren’t just between quality vs encode time, they’re between quality vs encode time vs file size. Of course, where each person’s preferences are in making the tradeoffs will vary! But storage is cheap and it’s hard for me personally to justify saving what might even generously be a cent’s worth of storage costs by making an encode take a relative eternity for the sake of maximal compression efficiency.
Agreed, you can generally get acceptable quality with low file size (4-5 GB) with using x264 (~3 Mbps average) even without using the “very slow” preset.
I target “close to transparent” quality above all factors at the lowest file size possible. I am willing to do multiple rounds of encodes to targets this.
That being said there is source BD content (older movies mostly) that is difficult to encode and sometimes even cases when I don’t bother and simply mux in the raw x264/x265/VC1 stream.
One example is the Hornblower series from the late 90s, early 2000s. Lot’s of images of the sea, rain/storms, sailing ships out at sea. You can notice the lower quality with lower compression/file size at faster encoding presets.
For whatever reason, the Primer (2004) BD source encodes very badly even with x265 at high bitrate and the “very slow” preset. I just went with source BD stream and gave up on encodes with Primer.
Honestly if storage costs weren’t an issue, I would go with remuxes for older FHD/newer 4K content, with encodes only for newer FHD movies and DVD/MPEG2. But x5 20 TB HDDs and a good enclosure would work out to be about $2700 were I live. An SSD based system (arguably a pointless luxury for NAS media storage) would be much higher.
With GPU encodes, I also notice a quality differential for any given bitrate outside of “non competitive” option. Since quality is the key, this doesn’t work for me.
Funny how even with giant streaming services, there is still relatively large “market” for home DIY movie collections.
I encode at roughly half the material’s playtime with a 1080p source. Using a Ryzen 3600 with Handbrake/SVT-AV1 @ RF 25, Preset 9.
Edit: I achieve about 80% compression like this
Wow, I don’t even get that level of speed with x264 1080p transcodes, although I guess it makes sense preset 9 on AV1 (I’ve only done “very slow” encodes with x264/x265).
80% compression is very low though. 40% - 60% is my target for x264/x265 for moderately complex content (x265 can achieve better “close to transparent” compression for newer content, made after 2005 or so).
cpu av1 is slow af, especially if you’re targeting ‘archival quality’. if you’re just after something ‘watchable’ (~ ‘dvd quality’), a lowly haswell i7 can do it at a ‘reasonable’ speed.
i would suggest trying a recent-gen (lovelace or newer) nvidia card with av1 support in hardware. a 4060 is running well here for what i’m currently doing. i also have a low-end alchemist (a380), but nvenc works better for me than qsv.
I only do CPU encodes at the slowest encoder preset possible (above placebo) as this is for my movies/series collection that I’ve been building for ~20 years.
I do actually watch the movies/series both by myself and with others, so this is not just OCD data hoarding. :)
I’ve tried it on a threadripper and it’s still way too slow. Hardware encoding is required for anything other than short clips. Use x265 for software encoding.
Which Threadripper? What preset (I am assuming this is for 1080p sources) and how much did it take to transcode 90 minutes.
I am sticking to x265 for HD content (x264 is fine for DVDRips), AV1 takes too long to encode and I didn’t see a noticeable improvement for size/quality ratio dynamics.
To be honest, I don’t even see a significant improvement with x265 (relative to x264) for content made before ~2005 or so. Grainy and older content generally requires file sizes comparable to x264 transcodes if you want to preserve grain and avoid smoothing.
It was a 1950x. I canceled the transcode after several hours and it only got though a couple minutes of 1080p video. I don’t remember the exact times, it was about 5 years ago. I haven’t bothered with AV1 since then.
Yeah, the first time I tried AV1 (on CPU) I also cancelled the transcode after 4 hours.
I was out for a few days, so I left the encode on. It was something stupid like over 50 hours for a 90 minute movie on a 5800X (this was on the slowest preset doe the AV1 encoder, since that’s what always use for x264/x265).
I would imagine Threadripper 9000 performance is notably better than the the 1950X even if you get a 16 core CPU. Going for a 32 core CPU should roughly halve the timing even further.