9 ms·

Guide to Adopting AV1 Encoding

160 points by andyfrancis 3y ago

eternityforest 3y ago
What's the state of mpeg-ts support? Or is there some other fixed block size, streamable container I can push over a network without having to think about block boundaries or stream negotiation or formats or metadata? With mp4 and TS it's almost trivial to get subsecond latency on a websocket, I hope AV1 has something like it.
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 ago
  The 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 ago
    Hardware 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 ago
      Yes, but AV1 hardware encoding beats x264 software encoding, if thats the only other option (albeit not by much).
      - netol 3y ago
        Do you have a way to reproduce this?
        brucethemoose2 3y ago
        This 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 ago
        The benchmark should be against x265 though, which is mainstream now
        tormeh 3y ago
        Is it? AFAICT most things are still on h264.
        vitorgrs 3y ago
        Most 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 ago
        Most 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.
  - querez 3y ago
    av1an 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 ago
      First 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 ago
      There'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 ago
  1. 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 ago
  Tricks 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 ago
    Back 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 ago
      h.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 ago
        Ok. 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 ago
  Haven't tested it yet. I'm waiting for OBS to enable hardware accelerated AV1 encoding on Linux.
- sergiotapia 3y ago
  How 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 ago
    Preset 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 ago
  AV1 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 ago
    In 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 ago
      That'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 ago
      It'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 ago
      hardware 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 ago
      Yes, 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 ago
  I 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 ago
    Try 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 ago
      I'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 ago
        It 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 ago
  That 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 ago
  Same 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 ago
  My 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 ago
  In 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.
techhiveblogs 3y ago
[flagged]
shmerl 3y ago
> YouTube for example, encodes content in H.264/AVC, VP9 and AV1 Why don't I see AV1 in many Youtube videos though? Checking with yt-dlp. It looks like they were planning to use it, but didn't really roll it out.
- Almondsetat 3y ago
  Av1 is almost always present in >2k videos
- adgjlsfhk1 3y ago
  the new codecs tend to only get deployed for higher resolution. 5% better 360p video doesn't help if you are also sending 4k video.
  - shmerl 3y ago
    Ah, that makes sense. Just checked one with high resolution available and I can see AV1 there.
  - andyfrancis 3y ago
    Yeah, that's true. I did see something from Meta recently where they were delivering lower resolution/bandwidth AV1 to devices that didn't have AV1 hardware decoders, but had enough CPU for software decoding of the smaller renditions.
- Jap2-0 3y ago
  My (not super informed) understanding is that it may also depend on how popular the video is - the increase in encoding time is less worth it if there are few people seeing quality or bandwidth benefits (depending on how they tune it).
  - snvzz 3y ago
    >if there are few people seeing quality or bandwidth benefits (depending on how they tune it). The client readiness is there. Already at 75% (relative to H264 100%, HEVC 15%). It is thus clear which of the new codecs won client-side; it will only grow from here. Definitely worth it.
deleted 3y ago
[deleted]
dmillar 3y ago
OPUS should have an honorable mention here. Same case could be made for OPUS vs AAC/AC3/etc.
- Dwedit 3y ago
  OPUS is everywhere where WebRTC is used, as a Mandatory to Implement codec.
- poser-boy 3y ago
  I too wish Opus got more love in the video space. Outside of YouTube and VOIP, it doesn't get used. Shame since Opus is smarter with bitrate allocation with surround sound.
- MrDrMcCoy 3y ago
  Opus is the best lossy codec I've used by a wide margin. My only complaint is that it isn't very flexible on sample rates. There are occasions where I want to really squeeze the bandwidth without sounding like it's coming over a telephone, and with other codecs I could do that by setting the sample rate to 32khz in addition to the more standard tuning. Opus sadly doesn't support that.
