Announcement

Collapse
No announcement yet.

Intel Contributes A Number Of Vulkan Filters/Improvements To FFmpeg

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

  • Intel Contributes A Number Of Vulkan Filters/Improvements To FFmpeg

    Phoronix: Intel Contributes A Number Of Vulkan Filters/Improvements To FFmpeg

    Aside from the separate work around experimental Vulkan Video decode support, thanks to Intel recently there have been a number of Vulkan improvements to the FFmpeg code around new accelerated filters...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I don't know if it's ffmpeg or mpv or the graphics drivers but mpv sometimes/often starts stuttering when playing a movie at speed > 1. (VLC seems to be fine).

    PS: Forgot to mention, it only happens when mpv.conf contains "af=lavfi=[loudnorm=I=-16:TP=-3:LRA=4]" which is used when the sounds are too loud and the voices to quiet.

    Had this on Ubuntu 21.04 and 21.10, AMD RX 570.
    Last edited by cl333r; 12 December 2021, 07:15 AM.

    Comment


    • #3
      Would be great if someone contributed VVC support I really want to test the codec and there's nothing to play VVC files yet. Not a single (free publicly available) player even for Windows/Android/iOS.

      Originally posted by cl333r View Post
      I don't know if it's ffmpeg or mpv or the graphics drivers but mpv sometimes/often starts stuttering when playing a movie at speed > 1. (VLC seems to be fine).

      Had this on Ubuntu 21.04 and 21.10, AMD RX 570.
      Please report to https://github.com/mpv-player/mpv/issues

      Comment


      • #4
        Originally posted by cl333r View Post

        PS: Forgot to mention, it only happens when mpv.conf contains "af=lavfi=[loudnorm=I=-16:TP=-3:LRA=4]" which is used when the sounds are too loud and the voices to quiet.

        Thanks for this! It's been bugging me for so long and tried some PA eq but I never tried a simple af command for it.

        Comment


        • #5
          Originally posted by geearf View Post
          Thanks for this! It's been bugging me for so long and tried some PA eq but I never tried a simple af command for it.
          I just turn on subtitles. It also helps to use noise-cancelling headphones, which lower the noise floor. That enables you to hear quiet dialog more clearly.

          Comment


          • #6
            Originally posted by birdie View Post
            Would be great if someone contributed VVC support
            VVC (aka H.266) has some of the same issues in terms of IP licensing as does HEVC (aka H.265), including, last I knew, multiple different organizations forming licensing pools. For those that believe in free open standards without being encumbered by licensing use fees, AV1 is going to be the preferred path (even if VVC has some advantages in some use cases over AV1).

            Comment


            • #7
              Meanwhile Debian still didn't package shaderc, so you can't use mpv with Vulkan.

              Comment


              • #8
                Originally posted by birdie View Post
                Would be great if someone contributed VVC support I really want to test the codec and there's nothing to play VVC files yet. Not a single (free publicly available) player even for Windows/Android/iOS.
                That's because the codec is in early stages ;p
                Same thing was with AV1. When it came out, only the reference encoder/decoder was available, and it took a year for several players to support it.

                Comment


                • #9
                  Originally posted by CommunityMember View Post

                  VVC (aka H.266) has some of the same issues in terms of IP licensing as does HEVC (aka H.265), including, last I knew, multiple different organizations forming licensing pools. For those that believe in free open standards without being encumbered by licensing use fees, AV1 is going to be the preferred path (even if VVC has some advantages in some use cases over AV1).
                  I'm not sure that's the reason. FFMpeg perfectly supports H.264/H.265 and multiple other patent-encumbered codecs both for encoding and decoding, though some distros don't enable such codecs support for obvious reasons (or don't even offer ffmpeg at all like Fedora). AFAIK FFMpeg developers have implied they are not interested in adding support for free, meaning they don't like its nature and probably expect paid programmers to submit patches and I can't blame them.

                  Originally posted by tildearrow View Post

                  That's because the codec is in early stages ;p
                  Same thing was with AV1. When it came out, only the reference encoder/decoder was available, and it took a year for several players to support it.
                  That's confusing. H.266 was finalized more than a year ago and its uptake, despite being backed by dozens of companies, has been a lot worse than AV1 before it. Weirdly the just released Snapdragon 8 Gen 1 supports neither AV1, nor H.266. That's utterly confusing. Mediatek however supports AV1 in multiple SoCs and they've recently added support for H.266 in their new upcoming Pentonic 2000 TV SoC.

                  Comment


                  • #10
                    Originally posted by birdie View Post
                    I'm not sure that's the reason. FFMpeg perfectly supports H.264/H.265 and multiple other patent-encumbered codecs both for encoding and decoding,
                    Really? Or is that just by linking in external encoders? AFAIK, FFMpeg never had native H.264 encoding support (though I think they can link in & wrap the x264 encoder). I can't say about H.265, but I wouldn't assume they implemented encoding for it, either.

                    Writing a good encoder is a lot harder than writing a decoder. For decoding, you just have to follow the spec. Maybe you can come up with a few clever optimizations, but you can't deviate much, because decoders should exactly match what the reference decoder produces. That makes it much simpler than all the schemes encoders use to pick a fairly optimal set of compression decisions, for a given bitrate & complexity target.

                    Comment

                    Working...
                    X