Kodi Community Forum

@wolfgar,

OK. The kernel that GeeXbox used was unclear to me. I cannot switch VTs on the prebuilt image. I had a look at the packaging and found that I didn't understand it as it wasn't one of the more common systems. However, it does seem to me that the the userspace libraries are not the ones that come with BSP 4.1.0. See for example here: http://hg.openbricks.org/openbricks/file...phics/meta That would explain why the md5sum I gave above is different to the files in the prebuilt image.

I'm not too worried about software rendering. Though I'm not sure why my mpeg2 videos are using it. I thought the vpu could do mpeg2.

I'm wondering about this Keying transparency issue though. What do you mean by "pure framebuffer libs"? Do you mean linking /usr/lib/libVIVANTE.so and friends to the "-fb" library and not "-dfb" nor "-x11" or whatever? That I have confirmed. I have also supplied an md5sum from the binary blob I'm using in a previous post.

My framebuffer is set to:

Quote:$ sudo fbset

mode "1920x1080-60"
# D: 148.500 MHz, H: 67.500 kHz, V: 60.000 Hz
geometry 1920 1080 1920 1080 16
timings 6734 148 88 36 4 44 5
hsync high
vsync high
rgba 5/11,6/5,5/0,0/0
endmode

Hi Wolfgar

Did you already tried not using V4L for output but using XBMC's standard EGL route?
If not mistaken, the VPU outputs YUV420 frames which can be simply passed to XBMC.

That'd make the code much simpler, avoid hacks, allow, e.g., 3D support to work and (probably) allow the code to be reused for Android.

Has anyone tried running a 1080p movie? I get some flickering issues, my TV goes blank (as if the HDMI signal is lost) and video returns after a while. At least it is not halting anymore, as it did in the previous version of XBMC I had compiled.

VLC reports the following information for the file I'm trying to watch:

• Codec: H264 - MPEG-4 AVC (part 10) (avc1)
  
• Resolution: 1920x800
  
• Framerate: 23.976216
  
• Decoded format: Planar 4:2:0 YUV
  

I think I get the following kernel warnings due to the 1080p playback:

Quote:[ 94.064973] mxc_v4l2_output mxc_v4l2_output.0: Bypass IC.
[ 108.508354] imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_10 = 0x00100000

Also, if I stop the playback, I cannot play afterwards any video file at all. I can hear the audio, but only the XBMC menu appears. The kernel currently running is 3.0.35_4.1.0-5-ARCH+, imx-vpu and gpu-viv-bin-mx6q-fb 3.10.17_1.0.0-1 (by CruX's PKGBUILDs). I have also compiled XBMC via CruX's PKGBUILD, it checked out from Wolfgar's repo, the imx-wip branch (04f006c).

@stephan,

I just built your commit 04f006cfb4 and this looks really good now :-) Thanks a lot!

Miro

(2014-02-08, 14:58)Koying Wrote: [ -> ]Hi Wolfgar

Did you already tried not using V4L for output but using XBMC's standard EGL route?
If not mistaken, the VPU outputs YUV420 frames which can be simply passed to XBMC.

That'd make the code much simpler, avoid hacks, allow, e.g., 3D support to work and (probably) allow the code to be reused for Android.

Hi Koying,

No I have not yet tried this because I was not familiar with Vivante direct texture extensions which allow efficient way of working with VPU output...
Also, the V4L2 path was the reference solution which was demonstrated in fsl BSP (and with natural plug for IPU hw functions like deinterlacing) so it seemed a safer way as a first implementation.
I have voluntary isolated most of V4L stuff in a dedicated class so that switching should not be so intrusive for core decoding function

But I know it is a path that would be interesting to explore... (On my todo list)

Best regards
Stephan

---

(2014-02-10, 01:14)mijanek Wrote: [ -> ]@stephan,

I just built your commit 04f006cfb4 and this looks really good now :-) Thanks a lot!

Miro

Thanks Miro

---

@joko

Which target and which kernel do you use ?
(As far as I can tell 1080p movies work just perfectly on all the targets I support...)

Regards
Stephan

Quote:[ 108.508354] imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_10 = 0x00100000

I get this warning too. Is it safe to ignore?

(2014-02-10, 03:00)wolfgar Wrote: [ -> ]No I have not yet tried this because I was not familiar with Vivante direct texture extensions which allow efficient way of working with VPU output...
Also, the V4L2 path was the reference solution which was demonstrated in fsl BSP (and with natural plug for IPU hw functions like deinterlacing) so it seemed a safer way as a first implementation.
I have voluntary isolated most of V4L stuff in a dedicated class so that switching should not be so intrusive for core decoding function

But I know it is a path that would be interesting to explore... (On my todo list)

Okido.
I'll start working on it.

In https://github.com/koying/xbmc/commits/imx , I've squashed your commits up to now (not the 1080i fixes) and I've baselined pure software rendering.
Too slow, unfortunately, but there might be bugs.