beastman82 3y ago
The only part of this that is a "guide to encoding" is them pitching their encoding mechanism. Quite a misleading title
Ayesh 3y ago
Instead of being a "guide" as it says in the title, this is merely comparing AV1 to other codecs, and ends by promoting their own thing. I don't think AV1 needs any "convincing", it's theoretically just better in every aspect. It's the tooling and hardware that needs work.
- tverbeure 3y ago
  One of my take-aways after going through it is the cross-over point between h.264 and AV1: it depends on the numbers of expected view. AV1 is computationally more intensive and there's a dollar number assigned to that.
  - judge2020 3y ago
    > AV1 is computationally more intensive and there's a dollar number assigned to that. This will only get cheaper over time as hardware accelerators get implemented and are improved YoY.
    - imtringued 3y ago
      Servers don't get hardware accelerators. I am forced to run everything with llvmpipe and then encode it with vp8 and essentially run at 80% to 90% CPU utilization 24/7. Yes the 1080p@30fps stream takes 2mbit/s in the worst case, no I don't give a damn about making it smaller. That is literally pointless. Yes in theory I could add eight times the CPU power to make it stream 4k@60fps and still end up with a lower bit rate but I don't care, because the CPU is the bottleneck and that many cores is incredibly expensive.
      - judge2020 3y ago
        Throwing a GPU in your server is always an option. Plex people have been doing it since forever to get HW-accelerated transcoding.
mastax 3y ago
I'm surprised the HEVC Support figure is so low: 15%! I suppose HEVC is practically only supported by relatively modern devices which have hardware support for it. None of the OS or browser makers want to ship software support because they'd have to pay the license fee. (I paid $1 for the HEVC extension in the Windows Store but I'm sure that's exceedingly rare). Browsers can ship software AV1 support without needing to pay.
- clouddrover 3y ago
  In addition to codec licensing fees, another problem with HEVC is the threat of content licensing fees: https://streaminglearningcenter.com/codecs/codec-royalties-on-content.html https://streaminglearningcenter.com/codecs/codec-royalties-o... It's just not worth it. Royalty-free formats (like AV1) are the way to go on the web.
  - MrDrMcCoy 3y ago
    Isn't AV1 also better on technical merits like quality per megabyte? I know it's computationally slower, but that can be fixed.
    - clouddrover 3y ago
      In these tests SVT-AV1 beats x265 on quality: - FullHD: http://compression.ru/video/codec_comparison/2022/main_report.html http://compression.ru/video/codec_comparison/2022/main_repor... - FullHD 10-bit: http://compression.ru/video/codec_comparison/2022/10_bit_report.html http://compression.ru/video/codec_comparison/2022/10_bit_rep... - 4K: http://compression.ru/video/codec_comparison/2022/4k_report.html http://compression.ru/video/codec_comparison/2022/4k_report.... SVT-AV1 has seen a number of speed ups in recent releases: https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases
