Announcement

Collapse
No announcement yet.

GStreamer 1.12 Is On Approach With New Features, Wayland Zero-Copy Playback

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

  • GStreamer 1.12 Is On Approach With New Features, Wayland Zero-Copy Playback

    Phoronix: GStreamer 1.12 Is On Approach With New Features, Wayland Zero-Copy Playback

    GStreamer 1.12.0 will soon be released as the latest version of this widely-used, open-source multimedia framework...

    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
    The official upstream release notes are at https://gstreamer.freedesktop.org/releases/1.12/ by the way, in case our friends over at Collabora are interested in updating their post to link to those as well.

    Comment


    • #3
      What about security improvements?

      It will try to parse data with any decoder, interpreter and parser regardless of file extension and MIME-type?
      So then a .jpg file can have a MPEG header and exploit the H.265 parser?

      Then if any frame is corrupted it will try to parse it anyway and end up in some weird unknown, unpredicted, corrupt state where the buffer overflows or the data ends up outside the stack and gets executed?

      Comment


      • #4
        Originally posted by uid313 View Post
        What about security improvements?
        Tracker recently added sandbox like things. Loads more things should get this. PDF viewers, Media Players, etc.

        Comment


        • #5
          Originally posted by bkor View Post

          Tracker recently added sandbox like things. Loads more things should get this. PDF viewers, Media Players, etc.
          Yes, all viewer-type of applications should use sec_comp or something to limit the available function calls to make it impossible to write anything to disk.

          Comment


          • #6
            Originally posted by uid313 View Post
            Yes, all viewer-type of applications should use sec_comp or something to limit the available function calls to make it impossible to write anything to disk.
            Problem is, a media player application may need write access to provide an easy transcoding via "save as" feature that users may find useful...

            Comment


            • #7
              Originally posted by silix View Post
              Problem is, a media player application may need write access to provide an easy transcoding via "save as" feature that users may find useful...
              Flatpak allows you to "break out" the sandbox safely using Portals. E.g. it can call a 'save as dialog' (outside of the sandbox), then give the sandboxed application only access to the given filename. Another solution would be to do the transcoding in a limited process (making use of things such as seccomp).

              Comment


              • #8
                Any bugfixes?

                IIRC that firefox dropped gstreamer on linux from a really nasty bug that would cause segfaults. Firefox gave up and just decided to use ffmpeg directly.

                Comment


                • #9
                  Originally posted by silix View Post
                  Problem is, a media player application may need write access to provide an easy transcoding via "save as" feature that users may find useful...
                  well if you write a media player that doesn't need write access, might as well have an option that disables it. Most media players don't have write access. There are a few like VLC that are more multi-media suites than simply "video players" might simply not use the function, same with your top end media jupe boxes. Parole and gnome videos would greatly benefit from this. So would lightweight media players.

                  But it does serve a niche in things like XFCE parole, which makes lightweight video players suited for more sensitive operations.

                  Comment


                  • #10
                    Originally posted by uid313 View Post
                    What about security improvements?

                    It will try to parse data with any decoder, interpreter and parser regardless of file extension and MIME-type?
                    So then a .jpg file can have a MPEG header and exploit the H.265 parser?

                    Then if any frame is corrupted it will try to parse it anyway and end up in some weird unknown, unpredicted, corrupt state where the buffer overflows or the data ends up outside the stack and gets executed?
                    That's not really how it works.

                    When you build a pipeline, you can either explicitly instantiate a given parser or you can rely on the typefind mechanism to detect the format and choose the correct parser.

                    However, whether or not the correct parser is used really has nothing to do with security exploits. Parsers are pretty robust to bad data, but there's always a chance of some bug in a parser that permits a buffer overrun or memory-exhaustion exploit.

                    Having used GStreamer quite a lot, I haven't seen bad data do anything too bad. Usually, it ends up causing an error and the pipeline aborts.

                    Comment

                    Working...
                    X