• 1
  • 3
  • 4
  • 5(current)
  • 6
  • 7
  • 8
Solved RPi3 and RPi4 hardware decoding expectations for version 19
#61
Excuse me for using this thread
I've been struggling for days with the new Kodi, with no success.
For this test I'm using current 5.4 kernel with bcm2711_defconfig settings, only BTRFS is compiled into the kernel

Running XBian, which is currently based on Debian Buster

I always get this error, no matter what settings I use in /boot/config.txt

Actually, I have these:
dtoverlay=vc4-kms-v3d-pi4,cma-size=402653184
dtoverlay=rpivid-v4l2

The error I get is that ffmpeg can't request memory for whatever reason
Code:
2020-07-26 19:21:51.957 T:3175    DEBUG <general>: CVideoPlayer::SetCaching - caching state 1
2020-07-26 19:21:51.957 T:3175    DEBUG <general>: CDVDClock::SetSpeedAdjust - adjusted:0.000000
2020-07-26 19:21:51.958 T:3285     INFO <general>: running thread: CVideoPlayerAudio::Process()
2020-07-26 19:21:51.958 T:3285    DEBUG <general>: CVideoPlayerAudio - CDVDMsg::GENERAL_PAUSE: 1
2020-07-26 19:21:51.958 T:3285    DEBUG <general>: CDVDAudio::Pause - pausing audio stream
2020-07-26 19:21:51.963 T:24949   DEBUG <general>: EGL Debugging:
                                                   Error: EGL_BAD_SURFACE
                                                   Command: eglSwapBuffers
                                                   Type: EGL_DEBUG_MSG_ERROR_KHR
                                                   Message: dri2_swap_buffers
2020-07-26 19:21:51.964 T:24949   DEBUG <general>: CDRMAtomic::FlipPage - Execute modeset at next commit
2020-07-26 19:21:51.995 T:25061   ERROR <general>: open_restricted - failed to open /dev/input/event9 (No such device)
2020-07-26 19:21:52.037 T:24949   DEBUG <general>: CWinSystemGbmGLESContext::PresentRender - Sending display reset to all clients
2020-07-26 19:21:52.037 T:24949    INFO <general>: VideoPlayer: OnResetDisplay received
2020-07-26 19:21:52.037 T:3283    DEBUG <general>: CVideoPlayerVideo - CDVDMsg::GENERAL_PAUSE: 0
2020-07-26 19:21:52.037 T:3285    DEBUG <general>: CVideoPlayerAudio - CDVDMsg::GENERAL_PAUSE: 0
2020-07-26 19:21:52.058 T:3175    DEBUG <general>: CVideoPlayer::HandleMessages - player 2 reported state: 0
2020-07-26 19:21:52.058 T:3175    DEBUG <general>: CVideoPlayer::HandleMessages - player 1 reported state: 0
2020-07-26 19:21:52.058 T:25511   DEBUG <general>: OnAVChange: CApplication::OnAVChange
2020-07-26 19:21:52.059 T:3175    DEBUG <general>: CVideoPlayer::SetCaching - caching state 1
2020-07-26 19:21:52.059 T:3283     INFO <general>: CVideoPlayerVideo - Stillframe left, switching to normal playback
2020-07-26 19:21:52.059 T:3175    DEBUG <general>: CDVDClock::SetSpeedAdjust - adjusted:0.000000
2020-07-26 19:21:52.059 T:3175    DEBUG <general>: CVideoPlayer::SetCaching - caching state 2
2020-07-26 19:21:52.059 T:3175    DEBUG <general>: CDVDClock::SetSpeedAdjust - adjusted:0.000000
2020-07-26 19:21:52.059 T:3175    DEBUG <general>: CVideoPlayer::CheckContinuity - wrapback :2, prev:130000.000000, curr:5000.000000, diff:-125000.000000
2020-07-26 19:21:52.065 T:3279    ERROR <general>: ffmpeg[(nil)X]: [hevc] get_buffer() failed
2020-07-26 19:21:52.065 T:3279    ERROR <general>: ffmpeg[(nil)X]: [hevc] thread_get_buffer() failed
2020-07-26 19:21:52.065 T:3279    DEBUG <general>: ffmpeg[(nil)X]: [hevc] Error parsing NAL unit #0.
2020-07-26 19:21:52.067 T:3280    ERROR <general>: ffmpeg[(nil)X]: [hevc] get_buffer() failed
2020-07-26 19:21:52.067 T:3280    ERROR <general>: ffmpeg[(nil)X]: [hevc] thread_get_buffer() failed
2020-07-26 19:21:52.067 T:3280    DEBUG <general>: ffmpeg[(nil)X]: [hevc] Error parsing NAL unit #0.
2020-07-26 19:21:52.068 T:3285    DEBUG <general>: CDVDAudio::Pause - pausing audio stream
2020-07-26 19:21:52.068 T:3285    DEBUG <general>: CDVDAudio::Pause - pausing audio stream
2020-07-26 19:21:52.069 T:3285     INFO <general>: Creating audio stream (codec id: 86019, channels: 2, sample rate: 48000, no pass-through)
2020-07-26 19:21:52.069 T:3285    DEBUG <general>: CVideoPlayerAudio:: synctype set to 0: clock feedback
2020-07-26 19:21:52.069 T:3281    ERROR <general>: ffmpeg[(nil)X]: [hevc] get_buffer() failed
2020-07-26 19:21:52.070 T:3281    ERROR <general>: ffmpeg[(nil)X]: [hevc] thread_get_buffer() failed
2020-07-26 19:21:52.070 T:3281    DEBUG <general>: ffmpeg[(nil)X]: [hevc] Error parsing NAL unit #0.
2020-07-26 19:21:52.071 T:3283    ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: Cannot allocate memory (-12)