poser-boy 3y ago
I'm sure AV1 will have it's time. But for now I'm preferring x265 HEVC for hi-fi video (movies etc.).
jzl 3y ago
I was doing some AV1 research recently and was surprised to find that there is still quite a bit of controversy about whether and how much it is still patent encumbered. In fact one of the top search hits is this HN sub-thread: https://news.ycombinator.com/item?id=30915369 https://news.ycombinator.com/item?id=30915369 Also interesting: https://news.ycombinator.com/item?id=23747923 https://news.ycombinator.com/item?id=23747923
dgreensp 3y ago
Is AV1 encoding still many times slower / more computationally intensive than other codecs? I think when they were developing it, it was said that the difference would mostly disappear as encoders got more optimized. (Not because of hardware encoding, apparently; I am learning that in contrast to hardware decoding, hardware encoding is limited and isn't a win if quality is important.)
- ksec 3y ago
  AV1 quality encoding complexity will always be higher than most older codec. That is by nature, I put emphasise on quality, because you could arguably disable all the AV1 features and lower the complexity to VP9 or h.264 level. But then you dont get the bitrate reduction benefits. Whether that higher computing requirement is justify will be up to debate. And depending on your usage people will have different trade offs.
betaporter 3y ago
Oh look a very long ad.
jknutson 3y ago
Good lord. This site is objectively annoying on mobile. As soon as I load the page, full-screen cookie consent notice, paired with some support chat widget that was overlapping with the accept/decline buttons on the cookie consent form. Had to turn my phone to landscape mode to get the chat widget out of the way to handle the cookie consent. Then, as soon as I accept the cookie consent form, the page immediately starts to reload. I cancel the reload/navigation, find the close button for the chat widget, and finally start to scroll and read the content after 20 seconds of fidgeting with the page. Immediately as I start scrolling, I realize the app bar header banner thing at the top of the page is actually being rendered with position: sticky; or some equivalent, and to top things off they’ve actually done me the favor of including some marketing banner ad about their “video developer report survey” being available, and they went ahead and attached that on top of their app bar, and also made it sticky. I was delighted to see that there was in fact no way to close that ad, as well. Seriously— why do we make sites like this? The top 1/3rd of my screen is a useless banner and app bar that I have no intent to use whatsoever, the bottom 1/5th of my screen is that stupid chat widget, all I have is… let me do the math here… give or take half of my phone screen to actually read the content of the site. /rant
- MrDrMcCoy 3y ago
  Mobile Firefox with uBlock Origin didn't have those issues for me. Even if they did, the built in reader mode usually fixes it. Just throwing that out there for people who want to avoid such nonsense.
a1o 3y ago
Is h264 safe now to implement in things without being surprised by someone hitting you with some license fee or patent royalty? What is the status in it?
- ksec 3y ago
  >Is h264 safe now to implement in things without being surprised by someone hitting you with some license fee or patent royalty? What is the status in it? I assume you mean to be included in things where things is either software or hardware? For software you get that for free from pretty much every single shipping PC, Smartphone or Tablet. So you really shouldn't implement it yourself. For hardware you still need to paid a tiny license fees ( which is why RPi 5 doesn't include it ) If you ignore extensions like SVC (Scalable Video Coding) and MVC (Multiview Video Coding) where most people dont use it. The normal H.264, especially baseline and Main Profile will have 99% of its patents expired within next 3-4 years.
snvzz 3y ago
>75% AV1-ready vs 15% HEVC-ready This means AV1 won, client-side. Now it is about time for the likes of netflix, youtube, twitch to deploy AV1 server-side. And we can say goodbye to MPEG and patent encumbered codecs. Good riddance.

160 points by andyfrancis 3y ago

What's the state of mpeg-ts support? Or is there some other fixed block size, streamable container I can push over a network without having to think about block boundaries or stream negotiation or formats or metadata? With mp4 and TS it's almost trivial to get subsecond latency on a websocket, I hope AV1 has something like it.

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 ago
The 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 ago
  Hardware 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 ago
    Yes, but AV1 hardware encoding beats x264 software encoding, if thats the only other option (albeit not by much).
    - netol 3y ago
      Do you have a way to reproduce this?
      - brucethemoose2 3y ago
        This 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 ago
      The benchmark should be against x265 though, which is mainstream now
      - tormeh 3y ago
        Is it? AFAICT most things are still on h264.
        vitorgrs 3y ago
        Most 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 ago
        Most 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.
- querez 3y ago
  av1an 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 ago
    First 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 ago
    There'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 ago
1. 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 ago
Tricks 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 ago
  Back 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 ago
    h.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 ago
      Ok. 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 ago
Haven't tested it yet. I'm waiting for OBS to enable hardware accelerated AV1 encoding on Linux.
sergiotapia 3y ago
How 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 ago
  Preset 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 ago
AV1 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 ago
  In 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 ago
    That'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 ago
    It'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 ago
    hardware 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 ago
    Yes, 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 ago
I 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 ago
  Try 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 ago
    I'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 ago
      It 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 ago
That 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 ago
Same 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 ago
My 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 ago
In 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.

techhiveblogs 3y ago

[flagged]

shmerl 3y ago

> YouTube for example, encodes content in H.264/AVC, VP9 and AV1 Why don't I see AV1 in many Youtube videos though? Checking with yt-dlp. It looks like they were planning to use it, but didn't really roll it out.

Almondsetat 3y ago
Av1 is almost always present in >2k videos
adgjlsfhk1 3y ago
the new codecs tend to only get deployed for higher resolution. 5% better 360p video doesn't help if you are also sending 4k video.
- shmerl 3y ago
  Ah, that makes sense. Just checked one with high resolution available and I can see AV1 there.
