+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+--- Thread: [i.MX6] XBMC running on Freescale SoC's (/showthread.php?tid=161793)
RE: [i.MX6] XBMC running on Freescale SoC's - wolfgar - 2014-02-19
(2014-02-18, 11:56)Koying Wrote: I *think* it is 3.10.9-1.0.0 alpha. It come from http://jas-hacks.blogspot.co.uk/2013/12/imx6-debian-jessie-gpuvpu-3109-100.html via http://imx.solid-run.com/forums/viewtopic.php?f=8&t=326Thanks will check against my own version...
(2014-02-18, 11:56)Koying Wrote: Okido.OK let's do it that way !
Not sure what you mean by "communicate broader without opening a PR". Do you want more tester? devs? users?
I suggest we use the master of this fork as the base for the future XBMC PR, and that we ourselves PR vs. this master to allow cross-reviews.
As you are already aware I have created the organization here : https://github.com/xbmc-imx6/
Let the world be aware of it ;-)
Now all imx6 porting effort will be shared at this place...
(2014-02-18, 11:56)Koying Wrote:I totally agree.(2014-02-18, 01:51)wolfgar Wrote: For the version It should be EGL I guess : I will not stupidly advertize V4L against the global xbmc approach for rendering...Well, for me, vsync is not quite ok. It deadlocks (internally) at some point.
For now I have 2 concerns :
- vsync still not perfect for me but if you say it is ok for you then I have to find what's wrong with my env
- deinterlacing : We have to renounce to using IPU deinterlacing engine otherwise we are back to a imx specific mechanism I fear...
(There are also the freezes you mentioned)
I haven't tried with smallint's suggestion of 3 buffers, yet, though.
I'd add
- resolution / refresh rate support
- I'm apparently loosing framebuffers when seeking, so I end up with "No framebuffers available" from the VPU
- simplify PTS handling (desynchronization). I saw you started on that. Most other XBMC codecs are using a simple queue which is pushed when we push a frame to the vpu and popped when doing the ::GetPicture
Regarding pts, the latest commits in my branch aim at this simplification by getting rid of the gstreamer lib.
I have to tell I fear a simple fifo would not be good enough because, depending on encoding, pictures are not always output in the same order as encoded block are submitted in the decode function.
My latest attempt to use the vpu buffer as a key to retrieve the correct pts of output picture seems easy to port on current smallint version as a good compromise simplicity/correctness...
I will push smallint latest changes (he has merged your own recent changes) as a first candidate on master branch in a few minutes ...
I thank you very much for your help
Best regards
Stephan
RE: [i.MX6] XBMC running on Freescale SoC's - wolfgar - 2014-02-19
Hi koying, smallint
Just an update
As we have to start somewhere, I have just pushed what seems to be the best combination from all contributions so far on master...
Regards
Stephan
RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-19
(2014-02-19, 05:31)wolfgar Wrote: Hi koying, smallintCool. Let's build on that
Just an update
As we have to start somewhere, I have just pushed what seems to be the best combination from all contributions so far on master...
Regards
Stephan
Just a note: When needed, I highly recommend rebasing vs. XBMC master rather than merging.
It's shitty from our side as it messes up our git, but it's mandatory for the futre PR vs XBMC.
RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-19
(2014-02-19, 02:17)wolfgar Wrote: As you are already aware I have created the organization here : https://github.com/xbmc-imx6/
Let the world be aware of it ;-)
Now all imx6 porting effort will be shared at this place...
I suggest that you create an entry in your blog regarding this.
Key points would be:
- Reference code now at https://github.com/xbmc-imx6/xbmc
- Dev team
- Aiming for inclusion in XBMC master
- Working via PR and contributions welcome
We can then spread the word across the boards we respectively hang around, pointing to your announcement.
We might also open a thread in "Linux support" to capture more feedback.
RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-19
Wow. Current build works impressively well
I confirm vsync is now working quite well for me, too, but with FB_MULTI_BUFFER=2. Setting it to 3 apparently skips a frame.
On the resolution subject, I can query the available resolutions with
Code:
cat /sys/class/graphics/fb0/modesCode:
echo 1 > /sys/class/graphics/fb0/blank
echo U:1280x720p-60 > /sys/class/graphics/fb0/mode
echo 0 > /sys/class/graphics/fb0/blankOnly problem is that /sys/class/graphics/fb0/mode is root:root 644
I'll create some minor PR's tomorrow.
RE: [i.MX6] XBMC running on Freescale SoC's - mijanek - 2014-02-19
(2014-02-19, 20:12)Koying Wrote: Wow. Current build works impressively well
I'm havin the same impression :-) Well done guys
RE: [i.MX6] XBMC running on Freescale SoC's - F.L.A.M - 2014-02-19
Hello, everybody,
first i would like to thank you for the amazing work. I've just compiled the sources from https://github.com/xbmc-imx6/ with OpenELEC for my Cubox-i4Pro and this is the only distro which can play my 1080i recordings without stutter, desync or frame drops. There is a noticible tearing on fast movement though. Is this a bug or is deinterlacing not implemented yet?
RE: [i.MX6] XBMC running on Freescale SoC's - mijanek - 2014-02-19
(2014-02-19, 21:02)F.L.A.M Wrote: Is this a bug or is deinterlacing not implemented yet?
Yes, now I noticed this to, deinterlacing is not working :-(
RE: [i.MX6] XBMC running on Freescale SoC's - F.L.A.M - 2014-02-19
I've added FB_MULTI_BUFFER=2 to the environment and activated VSync. I thing there is no tearing more. Really nice.
RE: [i.MX6] XBMC running on Freescale SoC's - mk01 - 2014-02-20
(2014-02-19, 20:12)Koying Wrote: Wow. Current build works impressively well
I confirm vsync is now working quite well for me, too, but with FB_MULTI_BUFFER=2. Setting it to 3 apparently skips a frame.
On the resolution subject, I can query the available resolutions with
and dynamically change it with, e.g.Code:cat /sys/class/graphics/fb0/modes
so I'll implement that in CEGLNativeTypeIMX.Code:echo 1 > /sys/class/graphics/fb0/blank
echo U:1280x720p-60 > /sys/class/graphics/fb0/mode
echo 0 > /sys/class/graphics/fb0/blank
Only problem is that /sys/class/graphics/fb0/mode is root:root 644
I'll create some minor PR's tomorrow.
this I have sll ready including udev rules etc.
but I don;t how far your already are after 12h
)
RE: [i.MX6] XBMC running on Freescale SoC's - wolfgar - 2014-02-20
(2014-02-19, 11:42)Koying Wrote: Cool. Let's build on that
Just a note: When needed, I highly recommend rebasing vs. XBMC master rather than merging.
It's shitty from our side as it messes up our git, but it's mandatory for the futre PR vs XBMC.
OK I note it : Always rebase vs xbmc master so that at the end the whole patch will apply on head, right ?
Does it mean that our master branch will always be in an "unreliable" state ?
I mean : if we want to use a commit or a tag as a reference for a distro build, we should use another branch, right ?
(2014-02-19, 11:51)Koying Wrote:(2014-02-19, 02:17)wolfgar Wrote: As you are already aware I have created the organization here : https://github.com/xbmc-imx6/
Let the world be aware of it ;-)
Now all imx6 porting effort will be shared at this place...
I suggest that you create an entry in your blog regarding this.
Key points would be:
- Reference code now at https://github.com/xbmc-imx6/xbmc
- Dev team
- Aiming for inclusion in XBMC master
- Working via PR and contributions welcome
I will for sure...
RE: [i.MX6] XBMC running on Freescale SoC's - emveepee - 2014-02-20
Yesterday's wolfgar update for the new xbmx-imx6 stream compiled fine and run's really well., tonight's 551a09545 with koyings changes give me the same error I had with koying's repo
LinuxRendererGLES.cpp:2697:66: error: 'glTexDirectVIVMap' was not declared in this scope
LinuxRendererGLES.cpp:2698:45: error: 'glTexDirectInvalidateVIV' was not declared in this scope
Any thought where to look for the error causing this difference?
Martin
RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-20
Apparently, the location of the vivante extension definitions is toolchain dependent.
I'll hardcode the functions definition and get the address via eglwrapper.
RE: [i.MX6] XBMC running on Freescale SoC's - CruX - 2014-02-20
(2014-02-19, 20:12)Koying Wrote: On the resolution subject, I can query the available resolutions with
and dynamically change it with, e.g.Code:cat /sys/class/graphics/fb0/modes
so I'll implement that in CEGLNativeTypeIMX.Code:echo 1 > /sys/class/graphics/fb0/blank
echo U:1280x720p-60 > /sys/class/graphics/fb0/mode
echo 0 > /sys/class/graphics/fb0/blank
Only problem is that /sys/class/graphics/fb0/mode is root:root 644
Hey there,
I worked around that by grepping the log and echoing the mode into that file but seems really, really nasty. Doing this from C itself seems cleaner but (to me) still is dirty, Shouldn't there be a possibility to do this via a ioctl or something like that? I tried to fool around with it, but the necessary bits (for example to list modes) seem to be only available in kernel code, not in userspace...
Cheers!
RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-20
Well, there is FBIOPUT_VSCREENINFO, but I don't know how to calculate the pixcloclk.
Anyway, I don't know how to get the list of actually available resolutions/framerate via FB ioctl.
The AML codec works basically the same way, btw, and I don't see what is dirty in using sysfs (from inside xbmc, obviously)