[Robotica]

I was just wondering: Isn´t the multi-platform approach slowing down on some features being implemented?

[topfs2]

What to you base this on?

Most of the time the multi platform approach lets our code be simpler, more error safe and such since we add abstractions to any part of xbmc which is multi platform.

e.g. Instead of adding crapload of opengl code all over we use abstracted classes which have well defined behaviour, this makes us know if its our use of our api or the actual opengl backend code thats to blame.

Supporting multiple backends (and thus platforms) does take more resources, this is a fact. If it slows down progress thats not really true. i.e. just because you need to develop backends for both linux and windows doesn't mean progress is slowed much for windows. You do need to develop for both which means more resources but as said, even if it needs more resources what you gain is more support and nicer abstraction in xbmc which in turns usually means less errors.

[darkscout]

Exactly! I'm STILL waiting for VDPAU on OS X and Win32.

[topfs2]

Exactly! I'm STILL waiting for VDPAU on OS X and Win32.

it doesn't exist... vdpau is made for linux by nvidia....

OS X have acceleration though via crystal hd and that apple thing
Win32 have via crystal hd and via dxva.

Please read up before yelling...

[Jezz_X]

And it stands for
Video Decode and Presentation API for Unix

[darkscout]

Woosh.

And not to mention

And it stands for
Video Decode and Presentation API for Unix

Is a complete misnomer.
http://en.wikipedia.org/wiki/Unix

Linux isn't even a UNIX, OS X is. So if it was truly "For Unix" then it'd be available for OS X and OpenSolaris.

[jhsrennie]

Exactly! I'm STILL waiting for VDPAU on OS X and Win32.

For all Windows' faults, DXVA(2) is a vendor independant API so once you've added support for it all video cards will work not just NVidia cards. There doesn't seem to be anything comparable for Unix or OSX.

JR

[Robotica]

@TOPFS2: Thanks giving your opinion. Like I said, I base this question on my curiosity.

My considerations are:
- Code / Features needs to be compatible with all platforms giving fewer options;
- Code needs more testing thus longer development;
- Some features need to be ported to other platforms;

BTW, I know all the work JFCaroll is doing the get the Addon API platform independent.

[spiff]

For all Windows' faults, DXVA(2) is a vendor independant API so once you've added support for it all video cards will work not just NVidia cards. There doesn't seem to be anything comparable for Unix or OSX.

JR

bollocks. ever heard of va-api?

[spiff]

BTW, I know all the work JFCaroll is doing the get the Addon API platform independent.

then you're alone. he's not doing work to make things platform independent, he's working to make things language agnostic.

[Robotica]

then you're alone. he's not doing work to make things platform independent, he's working to make things language agnostic.

Thanks for correcting me; you´re so kind.

[topfs2]

@TOPFS2: Thanks giving your opinion. Like I said, I base this question on my curiosity.

My considerations are:
- Code / Features needs to be compatible with all platforms giving fewer options;
- Code needs more testing thus longer development;
- Some features need to be ported to other platforms;

BTW, I know all the work JFCaroll is doing the get the Addon API platform independent.

First point means abstraction, abstraction enforces more thought out code design and thus less error prone. All in all, it may take a few % more time but overall benefits from it clearly outweights the time.

What you need to realize with the rest is that all those are parallel, when the abstraction is in place you can let windows take its time implementing said feature while the other OS's may have it. This may be what you are refering to as problematic but what you need to realize is that the developers do what they like, so if we had just focused on windows that said feature wouldn't arrive any faster since there is no reason to believe that the linux devs would even care for the app then.

Also testing goes down in a sense since you have abstraction, it allows easier testing of modules and as such we would have less of these "random" errors as you know (as you define) how each module must behave. When you implement the module you are 100% sure it behaves as defined and you can kindof forget about it.

In fact I would like to state the opposite, since we are multi platform we attract more developers which means more eye on the code and more resources to handle all the platforms. You can compare us with other htpc apps that are one platform and you can see that we generally don't lack anything (in fact we almost have more and better features I would say) (granted pvr is the big elephant in the room).

[jhsrennie]

bollocks. ever heard of va-api?

I've heard of it. Hardly widely supported though, is it?

JR

[spiff]

it's supported on intel, amd/ati through the xvba backend and nvidia through the vdpau backend. that covers most hw.

[poofyhairguy]

I've heard of it. Hardly widely supported though, is it?

JR

You are completely incorrect.

VAAPI is supported by every major industry player: Via, AMD, Intel and Nvidia (since VDPAU can be tied to VAPPI).

The problem with VAAPI has nothing to do with the actual standard. The decision to support VAAPI instead of trying to remake XvMC is the biggest victory in the Xorg community since AIGLX.

The "problem" with VAAPI is either terrible driver support (AMD), terrible actual GPU hardware (VIA), or both (Intel). Nvidia is ahead of the curve with its robustness of VDPAU which isn't surprising when you consider that they had composite in their Xorg driver literally years before anyone else.

Five years from now VAAPI will be the main backend used and will work great with most available hardware (hopefully).