Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Guide to Adopting AV1 Encoding

bitmovin.com

Post reply on HN
Print view View original

31–40 of 95 posts

Re: Guide to Adopting AV1 Encoding

#31

Post by aidenn0 »

bick_nyers wrote: post #30
aidenn0 wrote: post #19

Earlier quoted context omitted.

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.

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.

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

Re: Guide to Adopting AV1 Encoding

#32

Post by bick_nyers »

dylan604 wrote: post #6
jampekka wrote: post #2

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.

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?

This is done particularly when you are implementing adaptive bitrates (the thing that Netflix uses where it automatically sends you a higher or lower quality picture depending on your Internet connection).

In adaptive bitrate world, you split a video up into fragments, say 2-10 seconds large, and encode each segment in multiple bitrates, so that every say 5 seconds the video player can make a decision to download a different quality for the next 5 seconds.

Ok, but why not split the file up for standard encoding? Well, you can't just concatenate two .mp4 together without re-encoding and have it make sense to most media players (as far as I am aware), and moreover, it's inefficient from a RAM perspective when doing that. 1 second of RAW uncompressed 4k (24 fps) video is about 600MB. Source content for a single episode/movie at Netflix (I don't work there, just something I read once) can reach into the terabytes easily.

Re: Guide to Adopting AV1 Encoding

#33

Post by shmerl »

adgjlsfhk1 wrote: post #13
shmerl wrote: post #7

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

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.

Ah, that makes sense. Just checked one with high resolution available and I can see AV1 there.

Re: Guide to Adopting AV1 Encoding

#34

Post by bick_nyers »

aidenn0 wrote: post #31
bick_nyers wrote: post #30

Earlier quoted context omitted.

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.

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

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

Re: Guide to Adopting AV1 Encoding

#35

Post by bick_nyers »

brucethemoose2 wrote: post #17
Osiris wrote: post #16

Earlier quoted context omitted.

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.

Yes, but AV1 hardware encoding beats x264 software encoding, if thats the only other option (albeit not by much).

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

Re: Guide to Adopting AV1 Encoding

#36

Post by afvid »

dylan604 wrote: post #6
jampekka wrote: post #2

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.

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?

yep, that's what bitmovin does

Re: Guide to Adopting AV1 Encoding

#37

Post by dylan604 »

bick_nyers wrote: post #32
dylan604 wrote: post #6

Earlier quoted context omitted.

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?

This is done particularly when you are implementing adaptive bitrates (the thing that Netflix uses where it automatically sends you a higher or lower quality picture depending on your Internet connection). In adaptive bitrate world, you split a video up into fragments, say 2-10 seconds large, and encode each segment in multiple bitrates, so that every say 5 seconds the video player can make a decision to download a d…

okay, i don't agree with anything in your reply. segmenting a video file for HLS/DASH delivery is not at all the same thing I'm suggesting. Just for the sake of round numbers, i'm saying to take a 90 minute feature into nine 10-minute segments. fire up 10 separate instances to encode each 10-minute segment. you've just increased the encode time 10x. also, DASH/HLS does not require segmented files. you can have a single contiguous file like an fmp4 as a DASH/HLS source.

>Ok, but why not split the file up for standard encoding?

at this point, you would be better served by just writing an elementary stream rather than a muxed mp4 file since it's just a segment anyways so why waste the cycles on muxing? you then absolutely 100% can concat those streams (even if you did mux them into a container). if you think you can't, you clearly have not tried very hard.

>I don't work there, just something I read once

I don't work there either, but do have 30+ years of experience with this subject. Sadly, you're not as well informed as you might think. People don't tend to encode to AV1 from RAW. They instead are dealing with a deliverable file most typically a ProRes in today's world after the post process has been completed. No where near terabytes for a feature. More closely to a couple hundred gigabytes for UHD HDR content. You seem to be unnecessarily exaggerating.

Edit: it's a 10x increase in encode speed, not time. that would be opposite effect.

Re: Guide to Adopting AV1 Encoding

#38

Post by dylan604 »

afvid wrote: post #36
dylan604 wrote: post #6

Earlier quoted context omitted.

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?

yep, that's what bitmovin does

I'm pretty sure that's what everyone does after the first time they try a test encode and see the dismal speeds. It's a trick as old as time. The trick is to make that segment decision better than something like the YT algo that decides where to place an ad break.

Re: Guide to Adopting AV1 Encoding

#39

Post by andyfrancis »

adgjlsfhk1 wrote: post #13
shmerl wrote: post #7

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

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.

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.

Re: Guide to Adopting AV1 Encoding

#40

Post by andyfrancis »

blihp wrote: post #18
jampekka wrote: post #2

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.

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 pro…

Yeah, it will still be a while before anyone can fully get away from h264, but with Apple adding AV1 decoders to their latest chips, hopefully all the wheels are at least in motion now.
Post reply on HN