Full debug log can be found here


The current gbm branch of @popcornmix is used with builtin ffmpeg, I have no problems building with it

The same problem also occurs when I want to play a h.264 video via DRMPRIME, so I think it has nothing to do with the HEVC patch. the problem must be somewhere else.

Can somebody help me, I'm out of ideas now
Kodi 18.6 @ openSUSE 13.1 x86_64 - Asus E35M1-I DELUXE | 8GB Ram | 240G 2.5" SSD
Kodi 20.2 on 1st Raspberry Pi B @ XBian | Kodi 20.2 on Raspberry Pi 3B+ @ XBian | Kodi 21a2 on Raspberry Pi4B @ XBian | Kodi 19.0 on SolidRun i.MX6 @ XBian
VDR 2.4.5 & Tvheadend4.3-1917 (for recording) on Cubieboard2 @ Debian Buster
Reply
#62
@Nachteule if you actually read this thread you'd have seen that we already found the cause if this problem and the solution was posted.

https://forum.kodi.tv/showthread.php?tid...pid2964459
Reply
#63
(2020-07-26, 20:52)asavah Wrote: @Nachteule if you actually read this thread you'd have seen that we already found the cause if this problem and the solution was posted.

https://forum.kodi.tv/showthread.php?tid...pid2964459
Of cource i've read this thread many many times and theese settings are correct here
Code:
root@kmxbilr2 /dev # ll dma_heap/
insgesamt 0
crw-rw---- 1 root video 253, 1 Jul 26 21:08 linux,cma
crw-rw---- 1 root video 253, 0 Jul 26 21:08 system

and the user ist member of video

like I said, I have absolutely no more ideas what it could be

I have even just used the mesa libraries from raspbian (19.3.2-1~bpo10+1~rpt1), no difference

And, according to strace, he never gets to access the /dev/dma_heap/ devices
Kodi 18.6 @ openSUSE 13.1 x86_64 - Asus E35M1-I DELUXE | 8GB Ram | 240G 2.5" SSD
Kodi 20.2 on 1st Raspberry Pi B @ XBian | Kodi 20.2 on Raspberry Pi 3B+ @ XBian | Kodi 21a2 on Raspberry Pi4B @ XBian | Kodi 19.0 on SolidRun i.MX6 @ XBian
VDR 2.4.5 & Tvheadend4.3-1917 (for recording) on Cubieboard2 @ Debian Buster
Reply
#64
I still think that you are facing a permission issue.
To rule out a permssion issue - run kodi as root, if it works then its lack of necessary permissions.

Check this https://github.com/RPi-Distro/raspberryp...-com.rules and apply accordingly.
The user has to be in video and input group.
Reply
#65
@Nachteule - xstream and its repo are banned addons (wiki) around here due to their violation of our piracy policy (wiki).

The forum moderators have determined that banned addons (wiki) are present on your system. To receive assistance here, these banned items must be removed. If a clean log is not submitted within 3 days, then the relevant post(s) will be removed after this time.
|Banned add-ons (wiki)|Forum rules (wiki)|VPN policy (wiki)|First time user (wiki)|FAQs (wiki) Troubleshooting (wiki)|Add-ons (wiki)|Free content (wiki)|Debug Log (wiki)|

