Any plans to submit Intel SMD codec / player code upstream to XBMC mainline?

[Hedda]

Are there then any reasons for the Intel SMD / Intel CEx player and codec code not being submitted upstream into XBMC.org mainline repository?

It would get more developers of development if done as Intel SMD codec / CEx player or CEx codec in master https://github.com/xbmc/xbmc/

I'm thinking similar to how AMLCodec was now recently implemented in upstream mainline for decoding on AMlogic hardware

https://github.com/xbmc/xbmc/blob/master/xbmc/cores/dvdplayer/DVDCodecs/Video/AMLCodec.cpp https://github.com/xbmc/xbmc/blob/master/xbmc/cores/dvdplayer/DVDCodecs/Video/AMLCodec.h

Example of pull request: https://github.com/xbmc/xbmc/pull/3390

Either that, or how either the OpenMAX (OMXPlayer) player is implemented and developed upstream in mainline today

https://github.com/xbmc/xbmc/tree/master/xbmc/cores/omxplayer

Both those was developed separately in forks by third-parties at first (Raspberry Pi and Pivos respectivly) but have since gained traction and seem much development after the code for them was merged into xbmc.org master repository. And same have been seen with other major features that did not pick up development with more developers until they was merged upstream into mainline. In short, mainlining is very important to take development to the next step.

I guess the same question goes with any other code changes and optimizations need for D-Link Boxee Box and other Intel CEx based hardware?

Having this code in mainline would not only benefit the code for Boxee Box but also other development project that uses XBMC on similar Intel SMD / Intel CEx based hardware. Otherwise it is sad to see fragmentation between different forks of XBMC working on the same problems with others knowing about it, which causes unnecessary reinvention of the wheel and other ssues when several people are working on the same problems without collaborating.

PS: I am sure that if you submitted all your code for Intel SMD and other Intel CEx / Boxee Box patches uptsreas as seperate pull requests to XBMC.org's master reporitory for xbmc on GitHub then Team-XBMC would also ask you quarnster if you wanted to officially join Team-XBMC as primary maintainer of that code too, because if they are going to accept something into mainline then they also want a primary maintainer for that as well.

PPS: Checkout this semi-related forum thread http://forum.xbmc.org/showthread.php?tid=183989

[devilstrike]

No they wont and will never support it again, they have supported it for a few years back but dropped it from the main repo.

Same as for this 1. https://github.com/theuni/xbmc/tree/cex-abandoned

[Hedda]

Never say never.

You see, the initial support that was dropped was because Intel CE4xxx (4000 series) was not that popular for XBMC, and not used in many other commercial media player with XBMC other than D-Link's Boxee Box.

But the new Intel CE5xxx (5000 series) 5100 and 5300 models are gaining much traction and could be a great platform for XBMC. Again just checkout the ongoing discussion here:

http://forum.xbmc.org/showthread.php?tid=183989

So I might it might be a good idea to re-evaluate the edia of mainlining Intel SMD / Intel CEx player and codec support again now.

XBMC is getting more and more support for different hardware acceleration, especially now that many new media player SoC seem to support their own hardware acceleration API.

As before back when that previous Intel CEx playback code was abandoned they only supported VDPAU and VAAPI on Linux, DXVA for Windows because those was the widely used API's that had many people both using them and helping maintaining the code.

Today XBMC also supports Apple's VDADecoder/VideoToolBox, OpenMAX, Broadcom Crystal HD Enhanced Media Accelerator, Android StageFright API, and Android MediaCodec API, and now latest AMLogic 8726-Mx VPU too.

Work is also being to to add support for Freescale's i.MX6x series VPU and Allwinner's CedarX/CedarV VPU.

You saying that they will never support Intel CEx playback code again is a bad assumption based on old misconceptions I think.

@devilstrike @quarnster : The main point to remember here is that Team-XBMC does not want stale code upstream in XBMC mainline that is not actively maintained by a developer that fixes bugs, etc. And as long as you also offer to maintain the code too and not just drop it of and leave then they will probably gladly accept it.

[quarnster]

@Hedda, How about you offer to maintain the code? I'm certainly not going to.

[Hedda]

Then why not just submit the code as a "as-is" patch to upstream with a comment saying that you do not have time or ability to maintain the code in mainline? Or at least leave this ticket open for further discussion by others in the community if you do not want to do it yourself?

At least that could possibly get the discussion started with Team-XBMC developers if this is even at all going to get a chance to be accepted upstream for mainline in the future.

After all, all I hoped and wanted to do here is get a two way dialog conversation started between the developers of this Boxee Box fork of XBMC and upstream Team-XBMC developers about the possibility of getting the code into mainline some time in the future.

And the reason why I can not do this myself is that I am not a programmer, and even if I was a developer that could do that I would still not proceed with first getting your blessing as project owners.

In any case it is sad to hear what I now precieve as hostility from the Boxee Box fork of XBMC developers, it sounds as if hostility either towards the suggest of mainlining or hostility towards the upstream XBMC project or their development team.

Anyway I personally do not agree with the closing of this specific ticket as I feel the question have not been resolved, and I think that it would have been better of you just to ignore it as leave it open for discussion by others in the community in case someone else might want to offer to create a patch to upstream for mainlining. That I honestly believe would have been a much more diplomatic approach then just saying "no, never" and closing this ticket like you did.

[quarnster]

Then why not just submit the code as a "as-is" patch to upstream with a comment saying that you do not have time or ability to maintain the code in mainline? Or at least leave this ticket open for further discussion by others in the community if you do not want to do it yourself?

Yes, why don't you @Hedda do "at least" that?

precieve as hostility from the Boxee Box fork of XBMC developers, it sounds as if hostility either towards the suggest of mainlining or hostility towards the upstream XBMC project or their development team.

I can't speak for anyone else, but I'm "hostile" against anyone "offering" me unfair deals where I "get" to do even more work, but will get nothing I care about out of it in exchange. If you want something done, you do it or at the very least offer something in return, or ask if you can do something to make it easier for others to do it.

I might have started this port, but had you been paying attention you'd see that I haven't been much involved in a couple of months, I'm even not watching this project, I closed the ability to file issues down in projects that did not already have them disabled from before, and yet you decided to summon me here by calling me out specifically.

And on top of this you have the stomach to suggest that I've not done enough ("at least") and that I should do more stuff for free for you, in the way you would prefer to have it done.

I'm not interested in your manipulative attempts to sway my opinion. Go away.

[Hedda]

Sorry for asking. You could have just said that you are no longer actively working on this project, as you clearly noted I was simple not aware of that. It would have been a more satisfactory and non-hostile answer, and need to get offensive and impolite about it.

Again I'm not a programmer or developer myself so I do not have the skill to even package this as a patch to submit upstream. In any case I won't bother you again about this.

[quarnster]

Who's trying to get something from whom here, and who's yet again saying "no" and "go away"?