Kodi Community Forum

Full Version: current state and vision
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
It is always sad - seeing capable and qualified users / developers leaving. Though I can fully understand the reasons he named. Working on kodi with a little team in the freetime while overwhelmed with feature requests by users too tired to learn up coding, emails over emails ...

Good luck with the new job / project.
Does those new development also envision multi-threading (and/or Vulcan) support?
(2015-11-26, 00:12)fritsch Wrote: [ -> ]It is always sad - seeing capable and qualified users / developers leaving. Though I can fully understand the reasons he named. Working on kodi with a little team in the freetime while overwhelmed with feature requests by users too tired to learn up coding, emails over emails ...

Good luck with the new job / project.

yes

Sorry about this. On the other hand I did't even know that he existed 2 weeks ago.
(2015-11-26, 02:26)Robotica Wrote: [ -> ]Does those new development also envision multi-threading (and/or Vulcan) support?

please elaborate on this
(2015-11-26, 08:51)FernetMenta Wrote: [ -> ][quote='fritsch' pid='2170718' dateline='1448489542']
On the other hand I did't even know that he existed 2 weeks ago.

Sad to learn that a main Kodi dev didn't even know about the best Kodi fork ever...
If it's true it means a lot...
Forks normally don't knock at our door. They make their own thing with the goal to keep their own thing.

See: We all know them here: https://github.com/xbmc/xbmc/pulls?utf8=...&q=is%3Apr
(2015-11-26, 11:17)djoole Wrote: [ -> ]Sad to learn that a main Kodi dev didn't even know about the best Kodi fork ever...
If it's true it means a lot...

Such a narrow mind...
You have the right to think it is "the best Windows Kodi fork ever" but not more. As said numerous times by fritsch, there is currently 1 active windows dev, and he doesn't seem to even be interested in this discussion...
Funny you mention "narrow mind" in light of what just occurred...
I'll stop there, I don't want to spoil this dev topic.
(2015-11-26, 11:44)djoole Wrote: [ -> ]Funny you mention "narrow mind" in light of what just occurred...
I'll stop there, I don't want to spoil this dev topic.
You already did - but it's okay - it is fully clear that an unsigned char cannot hold an unsigned integer of decent value ...
To get back on topic: Would it make sense to split the video renderer (not the decoders or splitters, nor the GUI renderer, just the video renderer) into a separate binary (e.g. DLL in Windows) with a clean interface? I suppose for the other platforms it probably wouldn't bring much benefit? For Windows it might allow to use alternative external renderers (like mine) without having to fork Kodi at all. But if it's not useful for the other Platforms, it probably doesn't make too much sense?
As we are on the way with binary addons and other stuff as well - this is certainly an option. There are even some linux folks arround that want a gstreamer rendering :-) (no kidding). The interface dvdplayer VideoPlayer delivers is clean and stable since years. See: https://github.com/FernetMenta/xbmc/tree...oRenderers which is the current rework for version 17 of the player.
(2015-11-26, 08:52)FernetMenta Wrote: [ -> ]
(2015-11-26, 02:26)Robotica Wrote: [ -> ]Does those new development also envision multi-threading (and/or Vulcan) support?

please elaborate on this

New era (also DX12) with many decode threads, a smart submitting thread. And something similar for rendering and other components. I know dvdplayer became a lot smarter but hé, you have the vision and you are the dev. I just read Imagination's blog about it..

I hoped you could tell me...
(2015-11-26, 11:52)madshi Wrote: [ -> ]To get back on topic: Would it make sense to split the video renderer (not the decoders or splitters, nor the GUI renderer, just the video renderer) into a separate binary (e.g. DLL in Windows) with a clean interface?
Thanks. As far as I understand the situation video rendering depends on specific algorithms e.g. scaling and so on. I think actually the video renderer does all this stuff and DSPlayer uses different algorithms.


(2015-11-26, 11:57)fritsch Wrote: [ -> ]As we are on the way with binary addons and other stuff as well - this is certainly an option.
At the moment I can think of a processing chain like for for AudioDSP. Pre-, master- and postprocessing so for me it is a kind of IDSP (Image Digital Signal Processing). So the task could be to implement this algorithm into a binaray addon and build a nice GUI around it.
(2015-11-26, 11:57)fritsch Wrote: [ -> ]As we are on the way with binary addons and other stuff as well - this is certainly an option. There are even some linux folks arround that want a gstreamer rendering :-) (no kidding). The interface dvdplayer VideoPlayer delivers is clean and stable since years. See: https://github.com/FernetMenta/xbmc/tree...oRenderers which is the current rework for version 17 of the player.

gstreamer Smile Cory and I did that eons ago for Sigma and that code was pushed public long ago. Zero interest and bitrotten by now I'm sure.
(2015-11-26, 18:09)MrMC Wrote: [ -> ]gstreamer Smile Cory and I did that eons ago for Sigma and that code was pushed public long ago. Zero interest and bitrotten by now I'm sure.

Source link or it doesn't exist Smile
Pages: 1 2 3 4 5 6 7 8