There May Still Be Hope For R600g Supporting XvMC, VDPAU

[Jimbo]

I have nothing against decode video using shaders, it's a nice project and I hope it succeeds. But I really have the feeling that ffmpeg library (specially ffmpeg-mt) doesn't have the recognition it deserves. The main fault is probably that linux distros brings a really outdated versions of ffmpeg and no versions for ffmpeg-mt, and a lot of plp has not the patience to compile it themselves.

If you try to compile recent ffmpeg-mt, with intel compiler (it has a free evaluation version) with something like this:

./configure --cc=/home/jaime/intel/Compiler/11.1/072/bin/ia32/icc --disable-mencoder --disable-live --extra-cflags="-O3 -xSSE3_ATOM -ip -fp-model fast=2 -unroll-aggressive"

You can decode 40Mbps x264 hidef video on an intel atom D510, a 10w dual core cpu.

A positive effect of using ffmpeg is that those libraries are currently developed and reviewed by a lot of devs, profesional video devs, universities... since long time ago, I really have confidence of the functions, approximations ffmpeg uses a lot.

[jrch2k8]

I have nothing against decode video using shaders, it's a nice project and I hope it succeeds. But I really have the feeling that ffmpeg library (specially ffmpeg-mt) doesn't have the recognition it deserves. The main fault is probably that linux distros brings a really outdated versions of ffmpeg and no versions for ffmpeg-mt, and a lot of plp has not the patience to compile it themselves.

If you try to compile recent ffmpeg-mt, with intel compiler (it has a free evaluation version) with something like this:

./configure --cc=/home/jaime/intel/Compiler/11.1/072/bin/ia32/icc --disable-mencoder --disable-live --extra-cflags="-O3 -xSSE3_ATOM -ip -fp-model fast=2 -unroll-aggressive"

You can decode 40Mbps x264 hidef video on an intel atom D510, a 10w dual core cpu.

A positive effect of using ffmpeg is that those libraries are currently developed and reviewed by a lot of devs, profesional video devs, universities... since long time ago, I really have confidence of the functions, approximations ffmpeg uses a lot.

ffmpeg-mt fan and user here too but using a beasty phenom II X4 955 ,)

first of all i feel nothing but respect and appreciation for the ffmpeg and x264 teams cuz their work is outstanding, so is not like we want to get rid of ffmpeg or anything like it.

decode video using shaders has it's meaning and usefullness even agreeing with you that ffmpeg-mt do the job just fine when you only wanna watch a video and do nothing else but for example if i want to leave blender rendering an animation sequence in HD while i watch IronMan 2 bluray, well that is when using a cpu alone won't do the trick anymore but if you gently unload the most expensive process of video decoding to the gpu(note that we still need a cpu for the rest) like iDCT, MC, cabac, deblocking, etc. then my cpu now has enough horse power to do the render while i watch ironman 2 smoothly.

it's all about better resource usage and note that is not discarded that ffmpeg-mt can hook up to our shader functions so it can do mt and gpu offload wich will make it even better

[popper]

jrch2k8 i assume ttat you didn't actually joint x264dev and ffmpeg-devel and at least leave the client capturing the feeds in a large log buffer to look at later, it's a shame if so, as they both covered some basic GPU and related ground again, try and look at any logs for the last two days or so and you will see interesting stuff perhaps.

more before this
"<spellbound> far-in-out_: I've uploaded the project. http://rd.gnus.org/cuda_motion_estimation.7z
<spellbound> far-in-out_: It's two parts. A dll that implements the ME and has dependencies on the CUDA runtime. A GUI app that exercises the DLL and has dependencies on wxwidgets and ffmpeg.
<spellbound> The GUI app can open any video that ffmpeg can handle, run it through the ME and display the motion vectors on top of the video image for visual verification.
<spellbound> Note though, 1920x1080 video size is hard coded in there in some places, so it will crash on test videos of any other size...." etc

[HokTar]

It seems gpu video acceleration finally took off on Linux!

I can't wait to see the first h264 solution!

[popper]

"<pengvado> how can you not know?
<far-in-out_> ) i know)
<far-in-out_> it's just that it's similar words and i've been reading thisall day
<far-in-out_> and i'm thinking 5 things at once
<spellbound> pengvado: I'm just a lowly peon. Dark_Shikari described a way to do motion estimation that would be suitable for the GPU and I implemented it. The project has no integration with x264."

thats x264dev BTW LOL at spellbound "a lowly peon" comment, but as you see people take advice and come up with interesting tools as prototypes while they learn and try out new idea's , that is what you might consider too.

