Announcement

Collapse
No announcement yet.

An Update On Generic GPU Video Decoding

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

  • Gamester17
    replied
    When that is done all we need is VA API support in Gallium and FFmpeg, then a few OpenGL GLSL shaders that are able to offload some of the H.264 decoding processes (like motion compensation and iDCT, to begin with at least).

    So VAAPI support in Gallium and FFmpeg could possible be what is needed push more graphic manufactuers such as ATI, Intel, NVIDIA, and VIA to begin the active development of Gallium 3D device drivers.

    There are also two more GSoC students and project by the way that is trying to achive GPU hardware acceleration video decoder via GLSL for OpenGL (one for the H264 decoder in FFmpeg for the XBMC project, and one for the Dirac codec for the Dirac Schrodinger project):

    Kodi is a free media player that is designed to look great on your big screen TV but is just as at home on a small screen.




    Video decoding processes that should be possible (in theory) to decode on a GPU:
    • Motion compensation (mo comp)
    • Inverse Discrete Cosine Transform (iDCT)
    • Inverse modified discrete cosine transform (iMDCT)
    • In-loop deblocking filter
    • Intra-frame prediction
    • Inverse quantization (IQ)
    • Variable-Length Decoding (VLD), more commonly known as slice level acceleration
    • Spatial-Temporal De-Interlacing, (plus automatic interlace/progressive source detection)


    To sum up GPU Hardware Accelerated Video Decoding is really missing under Linux.

    Leave a comment:


  • some-guy
    replied
    Originally posted by cruiseoveride View Post
    Whatever it is, don't hold your breath.
    How long has GNASH been going on for? a few decades now, and they can't even implement Flash 7 properly.

    Good luck.
    This will work, you don't even know what it is? In a few months, every gallium driver can add gpu-accelerated video decoding, within a few days at the max, rather than months/years (if it isn't a priority)

    Leave a comment:


  • cruiseoveride
    replied
    Whatever it is, don't hold your breath.
    How long has GNASH been going on for? a few decades now, and they can't even implement Flash 7 properly.

    Good luck.

    Leave a comment:


  • LauriM
    replied
    Originally posted by cruiseoveride View Post
    I believe a UVD2 implementation is what Linux needs. Not another XvMC driver.
    I think this has more potential than UVD2. If I have understood it correctly, UVD2 is hardware that is limited to certain profiles of MPEG2/VC1/H.264. I have used another hardware solution (Popcorn Hour) and the profile constraints can make life difficult.

    This approach could lead to much more flexible decoding of different formats and profiles. XvMC is a good starting point to figure out how to do this kind of processing with hardware in X/Gallium3d environment.


    I'm hoping that Radeon drivers catch up soon. I have an NVidia 9600GT, which will probably take a long time to get free 3d support and the binary drivers are useless for this (and generally pretty bad quality.. can't wait to switch to ATI and free drivers).

    Leave a comment:


  • sundown
    replied
    This shit always sounds cool, but from an end user point of view, it always takes like YEARS to fully enjoy something on linux (especailly related to gpus) and when this support kicks in, there will be 5 other cool ideas about whatever new 3d api. or am I wrong?

    Leave a comment:


  • hubick
    replied
    I think it would be better to first provide such features to the drivers of manufacturers that work with the free software community through development efforts or providing hardware specs.

    People are of course free to code whatever they want, but I think it's a shame, all the skilled developer effort poured into reverse engineering Nouveau, that could have gone towards making the Intel or AMD driver implementation better.

    Leave a comment:


  • bridgman
    replied
    Originally posted by cruiseoveride View Post
    Seems like a waste of time to me if it's only an XvMC driver. XvMC is really useless today, the only time you would need mpeg2 acceleration is if you are on a 486DX. I believe a UVD2 implementation is what Linux needs. Not another XvMC driver.
    This is actually pretty useful, since most of the work done for MPEG2 decoding via XvMC would also be re-useable for decoding H.264 or VC-1 via either an extended XvMC API or something new (VAAPI or whatever). It's also a good first step towards shader-based transcoding.

    Leave a comment:


  • Michael
    replied
    Originally posted by Chewi View Post
    Does anyone know if the ati/radeonhd developers are planning to make use of Gallium3D?
    Yes they will, once their first-cut R600/700 driver is working.

    Leave a comment:


  • Chewi
    replied
    Does anyone know if the ati/radeonhd developers are planning to make use of Gallium3D?

    Leave a comment:


  • cruiseoveride
    replied
    Seems like a waste of time to me if it's only an XvMC driver.
    XvMC is really useless today, the only time you would need mpeg2 acceleration is if you are on a 486DX.

    I believe a UVD2 implementation is what Linux needs. Not another XvMC driver.

    Leave a comment:

Working...
X