• 1
  • 17
  • 18
  • 19(current)
  • 20
  • 21
  • 26
Input
Having svg support with animations would be superb!
Is that like a mammoth task to put in?
Reply
Probably but who knows until its done, PNG should be fine for a first step.
Reply
We have APNG support via FFMpeg, but it can only decode a single frame, so animations can't be shown. We'll have to proceed in the spirit of Ace's work with giflib and add the support ourselves via a new library. Would SVG be better? Know of any libraries that can decode APNG or SVG?

@RockerC thanks for the links, I was looking for those
Reply
I think SVG WOULD be better, but am not sure what level of interaction we can have out of a browser context.
SVG has it's own attributes for animation, would be able to use them with the renderer kodi uses?

Here's what I found for c++?
https://github.com/memononen/nanosvg
Reply
(2016-01-14, 18:46)grumpygamer Wrote: I think SVG WOULD be better, but am not sure what level of interaction we can have out of a browser context.
SVG has it's own attributes for animation, would be able to use them with the renderer kodi uses?

Here's what I found for c++?
https://github.com/memononen/nanosvg

We'll need a more established library to include in Kodi. We've been bitten before by libraries that were essentially abandoned upstream, leading to a maintenance headache.

This library would only be allowable in a binary add-on that can be updated independent of Kodi. We could create a new binary add-on API for animated/complex image decoding. Indeed, I did this for our platform-specific joystick drivers so that we could remove some libraries from core. A new binary add-on API requires a LOT of work, however. This would set me back at least several weeks of coding, if not several months.
Reply
Hmm I think you or some other dev would be better than me in finding a more suitable library. Tongue
Though if you gave me an idea of what features I can use for animation I could get a JS prototype ready
Reply
Let's proceed with PNGs for now. In the long term, we can think about integrating support for animated textures
Reply
I have already drafted image decoder addons. No support for animated as the only one in there is gif and it was a bit too convolved to read a generic api from. If retro needs this i can put in some more effort
Reply
I think in the future Kodi would greatly benefit of this at least graphically
Reply
(2016-01-14, 21:30)ironic_monkey Wrote: I have already drafted image decoder addons. No support for animated as the only one in there is gif and it was a bit too convolved to read a generic api from. If retro needs this i can put in some more effort
Yes please do! Two tumbs up! Even with only a library for APNG (Animated PNG) image decoding with a seperate library in addition to the existing libgif you would at least have two image decoders addons for such an API.

Supporting image decoder addons should then open up the possibility to make it easier to add even more additional image decoders in the future, such as example of for SVG, and perhaps more effective libraries for different RAW image formats (such as example TIFF and others) to faster display very large image files that was taken with modern digital cameras.

(2016-01-14, 18:15)garbear Wrote: Know of any libraries that can decode APNG or SVG?
Yes you have apngasm (libapngasm) which is a C++ GPL compatible zlib 'as is' licensed library for APNGs (Animated PNGs), see:

New apngasm sources: https://github.com/apngasm/apngasm
GUI authoring tool sources: https://github.com/apngasm/apngasm-gui
Ruby apngasm [rapngasm] sources: https://github.com/apngasm/rapngasm

(2016-01-14, 19:08)garbear Wrote: We'll need a more established library to include in Kodi. We've been bitten before by libraries that were essentially abandoned upstream, leading to a maintenance headache.
The apngasm work group is a FOSS project that recently got great respons promoting this free and open source APNG library via Kickstarter:

https://www.kickstarter.com/projects/374...escription

apngasm - FOSS Animated PNG tools and APNG standardization

Animated PNG, a high quality animated image format complete with full alpha channel and graceful degradation has been available and usable since 2004. Essentially APNG is like a much better Animated GIF. A large problem hindering widespread use is the lack of tools to create APNG. We would like to remedy this by taking the leading APNG conversion tool apngasm and, along with its author Max turn it into a robust and feature packed conversion library and a provide a full graphical authoring and editing tool.

Examples:

Mozilla has a good set of demos here: https://people.mozilla.com/~dolske/apng/demo.html

There is a very good comparison of APNG to GIF here: http://littlesvr.ca/apng/gif_vs_apng.html

The Phantom Open Emoji project is using APNG for animated emoji. Just check the cheat-sheet here: http://genshin.org/poe/cheat_sheet
Reply
I think if it's an effortless task then add the APNG which is better than what we have currently, but if you have to spend time to integrate it I would definitely suggest SVG or some form of vector library.
That would open up a new world of possibilities for Kodi
Reply
(2016-01-14, 18:15)garbear Wrote: We have APNG support via FFMpeg, but it can only decode a single frame, so animations can't be shown.

It can, I think I have a poc on one of my dev machines. Problem is that I have so much other stuff to do and I'm still not satisfied with the way animated images (gifs) are loaded at the moment (all frames at one go).
Reply
@RockerC way ahead of you Wink https://github.com/notspiff/imageencoder.raw
Reply
I'm trying to get GPIO controllers working on pi 2 but not having much luck. Kodi seems to detect the controllers but button presses are not being captured.
This is my first time attempting to compile kodi on pi so my lack of compile skills may be to blame.
I compiled the retroplayer-15.2 branch.

My configure options:
Code:
CFLAGS="-I/opt/vc/include/ -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux -mfloat-abi=hard -mcpu=cortex-a7 -mfpu=neon-vfpv4" CXXFLAGS="-I/opt/vc/include/ -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux -mfloat-abi=hard -mcpu=cortex-a7 -mfpu=neon-vfpv4" LDFLAGS="-L/opt/vc/lib" FFMPEG_OPTS="--cpu=cortex-a7" ./configure --disable-gl --enable-gles --with-platform=raspberry-pi --disable-x11 --disable-vaapi --disable-vdpau --disable-avahi --disable-pulse --disable-projectm --disable-optical-drive --disable-dvdcss --disable-vtbdecoder --enable-alsa --enable-player=omxplayer --disable-openmax --disable-rsxs --prefix=/usr