ffmpeg-devel "<Timmmm> Hi, I'm trying get ffmpeg/libavcodec to output the motion vectors it decodes for a video. I presume I need to modify the source, and restrict myself to one codec (since I guess there isn't a generic motion compensation step across all codecs). So can anyone tell me where I can find the decoded vectors for mpeg4? I assume it is somewhere in mpeg4videodec.c. Also what does "mb" stand for in that file? It is used everywhere...
<Dark_Shikari> lavc has an api for outputting mvs
<Dark_Shikari> afaik
<Dark_Shikari> don't presume. it makes an ass out of you and me. Oh wait, that's "assume", but anyways...
<pJok> kshishkov, but php is c-like, so its not that hard to learn if you know c
<Dark_Shikari> Timmmm: int16_t (*motion_val[2])[2];\
<Dark_Shikari> in avcodec.h
..."

[popper]

It seems gpu video acceleration finally took off on Linux!

I can't wait to see the first h264 solution!

No Do Not Read any more into it than is said, these are people coming in to get advice and Perhaps....... make some interesting tools and apps as they learn.


theres Still the BIG problem in that Intel.nv AND AMD Do not include simple things like the very useful SAD/SATD and related assembly instructions and actually place them INSIDE the SIMD section of their GPU's for instance, Or the fact that while its reasonably fast to get data To the GPU, they dont provide a super fast way to get the processed data Back to the CPU as would be a very good thing for all Encode/Decode software and related apps....

its not all bad though as can be seem here, at least people are trying.

one other point being vaapi on its very first page outlines how simple it could be to make something simply work,plug in sny ffmpeg x264 and whatever existing code Very very slowly.... but simple a pipe LOL

http://www.freedesktop.org/wiki/Software/vaapi

.....
About

The main motivation for VAAPI (Video Acceleration API) is to enable hardware accelerated video decode/encode at various entry-points (VLD, IDCT, Motion Compensation etc.) for the prevailing coding standards today (MPEG-2, MPEG-4 ASP/H.263, MPEG-4 AVC/H.264, and VC-1/VMW3). Extending XvMC was considered, but due to its original design for MPEG-2 MotionComp only, it made more sense to design an interface from scratch that can fully expose the video decode capabilities in today's GPUs.

The current video decode/encode interface is window system independent, so that potentially it can be used with graphics sub-systems other than X. In a nutshell it is basically a scheme to pass various types of data buffers from the application to the GPU for decoding or encoding. Feedback on the API is greatly welcomed, as this is intended to be a community collaborative effort."

now its up to 3rd partys to get around the GPU limitations to transfer data back to the CPU, port and run parts that can run on GPU in a SMART way to limit data GPU/CPU transfer OR AMD/Intel to put some actual USEFUL commands ON THE GPU SIMD BLOCK ASAP on there next revision for instance

[popper]

It seems gpu video acceleration finally took off on Linux!

I can't wait to see the first h264 solution!

on that note OC, you will have to wait for the New Intel sandy bridge CPU as they say they did a sandy bridge Encode/Decode patch for x264.

but that patched code is not due for several weeks as he works on it inside intel , and we STILL dont know if its actually any good as he didn't spend time in the IRC dev channel's talking about what and how he might implement and improve it, the biggest sin in x264dev is NOT asking questions while you work on x264 patches to make sure your not doing stupid mistakes

[HokTar]

No Do Not Read any more into it than is said, these are people coming in to get advice and Perhaps....... make some interesting tools and apps as they learn.

I know it's not going to happen overnight but it almost seems that most parts are done here and there and one only needs to assemble them to get something working!


/* Disclaimer:
I know that it is still hard work to do this and that many parts are still missing, I was deliberately exaggerating. But still, it seems many people are working on this and many useful code snippets are scattered around the web. And this is a good thing! (At least promising.) */

[bridgman]

theres Still the BIG problem in that Intel.nv AND AMD Do not include simple things like the very useful SAD/SATD and related assembly instructions and actually place them INSIDE the SIMD section of their GPU's for instance,

Evergreen and up have a 4x4 Sum of Absolute Differences instruction in the SIMD engine. Check the ISA guide for :

SAD_ACCUM_HI_UINT
SAD_ACCUM_PREV_UINT
SAD_ACCUM_UINT

Have fun...

[popper]

:0)

see, i like to give some room to advance talking here ( i already knew that OC)perhaps more people will use it in interesting ways If they can get feedback and advice on its use somewhere.

whats the SATD entry point , oops someone wasn't actually thinking about general video use when they added that and perhaps some Very interesting CPU like commands ? but still theres always the next EverGreen revision, but its a start and GOOD, now wheres the super fast cpu feedback channels.