Kodi Community Forum

Full Version: VDPAU API for Linux released by NVIDIA today - GPU hardware accelerated video decoder
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
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
none of us have the hardware. personally (and this is only me) i say gfy to closed api's.
IMO it's up to the ffmpeg guys. XBMC uses ffmpeg because a shit ton of work has already gone into it by guys who know that code WELL. It would be wheel reinvention for the XBMC guys to start patching ffmpeg or writing hacks to put it in directly.

ffmpeg mailing list with latest patch and attacks against it... -> http://lists.mplayerhq.hu/pipermail/ffmp...58529.html

As for spiffs lack of hardware - is that lack of a display that would benefit or lack of a video card capable or what? I already offered up video card hardware to Davilla and haven't heard back. I would make this same offer to any XBMC developer looking to work on this (within reason). I have benefited from the work you guys have done a great deal and I would be happy to try and help return the favor. Probably easiest with US based devs but I'd be shocked if there weren't folks overseas willing to help out the overseas folks too. I mean really, a VDPAU capable card isn't THAT expensive and I actually have an 8400 card just sitting! I'd even consider that spiffy new ASUS motherboard I like if someone else would pop for the CPU and we weren't fitting multiple devs heh.

So, what hardware is needed for a motivated dev to look into this? I know ffmpeg isn't patched yet but I also know you guys played with the CABAC stuff before they allowed it in their tree. Would that be applicable here too?
i don't lack any hw (well, my laptop is failing but that's besides the point). i happily run xbmc on my xbox using my sdtv.

the personally applied to the 'GFY to closed APIs'.

having it in ffmpeg would of course help tons. fyi (or whomever mentioned it in this thread); the patch hasn't been treated harsher than any other diff does over there. they will try to rip any patch in pieces, point out cosmetics, typos in comments and everything that can be said to not be perfect. that is not hostility. ffmpeg is a library with extremely high code quality standards, and we should all be glad for it.
GFY to closed code? Even when it's good? Too bad idealism comes before a good product. Sad
i'll put idealism before satisfying wankers like yourself trying to play the 'oh noes, somebody said our product isnt good' card any time. since when is xbmc a 'product'. that is pointy-haired boss talk
Wow, beginning with personal attacks. Seems like a certain someone ran out of rational arguments ....
Pulling the "bring a diff" card isn't exactly underused either LOL.
sure, that is a personal attack. but it has nothing to do with me running out of arguments - i was never in an argument in the first place.

you post in a demanding tone as if we owe you anything. i answered what it takes. a diff.

i repeatedly said what i stated is my personal opinion.

you again post, this time in an accusational tone of voice as if my personal idealism is standing in the way of this happening. as if it means it wont ever happen. which is totally silly and unfair. in addition to the already mentioned 'card.

THEN i resorted to personal attacks.
Shame that you interpret it that way.
Either you are a part of the XBMC team or not... If you can't just give a straight answer and rather just ask for a diff from an end user, well, then there is not much hope...
i am an INDIVIDUAL and i have EVERY RIGHT to express my PERSONAL opinions. you have absolutely NO right to reduce me to a mere sheep in a flock
@everyone, please stop the flames, ...another one and we will have to lock this thread.

@everyone, read this BEFORE you post in this thread:
http://www.catb.org/~esr/faqs/smart-questions.html
especially this:
http://www.catb.org/~esr/faqs/smart-ques...l#keepcool
and this part:
http://www.catb.org/~esr/faqs/smart-ques...not_losing

Now please stop nagging! Offering coding assistance (and hardware) is OK, nagging is not.
Look, I think most folks can agree that some form of accelerated video decoding would be beneficial to XBMC. If this were available we'd possibly be able to use small low power platforms like the NVIDIA ION.

Certainly it would be terrific if the drivers that accomplished this were cross platform and open sourced. However for all of the talking being done by companies about releasing open source video accelerated drivers not much has occurred except release of documentation and drivers that accelerate 2D desktop performance. So far as I know the docs released by ATI/AMD and Intel do diddly for acceleration of video we need for playback of movies. Meanwhile NVIDIA has actually released something that WORKS and can cut down CPU usage by as much as 90%. Hey they are even releasing drivers with OpenGL 3.0 support!