The GPIO controllers are set up as per: https://github.com/recalbox/mk_arcade_joystick_rpi and work fine with jstest.
Here is the log (i pressed all buttons on js0 but cant see any presses in the log). http://xbmclogs.com/pyd0k1ji5

EDIT: I also noticed that js0 is being detected as GPIO Controller 2. In jstest, js0 is definatly GPIO Controller 1.

Code:
pi@RetroPlayer ~ $ jstest /dev/input/js0
Driver version is 2.1.0.
Joystick (GPIO Controller 1) has 2 axes (X, Y)
and 8 buttons (BtnX, BtnY, BtnTL, BtnTR, BtnTR2, BtnSelect, BtnThumbL, BtnThumbR).

Code:
05:17:04 T:1964404736    INFO: AddOnLog: Joystick Support: CJoystickInterfaceLinux::Initialize: opening joystick /dev/input/js1
05:17:04 T:1964404736    INFO: AddOnLog: Joystick Support: CJoystickInterfaceLinux::Initialize: opening joystick /dev/input/js0
05:17:04 T:1964404736    INFO: AddOnLog: Joystick Support: Initialized joystick 0: "GPIO Controller 2", axes: 2, hats: 0, buttons: 8
05:17:04 T:1964404736    INFO: AddOnLog: Joystick Support: Initialized joystick 1: "GPIO Controller 1", axes: 2, hats: 0, buttons: 8
Image
Reply
(2016-01-20, 07:29)N3MIS15 Wrote: I'm trying to get GPIO controllers working on pi 2 but not having much luck. Kodi seems to detect the controllers but button presses are not being captured.
This is my first time attempting to compile kodi on pi so my lack of compile skills may be to blame.
I compiled the retroplayer-15.2 branch.

My configure options:
Code:
CFLAGS="-I/opt/vc/include/ -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux -mfloat-abi=hard -mcpu=cortex-a7 -mfpu=neon-vfpv4" CXXFLAGS="-I/opt/vc/include/ -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux -mfloat-abi=hard -mcpu=cortex-a7 -mfpu=neon-vfpv4" LDFLAGS="-L/opt/vc/lib" FFMPEG_OPTS="--cpu=cortex-a7" ./configure --disable-gl --enable-gles --with-platform=raspberry-pi --disable-x11 --disable-vaapi --disable-vdpau --disable-avahi --disable-pulse --disable-projectm --disable-optical-drive --disable-dvdcss --disable-vtbdecoder --enable-alsa --enable-player=omxplayer --disable-openmax --disable-rsxs --prefix=/usr

The GPIO controllers are set up as per: https://github.com/recalbox/mk_arcade_joystick_rpi and work fine with jstest.
Here is the log (i pressed all buttons on js0 but cant see any presses in the log). http://xbmclogs.com/pyd0k1ji5

If the hardware and kernel driver are working properly, Kodi should log the button presses. I've traced the execution through the source, from the GPIO register/i2c bus, to the line in Kodi that should log the button press. So unless the problem is in the kernel's evdev driver, the button press must get dropped at one of these places.

The only branch before Kodi logs is in the joystick add-on. It tests to make sure that the button's number is less than the max (in this case, 0 to 7). Being the only branch, and accepting only a small number of values, makes this a pretty suspicious line of code Wink

So my best guess is that the kernel driver isn't calling its buttons 0-7. In fact, I see (here)

Code:
static const short mk_arcade_gpio_btn[] = {
    BTN_START, BTN_SELECT, BTN_A, BTN_B, BTN_TR, BTN_Y, BTN_X, BTN_TL
};

I don't know what these are #defined as, but I'm guessing not 0-7. I would suggest replacing that line with this and seeing if anything is fixed

Code:
static const short mk_arcade_gpio_btn[] = {
    0, 1, 2, 3, 4, 5, 6, 7
};

If this hack fixes things, I'll be able to make allowances for this in the joystick add-on.

(2016-01-20, 07:29)N3MIS15 Wrote: EDIT: I also noticed that js0 is being detected as GPIO Controller 2. In jstest, js0 is definatly GPIO Controller 1.

Code:
pi@RetroPlayer ~ $ jstest /dev/input/js0
Driver version is 2.1.0.
Joystick (GPIO Controller 1) has 2 axes (X, Y)
and 8 buttons (BtnX, BtnY, BtnTL, BtnTR, BtnTR2, BtnSelect, BtnThumbL, BtnThumbR).

Code:
05:17:04 T:1964404736    INFO: AddOnLog: Joystick Support: CJoystickInterfaceLinux::Initialize: opening joystick /dev/input/js1
05:17:04 T:1964404736    INFO: AddOnLog: Joystick Support: CJoystickInterfaceLinux::Initialize: opening joystick /dev/input/js0
05:17:04 T:1964404736    INFO: AddOnLog: Joystick Support: Initialized joystick 0: "GPIO Controller 2", axes: 2, hats: 0, buttons: 8
05:17:04 T:1964404736    INFO: AddOnLog: Joystick Support: Initialized joystick 1: "GPIO Controller 1", axes: 2, hats: 0, buttons: 8

The mixup is visible in this log snippet. js1 is discovered first, so internally it is stored as "joystick 0". Similarly, js0 is stored as "joystick 1". I decided to omit any sorting code in the Joystick API because this is something that belongs at a higher level, like the GUI.
Reply
  • 1
  • 17
  • 18
  • 19(current)
  • 20
  • 21
  • 26

Logout Mark Read Team Forum Stats Members Help
Input3