[Bug]: HEVC/AV1 encode is ~2-3x larger then AV1 source

[vid-bin]

Which component impacted?

Encode

Is it regression? Good in old configuration?

None

What happened?

I am using some YouTube clips to test 8k -> 4k encodes and the overall best encoding settings to use.

When using landscape videos with slow moving content the output format (YouTube 8k60 AV1 10bit or 8bit -> HEVC_QSV 10bit) the end results are usually a smaller encode than YouTube. By a significant amount.

However when you throw a lot of fast moving content into the video (such as raindrops with fast movements) the output can be 2.5x as large as YouTube av1 video.

Example: 8k60 AV1 8bit (1.7GB size) -> 4k60 HEVC_QSV 10bit (4.37GB size)

Encode options on DG2/arc with linux:

"-pix_fmt yuv420p10le", "-global_quality 20", "-extbrc 1", "-b_strategy 1", "-look_ahead 1", "-preset 1", "-tile_cols 1", "-tile_rows 1", "-adaptive_i 1", "-adaptive_b 1", "-tier 256", "-mbbrc 1"

What's the usage scenario when you are seeing the problem?

Transcode for media delivery

What impacted?

No response

Debug Information

No response

Do you want to contribute a patch to fix the issue?

None

[intel-mediadev]

Auto Created VSMGWL-68043 for further analysis.

[vid-bin]

Same issue with av1_qsv with the ICQ patch that was just released. The only difference is the file size is around twice as large as the same H265 encode with a global_quality of 21.

~900MB AV1 8k source is around 1.6GB H265_QSV or 2.6GB AV1_QSV when converted to 5k resolution on a slow moving landscape video.

For av1_qsv with a global_quality of 30 it's around 600MB.

[OttoYang]

Hi @vid-bin, if you want to reduce file size in ICQ mode, you can increase the value of global_quality.
Because high motion contents require a higher bit rate to achieve the quality set by user.

[vid-bin]

Hi @vid-bin, if you want to reduce file size in ICQ mode, you can increase the value of global_quality. Because high motion contents require a higher bit rate to achieve the quality set by user.

Yeah but it shouldn't be larger then the source file should it? Seems odd. It's not like I'm doing an ICQ of 5-7 or anything like that.

[OttoYang]

Hi @vid-bin, if you want to reduce file size in ICQ mode, you can increase the value of global_quality. Because high motion contents require a higher bit rate to achieve the quality set by user.

Yeah but it shouldn't be larger then the source file should it? Seems odd. It's not like I'm doing an ICQ of 5-7 or anything like that.

For transcoding, it is divided into two parts, decoding and encoding, the encoding process references the decoded raw data rather than the source file. If you want the new encoded file to be smaller than the source file, maybe you need to set the target bitrate smaller than the source file or the qp value larger than the source file.

[BlakeB415]

Hi @vid-bin, if you want to reduce file size in ICQ mode, you can increase the value of global_quality. Because high motion contents require a higher bit rate to achieve the quality set by user.

Yeah but it shouldn't be larger then the source file should it? Seems odd. It's not like I'm doing an ICQ of 5-7 or anything like that.

If the source is from YouTube, YouTube often does CPU encoding using libaom-av1 which can hit lower bitrate targets. HEVC is also a different codec to AV1 so I'm not sure why it's being compared here. Consumer fixed-function hardware encoders don't usually have the same efficiency as software ones.

[OttoYang]

Hi @vid-bin , I'm not sure if these answers will help you?
And if you have any other concerns or questions, please feel free to post them here.

[OttoYang]

Hi @vid-bin , I'd like to know if you have any other questions about this?

[fredrik-eriksson]

I have a related (or maybe same) observation regarding AV1 encoding. My understanding of ICQ is that it is an algorithm to ensure consistent subjective quality and my assumption has been that this subjective quality parameter is independent on the codec used. Meaning that the quality will be the same for any codec with an ICQ of 16 (my test sample), but depending on the efficiency of the codec the resulting file size will differ. Either this assumption is not true or the intel AV1 encoding needs some work:

h264 (8 bit, as 10 bit encoding is not supported):

-c:v h264_qsv -profile:v high -global_quality:v 16 -look_ahead 1 -scenario:v archive -preset:v veryslow -low_power 1

Filesize: ~1.9G

hevc:

-vf vpp_qsv=format=p010 -c:v hevc_qsv -profile:v main10 -global_quality:v 16 -look_ahead 1 -scenario:v archive -preset:v veryslow -low_power 1

Filesize: ~1.3G

av1:

-vf vpp_qsv=format=p010 -c:v av1_qsv -profile:v main -global_quality:v 16 -look_ahead 1 -scenario:v archive -preset:v veryslow -low_power 1

Filesize: ~5.9G

My eyes are not good enough to compare the quality of the encodes (they all look great), but I found this very unexpected. Is my assumption about ICQ values wrong and how does they vary between codecs in that case? Or is this a bug in the AV1 encoder?

[leyu-yao]