Kodi Blog Posts
Reply
#66
(2020-07-26, 21:56)asavah Wrote: I still think that you are facing a permission issue.
To rule out a permssion issue - run kodi as root, if it works then its lack of necessary permissions.

Check this https://github.com/RPi-Distro/raspberryp...-com.rules and apply accordingly.
The user has to be in video and input group.

I've added KERNEL=="vcsm-cma", GROUP="video", MODE="0660" (no difference) and of course, user is member of video and input group

Running under root: NO difference

As an interim conclusion:
All attempts of the last days (new kernel with default settings, use of popcornmix' gbm branch and not only the commits, execution as root) brought absolutely no change and therefore no new insights

Oh yes, I forgot: if I deactivate DRMPRIME and everything is decoded by software, playback works. but that can't be the point
Kodi 18.6 @ openSUSE 13.1 x86_64 - Asus E35M1-I DELUXE | 8GB Ram | 240G 2.5" SSD
Kodi 20.2 on 1st Raspberry Pi B @ XBian | Kodi 20.2 on Raspberry Pi 3B+ @ XBian | Kodi 21a2 on Raspberry Pi4B @ XBian | Kodi 19.0 on SolidRun i.MX6 @ XBian
VDR 2.4.5 & Tvheadend4.3-1917 (for recording) on Cubieboard2 @ Debian Buster
Reply
#67
(2020-07-23, 22:50)graysky Wrote: If I manually copy /usr/lib/modules/5.4.51-1-ARCH/build/include/uapi/drm/drm_fourcc.h provided by linux-raspberrypi4-headers into the build root's /usr/include/drm/ the build finishes without error.  I think we can modify our linux-raspberrypi4-headers package to just supply that via a symlink to make the build work.

Again, THANK YOU very much for your engagement on this, @popcornmix!  With these changes, Arch ARM can offer your HEVC decoding mods in v19 to our users.

Just wanted to revisit this... another solution proposed by Kevin, one of the Arch ARM devs, is to add the following to the PKGBUILD, which allows the build to complete without the need to tweak the linux-rbp4-headers package with the symlink.
Code:
_kernel_release="$(pacman -Q linux-raspberrypi4-headers | grep -Eo "[^\ ]+$")-ARCH"
mkdir -p "$srcdir/uapi/drm"
ln -s /usr/lib/modules/$_kernel_release/build/include/uapi/drm/drm_fourcc.h "$srcdir/uapi/drm"
export CPPFLAGS+=" -I$srcdir/uapi"

Thanks again to @asavah and @popcornmix!

EDIT: and we are live with the package.
Need help programming a Streamzap remote?
Reply
#68
@popcornmix - Your most recent commit 1ac6ffe3315e556e24789a4bfc50b3925c8af0cd seems to move some of the internal headers back out?

I had to adjust to get the build to finish:
Code:
  _kernel_release="$(pacman -Q linux-raspberrypi4-headers | grep -Eo "[^\ ]+$")-ARCH"
  _uapi_headers="$(/usr/lib/modules/$_kernel_release/build/include/uapi)"

  mkdir -p "$srcdir/uapi/{drm,linux}"
  ln -s "$_uapi_headers"/drm/drm_fourcc.h  "$srcdir/uapi/drm"
  ln -s "$_uapi_headers"/linux/videodev2.h "$srcdir/uapi/linux"
  export CPPFLAGS+=" -I$srcdir/uapi"
Need help programming a Streamzap remote?
Reply
#69
Interpreting the instructions in this thread, I managed to compile and run Kodi 19 and 19.1 as follows

 cmake -DCMAKE_INSTALL_PREFIX=/usr/local \
-DCMAKE_INSTALL_LIBDIR=/usr/local/lib \
-DCMAKE_EXE_LINKER_FLAGS_INIT="-L/opt/vc/lib -lvcsm" \
-DCMAKE_EXE_LINKER_FLAGS="-L/opt/vc/lib -lvcsm" \
-DCMAKE_CXX_FLAGS="-Wl,-L/opt/vc/lib -Wl,-lvcsm" \
-DENABLE_EVENTCLIENTS=ON \
-DENABLE_INTERNAL_FFMPEG=ON \
-DENABLE_INTERNAL_FMT=ON \
-DENABLE_INTERNAL_CROSSGUID=ON \
-DENABLE_INTERNAL_FSTRCMP=ON \
-DENABLE_INTERNAL_FLATBUFFERS=ON \
-DENABLE_INTERNAL_SPDLOG=ON \
-DENABLE_EVENTCLIENTS=ON \
-DENABLE_VAAPI=OFF \
-DENABLE_VDPAU=OFF \
-DENABLE_OPENGL=OFF \
-DSPDLOG_URL="/spdlog-1.5.0.tar.gz" \
-DCORE_PLATFORM_NAME=gbm \
-DGBM_RENDER_SYSTEM=gles \
-DAPP_RENDER_SYSTEM=gles \
../xbmc-19.1-Matrix &&
make -j 1 && make install

The playback of h.264 video with those options is such that it does not stress the CPU too much @720p, but it is obviously software decoded and shows occasional artifacts - kodi info display says "ff-h246 (SW)", no acceleration options in the Player settings menu.

Unfortunately, it is not always clear in this thread who has which versions, so after spending some time, I am still not sure whether I can expect any improvement at all.

My current system is:

Raspberry 3B+ on Raspbian Buster with 32-bit Kernel v5.4 (d6d1ca1f0c0fd0e61f7933d714dd28363869c388) and
dtoverlay=vc4-fkms-v3d,cma-256
in config.txt. 

My first attempts with current Kernel v5.10 did not change that, but I didn't try all possible options.

Any chance I can improve things on the 3B+, e.g. by using a different kernel or pulling other dependencies?
Reply
#70
I do not know about your distro, but I believe you will need the 5.10.y kernel. On Arch ARM at least, try using my fork of popcornmix's gbm_matrix as your source.  It contains the ffmpeg patch from jc-kynesim/dev/4.3.2/clean_3 which is a little newer and also includes the needed defines for the hardware decoding.  Otherwise identical to popcornmix's.

You can also simplify your build:
Code:
_commit=f955df92d4e5d2a290261c3d29e87059b1443db7
wget -O xbmc-v19.1.tar.gz https://github.com/graysky2/xbmc/archive/$_commit.tar.gz

_args=(
  -DCORE_PLATFORM_NAME=gbm
  -DAPP_RENDER_SYSTEM=gles
  -DCMAKE_INSTALL_PREFIX=/usr/local
  -DCMAKE_INSTALL_LIBDIR=/usr/local/lib
  -DUSE_LTO=$(nproc)
  -DENABLE_LDGOLD=OFF
  -DENABLE_EVENTCLIENTS=ON
  -DENABLE_INTERNAL_FFMPEG=ON
  -DENABLE_INTERNAL_FMT=ON
  -DENABLE_INTERNAL_SPDLOG=ON
  -DENABLE_INTERNAL_CROSSGUID=ON
  -DENABLE_INTERNAL_FSTRCMP=ON
  -DENABLE_INTERNAL_FLATBUFFERS=ON
  -DENABLE_INTERNAL_UDFREAD=ON
  -DENABLE_MYSQLCLIENT=ON
)
cmake "${_args[@]}" ../xbmc-19.1-Matrix
make -j$(nproc)
make -j$(nproc) install
Need help programming a Streamzap remote?
Reply
#71
I don't think kernel 5.10 works on RPI 3+ at least with fdkms enabled. I tried and had to role back to 5.4 as I saw something on github regarding the 5.10 on the Pi 3+ doesn't work with fdkms. 1080p tv from mythtv pvr was unwatchable.
Reply
#72
I can't find the link, but you need to use kms not fkms with Matrix and/or rpi-5.10.y.  See what LE does for /boot/config.txt
Need help programming a Streamzap remote?
Reply
#73
(2021-05-23, 12:03)graysky Wrote: I can't find the link, but you need to use kms not fkms with Matrix and/or rpi-5.10.y.  See what LE does for /boot/config.txt

For the sake of completeness only:

Of course it also works with the fkms driver. supposedly this should only not be used because of tearing, which I could never determine with me. I personally use fkms because VNC still works with it.

Also the kernel 5.4 is still usable, only an additional patch is used. I currently use the 5.4, because the 5.10 is screwed up in my opinion and I don't know if there is a solution in sight. Here is the issue still open

You can also see that the cpu load when playing videos on 5.10 kernel is significantly higher than on 5.4 kernel
Kodi 18.6 @ openSUSE 13.1 x86_64 - Asus E35M1-I DELUXE | 8GB Ram | 240G 2.5" SSD
Kodi 20.2 on 1st Raspberry Pi B @ XBian | Kodi 20.2 on Raspberry Pi 3B+ @ XBian | Kodi 21a2 on Raspberry Pi4B @ XBian | Kodi 19.0 on SolidRun i.MX6 @ XBian
VDR 2.4.5 & Tvheadend4.3-1917 (for recording) on Cubieboard2 @ Debian Buster
Reply
#74
(2021-05-20, 20:41)graysky Wrote: I do not know about your distro, but I believe you will need the 5.10.y kernel. On Arch ARM at least, try using my fork of popcornmix's gbm_matrix as your source.  It contains the ffmpeg patch from jc-kynesim/dev/4.3.2/clean_3 which is a little newer and also includes the needed defines for the hardware decoding.  Otherwise identical to popcornmix's.

You can also simplify your build:
Code:
_commit=f955df92d4e5d2a290261c3d29e87059b1443db7
wget -O xbmc-v19.1.tar.gz https://github.com/graysky2/xbmc/archive/$_commit.tar.gz

_args=(
  -DCORE_PLATFORM_NAME=gbm
  -DAPP_RENDER_SYSTEM=gles
  -DCMAKE_INSTALL_PREFIX=/usr/local
  -DCMAKE_INSTALL_LIBDIR=/usr/local/lib
  -DUSE_LTO=$(nproc)
  -DENABLE_LDGOLD=OFF
  -DENABLE_EVENTCLIENTS=ON
  -DENABLE_INTERNAL_FFMPEG=ON
  -DENABLE_INTERNAL_FMT=ON
  -DENABLE_INTERNAL_SPDLOG=ON
  -DENABLE_INTERNAL_CROSSGUID=ON
  -DENABLE_INTERNAL_FSTRCMP=ON
  -DENABLE_INTERNAL_FLATBUFFERS=ON
  -DENABLE_INTERNAL_UDFREAD=ON
  -DENABLE_MYSQLCLIENT=ON
)
cmake "${_args[@]}" ../xbmc-19.1-Matrix
make -j$(nproc)
make -j$(nproc) install

Thanks for the hints. I had to adjust it a little to satisfy the dependencies. For Raspbian kernel v5.4 this will not build, because the kernel lacks the header linux/dma-heap.h . 

With Raspbian kernel v5.10 I got really close, but building fails at the very end when linking kodi-gbm:

/usr/bin/ld: out of memory allocating 336333 bytes after a total of 1246359552 bytes
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/kodi.dir/build.make:484: kodi-gbm] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:5285: CMakeFiles/kodi.dir/all] Fehler 2
make: *** [Makefile:141: all] Fehler 2

