rubenvb

  • Posts

    20
  • Joined

  • Last visited

Reputation Activity

  1. Like
    rubenvb reacted to jernej in Mainline VPU   
    Pick patches 14-23 here: https://github.com/jernejsk/LibreELEC.tv/tree/linux-5.13/projects/Allwinner/patches/linux
     
    With that, HEVC should work without problem. Official HEVC API still needs some work.
     
    Not a problem, I usually update them with every stable kernel release, just to check on progress.
  2. Like
    rubenvb reacted to jernej in Mainline VPU   
    Yeah, LE currently uses 5.10 kernel because we are preparing stable release (no ETA, but hopefully soon). Only after that Linux will be updated to whatever current stable release will be at the time. However, v4l2 request api ffmpeg patches for Linux 5.13 can be found here. Note that they are untested and you still need corresponding kernel patches too.
  3. Like
    rubenvb reacted to JMCC in Mainline VPU   
    Here. And read the posts above about Kodi
     
     
  4. Like
    rubenvb got a reaction from gounthar in Mainline VPU   
    What is the "mainline" status of the VPU code for rk3399? in both kernel and ffmpeg (and, well, kodi)?
     
    It seems there were quite big changes for kernel 5.11, but I haven't see any updated ffmpeg patches to match the changes in the kernal uapi headers.
    Does Armbian keep track of any of these media patches somewhere? I can't seem to find anything relevant in the armbian/build repo on github :(, and only the "outdated" (mismatching with kernels >=5.11) in the LibreElec repos.
  5. Like
    rubenvb got a reaction from gounthar in Mainline VPU   
    It seems I may have found the "issue" in my failed trials post-May 2020 on my NanoPi M4 (rk3399)..
    I discovered today (finally) that Kodi's internal ffmpeg isn't being configured with "--enable-libudev --enable-v4l2-request" resulting in missing hwaccels and obviously, no functional hardware acceleration. How this worked before in my build of May 2020 is a mystery (maybe ffmpeg from then auto-enabled these options by chance?).
    I first tried to use the FFMPEG_EXTRA_FLAGS variable set on the commandline when invoking cmake, but since it is passed to the ffmpeg cmake script unquoted (see the commit adding it here: https://github.com/xbmc/xbmc/commit/cdbc12608b947d4afefc5bba48dc82e1f3514e52#diff-efa915ad129932095ae6f2a6d75e0d261386dd442b44338b4f6c705e25f1658eR241), only the first item ends up in ffmpeg_conf (due to CMake language rules I believe: https://gitlab.kitware.com/cmake/cmake/-/issues/17113#note_294727).
    I have now added the arguments manually and confirmed they make it to ffmpeg, and am currently running a linuxtv-rkvdec-work-in-progress from @Kwiboo's linux-rockchip repository, rebased onto a clean v5.10.4.
    Failing to notice this is kind of silly of me, and I'm sorry if I wasted anyone's time with my build configuration issues.
     
    H264 decoding works great again (with DRMPRIME/DirectToPlane rendering enabled in the Kodi settings).
    I do notice that the limited HEVC content that I have, which worked before (kernel 5.8-rc1 and Kodi/ffmpeg from May 2020), now shows a black screen.
     
    Additionally, I tried merging in the changes from @Kwiboo's v5.10.1-drm-rockchip branch, and that gives me an option for a 4k resolution, but when playing back a 1080p H264 file, it appears only the top-left corner of the video output, including the black band around the 1920x800 movie, is shown full screen.
    Playing back a 4k Big Buck Bunny MP4 file gives me "no signal" on my TV (it seems the actual 4k resolution is one of those @Kwiboo mentioned in the linked IRC conversation.
    Is there a better branch to merge in from instead?
    Is there any useful information I can provide to help this get fixed?
     
    I hope the kernel v4l2 request uapi can move from staging soon (5.11?) so that the ffmpeg changes can be pulled in there.
     
    As always: keep up the good work, I, along with many others, really appreciate what you're doing for these chips!
  6. Like
    rubenvb got a reaction from aaditya in Mainline VPU   
    Current Kodi master (currently hash 9f6d978f646) with the v4l2-request-hwaccel-4.3-rkvdec ffmpeg branch leads to audio only when starting video playback. The log produces this:
    2020-07-23 20:32:06.003 T:57711 INFO <general>: Creating InputStream 2020-07-23 20:32:06.015 T:57711 INFO <general>: Creating Demuxer 2020-07-23 20:32:06.166 T:57711 INFO <general>: Opening stream: 0 source: 256 2020-07-23 20:32:06.166 T:57711 INFO <general>: Creating video codec with codec id: 27 2020-07-23 20:32:06.166 T:57711 INFO <general>: CDVDVideoCodecDRMPRIME::Open - using decoder H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 2020-07-23 20:32:06.167 T:57711 INFO <general>: Creating video thread 2020-07-23 20:32:06.168 T:57718 INFO <general>: running thread: video_thread 2020-07-23 20:32:06.168 T:57711 INFO <general>: Opening stream: 1 source: 256 2020-07-23 20:32:06.168 T:57711 INFO <general>: Finding audio codec for: 86020 2020-07-23 20:32:06.169 T:57711 INFO <general>: CDVDAudioCodecFFmpeg::Open() Successful opened audio decoder dca 2020-07-23 20:32:06.169 T:57711 INFO <general>: Creating audio thread 2020-07-23 20:32:06.169 T:57719 INFO <general>: running thread: CVideoPlayerAudio::Process() 2020-07-23 20:32:06.169 T:57711 INFO <general>: Opening stream: 2 source: 256 2020-07-23 20:32:06.172 T:57718 INFO <general>: CVideoPlayerVideo - Stillframe left, switching to normal playback 2020-07-23 20:32:06.180 T:57719 INFO <general>: Creating audio stream (codec id: 86020, channels: 8, sample rate: 48000, no pass-through) 2020-07-23 20:32:06.184 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:06.184 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:06.185 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: Invalid data found when processing input (-1094995529) ... 2020-07-23 20:32:06.589 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:07.006 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::Drain - send packet failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:07.006 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - receive frame failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:07.006 T:57718 INFO <general>: CVideoPlayerVideo - Stillframe detected, switching to forced 23.976024 fps 2020-07-23 20:32:07.047 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - receive frame failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:07.064 T:57718 INFO <general>: CVideoPlayerVideo - Stillframe left, switching to normal playback 2020-07-23 20:32:07.064 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: End of file (-541478725) 2020-07-23 20:32:07.064 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - receive frame failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:07.065 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: End of file (-541478725) 2020-07-23 20:32:07.065 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - receive frame failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:07.148 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: End of file (-541478725) 2020-07-23 20:32:07.231 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: End of file (-541478725) To be honest, this has been like this for a while, and my old build (kodi hash 9f6d978f646 with the 4.2.2 ffmpeg branch) works fine.
    If I translate the hashes into "revisions", I get r55120 (working) vs r55380 (hash e64b3034b56) broken, which means roughly 260 commits that might have broken it for me.
    I fear the move to ffmpeg 4.3 is at least partially to blame.
    I will try to bisect this better, but the old revision won't build due to some networking related function pointer not being convertible without -fpermissive.
    I'll need to find some time to bisect, so I don't know when I'll get to it.
     
    Any thoughts or anything I can try to provide more info or at best fix this issue without bisecting kodi?
     
    Thanks for everything so far, you guys are great!