nVidia likely to remain accelerated video king?

[gbeauche]

Well that's more of driver thing, I would think. Much like NV's sharpen texture feature. The problem with a CPU driven decoder is that it needs to be able to hand off some level of interaction with the driver and as yet HD content is being treated as any other codec in Linux media players.

VDPAU at least does it all on the GPU so you know that the handoff to the GPU's profiling and processing is actually happening and the visual results speak for themselves.

s/VDPAU/NVIDIA/ -- Other VDPAU implementations don't do that. Besides, ATI also supports this filter but not with anything that could be available to desktop Linux systems. IIRC, even the poor Poulsbo can do that, but Intel has not exposed the feature yet.

[IsawSparks]

Poor quality rips... THAT IS FUNNY!!! They aren't recompressed. They are the same size as the data on the bluray. There is no loss of quality. Just full 40 mbit AVS, sorry.

Well then either you can't see it or XvBA doesn't implement it, but the difference is there.

[LinuxID10T]

Well then either you can't see it or XvBA doesn't implement it, but the difference is there.

Frame per frame, there is no difference. The only difference is the amount of CPU usage.

[IsawSparks]

s/VDPAU/NVIDIA/ -- Other VDPAU implementations don't do that. Besides, ATI also supports this filter but not with anything that could be available to desktop Linux systems. IIRC, even the poor Poulsbo can do that, but Intel has not exposed the feature yet.

I sincerely doubt that to be true wrt to Nvidia. I can see the difference and the VDPAU documentation clearly refers to being able to offer post processing and compositing support. I see no reason for the driver feature being exposed and then being unused.

[gbeauche]

I sincerely doubt that to be true wrt to Nvidia. I can see the difference and the VDPAU documentation clearly refers to being able to offer post processing and compositing support. I see no reason for the driver feature being exposed and then being unused.

You said: "VDPAU at least does it all on the GPU". I only wanted to clarify that NVIDIA does that. VDPAU is the API and depends on the actual implementation (driver).

[IsawSparks]

You said: "VDPAU at least does it all on the GPU". I only wanted to clarify that NVIDIA does that. VDPAU is the API and depends on the actual implementation (driver).

I think I was clear enough and Bridgman understood me just fine. VDPAU does all the processing on the GPU. The API just interfaces with the hardware, as all APIs of such nature are designed to work.

[mirv]

For being purely pedantic, I have to agree with gbeauche - VDPAU is just an API. OpenGL for example can be done entirely in software, but is much better being given directly to hardware. Same deal.
This has no bearing on the main discussion, it's just being pedantic.

[IsawSparks]

For being purely pedantic, I have to agree with gbeauche - VDPAU is just an API. OpenGL for example can be done entirely in software, but is much better being given directly to hardware. Same deal.
This has no bearing on the main discussion, it's just being pedantic.

Except that VDPAU is DEPENDANT on the hardware, OpenGL is not.

[LinuxID10T]

Except that VDPAU is DEPENDANT on the hardware, OpenGL is not.

Not really... It is just an API. If the correct implementation was written, it could run on the CPU. However, that would be just plain silly.

[IsawSparks]

Not really... It is just an API. If the correct implementation was written, it could run on the CPU. However, that would be just plain silly.

It's written by Nvidia for use with the appropriate GPUs. God, sometimes I wonder why people bother arguing silly points of discussion.