Question to x264 developers

[qduaty]

I deleted the post when trying to edit it, sorry. But the most interesting part still exists.

Don't post about things you know nothing about.

All H.264 decoders are required to give identical output. Additionally, ME is not part of the decoding process. Finally, no GPU in existence performs video decoding; the process is done on a dedicated ASIC separate from the main processor.
Perhaps, conformant H.264 decoders must give identical output, but since their output differ in quality, it seems some are not conformant. Regarding the ASIC, Nvidia claimed there is such a part of their GPU that does the video decode in DirectX, but their developers just say that VDPAU will not be released in a form that exposes internal functions to the user - which means there are such functions in VDPAU (and it is not just an interface to some sort of a specialized device) and the decoding is implemented programatically.

[Dark Shikari]

Perhaps, conformant H.264 decoders must give identical output, but since their output differ in qualityNo they don't.Regarding the ASIC, Nvidia claimed there is such a part of their GPU that does the video decode in DirectX, but their developers just say that VDPAU will not be released in a form that exposes internal functions to the user - which means there are such functions in VDPAU (and it is not just an interface to some sort of a specialized device) and the decoding is implemented programatically.Or it just means they're not going to expose the proprietary features of their graphics cards.

[qduaty]

No they don't.
I know about the loop filter that can be disabled in ffh264 to make it decode faster. Maybe what I've seen was decoding with such tricks enabled. Anyway, Nvidia doesn't seem to do it and it's AVC output looks better.

Or it just means they're not going to expose the proprietary features of their graphics cards.
I just don't believe they devote so many transistors to a function that cannot be used in a game. And since they have a fast DCT implementation freely available as a test for CUDA in their SDK, any other function that is independent of time and reasonably data-parallel (ie. not an IIR filter) can be implemented this way.

Also, even if I don't distinguish between ME in an encoder and whatever function takes several reference frames to reproduce images in decoder, these algorithms seem to be related. I may be wrong but all those 500$ authors of CUDA encoders certainly aren't; they already have ME working. It's crap, but it works.

[Dark Shikari]

I know about the loop filter that can be disabled in ffh264 to make it decode faster. Maybe what I've seen was decoding with such tricks enabled. Anyway, Nvidia doesn't seem to do it and it's AVC output looks better.No decoder I know of does that unless you explicitly enable it as an option.I just don't believe they devote so many transistors to a function that cannot be used in a game. And since they have a fast DCT implementation freely available as a test for CUDA in their SDK, any other function that is independent of time and reasonably data-parallel (ie. not an IIR filter) can be implemented this way.Many transistors? The iPhone 3GS can decode Level 4.1 H.264. It is not a lot of transistors.

And video decoding is extremely non-data-parallel; it would be physically impossible to decode a 50 megabit CABAC stream in realtime on a GPU.

[Lyris]

Dark Shikari - can you elaborate on differences between decoders? I was under the impression that the output was bit-identical.

[Astrophizz]

The output is bit-identical, otherwise it's a bug in the decoder.

[Lyris]

Sorry, I totally skim-read - apologies!

[darkio]

Inside leadtek's SDK there's a modded (and very outdated) version of x264.exe, ffmpeg_candi and libx264.dll. Source code is included too inside archive. It's possible to patch or add inside, also unofficial, optimized version for spursengine cards ?