AV1 question

[amateurgod 33]

I've just ordered an intel Arc A40 GPU to upgrade from my quadro P1000 and noticed it supports AV1. I was wondering if I used this to re-encode all my media to AV1 to save space, if a client without AV1 support tries to play it will Emby transcode it into a container that is supported by the client?

 

I ask because while most my devices have AV1 support, there's like 2 that I haven't gotten around to upgrading yet. 

[rbjtech 5284]

Yes - to h264 if on the stable release, or the option of h265 (experimental) on the beta.

Either way, the AV1 transcode on those clients will lose quality - but it will play.

[amateurgod 33]

Thank you, I thought that would be the case but wanted to double check before setting up all my library to get re encoded to AV1.

[justinrh 260]

7 hours ago, amateurgod said:

re-encode all my media to AV1 to save space

Curious as to what you are re-encoding from.  Will the re-encoding also cost you some quality?

[amateurgod 33]

29 minutes ago, justinrh said:

Curious as to what you are re-encoding from.  Will the re-encoding also cost you some quality?

Usually h265 or h264, so lossy to lossy, so there will be some quality loss, but I doubt I'll notice it and if the filesizes are a large difference I'm willing to accept that loss

[pwhodges 2012]

Going from h265 to AV1 is not a big saving for equivalent quality; the quality loss in re-encoding will likely nullify the slight gain in compactness of the AV1 encoding. Going from h264 is easier to defend, though there will still be some quality loss however many bits you give the result.

Paul

[rbjtech 5284]

3 hours ago, pwhodges said:

Going from h265 to AV1 is not a big saving for equivalent quality; the quality loss in re-encoding will likely nullify the slight gain in compactness of the AV1 encoding. Going from h264 is easier to defend, though there will still be some quality loss however many bits you give the result.

Paul

It really depends on the target bitrate.   At ultra low bitrates sub 1 Mbit/sec, then I believe AV1 clearly has an advantage on bitrate vs quality vs h265/hevc - but above this for 'normal' bitrates - then I would agree - h265 > AV1 is probably going to lose you quality for no real filesize change.   Agree again h264 > AV1 is likely worth it.    

I chose the h264 > h265 path (fairly recently actually, in the last year or so) as AV1 doesn't appear to be getting as much attention / market as it should - adoptions seems very slow - thus in my eyes, it's probably risky doing a h265>AV1 incremental upgrade at this time.

Edited April 29, 2025 by rbjtech

[amateurgod 33]

4 hours ago, pwhodges said:

Going from h265 to AV1 is not a big saving for equivalent quality; the quality loss in re-encoding will likely nullify the slight gain in compactness of the AV1 encoding. Going from h264 is easier to defend, though there will still be some quality loss however many bits you give the result.

Paul

ill be using Tdarr to automate it with it only keeping the re-encoded version if it saves more than 25% otherwise it will keep the original, so not everything will be re-encoded only stuff that actually saves a decent amount of storage. most of what i have are bluray remuxes or web-DL so i expect to save space with the remuxes but not so much with the web-DL

[pwhodges 2012]

Do you plan to set a target bitrate, or a fixed CRF, or what?

You might want to vary the parameters according to the amount of action involved, with different targets also for animated and real-life series.

Paul

[Lessaj 467]

A few months ago I converted all my h264 files to h265 and included that conversion as part of my ingestion pipeline. I did some initial testing with bit rates/quality settings and found for me that I could target an h265 bitrate that was 1/2 of the h264 bitrate and couldn't really tell a difference outside of a few select scenarios that I came across when spot checking certain things - like a nature documentary scene that was full of a swarm of bugs had some pretty bad blockiness, but I'm not really surprised for that scene that was the result. It does seem that for animations a slightly higher bitrate would be better but my automation has no way to know what kind of content it is, it's a very basic blanket take the bitrate divide by 2, I should probably add some bounds checks to make sure the bitrate isn't too low as a result though. File sizes are roughly 50-65% the original file size with little to no discernible difference in quality to me outside specific scenarios. You'll have to do some of your own testing and see the results.

[rbjtech 5284]

25 minutes ago, Lessaj said:

A few months ago I converted all my h264 files to h265 and included that conversion as part of my ingestion pipeline. I did some initial testing with bit rates/quality settings and found for me that I could target an h265 bitrate that was 1/2 of the h264 bitrate and couldn't really tell a difference outside of a few select scenarios that I came across when spot checking certain things - like a nature documentary scene that was full of a swarm of bugs had some pretty bad blockiness, but I'm not really surprised for that scene that was the result. It does seem that for animations a slightly higher bitrate would be better but my automation has no way to know what kind of content it is, it's a very basic blanket take the bitrate divide by 2, I should probably add some bounds checks to make sure the bitrate isn't too low as a result though. File sizes are roughly 50-65% the original file size with little to no discernible difference in quality to me outside specific scenarios. You'll have to do some of your own testing and see the results.

