Openelec Build for OPI PC and 2 now with HW decoding

runnerway

jernej replied at 2015-12-26 23:59
I managed to fix black screen for TS files. Main problem was video files with multiple streams insi ...

Thank you for the fix. I will try very soon

I tried again MPEG2 without direct rendering as you asked: we have a lot of dropped frames even with GPU rendering.
We have a lot of skipped frames too. I think now with direct rendering we don't have skipped frames anymore (i will confirm soon).
So it's already a step forward.

I've to try other VP9 videos but if all of them stop on their own as the adele' one i think it's better to disable HW acceleration (or it's better to say "decoding with CedarX lib") for VP9 until a solution is here.

handyfreax

i have Downloaded the img and with win32imager install on the SD card are the LED is out, and no screen is it an OPi PC.
or must install other way?

swordfish6975

handyfreax replied at 2015-12-27 03:16
i have Downloaded the img and with win32imager install on the SD card are the LED is out, and no scr ...

the file ending in geac7c06.img.gz  ?

you extracted it?

once extracted check it matches https://imgur.com/X6QBme9   SHA-256  (using 7zip)

Also the red light wont come on with this build, something to do with the new Uboot, but it works on my OPI PC, note it also is default HDMI.  (and defaults to analog audio)

If you can hookup something to the serial pins near the power jack to see the debug info and put it in pastebin that would also be helpfull.

perhaps also try a diffrent SD card?

handyfreax

ich benutze normalen HDMI, ich habe die SHA überprüft es die gleiche decompress mit 7zip und überprüfen Sie mit 7Zip.
sind, wenn ich putten Sie die Karte, und schalten Sie die OPI-PC die aus dem Netzwerk geführt gehen Blitz und nach 3 Minuten.
Sind i werden nicht angezeigt. edit: andere Karte ist die gleiche.

lymon

jernej replied at 2015-12-26 23:59
I managed to fix black screen for TS files. Main problem was video files with multiple streams insi ...

with this new patch any video that uses cedarx for decoding is still giving only audio and no (black) video on my end.
other decoders still work

jernej

lymon replied at 2015-12-27 19:05
with this new patch any video that uses cedarx for decoding is still giving only audio and no (bla ...

Which orange pi do you use? Do you use any non standard setting, e.g. display resolution, different graphic driver, etc.?

Please give me the output of this command, run on orange pi:

1. cat /sys/class/graphics/fb0/bits_per_pixel

Copy code

If it is lower than 32, it may explain this.

lymon

jernej replied at 2015-12-28 03:03
Which orange pi do you use? Do you use any non standard setting, e.g. display resolution, differen ...

this is on a OPI-PC

compiled straight from (your) github source ...only change is the kodi-000-windowing-cedarx-and-HW-deinterlacing.patch (and removal of the "old" cedarx + windowing patch)
Then flashed image to SD.

compiled and boots fine

(standard) resolution: 1920x1020@60Hz
the (standard) bits_per_pixel in this image is 16 (if this needs to be 32 bits then boot.scr or fb0_format in the fex-file probably needs adjusting ?...current value for fb0_format is 0 and for 32 bit colors it needs to be ARGB8888, value 10 )

..tried changing it to 32 ( echo 32 > /sys/class/graphics/fb0/bits_per_pixel ) and then start a video, but still no cigar.

However..if it change it to 8 bits and then to 32 bits during video playback, then it starts showing  the video but kodi mainscreen/menus will be all messed up

jernej

lymon replied at 2015-12-27 21:13
this is on a OPI-PC

compiled straight from (your) github source ...only change is the kodi-000-win ...

I really don't know how you managed to get 16 bit per pixel. In driver, value 0 means DISP_FORMAT_ARGB_8888, which have following settings:

1. case DISP_FORMAT_ARGB_8888:
   
2.         var->bits_per_pixel = 32;
   
3.         var->transp.length = 8;
   
4.         var->red.length = 8;
   
5.         var->green.length = 8;
   
6.         var->blue.length = 8;
   
7.         var->blue.offset = 0;
   
8.         var->green.offset = var->blue.offset + var->blue.length;
   
9.         var->red.offset = var->green.offset + var->green.length;
   
10.         var->transp.offset = var->red.offset + var->red.length;
    
11.         break;

Copy code

I think that you can't so easily change bits per pixel. As you found out, it messes with framebuffer.

Can anyone confirm that latest patch works/don't work with OPi PC?

Reason why this patch doesn't work for you is because you don't have active alpha channel. Video is rendered on a layer behind the framebuffer and if there is no alpha information, every pixel is treated as opaque. In this case, color keying would be needed, but unfortunatelly, Allwinner thought that it is not needed. However, there is some code in display driver, which might be enough to get it working with patch.

EDIT: Where did you look at for ARGB8888 value? My header file says that it is 0.

EDIT2: Did you pull latest changes from my github repository? Can you please test settings before and after this commit:
https://github.com/jernejsk/Open ... ae73007885764d9d595

runnerway

jernej replied at 2015-12-28 04:35
I really don't know how you managed to get 16 bit per pixel. In driver, value 0 means DISP_FORMAT_A ...

As you know i tried before this commit with my OPiPC.Now i tried again after this commit using the patch you linked in previous post. And it works without problems in all cases.


"OpenELEC:~ # cat /sys/class/graphics/fb0/bits_per_pixel
32"


Tomorrow i can upload a build if lymon want to try.
@lymon Did you try to do a clean build?
(Removing all the files from target folder)

I can confirm that problems with ts videos are solved
Thank you.

I saw the tearing with interlaced videos you told us.
I'm curious to see what we have to patch in the kernel
Do you already know?

jernej

runnerway replied at 2015-12-27 22:58
As you know i tried before this commit with my OPiPC.Now i tried again after this commit using the  ...

So you get 32 bits per pixel in both cases? Now that I checked header files, value 10 means DISP_FORMAT_RGB_565 which indeed doesn't have alpha channel. @lymon, don't rely on values found on linux sunxi's fex guide. Those values are for old display engine, you can check the new ones in include/video/sunxi_display2.h.

Change for vsync is rather small, just uncommenting one line in drivers/video/sunxi/disp2/disp/dev_fb.c:

1.     case FBIO_WAITFORVSYNC:
   
2.     {
   
3.         //ret = fb_wait_for_vsync(info);
   
4.         break;
   
5.     }

Copy code

Then this ioctl call can be used to wait for vsync, at least that I hope