Page 3 of 3 FirstFirst 123
Results 21 to 30 of 30

Thread: Gallium3D Gets An OpenMAX Video State Tracker

  1. #21
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    965

    Default

    Quote 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.

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

    Quote 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

  2. #22
    Join Date
    Nov 2010
    Posts
    8

    Default

    Quote 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...

  3. #23
    Join Date
    Dec 2009
    Posts
    338

    Default

    Quote 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.

  4. #24
    Join Date
    Jan 2009
    Posts
    1,196

    Default

    Quote 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.

  5. #25
    Join Date
    Dec 2007
    Posts
    2,276

    Default

    Quote 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.

  6. #26
    Join Date
    Nov 2011
    Posts
    263

    Default

    Quote 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.

  7. #27
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,746

    Default

    Quote 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?

  8. #28
    Join Date
    Jan 2009
    Posts
    1,196

    Default

    Quote 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.

  9. #29
    Join Date
    Dec 2007
    Posts
    2,276

    Default

    Quote 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.

  10. #30
    Join Date
    Dec 2011
    Posts
    137

    Default

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •