Announcement

Collapse
No announcement yet.

GStreamer Making Progress On Vulkan Video Support

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

  • GStreamer Making Progress On Vulkan Video Support

    Phoronix: GStreamer Making Progress On Vulkan Video Support

    Back in April was the release of Vulkan Video extensions for GPU-accelerated video encode/decode using this cross-platform API. NVIDIA was quick to publish a beta driver with Vulkan Video support while adoption beyond that by drivers or multimedia software has been rather limited so far. Fortunately, the popular GStreamer multimedia framework for Linux users is working in the direction of supporting Vulkan Video...

    https://www.phoronix.com/scan.php?pa...treamer-Igalia

  • #2
    But GStreamer is written in C so it is hard to write secure could, so a specially crafted video file could be used to exploit a vulnerability. It is hard to trust any decoder written in C when data is coming from arbitrary non-trusted sources. I think Rust is needed here.

    Comment


    • #3
      Originally posted by uid313 View Post
      But GStreamer is written in C so it is hard to write secure could, so a specially crafted video file could be used to exploit a vulnerability. It is hard to trust any decoder written in C when data is coming from arbitrary non-trusted sources.
      In this case, the GStreamer plugin is little more than a wrapper. It's probably not doing much with the data beyond passing it to the next layer.

      And writing secure C isn't necessarily hard. Like everything in C, it just takes more work. C has a bad reputation because programmers tend to get lazy and use sloppy short cuts. These days, everyone is much more aware of the need to follow best practices.

      Originally posted by uid313 View Post
      I think Rust is needed here.
      There's support for that, but it's still new and I think it's still early to use it for something like this.


      It's weird that you'd single out this case as needing Rust. If you're that concerned, then probably just don't use GStreamer at all, because it consists of many millions of lines of C code, and that's not set to change in the foreseeable future.

      Oh, and you'd better not use libav/ffmpeg either, because that was all C, last time I checked. And that does include full parsers and decoders!

      Comment


      • #4
        Originally posted by uid313 View Post
        But GStreamer is written in C so it is hard to write secure could, so a specially crafted video file could be used to exploit a vulnerability. It is hard to trust any decoder written in C when data is coming from arbitrary non-trusted sources. I think Rust is needed here.
        Just think, I'll soon be able to post a cat clip that copies a person's credit card information so I can buy a Fender Tony Franklin Fretless P Bass, the blue one.....I mean .bashrc so I can get some startup script ideas

        Comment


        • #5
          Originally posted by coder View Post
          In this case, the GStreamer plugin is little more than a wrapper. It's probably not doing much with the data beyond passing it to the next layer.

          And writing secure C isn't necessarily hard. Like everything in C, it just takes more work. C has a bad reputation because programmers tend to get lazy and use sloppy short cuts. These days, everyone is much more aware of the need to follow best practices.
          Maybe so, but it doesn't help that iPhones were vulnerable to jpegs at one point in time.

          We're in the age of hackers now. This is why:

          Comment


          • #6
            Originally posted by skeevy420 View Post
            Maybe so, but it doesn't help that iPhones were vulnerable to jpegs at one point in time.
            Yeah, but also libjpeg is a couple decades older than GStreamer and was written to work on DOS machines and microcontrollers. And it's a full-fledged decoder, whereas GStreamer itself (and its plugins) don't do much in the way of decoding compressed data.

            Like I said, there's been no shortage of insecure C code out there. Is Rust better? Sure. But GStreamer and its main libs and plugins are in the MLOCs range and have been around for long enough to establish a decent track record. It's not as if every piece of C code is like a hand grenade with the pin half-pulled.

            Comment


            • #7
              Originally posted by coder View Post
              Yeah, but also libjpeg is a couple decades older than GStreamer and was written to work on DOS machines and microcontrollers. And it's a full-fledged decoder, whereas GStreamer itself (and its plugins) don't do much in the way of decoding compressed data.

              Like I said, there's been no shortage of insecure C code out there. Is Rust better? Sure. But GStreamer and its main libs and plugins are in the MLOCs range and have been around for long enough to establish a decent track record. It's not as if every piece of C code is like a hand grenade with the pin half-pulled.
              I'm not trying to disagree with you. Technically speaking, both of y'all are right.

              Comment


              • #8
                Originally posted by coder View Post
                In this case, the GStreamer plugin is little more than a wrapper. It's probably not doing much with the data beyond passing it to the next layer.
                Even parsing just the headers can introduce vulnerabilities.

                Originally posted by coder View Post
                And writing secure C isn't necessarily hard. Like everything in C, it just takes more work. C has a bad reputation because programmers tend to get lazy and use sloppy short cuts. These days, everyone is much more aware of the need to follow best practices.
                Yes, it is hard. I wouldn't be able to write secure C code. Microsoft is now using Rust in the Windows kernel, and Google is pushing for Rust in the Linux kernel, because writing secure C is hard.

                Originally posted by coder View Post
                There's support for that, but it's still new and I think it's still early to use it for something like this.

                Oh, that's cool, I hope to see these plugins progress!

                Originally posted by coder View Post
                It's weird that you'd single out this case as needing Rust. If you're that concerned, then probably just don't use GStreamer at all, because it consists of many millions of lines of C code, and that's not set to change in the foreseeable future.

                Oh, and you'd better not use libav/ffmpeg either, because that was all C, last time I checked. And that does include full parsers and decoders!
                No, I am not only concerned about GStreamer, but also PDF parsing, and libavb/ffmpeg. Yeah, I better not use libav/ffmpeg either, these really ought to be replaced by something written in Rust.

                Comment


                • #9
                  Originally posted by uid313 View Post
                  Even parsing just the headers can introduce vulnerabilities.
                  Knowing a fair amount about GStreamer, I doubt it's doing even that much. GStreamer separates that task into separate elements that would already exist for many years now, and probably just wrap libav, anyway.

                  Originally posted by uid313 View Post
                  Yeah, I better not use libav/ffmpeg either, these really ought to be replaced by something written in Rust.
                  Well, fire up your text editor and get to work!

                  Comment


                  • #10
                    Originally posted by coder View Post
                    Well, fire up your text editor and get to work!
                    I am a dumb ass high-school dropout who struggled in math, I know nothing about algorithms or math. I've tried Rust but I am pretty bad at it. Python is much easier.

                    Comment

                    Working...
                    X