2010-01-22, 21:12
Support is planned and worked on.
2010-01-22, 21:29
vdrfan Wrote:Support is planned and worked on.
Thank you once again vdrfan, that is great to hear. I know that as a developer, you must also have many frustrations too. I wish I knew something about programming, I'd love to help out if I could.
Cheers
The REAL Joe
2010-01-22, 21:47
therealjoeblow Wrote:In these 2 cases, at least for the time being, it appears that we're putting the decoding load on the processor while it actually belongs on the GPU; and putting high quality scaling on the GPU when it can easily be handled by the CPU. These development decisions just don't make sense to me.The fact that you have a crap gpu doesn't make it a bad development decision.
2010-01-22, 22:36
therealjoeblow Wrote:For example, most modern GPU's already have the ability to decode 1080 video in hardware, and many users already have one of these GPU's, but the dev's feel it's better to pursue the Broadcom Crystal HD addin card instead of developing hardware decoding for what many already have. Doesn't make sense.It makes perfect sense when you consider that the main XBMC focus is on Linux, and there are only a few Windows developers.
A DXVA accellerated XBMC benefits windows people _only_. The CrystalHD support benefits Linux folk, OSX folk AND Windows folk...not sure why getting that working is a bad development choice.
Outside of that, the DSPlayer branch has been in active development for 3 months now to the point that it's very usable. Saying that hardware decoding has not been worked on is just plain wrong and an insult to the people who ARE working on it.
It's not perfect, but it's in development, it's not supposed to be perfect yet...
2010-01-23, 01:12
"Bad development decision" lol! Davilla is an osx developer, who loves his ATV boxes - that's one of the main reasons for the broadcom stuff. It's not like Team-XBMC has some drunk guy with a whip at the top, making decisions about who has to code what in his free time. This is still a free project made by people for fun in their spare time and open for everybody to contribute to. There are even people who DO work on dxva and whatnot, if you get frustrated by the time it takes to develop when there are 1-2 people working on a specific topic, then get your hands dirty and learn c++ (as Tiben for example did, when he wanted to make his directshow branch work), pay somebody to do it - or just be grateful for what you are getting.
/rant off
/annoyed
/back to topic: we are talking about scaling pixel shaders for windows here, take everything else elsewhere please.
/rant off
/annoyed
/back to topic: we are talking about scaling pixel shaders for windows here, take everything else elsewhere please.
2010-01-23, 02:40
Just wanted to add that, as little as I understand this, from what I do understand scaling on a GPU is far from being an inefficient solution. GPUs can do with shaders what a CPU has to waste many more cycles to achieve.
This is what I understand. Am I wrong devs?
This is what I understand. Am I wrong devs?
2010-01-23, 03:13
ashlar Wrote:Just wanted to add that, as little as I understand this, from what I do understand scaling on a GPU is far from being an inefficient solution. GPUs can do with shaders what a CPU has to waste many more cycles to achieve.
This is what I understand. Am I wrong devs?
Haha, "understand scaling on a GPU is far from being an inefficient solution", try running with software rendering. Certain death on anything but beefy CPUs.
2010-01-23, 17:22
You're absolutely correct, most graphics operations are very specific and can be split up into small parts and executed in parallel, gpu designers take great advantage of that by creating a chip that can perform those specific operations extremely fast and efficient.
A cpu core on the other hand has to scale one pixel at a time so it will never be as efficient, you need an expensive quadcore cpu and 4 scaling threads to match the speed of a $50 videocard.
A cpu core on the other hand has to scale one pixel at a time so it will never be as efficient, you need an expensive quadcore cpu and 4 scaling threads to match the speed of a $50 videocard.
2010-01-27, 20:55
One major thing that's holding XBMC back ATM is it's poor picture quality/lack of post-processing.
Compared to eg. the Cyberlink MPEG-2/1 codec in K-Lite media pack - the picture is simply very bad in terms of how clarity. This works even with old cards like early Radeon 9xxx.
I understand that if you have a VDPAU capable card, you will get activate some PureVideo filters that gives the same effect. However, this doesn't work with older cards - you need Nvidia 8xxx and above.
Is there any chance that we might get support for GPU-assisted postprocessing in older cards in the future? Or is it not prioritized at all or impossible to do with today's linux drivers for those cards? And in that case - is it likely that the open drivers will improve soon so that we can take advantage of these slightly older cards built-in postprocessing support?
Compared to eg. the Cyberlink MPEG-2/1 codec in K-Lite media pack - the picture is simply very bad in terms of how clarity. This works even with old cards like early Radeon 9xxx.
I understand that if you have a VDPAU capable card, you will get activate some PureVideo filters that gives the same effect. However, this doesn't work with older cards - you need Nvidia 8xxx and above.
Is there any chance that we might get support for GPU-assisted postprocessing in older cards in the future? Or is it not prioritized at all or impossible to do with today's linux drivers for those cards? And in that case - is it likely that the open drivers will improve soon so that we can take advantage of these slightly older cards built-in postprocessing support?
2010-01-27, 21:14
So what type of post processing do you think is needed?
2010-01-27, 21:25
Here's a thread about cpu assisted post processing.
Looks like it was waiting for Camelot so it'll probably show up soon-ish now (not a dev, just guessing) in nightlies.
Oh and Tibens DSplayer for windows XBMC (thread) would theoretically let you use pretty much any filter you feel like, it's WIP right now though I'm not sure how easy that'd be in practice.
[edit] just noticed you're on linux, DSPlayer is windows only, sorry.
Looks like it was waiting for Camelot so it'll probably show up soon-ish now (not a dev, just guessing) in nightlies.
Oh and Tibens DSplayer for windows XBMC (thread) would theoretically let you use pretty much any filter you feel like, it's WIP right now though I'm not sure how easy that'd be in practice.
[edit] just noticed you're on linux, DSPlayer is windows only, sorry.
2010-01-28, 20:47
bobo1on1 Wrote:So what type of post processing do you think is needed?
I'm not an expert on what is needed. I just see what works. And the picture with Cyberlink Mpeg-2 decoder or NVIDIA's Purevideo codec (even on old radeon 9xxx cards) is fluid and sharp, while XBMC seems blurry, unsmooth and ugly on the same card - no offense.
2010-01-28, 22:00
Freddo Wrote:Here's a threadOh and Tibens DSplayer for windows XBMC (thread) would theoretically let you use pretty much any filter you feel like, it's WIP right now though I'm not sure how easy that'd be in practice.
[edit] just noticed you're on linux, DSPlayer is windows only, sorry.
I noticed that too, but unfortunately as I understand it you loose XBMC's .ISO and .RAR browsing features with external player.
2010-01-28, 22:23
It's actually not an external player, its another internal player engine alongside the existing dvdplayer one, but it supports directshow filters.
It's still fairly early days but it'll let you load a custom filterchain I guess maybe even using purevideo, though I don't think I've seen anyone try it. Tibens concentrating on subtitles right now though, so you may be on your own experimenting.
sorry if its still academic since your on linux, but I thought it was worth clarifying for anyone else reading.
It's still fairly early days but it'll let you load a custom filterchain I guess maybe even using purevideo, though I don't think I've seen anyone try it. Tibens concentrating on subtitles right now though, so you may be on your own experimenting.
sorry if its still academic since your on linux, but I thought it was worth clarifying for anyone else reading.