If I run make -j 1 again, I get an (also strange)
/usr/bin/ld: build/pvr/guilib/pvr_guilib.a: member build/pvr/guilib/pvr_guilib.a(PVRGUIActions.cpp.o) in archive is not an object
or similar until I "make clean" everything in build/pvr. The PVRGUIActions.cpp.o is an object according to objdump.

I tried to fix the memory issue by increasing swap, stopping unnecessary daemons, changing the memory split and stripping debug symbols from all objects, all without success. Either the 1GB volatile memory on my RP3B+ is just too small to build this natively, or there is some issue that drains memory. Probably its latter, because I have already build kodi 19 and 19.1 with a variety of options and different kernels from the official repository.
Reply
#75
You didn't provide enough context in the error log, also nice to build with export LANG=en_US.UTF-8 if you want to share on forums in general (don't assume everyone can read your locale).  In any case, seems to be a linking issue so my first suggestion is disable LTO which requires a bit of memory (lots in some cases):
-DUSE_LTO=OFF

If you want to keep LTO, and it does produce smaller bins and offers theoretical efficiencies/micro speed-ups, you'll need more swap.  Before I got a RPi4B with 8 GB of RAM, building the toolchain required me having a 4 GB swap file on the RPi4B with 4 GB of RAM for example.

How much swap are you using?  Double it, try again.  If it fails, double it again.  If you're using a static swap partition, stop for this test and use a swapfile instead which offers more flexibility in resizing. 
 
Code:
# as root
SF=/path/to/swapfile
dd if=/dev/zero of=$SF bs=1024 count=4194304
chmod 600 $SF
mkswap $SF
swapon $SF
Need help programming a Streamzap remote?
Reply
  • 1
  • 3
  • 4
  • 5(current)
  • 6
  • 7
  • 8

Logout Mark Read Team Forum Stats Members Help
RPi3 and RPi4 hardware decoding expectations for version 190