AMD Aims For AMF Decode In FFmpeg, Questioned Over Vulkan Video Commitment

[Quackdoc]

And who actually cares about such insignificant differences? Either you decode in hardware so it's irrelevant or you decode with dav1d where it won't make a significant difference either. And yes of course, different settings do different things for different codecs, what a surprise. Still, there isn't any relevant difference in the result if you make an actually fair comparison.

it does make a significant difference, svt-av1's fast decoding feature is the difference between 21fps vs 40fps on many of the android devices i've tested at 1080p making the difference between something completely unusable vs something not bad. it also makes a significant difference in battery life too even at 720p, which can be a large concern with services like discord, or in the case I am interested in, video calling.

SVT-AV1 with fast decoding can make a very low bitrate stream that doesn't cripple devices making it ideal for video calling, Another use case I am in is video streaming services with low input high output (a self hosted peertube is a good legal example). Every little bit that you can shave off is a large deal for a lot of services that pay for bandwidth. Optimizing the snot out of bitrate as much as possible while still keeping up with injest is an extremely high priority since it can save a good chunk of money on both hosting and bandwidth costs.

it's actually really significant to a lot of people and services.

[Artim]

it does make a significant difference, svt-av1's fast decoding feature is the difference between 21fps vs 40fps on many of the android devices i've tested at 1080p making the difference between something completely unusable vs something not bad. it also makes a significant difference in battery life too even at 720p, which can be a large concern with services like discord, or in the case I am interested in, video calling.

SVT-AV1 with fast decoding can make a very low bitrate stream that doesn't cripple devices making it ideal for video calling, Another use case I am in is video streaming services with low input high output (a self hosted peertube is a good legal example). Every little bit that you can shave off is a large deal for a lot of services that pay for bandwidth. Optimizing the snot out of bitrate as much as possible while still keeping up with injest is an extremely high priority since it can save a good chunk of money on both hosting and bandwidth costs.

it's actually really significant to a lot of people and services.

If you only get 21 fps with 1080p AV1 on an Android, you're either on some ancient device or have done something very wrong. Of course it's not helpful that Google just threw out their own crappy decoder in favor of dav1d, after using their own decoder way too long.

Also, how on earth did you end up in a discussion about SVT-AV1? Your claim was software encoding > Nvidia > Intel > AMD - and with actually relevant differences - which I questioned, yet you only admit that the result in one single software encoder wildly vary, casting serious doubt that your comparison to come to that questionable conclusion are fair even in the slightest. Of course, you can optimize every encoder for various use cases with the right settings, and of course there is a wider set of possibilities for software encoders as hardware encoders are literally set in hardware and thus can only do a predefined set of things. But that doesn't mean that, e.g. for a set bitrate (or better yet an interval for vbr), the difference in quality of the result will be that different.

[Quackdoc]

If you only get 21 fps with 1080p AV1 on an Android, you're either on some ancient device or have done something very wrong. Of course it's not helpful that Google just threw out their own crappy decoder in favor of dav1d, after using their own decoder way too long.

Also, how on earth did you end up in a discussion about SVT-AV1? Your claim was software encoding > Nvidia > Intel > AMD - and with actually relevant differences - which I questioned, yet you only admit that the result in one single software encoder wildly vary, casting serious doubt that your comparison to come to that questionable conclusion are fair even in the slightest. Of course, you can optimize every encoder for various use cases with the right settings, and of course there is a wider set of possibilities for software encoders as hardware encoders are literally set in hardware and thus can only do a predefined set of things. But that doesn't mean that, e.g. for a set bitrate (or better yet an interval for vbr), the difference in quality of the result will be that different.

Yes. at a given quality SVT-AV1 or Aomenc will be smaller then Nvidia, which is marginally smaller then intel, and both of which are much smaller then AMD. HW encoders can't get remotely close to the quality:bitrate that svtav1 or aomenc can. ofc they are much faster, but the their their lower floor is just much to high.

Both Intel and Nvidia are capable of even lossless encoding, but doing any higher fidelity encoding at remotely the same bitrate as svtav1 or aomenc is just not going to happen.

[Artim]

Yes. at a given quality SVT-AV1 or Aomenc will be smaller then Nvidia, which is marginally smaller then intel, and both of which are much smaller then AMD. HW encoders can't get remotely close to the quality:bitrate that svtav1 or aomenc can. ofc they are much faster, but the their their lower floor is just much to high.

Both Intel and Nvidia are capable of even lossless encoding, but doing any higher fidelity encoding at remotely the same bitrate as svtav1 or aomenc is just not going to happen.

