Announcement

Collapse
No announcement yet.

GStreamer 1.14 Working On AV1 & RTSP 2.0 Support, Promote MP3 Encoder/Decoder

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

  • GStreamer 1.14 Working On AV1 & RTSP 2.0 Support, Promote MP3 Encoder/Decoder

    Phoronix: GStreamer 1.14 Working On AV1 & RTSP 2.0 Support, Promote MP3 Encoder/Decoder

    GStreamer core developer Tim-Philipp Müller has provided some insight about some current and upcoming happenings for the GStreamer multimedia framework project. He also addressed the recurring comment of "write it in Rust!" for better security/safety/reliability...

    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 GPL is ugly?!?

    Comment


    • #3
      Really looking forward to WebRTC and meson support. I've been adding meson support for a couple of simple gstreamer plugins lately, works rather well. Hopefully openembedded will start porting their gstreamer recipes for meson soon for us embedded folks

      Comment


      • #4
        Originally posted by FireBurn View Post
        The GPL is ugly?!?
        "GStreamer itself is released under the LGPL, so GPL plugins that could pose problems for distributors wind up in "ugly"."
        -- https://lwn.net/Articles/737572/

        Comment


        • #5
          Originally posted by FireBurn View Post
          The GPL is ugly?!?
          for libraries. there is a reason for lgpl's existence, you know

          Comment


          • #6
            Originally posted by pal666 View Post
            for libraries. there is a reason for lgpl's existence, you know
            And as Stallman explained more than once (and I agree with him), it's not always a good reason. The point of the FLOSS community shouldn't be to give a free ride to proprietary software developers.

            Comment


            • #7
              Originally posted by FireBurn View Post
              The GPL is ugly?!?
              MIT license is beautiful. But MIT is not.

              Comment


              • #8
                Nothing against their decision to not port to Rust, did they mention why? I could understand they'd be some problems/barriers atm, if it was language limitations Mozilla would probably want to know to better prioritize feature dev? Lot of good arriving by end of 2018 for Rust. GStreamer devs though were saying even in the long-term they'd decided not to go with Rust which is interesting?

                Comment


                • #9
                  Originally posted by polarathene View Post
                  Nothing against their decision to not port to Rust, did they mention why? I could understand they'd be some problems/barriers atm, if it was language limitations Mozilla would probably want to know to better prioritize feature dev? Lot of good arriving by end of 2018 for Rust. GStreamer devs though were saying even in the long-term they'd decided not to go with Rust which is interesting?
                  Speaker here. No one said anything like this, quite the opposite really The context for the remarks on Rust was that there are plenty of blog posts by GStreamer maintainers about Rust and GStreamer and how to write plugins in Rust etc., so this was simply a clarification for users that they don't need to "worry" about GStreamer suddenly making Rust a hard depenency or core component of GStreamer, but that they should check it out and perhaps play with the Rust bindings for their own applications and plugins. If you look at the slides you will find "No plans to switch to it in the short run" but "Something for the longer term".

                  We're very very interested in Rust, and I think (hope) that it's just a matter of time until we can start using it. Also see Sebastian's FOSDEM talk about GStreamer and Rust in the Rust devroom. However, this is something that will realistically take quite some time to introduce and it needs to be done slowly and carefully. You can't just "switch" a 1-2 million line code base.

                  Comment


                  • #10
                    Originally posted by (tpm) View Post

                    Speaker here. No one said anything like this, quite the opposite really The context for the remarks on Rust was that there are plenty of blog posts by GStreamer maintainers about Rust and GStreamer and how to write plugins in Rust etc., so this was simply a clarification for users that they don't need to "worry" about GStreamer suddenly making Rust a hard depenency or core component of GStreamer, but that they should check it out and perhaps play with the Rust bindings for their own applications and plugins. If you look at the slides you will find "No plans to switch to it in the short run" but "Something for the longer term".

                    We're very very interested in Rust, and I think (hope) that it's just a matter of time until we can start using it. Also see Sebastian's FOSDEM talk about GStreamer and Rust in the Rust devroom. However, this is something that will realistically take quite some time to introduce and it needs to be done slowly and carefully. You can't just "switch" a 1-2 million line code base.
                    My bad, I misread, probably shouldn't be intaking news at 5am :P

                    Good to hear!

                    Comment

                    Working...
                    X