Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Quackdoc View Post

    is there any evidence that AMD is slowing down adoption of it?
    Have you read the article? They are pushing their closed source garbage, while I don't that much progress of them implementing the Vulkan video extensions in their drivers. And they are trying to add the new-yet-already-deprecated AMF to ffmpeg. How much more evidence do you need? I mean you are fine with ridiculous anecdotal evidence for any major quality differences between software encoders and various hardware encoders, yet you still refuse to see that AMD slows down Vulkan video extension adoption? Get your act together and stop being such a bigot.

    Comment


    • #32
      Originally posted by Artim View Post

      Have you read the article? They are pushing their closed source garbage, while I don't that much progress of them implementing the Vulkan video extensions in their drivers. And they are trying to add the new-yet-already-deprecated AMF to ffmpeg. How much more evidence do you need? I mean you are fine with ridiculous anecdotal evidence for any major quality differences between software encoders and various hardware encoders, yet you still refuse to see that AMD slows down Vulkan video extension adoption? Get your act together and stop being such a bigot.
      my "anecdotal" evidence is based testing hours of varying footage from a large variety of sources, Yes, it's anecdotal in the way that it's mine, but it's not anecdotal on the scale of it.

      Comment


      • #33
        Originally posted by Quackdoc View Post

        my "anecdotal" evidence is based testing hours of varying footage from a large variety of sources, Yes, it's anecdotal in the way that it's mine, but it's not anecdotal on the scale of it.
        It's anecdotal in the meaning of it. As I already said, at least 99 % of people will not be able to tell any difference from a typical viewing distance, especially without side-by-side comparison and zooming in 500x on some details. So whatever you may have found, it may be measurable, but not noticable, and much less meaningful. So spare us the bs.

        Comment


        • #34
          Originally posted by Artim View Post

          It's anecdotal in the meaning of it. As I already said, at least 99 % of people will not be able to tell any difference from a typical viewing distance, especially without side-by-side comparison and zooming in 500x on some details. So whatever you may have found, it may be measurable, but not noticable, and much less meaningful. So spare us the bs.
          many users finding blocking very distracting, lots of them will be able to tell the difference when a video becomes a blocky mess, or starts banding heavily.

          Comment


          • #35
            Originally posted by Quackdoc View Post

            many users finding blocking very distracting, lots of them will be able to tell the difference when a video becomes a blocky mess, or starts banding heavily.
            Sure, if you are explicitly setting bad settings, you will get bad results. That independent of the codec. And of course every implementation needs slightly different settings. But just giving ffmpeg the codec and a bit rate at least 99 % of the time will result in indistinguishable results. Sure, I've seen some strange results myself, where a much higher bit rate was needed than expected, but only for very low resolution content. I can't tell what exactly went wrong, but I'm very sure a bug is much more likely than shortcomings in the hardware codec.

            Comment


            • #36
              Originally posted by Artim View Post

              Sure, if you are explicitly setting bad settings, you will get bad results. That independent of the codec. And of course every implementation needs slightly different settings. But just giving ffmpeg the codec and a bit rate at least 99 % of the time will result in indistinguishable results. Sure, I've seen some strange results myself, where a much higher bit rate was needed than expected, but only for very low resolution content. I can't tell what exactly went wrong, but I'm very sure a bug is much more likely than shortcomings in the hardware codec.
              the issue is when you start comparing quality:bitrate different features can drastically effect the end bitrate needed to achieve a certain quality. and then if you care about decode speed thats a whole new bag of worms. for instance svtav1 has a fast decode option that disable features which have heavier decode perf but can greatly balloon in size depending on the footage in question. aomenc can also often be a lot harder to decode as well depending on the preset and settings used.

              Comment


              • #37
                Originally posted by Quackdoc View Post

                is there any evidence that AMD is slowing down adoption of it?
                I would say, they kinda can always implement functionality in vulkan video as vendor specific extension, if they cannot grant it KHR/EXT for now and just in ffmpeg use their own propertiary extensions until they materialize to KHR/EXT format hopefully in a way many vendors can agree how to use it.

                Since they don't do that, it begs question... why?
                Last edited by piotrj3; 12 May 2024, 06:48 PM.

                Comment


                • #38
                  Originally posted by piotrj3 View Post

                  I would say, they kinda can always implement functionality in vulkan video as vendor specific extension, if they cannot grant it KHR/EXT for now and just in ffmpeg use their own propertiary extensions until they materialize to KHR/EXT format.

                  Since they don't do that, it begs question... why?
                  the issue with vendor specific extensions is that you need to add them on a per application basis. with AMF all you do is add them to ffmpeg or gstreamer, and downstream apps will just work. The only way around this that I see is if vulkan video allows exposing these arbitrary settings manually, which is what I asked before. I don't actually know whats in the pipeline, but lynne seems to think it's adequate, and AMD doesn't.

                  also I really don't see how this "hinders" vulkan video adoption, really the crux of the matter is on RADV/Mesa folk, since they are what the general consumer need to use.

                  Comment


                  • #39
                    Originally posted by Artim View Post

                    How should Vulkan be used for OpenCV? There isn't any overlap between what they do.
                    Ffmpeg produces video frames. OpenCV processes video frames. And then potentially Ffmpeg encodes processed videos frames back. That's the overlap. That includes decoding video on GPU and then processing video on GPU, without ever copying raw video data off the GPU. Naturally, if Ffmpeg can universally decode video via Vulkan video extensions, and then OpenCV can process them via Vulkan compute, then it would be a perfect interop scenario.

                    Similarly, VLC can process video frames on GPU (e.g. HDR tonemapping via libplacebo or deinterlacing) and then present them to the composer, all without ever taking video frames off the GPU. This is even more involved, since it includes Vulkan video, then potentially Vulkan compute, and then Vulkan graphics.

                    Comment


                    • #40
                      Originally posted by Quackdoc View Post

                      the issue is when you start comparing quality:bitrate different features can drastically effect the end bitrate needed to achieve a certain quality. and then if you care about decode speed thats a whole new bag of worms. for instance svtav1 has a fast decode option that disable features which have heavier decode perf but can greatly balloon in size depending on the footage in question. aomenc can also often be a lot harder to decode as well depending on the preset and settings used.
                      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.

                      Comment

                      Working...
                      X