Still, you haven't proven that the difference is that relevant, that it's not only measurable, but noticeable. The tiny amount of saved bandwith or storage and the amount of saved battery when transfering the content, is just in no way comparable with the large reduction of battery use when encoding and decoding in hardware. Sure, SVT-AV1 is a very competent encoder that's not as abysmally slow as many others, but that's due to much better multi threading, and thus higher CPU usage.

[Quackdoc]

Still, you haven't proven that the difference is that relevant, that it's not only measurable, but noticeable. The tiny amount of saved bandwith or storage and the amount of saved battery when transfering the content, is just in no way comparable with the large reduction of battery use when encoding and decoding in hardware. Sure, SVT-AV1 is a very competent encoder that's not as abysmally slow as many others, but that's due to much better multi threading, and thus higher CPU usage.

you are right, I haven't. I generally don't feel a need to because anyone with half a brain and accsess to said hardware can test it for themselves and see that unless you use high cpu presets swenc will look better at a given bitrate. Hell in my testing even svt-vp9 preset 9 can look appreciably better then intel's av1 encoder under "live streaming scenarios". and even when you compare swencodes, sometimes svt-av1 is just plain better then aomenc is.

a good example was a live streaming test I was doing for VDI not only was svt-av1 significantly faster then aomenc in this test, it was also much higher quality stream

https://files.catbox.moe/qsgibn.png

https://files.catbox.moe/41jdeu.png

Another good example was this comparison when I was tesing live streaming svt-av1 vs qsv, qsv in this scenario is significantly worse,

https://slow.pics/c/imZ2OKhg

[Artim]

you are right, I haven't. I generally don't feel a need to because anyone with half a brain and accsess to said hardware can test it for themselves and see that unless you use high cpu presets swenc will look better at a given bitrate. Hell in my testing even svt-vp9 preset 9 can look appreciably better then intel's av1 encoder under "live streaming scenarios". and even when you compare swencodes, sometimes svt-av1 is just plain better then aomenc is.

a good example was a live streaming test I was doing for VDI not only was svt-av1 significantly faster then aomenc in this test, it was also much higher quality stream

https://files.catbox.moe/qsgibn.png

https://files.catbox.moe/41jdeu.png

Another good example was this comparison when I was tesing live streaming svt-av1 vs qsv, qsv in this scenario is significantly worse,
https://slow.pics/c/imZ2OKhg

I have tested it, there isn't any relevant difference. As I said, differences you can only notice with 500x zoom and a side by side comparison just don't count.

PS: your first to pictures didn't load. PR_CONNECT_RESET_ERROR. And without exact encoding parameters that's kinda irrelevant.

[Quackdoc]

I have tested it, there isn't any relevant difference. As I said, differences you can only notice with 500x zoom and a side by side comparison just don't count.

PS: your first to pictures didn't load. PR_CONNECT_RESET_ERROR. And without exact encoding parameters that's kinda irrelevant.

the slowpics files were encoded with svt preset 9 and qsv preset veryslow @ 5000kbs, for the catbox files reload them, catbox can be a bit spotty for some people sometimes

the files presented in the slow.pics are have very noticeable and distracting artifacting without zooming in. in fact, QSV is so bad in this case that I can even zoom out and still easily tell that the qsv encode is heavily degraded compared to svtav1

[Artim]

the slowpics files were encoded with svt preset 9 and qsv preset veryslow @ 5000kbs, for the catbox files reload them, catbox can be a bit spotty for some people sometimes

the files presented in the slow.pics are have very noticeable and distracting artifacting without zooming in. in fact, QSV is so bad in this case that I can even zoom out and still easily tell that the qsv encode is heavily degraded compared to svtav1

Without the original and without the other two pictures loading there isn't any way to tell.

[Quackdoc]

Without the original and without the other two pictures loading there isn't any way to tell.

all I can say is that slow.pics is working fine for me and a few others I had test it, it has original, svt-av1, qsv . as for the slow.pics one it's very clear to see that one is very clearly better then the other since loads of detail is just destroyed.

[Artim]

all I can say is that slow.pics is working fine for me and a few others I had test it, it has original, svt-av1, qsv . as for the slow.pics one it's very clear to see that one is very clearly better then the other since loads of detail is just destroyed.

Yes, but 2/3 aren't on slowpics. Anyways, I've just made a comparison myself, uploading now. No difference whatsoever.

Now that this page loads, there is a slight difference, but only noticable in a side-by-side comparison. If you didn't know they where there, you wouldn't notice them.