So sure, they skipped all of the issues that ATI/AMD has had with releasing licensed IP and simply done it closed source. By doing so they were able to release more functional actual drivers and not just docs. Even if ATI/AMD releases all they can some parts of their hardware won't get documented due to 3rd party license issues - I believe they have stated as much.

So there's your choice, go with what works NOW or wait who knows how long for the other companies to get it together and even then possibly be using hobbled drivers. As an end user with a GPU twiddling it's thumbs I know what I'd like to see happen! That's not to say I don't want to see ATI/AMD build something nice too but promises for the future vs solid here and now benchmarks don't hold too much weight for me....
BLKMGK,

can you try to patch ffmpeg with the patch proposed by Carl Eugen? I suppose mplayer doesn't need to be patched anymore if this patch is applied?

I want to know if it automatically switches to vdpau (if compiled with --enabled-vdpau) or if you still have to add an option to the mplayer command line.

Next step could be to patch ffmpeg inside xbmc and see what happens Wink

Thx
beefke Wrote:BLKMGK,

can you try to patch ffmpeg with the patch proposed by Carl Eugen? I suppose mplayer doesn't need to be patched anymore if this patch is applied?

I want to know if it automatically switches to vdpau (if compiled with --enabled-vdpau) or if you still have to add an option to the mplayer command line.

Next step could be to patch ffmpeg inside xbmc and see what happens Wink

Thx

If I'm not misstaken it's not as simple as patching the ffmpeg source and compile it and then slap it in the xbmc sourcetree. There's a lot of changes made to the ffmpeg source to make it work with xbmc. Heck if it wore as easy as slapping on a patch, compile it and then put it in the xbmc source tree, I'd do it in a second! Smile
watzen Wrote:If I'm not misstaken it's not as simple as patching the ffmpeg source and compile it and then slap it in the xbmc sourcetree. There's a lot of changes made to the ffmpeg source to make it work with xbmc. Heck if it wore as easy as slapping on a patch, compile it and then put it in the xbmc source tree, I'd do it in a second! Smile

I think it is the other way round. Patch ffmpeg inside xbmc and adapt the xbmc code (DVDPlayer) to make it work with the patches without breaking the software decoding.

Now I wasn't expecting it to work already, but if it would already compile, we can check what error messages we get.
beefke Wrote:I think it is the other way round. Patch ffmpeg inside xbmc and adapt the xbmc code (DVDPlayer) to make it work with the patches without breaking the software decoding.

Now I wasn't expecting it to work already, but if it would already compile, we can check what error messages we get.

I'm thinking it's not going to be quite that easy, especially since I am NOT familiar with XBMC's codebase and haven't done any sort of development in years - none of that development was nearly as complex as XBMC nor in a language even remotely resembling XBMC. So no, I cannot easily try this.

That said, I think some of the bitches about the ffmpeg patches appear to be that it doesn't fail over the way they might like when the code isn't able to do the hardware based decoding. I don't know about you but I would NOT want to be in a situation where I could use hardware decoding or nothing at all so I think that this sort of behaviour is certainly not what we would want. Hopefully that has been solved but I am not sure from some of the comments I'm reading - it's hard to follow sometimes.

Now, I'm not sure who maintains the ffmpeg code in XBMC but whoever it is is probably watching the ffmpeg mailing list and is probably WELL aware of these patches. They are probably playing with them quietly waiting for them to mature or they have a philosophical issue with the closed source stuff and refuse - maybe they just haven't had time. So, it's interesting to follow what's going on and point it out for others to look at but really we're at the mercy of whoever has the talent to integrate this. Hopefully they have the hardware needed to test it and develop for it, if not I may be willing to step up and solve the problem if it's simply hardware. Davilla in particular sounded interested in this but I know he's REALLY busy with the OSX and aTV stuff too so he might not be able to split his attention from that valuable work...
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