(2014-02-10, 03:00)wolfgar Wrote: [ -> ]Which target and which kernel do you use ?
(As far as I can tell 1080p movies work just perfectly on all the targets I support...)

Hello, Stephan,

And many thanks for your work! I'm using a Wandboard Quad and Arch Linux ARM. The reported kernel is 3.0.35_4.1.0-5-ARCH+, it's b8d0163 from the wandboard_imx_3.0.35_4.1.0 branch of your linux repo on GH along with a couple of patches to support the newest GPU blobs from Freescale (I'm using CruX's PKGBUILD from here).

I would like also to add that XBMC accesses files from SMB shares mostly. Maybe setting up some NFS shares would be better?

(2014-02-10, 14:14)Koying Wrote: [ -> ]Okido.
I'll start working on it.

In https://github.com/koying/xbmc/commits/imx , I've squashed your commits up to now (not the 1080i fixes) and I've baselined pure software rendering.
Too slow, unfortunately, but there might be bugs.

Oki, have you tried to use the vivante direct extension I mentioned ? I mean using glTexDirectVIVMap...

Regards
Stéphan

(2014-02-10, 20:27)wolfgar Wrote: [ -> ]Oki, have you tried to use the vivante direct extension I mentioned ? I mean using glTexDirectVIVMap...

That's what meant by "start working on it"

(2014-02-10, 14:54)joko Wrote: [ -> ]And many thanks for your work! I'm using a Wandboard Quad and Arch Linux ARM. The reported kernel is 3.0.35_4.1.0-5-ARCH+, it's b8d0163 from the wandboard_imx_3.0.35_4.1.0 branch of your linux repo on GH along with a couple of patches to support the newest GPU blobs from Freescale (I'm using CruX's PKGBUILD from here).

I would like also to add that XBMC accesses files from SMB shares mostly. Maybe setting up some NFS shares would be better?

OK,, I asked because the reported IPU error is a sync error which occurs when the IPU does not get the display data on time to display them (kind of underrun). Harmless issue as long as your don't loose screen sync. This issue is largely mitigated by boosting IPU exchanges on the AXI bus (that's why I asked which kernel you use : I little patch enables this tweak but you have it...)
Have you tried another image before the archi linux arm one ? I ask to be sure we are safe regarding hw setup (board+screen) but it should work fine based on crux packaging.
Regarding SMB I use it everyday flawlessly even for demanding bitrates so I don't think it is the issue but you can try to play a file stored locally to be sure it is not about network...

Stephan

---

(2014-02-10, 20:31)Koying Wrote: [ -> ]That's what meant by "start working on it"

ok, I get it !
It makes sense as you already switched to gpu rendering 3 days ago...
I cross my fingers but I am confident it will really help...

Hello,

I have a wandboard quad and I am using a TV Sony KDL32W656 as monitor. The rootfs is in a HD. The movies are in the same HD. The command line is:

console=ttymxc0,115200 consoleblank=0 fixrtc root=/dev/sda3 rootfstype=ext4 rootwait video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=16 dmfc=3

I tested the xbmc using archlinux and this pkgbuilds: https://github.com/CrawX/PKGBUILDs

So, after some minutes using the menus, the video hangs. Sometimes, the audio still play. Sometimes, all xbmc hangs.

I have this errors in dmesg and logs:


After that, the screen goes blank / standby.


And I got this error:


I have make a video showing the problem. Its happen at 2:20 .

Link: https://mega.co.nz/#!tMtDgIiS!gmHq5zonfI...LAzu7lJ-0Y

Hi LeoKesler

I fear it is a regression with VPU allocations.
In fact I have applied the patch provided by wandboard team here : https://github.com/wandboard-org/linux/c...990bc69233 (you can also refer to the post "January 17 2014 - Video playback using the Wandboard VPU, part 1" on http://wandboard.org/) and it seems it is responsible for this crash...
You can revert my commit https://github.com/wolfgar/linux/commit/...a41883ca5e and give it a try without this change

Generally speaking I thing we should move to the new wandboard kernel and only apply the few relevant patches I have done to improve xbmc behavior on top of this one to check whether it helps regarding stability ..

Regards

Hi Stephan,

steven@tbs reported the same issue with the same patch, so I seems to make some troubles with hdtv playback. In fact I didn't tried this one out yet, but I guess it will endup same..

Regarding to xbmc, so using still the same build as I reported last, I'm having on some interlaced SDTV Videos stottering behaviour, like it was on the HDTV (but not so heavy) I will try out to find some exaple video for you..

Miro

Hi Miro,

Yes I had private mail exchange with steven.
So as immediate action I would advise to revert this commit.
I am trying to reproduce the issue to investigate and try to solve it for good.
I pushed this wandboard commit because many users reported VPU allocation issues and I hoped to improve their experience ... I guess I missed my point

Kind regards
Stephan