- andyfrancis 3y ago
  Yeah, that's true. I did see something from Meta recently where they were delivering lower resolution/bandwidth AV1 to devices that didn't have AV1 hardware decoders, but had enough CPU for software decoding of the smaller renditions.
Jap2-0 3y ago
My (not super informed) understanding is that it may also depend on how popular the video is - the increase in encoding time is less worth it if there are few people seeing quality or bandwidth benefits (depending on how they tune it).
- snvzz 3y ago
  >if there are few people seeing quality or bandwidth benefits (depending on how they tune it). The client readiness is there. Already at 75% (relative to H264 100%, HEVC 15%). It is thus clear which of the new codecs won client-side; it will only grow from here. Definitely worth it.

deleted 3y ago

[deleted]

dmillar 3y ago

OPUS should have an honorable mention here. Same case could be made for OPUS vs AAC/AC3/etc.

Dwedit 3y ago
OPUS is everywhere where WebRTC is used, as a Mandatory to Implement codec.
poser-boy 3y ago
I too wish Opus got more love in the video space. Outside of YouTube and VOIP, it doesn't get used. Shame since Opus is smarter with bitrate allocation with surround sound.
MrDrMcCoy 3y ago
Opus is the best lossy codec I've used by a wide margin. My only complaint is that it isn't very flexible on sample rates. There are occasions where I want to really squeeze the bandwidth without sounding like it's coming over a telephone, and with other codecs I could do that by setting the sample rate to 32khz in addition to the more standard tuning. Opus sadly doesn't support that.

beastman82 3y ago

The only part of this that is a "guide to encoding" is them pitching their encoding mechanism. Quite a misleading title

Ayesh 3y ago

Instead of being a "guide" as it says in the title, this is merely comparing AV1 to other codecs, and ends by promoting their own thing. I don't think AV1 needs any "convincing", it's theoretically just better in every aspect. It's the tooling and hardware that needs work.

tverbeure 3y ago
One of my take-aways after going through it is the cross-over point between h.264 and AV1: it depends on the numbers of expected view. AV1 is computationally more intensive and there's a dollar number assigned to that.
- judge2020 3y ago
  > AV1 is computationally more intensive and there's a dollar number assigned to that. This will only get cheaper over time as hardware accelerators get implemented and are improved YoY.
  - imtringued 3y ago
    Servers don't get hardware accelerators. I am forced to run everything with llvmpipe and then encode it with vp8 and essentially run at 80% to 90% CPU utilization 24/7. Yes the 1080p@30fps stream takes 2mbit/s in the worst case, no I don't give a damn about making it smaller. That is literally pointless. Yes in theory I could add eight times the CPU power to make it stream 4k@60fps and still end up with a lower bit rate but I don't care, because the CPU is the bottleneck and that many cores is incredibly expensive.
    - judge2020 3y ago
      Throwing a GPU in your server is always an option. Plex people have been doing it since forever to get HW-accelerated transcoding.

mastax 3y ago

I'm surprised the HEVC Support figure is so low: 15%! I suppose HEVC is practically only supported by relatively modern devices which have hardware support for it. None of the OS or browser makers want to ship software support because they'd have to pay the license fee. (I paid $1 for the HEVC extension in the Windows Store but I'm sure that's exceedingly rare). Browsers can ship software AV1 support without needing to pay.

clouddrover 3y ago
In addition to codec licensing fees, another problem with HEVC is the threat of content licensing fees: https://streaminglearningcenter.com/codecs/codec-royalties-on-content.html https://streaminglearningcenter.com/codecs/codec-royalties-o... It's just not worth it. Royalty-free formats (like AV1) are the way to go on the web.
- MrDrMcCoy 3y ago
  Isn't AV1 also better on technical merits like quality per megabyte? I know it's computationally slower, but that can be fixed.
  - clouddrover 3y ago
    In these tests SVT-AV1 beats x265 on quality: - FullHD: http://compression.ru/video/codec_comparison/2022/main_report.html http://compression.ru/video/codec_comparison/2022/main_repor... - FullHD 10-bit: http://compression.ru/video/codec_comparison/2022/10_bit_report.html http://compression.ru/video/codec_comparison/2022/10_bit_rep... - 4K: http://compression.ru/video/codec_comparison/2022/4k_report.html http://compression.ru/video/codec_comparison/2022/4k_report.... SVT-AV1 has seen a number of speed ups in recent releases: https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases

poser-boy 3y ago

I'm sure AV1 will have it's time. But for now I'm preferring x265 HEVC for hi-fi video (movies etc.).

jzl 3y ago

I was doing some AV1 research recently and was surprised to find that there is still quite a bit of controversy about whether and how much it is still patent encumbered. In fact one of the top search hits is this HN sub-thread: https://news.ycombinator.com/item?id=30915369 https://news.ycombinator.com/item?id=30915369 Also interesting: https://news.ycombinator.com/item?id=23747923 https://news.ycombinator.com/item?id=23747923

dgreensp 3y ago

Is AV1 encoding still many times slower / more computationally intensive than other codecs? I think when they were developing it, it was said that the difference would mostly disappear as encoders got more optimized. (Not because of hardware encoding, apparently; I am learning that in contrast to hardware decoding, hardware encoding is limited and isn't a win if quality is important.)

ksec 3y ago
AV1 quality encoding complexity will always be higher than most older codec. That is by nature, I put emphasise on quality, because you could arguably disable all the AV1 features and lower the complexity to VP9 or h.264 level. But then you dont get the bitrate reduction benefits. Whether that higher computing requirement is justify will be up to debate. And depending on your usage people will have different trade offs.

betaporter 3y ago

Oh look a very long ad.

jknutson 3y ago

Good lord. This site is objectively annoying on mobile. As soon as I load the page, full-screen cookie consent notice, paired with some support chat widget that was overlapping with the accept/decline buttons on the cookie consent form. Had to turn my phone to landscape mode to get the chat widget out of the way to handle the cookie consent. Then, as soon as I accept the cookie consent form, the page immediately starts to reload. I cancel the reload/navigation, find the close button for the chat widget, and finally start to scroll and read the content after 20 seconds of fidgeting with the page. Immediately as I start scrolling, I realize the app bar header banner thing at the top of the page is actually being rendered with position: sticky; or some equivalent, and to top things off they’ve actually done me the favor of including some marketing banner ad about their “video developer report survey” being available, and they went ahead and attached that on top of their app bar, and also made it sticky. I was delighted to see that there was in fact no way to close that ad, as well. Seriously— why do we make sites like this? The top 1/3rd of my screen is a useless banner and app bar that I have no intent to use whatsoever, the bottom 1/5th of my screen is that stupid chat widget, all I have is… let me do the math here… give or take half of my phone screen to actually read the content of the site. /rant

MrDrMcCoy 3y ago
Mobile Firefox with uBlock Origin didn't have those issues for me. Even if they did, the built in reader mode usually fixes it. Just throwing that out there for people who want to avoid such nonsense.

a1o 3y ago

Is h264 safe now to implement in things without being surprised by someone hitting you with some license fee or patent royalty? What is the status in it?

ksec 3y ago
>Is h264 safe now to implement in things without being surprised by someone hitting you with some license fee or patent royalty? What is the status in it? I assume you mean to be included in things where things is either software or hardware? For software you get that for free from pretty much every single shipping PC, Smartphone or Tablet. So you really shouldn't implement it yourself. For hardware you still need to paid a tiny license fees ( which is why RPi 5 doesn't include it ) If you ignore extensions like SVC (Scalable Video Coding) and MVC (Multiview Video Coding) where most people dont use it. The normal H.264, especially baseline and Main Profile will have 99% of its patents expired within next 3-4 years.

snvzz 3y ago

>75% AV1-ready vs 15% HEVC-ready This means AV1 won, client-side. Now it is about time for the likes of netflix, youtube, twitch to deploy AV1 server-side. And we can say goodbye to MPEG and patent encumbered codecs. Good riddance.