+- 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 - Koying - 2014-02-17
(2014-02-17, 02:27)wolfgar Wrote: My question was simply about the use of direct texture and the associated performance improvement.Oh right
But OK I have just been able to try your version and obviously your cpu load issue is gone (it seems to be very similar to the V4L version)
Have you also been able to give it a try for android ?
No, I haven't started Android work, yet. There will be specific work to be done for this, e.g. decouple CEGLNativeTypeIMX from CDVDVideoCodecIMX (android has its own CEGLNativeType, CEGLNativeTypeAndroid).
(2014-02-17, 02:27)wolfgar Wrote: Apart from the deinterlacing issue you mentioned, I can't have a good VSYNC in spite of defining the environment variableDid you enable vsync in System-Video? I suggest to try with "when playing video" only, as I noticed some deadlocks when doing the eglSwapBuffers.
export FB_MULTI_BUFFER=2
before launching xbmc. Have you configured something else ?
(2014-02-17, 02:27)wolfgar Wrote: Also, as you are a xbmc team member, maybe you can help with upstream this imx6 port ?Sure.
The work won't be merged for Gotham, as we are in feature-freeze, but that does not prevent to create a "WIP" PR to make it semi-official.
I suggest to create a topical organization in github, create an xbmc fork under this umbrella and apply the imx patches. This way, you can have multiple devs working on imx while leaving your personal branches alone.
That would be the base for the PR.
Now you have to decide whether you want the V4L or EGL version to be merged...
(2014-02-17, 02:27)wolfgar Wrote: At last for the DMA issue, I have lots of reports but on my side, I have really very rare issue with my main configuration (utilite pro).Actually, running xbmc doesn't cause problems. The DMA is not fragmented neither at runtime nor at exit.
As I said, in my case, it is actually compiling on the device that fragments it
RE: [i.MX6] XBMC running on Freescale SoC's - mk01 - 2014-02-17
take those /usr files if you will be using framebuffer
http://xbian.brantje.com/pool/devel/main/x/xbian-package-firmware-6q/xbian-package-firmware-6q_1.5.0-1_armhf.deb
take those for wayland
http://xbian.brantje.com/pool/devel/main/x/xbian-package-firmware-wayland-6q/xbian-package-firmware-wayland-6q_1.5.0-1_armhf.deb
there is also option for x11
just do -x on debs. you cant have both at the same time, vivante is using same .so file in case of different targets (fb/wl/x11)
RE: [i.MX6] XBMC running on Freescale SoC's - LeoKesler - 2014-02-17
(2014-02-17, 12:48)mk01 Wrote: take those /usr files if you will be using framebuffer
http://xbian.brantje.com/pool/devel/main/x/xbian-package-firmware-6q/xbian-package-firmware-6q_1.5.0-1_armhf.deb
take those for wayland
http://xbian.brantje.com/pool/devel/main/x/xbian-package-firmware-wayland-6q/xbian-package-firmware-wayland-6q_1.5.0-1_armhf.deb
there is also option for x11
just do -x on debs. you cant have both at the same time, vivante is using same .so file in case of different targets (fb/wl/x11)
Hello,
I tested your build:
http://xbian.brantje.com/pool/devel/main/x/xbian-package-xbmc-gotham-nightly-6q/xbian-package-xbmc-gotham-nightly-6q_2.9-10.32_armhf.deb
And it is very very stable. I tested many videos and I dont get a single crash. The only common issue with others builds was a blink screen: picture x black screen x picture x black screen etc...
The other issue was I am unable to change the audio device, to use my TV speakers by HDMI. The option is grey.
I used the arch linux and I have made a "frankenbuild" to be able to test.
Can you add wandboard (quad) support for your image ?
Log details, probably because my frankenbuild:
Code:
Lots and lots of
10:05:16 T:1512043568 INFO: ffmpeg[5A1FF430]: [matroska,webm] Unknown entry 0xF0
10:05:16 T:1512043568 INFO: ffmpeg[5A1FF430]: [matroska,webm] Unknown entry 0xB2
Lots and lots of
10:36:27 T:1401943088 ERROR: CAESinkALSA::HandleError(snd_pcm_writei(1)) - underrun
10:36:27 T:1401943088 INFO: CAESinkALSA - ALSA: pcm_hw.c:515:(snd_pcm_hw_delay) SNDRV_PCM_IOCTL_DELAY failed (-32): Broken pipeRE: [i.MX6] XBMC running on Freescale SoC's - mk01 - 2014-02-18
Stephan,
I just discussed it with a guy who has SAMLE file doing it the same way on each play. I let him aware of this thread and that you can't reproduce anymore - so no way to move forward with it.
Told him to get in touch with you.
RE: [i.MX6] XBMC running on Freescale SoC's - wolfgar - 2014-02-18
(2014-02-17, 12:07)Koying Wrote:(2014-02-17, 02:27)wolfgar Wrote: Apart from the deinterlacing issue you mentioned, I can't have a good VSYNC in spite of defining the environment variableDid you enable vsync in System-Video? I suggest to try with "when playing video" only, as I noticed some deadlocks when doing the eglSwapBuffers.
export FB_MULTI_BUFFER=2
before launching xbmc. Have you configured something else ?
Yes I have : I can't manage to get rid of a little flickering from time to time. Which GPU libs do you use ? Maybe they are the key ...
(2014-02-17, 12:07)Koying Wrote: Sure.OK, this week, I will create this organization, will fork xbmc and push imx patches.
The work won't be merged for Gotham, as we are in feature-freeze, but that does not prevent to create a "WIP" PR to make it semi-official.
I suggest to create a topical organization in github, create an xbmc fork under this umbrella and apply the imx patches. This way, you can have multiple devs working on imx while leaving your personal branches alone.
That would be the base for the PR.
Now you have to decide whether you want the V4L or EGL version to be merged...
When it is ready how can I communicate broader without opening a PR ?
For the version It should be EGL I guess : I will not stupidly advertize V4L against the global xbmc approach for rendering...
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)
(2014-02-17, 12:07)Koying Wrote: Actually, running xbmc doesn't cause problems. The DMA is not fragmented neither at runtime nor at exit.
As I said, in my case, it is actually compiling on the device that fragments it
Did you use a usb drive to compile ?
Regards
Stephan
RE: [i.MX6] XBMC running on Freescale SoC's - smallint - 2014-02-18
Hi
(2014-02-17, 12:07)Koying Wrote: Did you enable vsync in System-Video? I suggest to try with "when playing video" only, as I noticed some deadlocks when doing the eglSwapBuffers.
I tried your imx branch yesterday and it works great so far with some minor modifications [1] except some box freezes. It is not just a deadlock in the application that can be resolved by killing xbmc. It its bringing my box down and I need to unplug/plug power to bring it back to life. I also was testing with my own implementation of glTexDirectVIVMap and I experienced freezes when you pass invalid pointers. For me the complete freeze occurs sometimes when I switch from one stream to another. Is it possible that the VPU handle is already destroyed and deleted while the renderer is still mapping memory for the last frame (just a guess)?
Btw, I need to set FB_MULTI_BUFFER=3 otherwise xbmc ends up with a black screen and sound does not play neither.
[1] https://github.com/smallint/xbmc/commit/02525e11e679e95c81e0845908bb93ee46cc5c77#diff-ba3cd61e4953cecff627b1401588fb1e
RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-18
(2014-02-18, 01:51)wolfgar Wrote: Yes I have : I can't manage to get rid of a little flickering from time to time. Which GPU libs do you use ? Maybe they are the key ...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=326
(2014-02-18, 01:51)wolfgar Wrote: OK, this week, I will create this organization, will fork xbmc and push imx patches.Okido.
When it is ready how can I communicate broader without opening a PR ?
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.
(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
(2014-02-18, 01:51)wolfgar Wrote: Did you use a usb drive to compile ?Righty right. Didn't think about that.
RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-18
(2014-02-18, 11:13)smallint Wrote: Is it possible that the VPU handle is already destroyed and deleted while the renderer is still mapping memory for the last frame (just a guess)?Mmm... I'm testing for a valid handle, but it's possible the handle is already the new one by the time we render.
There is probably a relation with the fact that framebuffers are lost when seeking...
RE: [i.MX6] XBMC running on Freescale SoC's - smallint - 2014-02-18
(2014-02-18, 11:56)Koying Wrote:(2014-02-18, 01:51)wolfgar Wrote: Did you use a usb drive to compile ?Righty right. Didn't think about that.
This fits very well with my observations. I switched from a USB drive to a SATA disc and I haven't had any DMA allocation issues anymore. Before I also needed to drop the disc cache manually to give cached memory back to xbmc otherwise I got out of memory errors. I have tvheadend + timeshift running and writing to an USB disc is probably the problem. It is either causing high fragmentation or there even is a memory leak in the driver.
RE: [i.MX6] XBMC running on Freescale SoC's - smallint - 2014-02-18
(2014-02-18, 11:56)Koying Wrote: - I'm apparently loosing framebuffers when seeking, so I end up with "No framebuffers available" from the VPU
Maybe I missed some important fact but as I understood your code you are potentially calling VPU_DecOutFrameDisplayed from the render thread if the codec info buffer is released there. VPU_* functions are not thread safe and this could lead to undefined behaviour. This needs to be sorted out. I also think that the static member for the VPU handle is not the best choice. Just in case you want to play two or more streams this won't work anymore (e.g. future PIP extensions). And as you say, if the handle is reassigned the buffer won't be notified about this.
RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-18
Yeah. I'll rework that.
RE: [i.MX6] XBMC running on Freescale SoC's - smallint - 2014-02-18
I made a first attempt to fix my freezes and to pull every VPU handling into the decoder thread [1]. Furthermore everything is bound to one decoder instance. I used the same approach as previously with Wolfgars V4L version: a static pool of output buffers that are just referenced by the render buffers, no dynamic allocations. It is working for me currently as I am testing with LiveTV and switching back and forth.
[1] https://github.com/smallint/xbmc/tree/imx
RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-18
The concept is good.
The potential problem is see is that there is no guarantee that an attempt won't be made to render a passed buffer after the :
ispose and their delete.[EDIT]
I seem to have a working solution, too: https://github.com/xbmc-imx6/xbmc/commits/koying
I'll do some squashing / cleanup tomorrow
RE: [i.MX6] XBMC running on Freescale SoC's - smallint - 2014-02-18
(2014-02-18, 21:53)Koying Wrote: The concept is good.
The potential problem is see is that there is no guarantee that an attempt won't be made to render a passed buffer after the :
The render issue can be solved by checking IsValid() on the buffer during render. The buffers itself are reference counted (your implementation) and one reference is held by the codec. In Dipose the codec releases the reference and invalidates the buffers (synchronized with a lock) so it should be safe. I tested it and XBMC was still holding the buffers until the next codec creation because they were not released in DeleteTexture and it was working. I added a TRACE_FRAMES define to really trace the lifetime of each buffer and it looked good so far. My XBMC is still running after lots of channel switches and video start/stops
It is really good to know that we are on the right track to solve all the issues we had in the past with syncing and frame dropping. Thank you for your implementation, it helped a lot especially for my setup.
[EDIT] And not to forget Stephan for his amazing work he has done and is still doing ...
RE: [i.MX6] XBMC running on Freescale SoC's - smallint - 2014-02-19
I experienced as well "out of buffer" errors while seeking. This is now fixed. I pushed my changes to my fork as well as to xbmc-imx6/xbmc
mallint.