50% - wow - brave.

I used constant quality in the end and got a decent enough 30% saving (h264>h265) - but unless you review everything (obviously impossible to do) there is no real way of knowing what detail you may have lost.  Of course, as you have the original - then you can just re-encode it when you eventually discover it looks like a VHS ... 

[Jdiesel 1431]

What profile and level did you use for your h265 encodes. I have some older FireTVs that have limited support for h265, potentially just Main profile, and Emby was failing to detect playback compatibility with the devices which caused playback to outright fail. I have considered moving to h265 but want to maintain maximum direct play compatibility.

[Lessaj 467]

4 minutes ago, rbjtech said:

50% - wow - brave.

I used constant quality in the end and got a decent enough 30% saving (h264>h265) - but unless you review everything (obviously impossible to do) there is no real way of knowing what detail you may have lost.  Of course, as you have the original - then you can just re-encode it when you eventually discover it looks like a VHS ... 

I tried using some of the h265 constant quality profile settings, I forget what the command line arguments I tried are now, but some files weren't noticably smaller and I think sometimes were even larger when I was trying to dial in a value that seemed acceptable, so I went the bitrate route. To be fair Emby will do 50% higher bitrate for h265->h264 transcoding.

[Lessaj 467]

6 minutes ago, Jdiesel said:

What profile and level did you use for your h265 encodes. I have some older FireTVs that have limited support for h265, potentially just Main profile, and Emby was failing to detect playback compatibility with the devices which caused playback to outright fail. I have considered moving to h265 but want to maintain maximum direct play compatibility.

I'm not specifying anything in my command, but looks like it's Main level 120 based on the info I can see. I tried using a 10bit format as well (which I think is level 123) but I didn't notice any difference with file size or the time to re-encode so I stuck with 8bit.

$FFMPEG -loglevel error -stats -hwaccel cuda -i "$INPUT" -c:v hevc_nvenc -preset:v medium -b:v ${BITRATE} -c:a copy -c:s copy "$OUTPUTHEVC"

 

Edited April 29, 2025 by Lessaj

[amateurgod 33]

On 29/04/2025 at 14:58, pwhodges said:

Do you plan to set a target bitrate, or a fixed CRF, or what?

You might want to vary the parameters according to the amount of action involved, with different targets also for animated and real-life series.

Paul

I forgot to replay to this, however I discovered AV1 has a lossless mode and FFMPEG added support for lossless AV1 if you set the CRF to 0 or on GPU the qp to 0 

 

I have been doing lossless AV1 transcodes while also creating more audio streams as I create duplicates of my audio streams and rencode them to AAC, so for example TrueHD7.1 would also get an AAC7.1 alongside it for compatibility and I've been saving literal GBs, most new files tend to be between 10-20% of the original size, for example a 29Gb file after being re-encoded was 3.7Gb and that was with AV1 lossless or as close to lossless as you can get with a GPU since how I understand it is true lossless can only be done on CPU and hardware acceleration can get close but not perfect lossless, either way though there is no visible loss in quality that I can tell from before and after 

[RanmaCanada 494]

You might want to check your VMAF scores to see if you're within tolerable range. Most of us don't accept anything with a score of less than 95. I test mine with ffmetrics as it allows you to test multiple encoded files of the master file to help you tune your settings.

[visproduction 315]

Variable bit rate can cause issues with Web media streaming delivery.  Variable should really only be used for direct file playback and not to send to any user over the Internet.  Of course, variable can work, but the problem is in the placement of the I Frames within TCP packets.  When there is a large media file and the required I Frame packet is lost, or arrives inside a TCP packet, out of order, the player needs to play cached media until the I Frame arrives to set up the next block of video content.  So, with online traffic, out of order or lost TCP packets cause more buffering with variable bit rate, compared to constant bit rate.  This effect does sort of slide around, depending on the media size.  The diference might not be noticable for someone with a fast connection, but it can grow worse with variable bit rate for a user on a slower or mobile connection that is far removed from the server.  I would think that any speed test an admin runs on the server or with a nearby connected test user,  would not see much difference.  But it is a known issue.  I believe that major online streaming sites have avoided variable, for this reason as well as variable transcoding just takes a lot longer.

I have not kept up to date with the latest codecs,  Perhaps some of this is solved, but since Emby needs to transcode a lot of video codecs that are not .mp4 (h.264) anyway, the variable bit rate would be more taxing on the transcoding than a constant bit rate, so the efficiency and quality of media delivery drops again for a different reason if you use variable bit rate on non-.mp4 (h.264) codecs.

See info on this: https://duckduckgo.com/?q=iFrame+video+codec+variable+bit+rate+problem+over+Internet+TCP&ia=web 

Edited October 26, 2025 by visproduction