Kodi Community Forum
VDPAU API for Linux released by NVIDIA today - GPU hardware accelerated video decoder - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: VDPAU API for Linux released by NVIDIA today - GPU hardware accelerated video decoder (/showthread.php?tid=40362)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28


- beefke - 2008-12-20

CapnBry Wrote:So based on these specs, I'd say they're either High or Main profile up to Level 4.1, but as long as your video fits under the frame size and reference count, you should be good to go. I haven't seen anything you can generate with a sane x264 command line (a.k.a not a killasampla) that it will not play. I have also not tried anything except MPEG2 and H.264 either.

Hope that helps!

In windows they already support L5.1 (ATI still hasn't!), so I suppose it will also come into the linux drivers. And I am pleasantly suprised by the speed they are implementing and fixing things, so I think it will rather go fast.

By the way, nvidia has already the killa sample in their hands (and it is not working for the moment)

http://www.nvnews.net/vbulletin/showpost.php?p=1876385&postcount=302


- CapnBry - 2008-12-20

BLKMGK Wrote:Here's the commandline meGUI feeds me that it uses for x.264. It's likely a bit insane but hopefully not using anything that this patch cannot handle. Produces decent sized flawless video for me so far and my CPu can decode it - not quite Killa' levels of nutz though.
Code:
program --pass 2 --bitrate 11000 --stats ".stats" --keyint 14 --min-keyint 2 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --weightb --direct auto --deblock -1:-1 --trellis 2 --partitions all  --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 14475 --vbv-maxrate 24000 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input" --mvrange 511 --aud --nal-hrd
That's actually not too insane, I mean only 3 refs, 2 bframes and all the Main profile bells and whistles which should be supported. I think you're good to go! What is that for, 1080p?

And I too am pleased with how fast nVidia is making changes, and really being interactive with both developers and users to get problems solved. At first I thought nVidia just threw this out there as fast as possible to beat ATI to the punch (who may be putting out their first stab at video acceleration API in the next driver release) but they are really following through on making the first version actually work. Feels like a first for video drivers under linux!


- mythmaster - 2008-12-20

beefke Wrote:In windows they already support L5.1 (ATI still hasn't!), so I suppose it will also come into the linux drivers. And I am pleasantly suprised by the speed they are implementing and fixing things, so I think it will rather go fast.

By the way, nvidia has already the killa sample in their hands (and it is not working for the moment)

http://www.nvnews.net/vbulletin/showpost.php?p=1876385&postcount=302

This file actually plays in mythtv, but it pauses every couple of seconds to buffer.


- BLKMGK - 2008-12-20

TY CapnBry for looking that over! When I have tried some of the "recommended" settings in the past I wasn't happy with the results so I rolled my own - always open for improvement though! Anyway, yes that is what I encode 1080P BD and HD-DVD rips with and I see about a 40-50% reduction in file size and ZERO issues with artifacts so far - I'm picky. That it ought to be supported is awesome news indeed since I have so danged many vids done that way now! Hints for improvement especially ones that could impact file size always welcome as I am NO expert Wink

I too am watching their pace of fixes eagerly. That they are looking at Killa' is pretty awesome, kripes if they can accelerate THAT they will make my day! Funny how folks are calling that a benchmark and calling out the C2D 3ghz level of CPU to play it since that was what we all worked out here heh. I look forward to seeing what they can do with it for sure as even with MY settings that scene is rough. I haven't been following the ffmpeg list of late, have they begun to be more accepting of the NVIDIA code or are they still turning it away as they seemed to be last I looked?

Mythmaster - are you running their accelerated code?


- mythmaster - 2008-12-20

BLKMGK Wrote:Mythmaster - are you running their accelerated code?

Yes, that's with the internal player. It eats around 28-32% cpu.

EDIT: To clarify, I'm referring to mythtv's internal player which is VDPAU accelerated.


- beefke - 2008-12-20

BLKMGK Wrote:I haven't been following the ffmpeg list of late, have they begun to be more accepting of the NVIDIA code or are they still turning it away as they seemed to be last I looked?

I think they will be first concentrating on debugging their own propietary code.

But it seems to me from the post below that nvidia is willing to change the code according to the needs of the ffmpeg developers.

http://www.nvnews.net/vbulletin/showpost.php?p=1880871&postcount=341


- BLKMGK - 2008-12-21

mythmaster Wrote:Yes, that's with the internal player. It eats around 28-32% cpu.

EDIT: To clarify, I'm referring to mythtv's internal player which is VDPAU accelerated.

Excellent! Interesting that it has to keep buffering though but the CPU usage is pretty awesome for such a heavy duty clip! I look forward to hearing what tweaks they make in order to better play that clip.Nod


- mythmaster - 2008-12-21

BLKMGK Wrote:Excellent! Interesting that it has to keep buffering though but the CPU usage is pretty awesome for such a heavy duty clip! I look forward to hearing what tweaks they make in order to better play that clip.Nod

I'm sure that it has everything to do with the driver not allowing enough frames to buffer through at this point -- they're keeping it scaled back for testing in order to make sure that everything is working properly. I expect that limitation to be lifted in the stable release or, perhaps, even sooner. Smile


- beefke - 2008-12-21

mythmaster Wrote:Yes, that's with the internal player. It eats around 28-32% cpu.

EDIT: To clarify, I'm referring to mythtv's internal player which is VDPAU accelerated.

Mythmaster, what cpu do you have?


- mythmaster - 2008-12-21

beefke Wrote:Mythmaster, what cpu do you have?

Phenom 9850 (4 x 2.5 GHz) Big Grin

So, I guess you could double the cpu % for a dual-core 2.5 (?)


- theuni - 2008-12-23

Just thought i'd update here...

With yesterday's new driver and today's mplayer patches (180.18), 100% of my h264 movies now play using vdpau... very well at that.

Promising indeed.

TheUni


- malloc - 2008-12-24

theuni Wrote:Just thought i'd update here...

With yesterday's new driver and today's mplayer patches (180.18), 100% of my h264 movies now play using vdpau... very well at that.

Promising indeed.

TheUni

Scene releases or self ripped with some specific profile?


- theuni - 2008-12-24

malloc Wrote:Scene releases or self ripped with some specific profile?

Everything plays. Even rips with too may ref frames, or that don't comply strictly to L4.1.

Slight patch to their mplayer source is necessary to handle the out-of-spec ref frames, and it doesn't seem to hinder anything else:

change line 705 of lib_vo/vo_vdpau.c to

Code:
max_references = ((12 * 1024 * 1024) / surf_size) + 2;
to account for the possibility of 2 extra ref frames. I haven't found a rip that requires more than that, but the number could be bumped up obviously.

TheUni


- beefke - 2008-12-24

TheUni,

can you try to play the killa sample and tell us:

if it plays fine?
cpu usage? (how many cores are used?)
cpu model, speed?
gpu?

Thanks a lot!


- Clumsy - 2008-12-24

God I hate that stupid killa sample, why on earth has THAT become the standard for h264 benchmarking, why on Earth has nobody made a high bitrate sample with real world settings that make use of all the h264 features and trying to achieve the best possible picture. I dont't get it.