6 ms·
Maybe this is not such a concern to audience of this article, but at least for me I'm stuck with h264 because VP9/AV1 encoding is really really slow. I'd love t
by jampekka 3y ago
Maybe this is not such a concern to audience of this article, but at least for me I'm stuck with h264 because VP9/AV1 encoding is really really slow. I'd love to use the codecs that are open and technically better, but when the video encodes at 1fps, it's too just too convenient to use the magnitudes faster h264.
I'm probably not up to date with newer/hardware encoders and please let me know if my view is outdated.
- brucethemoose2 3y agoThe hardware encoders are very fast and generally better than x264 (but not by as much as you'd think with the x264 slow preset). In addition, there are fast threaded AV1 encoders you may be overlooking, like SVT-AV1. For non-realtime, my favorite is av1an, which also yields better quality than is possible from aomenc and works with pretty much any encoder/codec: https://github.com/master-of-zen/Av1an https://github.com/master-of-zen/Av1an
- Osiris 3y agoHardware encoders are fine for streaming but not archiving. A CPU encoder can produce a file that is half the size or less for the same quality.
- brucethemoose2 3y agoYes, but AV1 hardware encoding beats x264 software encoding, if thats the only other option (albeit not by much).
- netol 3y agoDo you have a way to reproduce this?
- brucethemoose2 3y agoThis comparison is not mine, and its excellent: https://giannirosato.com/blog/post/nvenc-v-qsv/ https://giannirosato.com/blog/post/nvenc-v-qsv/ x264 used the medium 10 bit preset, which is a bit of an oddball because 10 bit AVC is "unofficial," and many hardware decoders don't support it.
- mihaic 3y agoThe benchmark should be against x265 though, which is mainstream now
- tormeh 3y agoIs it? AFAICT most things are still on h264.
- vitorgrs 3y agoMost things where? Like, the biggest video app on the earth called Youtube uses mostly VP9/AV1 (it will only play H.264 if you don't have any encoding for VP9 OR AV1, which is very, rare). Netflix also uses H.265/AV1. Amazon, HBO, Disney, etc also use H.265, but I believe only on higher resolutions. On Apple world even phone pics uses HEVC (HEIC). I think it's a total mix honestly (Because tiktok/X/Meta uses h264 as far I know).
- LASR 3y agoMost things like the rest of the world - H.264 is really the only option. More technically correctly, more than half the currently in use devices in the world do not support more than H.264 Like all my Smart TVs, my kitchen iMac, my parents’ phones etc. only my phone and my laptop support HEVC.
- vitorgrs 3y agoThey force AV1 and VP9 via software decoding even if your hardware doesn't support it. Youtube been using VP9 for a decade, even without HW support at the time. Netflix uses AV1 when on mobile data, even if the HW doesn't support as well (for TVs, it need HW decoding). The only way to not use VP9 on Youtube is if you don't have the codec installed, which is super rare because the codec is open.
- bick_nyers 3y agox264 opponents are earlier versions of AV1, namely VP8 and VP9. x265 should be what is compared against AV1 when discussing quality and encode speeds. We use x264 for compatibility purposes, if your device is intended to play video, it will decode x264. x265 decoders are in a lot of devices at this point, and AV1 is just now starting to see representation. x264 is like .jpeg and will probably never die.
- brucethemoose2 3y agoYeah y'all are preaching to the choir, but AVC is still the default for... Well, everything, including OP. It will probably eventually be like mp3, where users are still reflexively encoding to it without a good reason.
- amlib 3y agoUnlike mp3s compared to other audio codecs, h264 has the luxury of pretty much ubiquitous support for hardware decoders and encoders against other video codecs, so I believe it will have an even longer life than mp3.
- vore 3y agoA nitpick: x264 is an encoder implementation, the format itself is called H.264 (and H.265).
- querez 3y agoav1an is essentially a "wrapper" around other encoders. I've played around with it lot in the past, but have never seen any real quality gains from using it (as measured by VMAF) instead of just using the encoder directly. Am I doing something wrong? What exactly does av1an buy me (except maybe for better independent threads?)
- brucethemoose2 3y agoFirst some background. Av1an works by splitting videos into scenes/chunks, which it then encodes in parallel. But this also allows it to change encoding settings for each scene. Specifically, it has a "VMAF target" mode that encodes a few frames from each scene as samples, measures their VMAF, and then boosts or reduces the encoding preset for that individual scene based on the result. It also has a "black boost" feature to allocate more bitrate to dark scenes, which encoders and various metrics tend to misrepresent. Also, the possibilities with the VapourSynth support are infinite. Some simple examples include denoising a noisy video on the GPU for better quality than the encoders' CPU denoising, or deblocking with custom parameters, or upscaling with some model in PyTorch. And that's just the start: https://vsdb.top/ https://vsdb.top/
- FreezyLemon 3y agoThere's a feature that allows you to try and target a specific VMAF score, but it doesn't work very well. What av1an does do for you is increase the speed by a lot, especially for aomenc and rav1e, which don't scale well with high thread counts. SVT-AV1 doesn't really have this problem. A faster encode might allow using a slower speed/preset setting, which would increase quality per bitrate a little bit. But I don't really consider av1an a tool that increases encode quality, to be honest.
- malloc-0x90 3y ago1. Compile this: https://gitlab.com/AOMediaCodec/SVT-AV1 https://gitlab.com/AOMediaCodec/SVT-AV1 2. ffmpeg -i infile.mp4 -map 0:v:0 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp -i stdin --preset 6 --keyint 240 --input-depth 10 --crf 30 --rc 0 --passes 1 --film-grain 0 -b infile.ivf 3. ffmpeg -i infile.ivf -i infile.mp4 -map 0:v -map 1:a:0 -c copy outfile.mp4
- dylan604 3y agoTricks of the trade: why have one computer compress the file when you can split it up into logical segments and have each segment sent to its own encoder?
- tombert 3y agoBack when I still cared about saving disk space, I made a cluster of NVidia Jetson Nanos running in a docker swarm configuration [1] to compress my blu-ray rips, but honestly even when you have six computers working at once, H264 on a single computer is still often faster. On the Jetson Nanos I was lucky to get maybe 1fps in ffmpeg using VP9. Multiply that by six boards and that's about 6fps in total; ffmpeg running x264 in software mode was getting around 11fps on a single board, not even counting using the onboard encoder chip, meaning that I was getting better performance from one board using x264 than all six using VP9. Now obviously this is a single anecdote on specific hardware, so I'm not saying that this applies to every single case, but it's a big reason why I personally have not used VP9 for anything substantial yet. [1] https://gitlab.com/tombert/distributed-transcode https://gitlab.com/tombert/distributed-transcode
- dylan604 3y agoh.264 is from the 90s, so of course it's fast after ~30 years of use. hell, when I first got into encoding, we had dedicated expansion cards to do MPEG-1/MPEG-2 encoding because it was so difficult at the time. New codecs always take time in the beginning while the encoding software is tweaked/optimized. Eventually, it becomes part of the CPU hardware and then we all make comments like "remember when ____ was so slow?" one day, you'll regale the young whiper snappers on internet forums about how painfully slow AV1 encodes were when they start complaining how newHotnessEncoder5000 is so slow.
- imtringued 3y agoOk. You are allowed to think that but stop forcing AV1 down my throat, because you think CPUs will be both cheap and fast in the far away future, because as far I am aware, I exist in the present moment until that future arrives.
- deleted 3y ago[deleted]
- shmerl 3y agoHaven't tested it yet. I'm waiting for OBS to enable hardware accelerated AV1 encoding on Linux.
- sergiotapia 3y agoHow are you getting 1fps encoding? I see 332fps on my 12900K with preset 10. -vf scale=1280:720 -c:v libsvtav1 -crf 30 -preset 7 -c:a libopus -b:a 96k -ac 2
- RealStickman_ 3y agoPreset 10 is pretty fast, but you're disabling a lot of the features that allow better quality and compression ratios (see readme on the svt-av1 repo). For archiving 3 or 4 is probably good.
- blihp 3y agoAV1 hardware encode just started rolling out with the most recent GPU architectures so the majority of hardware still has to do software encoding. I'd also guess that a very large fraction of the hardware out there doesn't even have hardware decode for AV1 since it was only the last generation of GPUs that got that. AV1 is mainly solving problems for the platform owners (google/netflix/facebook etc) and h264 will probably serve typical users for years to come especially if they have that one device they want to keep using that only supports h264.
- rb2k_ 3y agoIn the past (with h265 / h264 at least), hardware encoding always ended up with visibly worse quality (and often even bigger file sizes) compared to a software encoder like x264/x265. Do you happen to know if that's still the case? (I guess for use-cases such as live streaming it doesn't matter that much, but for video that ends up in some archive, it's probably less acceptable)
- blihp 3y agoThat's usually the case as the hardware encoders tend to make tradeoffs in the direction of lower transistor count / faster frame processing while software encoders have the luxury of going for higher quality.
- bick_nyers 3y agoIt's around 5% (maybe 10%?) larger file sizes for same visual quality at the moment. For archival I think that's fine, as storage is cheap, it can still be a problem when you pay for outbound bandwidth to users.
- adgjlsfhk1 3y agohardware encoding gives up a little quality and filesize, but hardware encoding of AV1 will generally beat software encoding of X264 on all axes.
- FreezyLemon 3y agoYes, a YouTuber named EposVox released a video on AV1 hardware encoding when the first Intel dGPUs with support for it released: https://www.youtube.com/watch?v=ctbTTRoqZsM https://www.youtube.com/watch?v=ctbTTRoqZsM Later on in the video, there are some graphs comparing Intel's AV1 encoder to SVT-AV1 at different speed presets. Even one of the faster presets (9) will comfortably stay above AV1 quality according to VMAF, and if you don't need real-time speeds you can lower the preset to get further ahead of the hardware encoder. (BTW: That video is >1 year old now, and SVT-AV1 had some significant updates in the meantime too. So the software side is probably looking better now.)
- aidenn0 3y agoI care mainly about archiving, so 1FPS encodes for 24fps content is within the range that I consider okay. However, I ran into issues with decoder speed too; whatever codec Kodi was using 18 months ago struggled to decode high-bitrate 1080p AV1 video last time I tried. Maybe this weekend I'll try again on the current version of Kodi.
- bick_nyers 3y agoTry encoding with a "low-latency" or a "fast-decode" parameter, and see if that is acceptable to you. Keep in mind not all AV1 encoders are created equal. If you're on Windows I recommend using StaxRip for encoding.
- aidenn0 3y agoI'm on Linux, currently using ffmpeg for encoding. I'll look for options that might improve decodability, but I seem to recall I had to go pretty aggressive on both of the two av1 encoders I tried to get any savings vs H.265
- bick_nyers 3y agoIt depends on what bitrate you are targeting, and the source content. AV1 does not outperform H265 at high bitrates (and in certain cases, medium bitrates). What is considered "high bitrate" is dependent on source content, but a good rule of thumb is 40 MBit (think BluRay quality) or more for 4k content almost always goes to H265. For AV1, depending on what you are encoding, and how much extra time you want to dedicate to experimentation, take a look at grain synthesis (you will want to test decode capabilities on that one).
- crazygringo 3y agoThat sounds crazy slow. Look into what flags you're using, and choose a setting that reduces CPU in exchange for compressing less. All the major codecs have flags for you to balance speed against quality and compression, and it's up to you to pick the right tradeoffs for your use case. And for most purposes, you want to use software encoders because they're much more flexible in terms of flags/options than hardware encoders. (Hardware encoders are usually optimized for speed rather than quality -- they're for live capture more then for video conversion.)
- turtlebits 3y agoSame here. I'm not willing to pony up money for hardware/compute to encode AV1. I encode x265 on a $2.5/month VPS w/ 4gb ram during the off hours. AV1 is almost an order of magnitude slower.
- cbhl 3y agoMy understanding is there is some support for GPU-accelerated AV1 encoding in top-of-the-line latest-gen discrete GPUs that can be used for live streaming with OBS Studio 29.1 or higher. Helpful if you are in a situation where you have extra GPU and are tight on bandwidth. In my opinion it's still in the early-adopter phase though, and it's perfectly valid to use tried-and-true codecs for user-interactive rendering and encoding cases, or where the existing codec meets your requirements for the compute vs disk/bandwidth trade-off.
- ksec 3y agoIn terms of software encoding that is still the case. You are basically doing a trade-off between, Bit-Rate / File Size and Encoding Time. We could have EVC which provide same H.264 ( or x264 ) encoding time but 30%+ Bit-Rate reduction. But market seems to want maximum BitRate reduction regardless of computational complexity.