Announcement

Collapse
No announcement yet.

Gallium3D Gets An OpenMAX Video State Tracker

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

  • #16
    Originally posted by droidhacker View Post
    That's miget/obsolete hardware.
    Obsolete for desktop use, but not for its intended purpose of teaching people to program (using Python).

    Originally posted by droidhacker View Post
    3) Its... commandline. Kinda makes it somewhat.... pointless, no?
    Oddly enough, it doesn't: omxplayer runs by banging the hardware directly - so no matter how you access the Pi, if you run omxplayer it will only be visible over the HDMI/RCA link (I had a Pi linked up to my TV that I controlled via SSH).

    Comment


    • #17
      What hardware out there supports hi10p decode?

      Comment


      • #18
        Originally posted by Deathsimple View Post
        Not sure if it's really validated, but I tried it 10bit content with the OpenMAX implementation and it seemed to work fine.
        Interesting. This makes Mesa the first driver that can decode hi10p with dedicated hardware and not in software! Fantastic job, Christian!

        Comment


        • #19
          gstreamer supports openmax.

          Comment


          • #20
            Originally posted by agd5f View Post
            gstreamer supports openmax.
            So should XBMC -- according to their wikipedia page. I will see when this gets merged and packaged.

            Comment


            • #21
              Originally posted by droidhacker View Post
              "OMXPlayer is a commandline OMX player for the Raspberry Pi."
              1) That's not "normal" linux. That's miget/obsolete hardware.
              It uses OpenMAX "OMX". The raspberry pi exposes its video decoding stuff via OpenMAX. As I said, I don't know if it additionally depends on raspberry pi stuff.

              Originally posted by droidhacker View Post
              2) That's not available with an AMD GPU... obviously.
              Obviously?

              Originally posted by droidhacker View Post
              3) Its... commandline. Kinda makes it somewhat.... pointless, no?
              1. mplayer is so pointless?
              2. There are gui wrappers: https://github.com/KenT2/tboplayer

              Comment


              • #22
                Originally posted by HokTar View Post
                So should XBMC -- according to their wikipedia page. I will see when this gets merged and packaged.
                I guess it's already there, since pi support...

                Comment


                • #23
                  Originally posted by Vanek View Post
                  I guess it's already there, since pi support...
                  Apparently tegra 2 also exposes openmax, but you are right.

                  Comment


                  • #24
                    Originally posted by agd5f View Post
                    gstreamer supports openmax.
                    I thought they did as well. So, is there any advantage to using the gallium state tracker over gstreamer? The gstreamer lib would have the advantage that it would work as long as some driver provided the interface. The only advantage I see the state tracker providing is that it doesn't require you to use gstreamer to make use of OMX if you have open driver support.

                    Comment


                    • #25
                      Originally posted by liam View Post
                      I thought they did as well. So, is there any advantage to using the gallium state tracker over gstreamer? The gstreamer lib would have the advantage that it would work as long as some driver provided the interface. The only advantage I see the state tracker providing is that it doesn't require you to use gstreamer to make use of OMX if you have open driver support.
                      gstreamer can make use of the openmax gallium support for hw accelerated decode.

                      Comment


                      • #26
                        Originally posted by liam View Post
                        I thought they did as well. So, is there any advantage to using the gallium state tracker over gstreamer? The gstreamer lib would have the advantage that it would work as long as some driver provided the interface. The only advantage I see the state tracker providing is that it doesn't require you to use gstreamer to make use of OMX if you have open driver support.
                        I don't think you're getting what a state tracker is.
                        A state tracker is the generic interface part of a Mesa (gallium3d?) driver. If you don't have a state tracker for (insert feature), or it was disabled, the driver doesn't have that feature.

                        Comment


                        • #27
                          Originally posted by agd5f View Post
                          gstreamer can make use of the openmax gallium support for hw accelerated decode.
                          Hey Alex, this is kind of a weird question but I'd hope you could clear it up... Is there anything stopping Radeon from just going "We support ALL the things!" and ship codepaths to cover VDPAU, XvBA, OpenMAX, Open Video Decode, Libva? Like I realize there's a maintenance burden involved, but architecturally / theoretically is there anything that makes those API's exclusive of eachother?

                          Comment


                          • #28
                            Originally posted by agd5f View Post
                            gstreamer can make use of the openmax gallium support for hw accelerated decode.
                            Yes it certainly could.
                            I know something was genuinely puzzling to me when I was reading this but for the life of me I'm not sure why I was imagining a collision of interests between a consumer and a provider of apis.

                            Comment


                            • #29
                              Originally posted by Ericg View Post
                              Hey Alex, this is kind of a weird question but I'd hope you could clear it up... Is there anything stopping Radeon from just going "We support ALL the things!" and ship codepaths to cover VDPAU, XvBA, OpenMAX, Open Video Decode, Libva? Like I realize there's a maintenance burden involved, but architecturally / theoretically is there anything that makes those API's exclusive of eachother?
                              Some APIs are better fits for the hardware than others, but in general, there's nothing stopping you from writing an appropriate state tracker for a new api and supporting it. There are already video related gallium state trackers for VDPAU, XvMC, OpenMax, and VAAPI.

                              Comment


                              • #30
                                How is this looking? Is it dead? Or simply forgotten? Along with the DX9 tracker, this is IMO one of the things that are a shame they didn't get into 10.0.

                                Keep up the amazing work

                                Serafean

                                Comment

                                Working...
                                X