I have a related (or maybe same) observation regarding AV1 encoding. My understanding of ICQ is that it is an algorithm to ensure consistent subjective quality and my assumption has been that this subjective quality parameter is independent on the codec used. Meaning that the quality will be the same for any codec with an ICQ of 16 (my test sample), but depending on the efficiency of the codec the resulting file size will differ. Either this assumption is not true or the intel AV1 encoding needs some work:

h264 (8 bit, as 10 bit encoding is not supported):

-c:v h264_qsv -profile:v high -global_quality:v 16 -look_ahead 1 -scenario:v archive -preset:v veryslow -low_power 1

Filesize: ~1.9G

hevc:

-vf vpp_qsv=format=p010 -c:v hevc_qsv -profile:v main10 -global_quality:v 16 -look_ahead 1 -scenario:v archive -preset:v veryslow -low_power 1

Filesize: ~1.3G

av1:

-vf vpp_qsv=format=p010 -c:v av1_qsv -profile:v main -global_quality:v 16 -look_ahead 1 -scenario:v archive -preset:v veryslow -low_power 1

Filesize: ~5.9G

My eyes are not good enough to compare the quality of the encodes (they all look great), but I found this very unexpected. Is my assumption about ICQ values wrong and how does they vary between codecs in that case? Or is this a bug in the AV1 encoder?

Hi @fredrik-eriksson Since AV1 and HEVC is using different ICQ algorisms, we are expecting some certain file size difference. We run quality tests upon our internal clips. We do observe some file size difference between AV1 and HEVC on some clips, but not so large as what you observed, like 5.9G over 1.3G. The max file size difference we found is AV1 is 65% larger than HEVC. To further investigate into this issue, we would like to debug into the specific clip if you are fine with sharing out the test clip, that would be of great help for us to narrow this issue.

[fredrik-eriksson]

Certainly, I will attempt to send you a private link for the test clip. I don't remember which sample I used for the previous test, but it was probably an Anime bluray. I get basically the same size difference using the first 5 minutes of the Suzume bluray.

Test clip is 5 minutes long, has no audio and is ~1,2G. It has black borders at top and bottom, and I did test encodes both with them in place and cropped away.

AV1:

/opt/jellyfin-ffmpeg/ffmpeg -v verbose -init_hw_device qsv=hw \
-filter_hw_device hw -hwaccel qsv -hwaccel_output_format qsv -i test.mkv \
-vf vpp_qsv=format=p010 -c:v av1_qsv -profile:v main -global_quality:v 16 \
-look_ahead 1 -scenario:v archive -preset:v veryslow -low_power 1 -map 0 test.av1.mkv

AV1 (cropped):

/opt/jellyfin-ffmpeg/ffmpeg -v verbose -init_hw_device qsv=hw \
-filter_hw_device hw -hwaccel qsv -hwaccel_output_format qsv -i test.mkv \
-vf vpp_qsv=ch=800:cy=140:format=p010 -c:v av1_qsv -profile:v main -global_quality:v 16 \
-look_ahead 1 -scenario:v archive -preset:v veryslow -low_power 1 -map 0 test.av1.mkv

HEVC:

/opt/jellyfin-ffmpeg/ffmpeg -v verbose -init_hw_device qsv=hw \
-filter_hw_device hw -hwaccel qsv -hwaccel_output_format qsv -i test.mkv \
-vf vpp_qsv=format=p010 -c:v hevc_qsv -profile:v main10 -global_quality:v 16 \
-look_ahead 1 -scenario:v archive -preset:v veryslow -low_power 1 -map 0 test.mkv

HEVC (cropped):

/opt/jellyfin-ffmpeg/ffmpeg -v verbose -init_hw_device qsv=hw \
-filter_hw_device hw -hwaccel qsv -hwaccel_output_format qsv -i test.mkv \
-vf vpp_qsv=ch=800:cy=140:format=p010 -c:v hevc_qsv -profile:v main10 -global_quality:v 16 \
-look_ahead 1 -scenario:v archive -preset:v veryslow -low_power 1 -map 0 test.mkv

codec	crop	size (bytes)
av1	no	403856667
av1	yes	306393515
hevc	no	112054276
hevc	yes	115689503

Note that for AV1 cropping the black borders cut almost 100MB, but for HEVC it instead increased size by 4MB.

GPU is DG2 (Arc A750). Other version information:	package	version	comment
jellyfin-ffmpeg	6.0.1-1
media-driver	23.4.1	gentoo package
onevpl-intel-gpu	23.4.1	gentoo package

[fredrik-eriksson]

Since I've heard no reply, I assume my e-mail was never received. I've shortened the test file to 1 minute and ~260MB and made it available here. I still get roughly the same compress-ratios as posted in previous comment with this file. Please let me know when the clip is no longer needed.

EDIT: Link removed

[leyu-yao]

Since I've heard no reply, I assume my e-mail was never received. I've shortened the test file to 1 minute and ~260MB and made it available here. I still get roughly the same compress-ratios as posted in previous comment with this file. Please let me know when the clip is no longer needed.

Thanks @fredrik-eriksson We had downloaded your clip. We are analyzing some of our clips on AV1/HEVC ICQ, and we will work on the clip you provided.