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 4939]

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 212]

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 1832]

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 4939]

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 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 1832]

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 277]

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 4939]

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 1285]

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 277]

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 277]

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 by Lessaj