Announcement

Collapse
No announcement yet.

Gallium3D Gets An OpenMAX Video State Tracker

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

  • Serafean
    replied
    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

    Leave a comment:


  • agd5f
    replied
    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.

    Leave a comment:


  • liam
    replied
    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.

    Leave a comment:


  • Ericg
    replied
    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?

    Leave a comment:


  • Ibidem
    replied
    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.

    Leave a comment:


  • agd5f
    replied
    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.

    Leave a comment:


  • liam
    replied
    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.

    Leave a comment:


  • HokTar
    replied
    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.

    Leave a comment:


  • Vanek
    replied
    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...

    Leave a comment:


  • ChrisXY
    replied
    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

    Leave a comment:

Working...
X