Jump to content

rubenvb

Members
  • Posts

    21
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. rubenvb

    Mainline VPU

    It seems HEVC is going to be pushed to mainline "soon": https://www.phoronix.com/scan.php?page=news_item&px=RkVDEC-HEVC-Patches I've had HEVC patches applied all since they were available, but none of my HEVC content ever really played well post kernel 5.6 era. It's probably a 10bit color conversion thing, I wonder if this patch series also tackles that, or if the problem actually lies in FFMPEG or even Kodi itself. Is there any news on the merging of v4l2-request hwaccel support in FFMPEG's releases? It seems like this has been a proof-of-concept patch series since the beginning. For which I am eternally grateful, obviously. Just wondering if anyone knows if anyone is working on getting that solidified in the FFMPEG codebase.
  2. rubenvb

    Mainline VPU

    I am currently running kernel 5.14.9 with the LibreELEC patches applied that were at that time created against that version. I then compiled Kodi with FFmpeg from the v4l2-request-hwaccel-4.3.2 branch of https://github.com/jernejsk/FFmpeg The result can play MPEG2 and H264 video with DRM prime accel turned on, has 4k resolution available, and HDMI-CEC which is all quite awesome. Only thing not working for me is 10-bit HEVC, which proceeds to play audio but freezes on the Kodi menu. I'm unsure of where the problem lies, but it seems like an unsupported color format: After this and the AE_FMT_FLOAT support is fixed, this thing will be golden. I notice this is the color format I reported previously that was completely borked when played by FFmpeg, but subsequently reported as working somehow in Kodi itself by myself. So this seems like some weird/transient regression against a previous state of all the code involved (somewhere between kernel/ffmpeg/kodi). Are there any patches I can test for either the yuv420p10le or AE_FMT_FLOAT support? It's no problem for me to recompile any component. Anything to help each other out :). For now, the powerful rk3399 CPU can just about decode the HEVC content all by itself, if the scenes aren't overly complex or fast-moving.
  3. rubenvb

    Mainline VPU

    I just tested this with vanilla Linux 5.13.7 and at least H264 playback with DRM Prime Direct To Plane rendering in Kodi 19.1 works as expected. HEVC content still just doesn't render at all, but maybe I need some extra kernel patches for that still. Thanks for the link to the up to date FFmpeg patches, you're a lifesaver!
  4. rubenvb

    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. rubenvb

    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. rubenvb

    Mainline VPU

    RIght, but these files work well enough with my old Kodi build. The same thing (no video, busy spinner flashing) happens when I try to play H264 files. I'll see if I can conjure up logs for that, although they won't be much different.
  7. rubenvb

    Mainline VPU

    You're absolutely correct, I saw what I wanted to see :(. It's just using the CPU decoder. The SoC is NanoPi M4 (RK3399). I use Kodi with GBM started directly through a systemd service; no desktop, no window manager. Mesa 20.2.1 Panfrost gets me OpenGL ES 3.0, which is used for the Kodi GUI. Kwiboo's 5.8-rc1 kernel (built from source on the 27th of June) gives me the driver-side v4l2-request API support through the rkvdec device. The last functional build of Kodi I have is from commit 9f6d978f646, and was built the 25th of May. Anything later (even if I try to build that same exact commit again, though with the current Kwiboo v4l2-request-hwaccel-4.2.2-rkvdec branch, Kodi used 4.2.2 at the time ), I get the broken behaviour :(. My guess is Kwiboo changed something when rebasing the branch after the 25th of May. For the current kodi-git build, I tried both the EGL and Direct-to-Plane options for the DRM PRIME acceleration. EGL results in no video output (stays on the Kodi menu) and Direct-to-Plane results in flashing of the busy spinner (and no video output) and in both cases normal audio output. Both result in the UI drawing over itself (i.e. it's not being cleared before it's drawn over) until I stop playback. Is there any way I can provide you with better info about this? Here is a log of a H265 file not playing back with FFMPEG and video logging enabled: https://gist.github.com/rubenvb/9da672e92577fd161e8dc51073ee0eda I added a second log to that gist of the old functional build I have, so the output can be compared. Note the nonfunctional output is from Kodi commit 9d256dd15d9 built yesterday, and the functional output is commit 9f6d978f646, built on the 25th of May. If the kernel needs to be updated for this to work again, I'll need to investigate the SATA hat not being detected in 5.9-rc1. Thanks for taking interest!
  8. rubenvb

    Mainline VPU

    I finally figured out what was going wrong with my new Kodi git builds: it seems an option "enable DRM PRIME acceleration" appeared in the settings. To get video output at all, I need to disable this. Strange thing is, rebuilding the same working commit on an up to date system (I run ArchLinuxARM) produced the same issue, so I am still in the dark what exactly is happening here. Installing my old build (and restoring the old versions of various dependencies, as Arch updates everything quite frequently), always worked. But building it again, in the same exact way, gave no video output as described in the post above. Is this due to something not working in Kodi, or with the way Kwiboo's FFMPEG works (i.e. "automagically" using the v4l2-request hwaccel path when outputting to DRM)? Having tried the 5.9-rc1 kernel, it seems something broke the NanoPi M4 SATA hat in that release. So still on the 5.8-rc1. I should really look into a nice way to extract the series of patches Kwiboo maintains (or is most of it already merged into mainline?). But in any case, all is well (except 5.9-rc1 SATA hat, but that's not relevant here), it seemed to be user (my) error of having the DRM PRIME acceleration enabled in the Kodi settings. I can't keep thanking you all enough, especially @Kwiboo!
  9. rubenvb

    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!
  10. I don't have the ROCKCHIPSPDIF entry. What did you do to get it? It doesn't pop up with any unpatched kernel 5.6 or 5.7. The realtek5651co I can get by editing the device tree with a patch you sent my some time ago, but that's not really important as it's the analog 3.5mm jack if I'm not mistaken. OK, thought as much as HDMI PCM audio worked without it. I'll try with PulseAudio again next time I play with this. I'd really like to get this working without PulseAudio though. I do think the missing ROCKCHIPSPDIF device might have something to do with all this, so any information you have about its origins would be helpful. Thanks for the input.
  11. Thanks for the information. I have tried PulseAudio but it didn't seem to like my sound card: pavucontrol didn't show any devices it could configure so I couldn't even try setting it up correctly. I'd also like to pass through the two HD audio formats that can't be handled by PulseAudio as described in the linked page. I'm guessing the same underlying reason prevents PA from approaching the device, I just don't know what it is, nor could I figure out any meaningful differences at runtime on the LibreElec images. I have taken the collection of ALSA configuration files of LibreELEC (which seemed to include IEC915 options): asound.conf In the dmesg log I always saw this [ 4.422051] ALSA device list: [ 4.422324] No soundcards found. But that never prevented Kodi from outputting PCM audio. With the aforementioned asound.conf, aplay -l shows this: **** List of PLAYBACK Hardware Devices **** card 0: hdmisound [hdmi-sound], device 0: ff8a0000.i2s-i2s-hifi i2s-hifi-0 [ff8a0000.i2s-i2s-hifi i2s-hifi-0] Subdevices: 0/1 Subdevice #0: subdevice #0 And "alsamixer" shows the device has no controls ("amixer scontrols" gives no output at all).
  12. rubenvb

    Mainline VPU

    Makes sense, and assures me I'm not mixing two incompatible patch sets or something. OK, see below. I compiled kodi-gbm using your git branch and it's running like never before! CPU usage during playback is 20-30% for 1080p and 35-45% for 2160p downscaled to 1080p (probably the audio decoding to PCM takes a big chunk in that, and panfrost maybe the rest?). This percentage does not seem to depend on content (H264 vs HEVC). The HEVC file mentioned above that showed garbled output when using ffmpeg directly to framebuffer, plays back just fine in Kodi proper, so indeed it must be some software pixel format conversion that Kodi does handle fine itself. This is hands down incredibly awesome! If you mean the Jellyfish sample, I didn't notice any artifacts either with FFmpeg directly nor through kodi-gbm (of course both using the "v4l2-request-hwaccel-4.2.2-rkvdec" FFmpeg branch). I think all LibreElec releases (9.2) still use rkmpp and Rockchip kernel 4.4.x. Balbes does bring together LibreElec stuff with the mainline kernel if I'm not mistaken and Kwiboo has moved LibreElec master to kernel 5.x (which I haven't been able to build due to various software packages not building on the LibreElec master branch). Now if I could only get 4k output and audio bitstreaming working I can stop tinkering (I mean, start tinkering on something else ). You guys are all awesome, don't let anyone ever tell you any different!
  13. Hi everyone, I'm trying to get 4k output from my NanoPi M4. I have tried (using a Steamlink HDMI cable) directly connected to my TV (to eliminate my receiver as a point of failure/bugs) to get something to output to the screen in 4k. I haven't succeeded. What information I've gathered so far: There are two "vops" a big and little, and the little one is not designed to, and cannot output 4k (there was a patch hacking that into vopl but I never dared test it and can't find it now). There was this change setting the maximum resolution to 4k in a file/subdirectory I cannot find in recent kernels anymore: https://patchwork.ozlabs.org/project/uboot/patch/20200402114125.2501-6-jagan@amarulasolutions.com/ Any LibreElec/Kodi build (Joern-P, @Kwiboo, @balbes150, @@lex) didn't seem to give me any 4K output options, on kernel 4.4 or 5.x. The EDID returned from my TV contains the 4k modes (but seems to not be able to handle them correctly): Section "Monitor" Identifier "LG TV" ModelName "LG TV" VendorName "GSM" # Monitor Manufactured week 1 of 2015 # EDID version 1.3 # Digital Display DisplaySize 1600 900 Gamma 2.20 Option "DPMS" "false" Horizsync 30-83 VertRefresh 58-62 # Maximum pixel clock is 160MHz #Not giving standard mode: 640x480, 60Hz #Not giving standard mode: 800x600, 60Hz #Not giving standard mode: 1024x768, 60Hz #Not giving standard mode: 1152x864, 60Hz #Not giving standard mode: 1280x1024, 60Hz #Extension block found. Parsing... #WARNING: I may have missed a mode (CEA mode 93) #WARNING: I may have missed a mode (CEA mode 94) #WARNING: I may have missed a mode (CEA mode 95) #WARNING: I may have missed a mode (CEA mode 98) #WARNING: I may have missed a mode (CEA mode 99) #WARNING: I may have missed a mode (CEA mode 100) Modeline "Mode 16" 74.25 1920 2008 2052 2200 540 542 547 562 +hsync +vsync interlace Modeline "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 1" 85.50 1360 1424 1536 1792 768 771 777 795 +hsync +vsync Modeline "Mode 2" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 3" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 4" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync Modeline "Mode 5" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync Modeline "Mode 6" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace Modeline "Mode 7" 74.250 1920 2448 2492 2640 1080 1082 1089 1125 +hsync +vsync interlace Modeline "Mode 8" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 9" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 10" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 11" 74.250 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 12" 74.250 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 13" 74.250 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 14" 27.000 1440 1464 1590 1728 576 578 581 625 -hsync -vsync interlace Modeline "Mode 15" 25.200 640 656 752 800 480 490 492 525 -hsync -vsync Modeline "Mode 17" 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync Option "PreferredMode" "Mode 16" EndSection CEA mode 93-95 and 98-100 are all 4k output modes, see the table listing them on Wikipedia. My question is then, what am I missing and how do I get 4k output from my NanoPi M4? Thanks for any input!
  14. Hi everyone, I have been playing a lot (too much maybe) with my NanoPi M4. It seems that most of what I need will be working "soon" (yay for hardware decoding), except HDMI audio bitstream passthrough. Whatever kernel I try, I always get this output from Kodi: Device 1 m_deviceName : default m_displayName : Default (hdmi-sound ff8a0000.i2s-i2s-hifi i2s-hifi-0) () m_displayNameExtra: m_deviceType : AE_DEVTYPE_PCM m_channels : FL, FR, LFE, UNKNOWN1, FC, BC, BL, BR, BLOC, BROC, FLOC, FROC m_sampleRates : 32000,44100,48000,88200,96000,176400,192000 m_dataFormats : AE_FMT_S24NE4,AE_FMT_S32NE,AE_FMT_S16NE,AE_FMT_S16LE m_streamTypes : No passthrough capabilities And PCM audio works just fine of course, but Kodi shows an empty "Audio Passthrough" section. The most functional OS I have seen for HDMI audio passthrough was Joern-p's custom branches: https://github.com/Joern-P/LibreELEC.tv/releases This gave me functional passthrough for DD and DTS and some of the HD formats (I think it was DTS-HD that worked, but Dolby Atmos gave sharp noise). I tried extracting the changes he applied, and also tried various 4.4 kernels, but none of them seem to be enough to enable the passthrough options. I wonder if I'm looking for this in the wrong place, and this needs to be configured somewhere higher-level (ALSA?) than the kernel. I'm used to everything working out of the box with the right kernel, but I may be spoiled by x86 systems. Does anyone have any idea how to enable HDMI audio passthrough on the NanoPi M4 with Kodi? Thanks!
  15. rubenvb

    Mainline VPU

    The Jellyfish sample decodes at about 58 fps and a reported speed per frame between 1.5-2.0x using this command: ffmpeg -loglevel debug -hwaccel drm -i Jellyfish_1080_10s_30MB.mp4 -pix_fmt bgra -f fbdev /dev/fb0 > log.txt 2>&1 This was with my existing setup: vanilla Linux 5.6.14 with Ezequiel patches for H264 and VP8 decoding and @Kwiboo's "v4l2-request-hwaccel-4.2.2" FFmpeg. The log reports v4l2_request being used as before: https://pastebin.com/U31f22YT CPU usage was 1 core at 100%, which seems to me like there is too much overhead somewhere in the pipeline. Using @Kwiboo's kernel branch, together with the same FFmpeg build as before, I don't seem to get any v4l2_request decoding: https://pastebin.com/MtdcVE6g [...] [h264 @ 0xaaab060f2310] Format drm_prime chosen by get_format(). [h264 @ 0xaaab060f2310] Format drm_prime requires hwaccel initialisation. [h264 @ 0xaaab060f2310] ff_v4l2_request_init: avctx=0xaaab060f2310 hw_device_ctx=0xaaab060ed500 hw_frames_ctx=(nil) [h264 @ 0xaaab060f2310] v4l2_request_probe_media_device: avctx=0xaaab060f2310 ctx=0xffff84098070 path=/dev/media0 driver=hantro-vpu [h264 @ 0xaaab060f2310] v4l2_request_probe_video_device: avctx=0xaaab060f2310 ctx=0xffff84098070 path=/dev/video1 capabilities=69222400 [h264 @ 0xaaab060f2310] v4l2_request_try_format: pixelformat 875967059 not supported for type 10 [h264 @ 0xaaab060f2310] v4l2_request_probe_video_device: try output format failed [h264 @ 0xaaab060f2310] v4l2_request_probe_video_device: avctx=0xaaab060f2310 ctx=0xffff84098070 path=/dev/video2 capabilities=69222400 [h264 @ 0xaaab060f2310] v4l2_request_try_format: pixelformat 875967059 not supported for type 10 [h264 @ 0xaaab060f2310] v4l2_request_probe_video_device: try output format failed [h264 @ 0xaaab060f2310] Failed setup for format drm_prime: hwaccel initialisation returned error. [h264 @ 0xaaab060f2310] Format drm_prime not usable, retrying get_format() without it. [h264 @ 0xaaab060f2310] Format yuv420p chosen by get_format(). [h264 @ 0xaaab060f2310] Reinit context to 1920x1088, pix_fmt: yuv420p [...] So I rebuilt FFmpeg with the "v4l2-request-hwaccel-4.2.2-rkvdec" branch and get pretty much the same output. Inspecting the output of "v4l2-ctl --list-devices", @Kwiboo's kernel doesn't seem to give me the rkvdec device at all, but the hantro devices are present (they are present in the vanilla kernel as well, so that's not unexpected). So I went and applied the patch I used to actually enable the "vdec" node in the device tree (which doesn't seem to be applied by @Kwiboo on his branch). So either he uses device tree overlays to do the same or there is some other magic I'm not seeing. With this patch applied, I get this output from "v4l2-ctl -L -d 3": Codec Controls h264_level 0x00990a67 (menu) : min=0 max=15 default=0 value=0 0: 1 1: 1b 2: 1.1 3: 1.2 4: 1.3 5: 2 6: 2.1 7: 2.2 8: 3 9: 3.1 10: 3.2 11: 4 12: 4.1 13: 4.2 14: 5 15: 5.1 h264_profile 0x00990a6b (menu) : min=0 max=6 default=2 value=2 0: Baseline 1: Constrained Baseline 2: Main 4: High 5: High 10 6: High 422 vp9_profile 0x00990b00 (menu) : min=0 max=0 default=0 value=0 0: 0 hevc_profile 0x00990b67 (menu) : min=0 max=2 default=0 value=0 0: Main 1: Main Still Picture 2: Main 10 hevc_level 0x00990b68 (menu) : min=0 max=8 default=0 value=0 0: 1 1: 2 2: 2.1 3: 3 4: 3.1 5: 4 6: 4.1 7: 5 8: 5.1 h264_sequence_parameter_set 0x00990ce8 (unknown): type=110 flags=has-payload h264_picture_parameter_set 0x00990ce9 (unknown): type=111 flags=has-payload h264_scaling_matrix 0x00990cea (unknown): type=112 flags=has-payload h264_slice_parameters 0x00990ceb (unknown): type=113 flags=has-payload h264_decode_parameters 0x00990cec (unknown): type=114 flags=has-payload h264_decode_mode 0x00990ced (menu) : min=1 max=1 default=1 value=1 1: Frame-Based h264_start_code 0x00990cee (menu) : min=1 max=1 default=1 value=1 1: Annex B Start Code hevc_sequence_parameter_set 0x00990cf0 (unknown): type=120 flags=has-payload hevc_picture_parameter_set 0x00990cf1 (unknown): type=121 flags=has-payload hevc_slice_parameters 0x00990cf2 (unknown): type=122 [16] flags=has-payload hevc_scaling_matrix 0x00990cf3 (unknown): type=123 flags=has-payload hevc_decode_mode 0x00990cf7 (menu) : min=1 max=1 default=1 value=1 1: Frame-Based hevc_start_code 0x00990cf8 (menu) : min=1 max=1 default=1 value=1 1: Annex B Start Code vp9_frame_context_0 0x009918a0 (unknown): type=400 flags=has-payload vp9_frame_context_1 0x009918a1 (unknown): type=400 flags=has-payload vp9_frame_context_2 0x009918a2 (unknown): type=400 flags=has-payload vp9_frame_context_3 0x009918a3 (unknown): type=400 flags=has-payload vp9_frame_decode_parameters 0x009918a4 (unknown): type=404 flags=has-payload Which looks very promising. Indeed, playing back H264 video gives speeds over 1x (I saw 1.64-3.04x in the log). Playing back the only HEVC content I have laying about give me fast playback, but there is something terribly wrong with the colors: I'm guessing this is what @Kwiboo meant with "small artifacts while decoding". I'm not at liberty to share the video file, but this is what the log shows about the stream: Stream #0:0, 73, 1/1000: Video: hevc (Main 10), 1 reference frame, yuv420p10le(tv), 1920x1080, 0/1, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default) Metadata: BPS : 3017706 BPS-eng : 3017706 DURATION : 01:30:01.355000000 DURATION-eng : 01:30:01.355000000 NUMBER_OF_FRAMES: 129503 NUMBER_OF_FRAMES-eng: 129503 NUMBER_OF_BYTES : 2037463275 NUMBER_OF_BYTES-eng: 2037463275 _STATISTICS_WRITING_APP: mkvmerge v20.0.0 ('I Am The Sun') 64-bit _STATISTICS_WRITING_APP-eng: mkvmerge v20.0.0 ('I Am The Sun') 64-bit _STATISTICS_WRITING_DATE_UTC: 2020-03-07 04:20:25 _STATISTICS_WRITING_DATE_UTC-eng: 2020-03-07 04:20:25 _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES Stream #0:0, 73, 1/1000: Video: hevc (Main 10), 1 reference frame, yuv420p10le(tv), 1920x1080, 0/1, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default) Metadata: BPS : 3017706 BPS-eng : 3017706 DURATION : 01:30:01.355000000 DURATION-eng : 01:30:01.355000000 NUMBER_OF_FRAMES: 129503 NUMBER_OF_FRAMES-eng: 129503 NUMBER_OF_BYTES : 2037463275 NUMBER_OF_BYTES-eng: 2037463275 _STATISTICS_WRITING_APP: mkvmerge v20.0.0 ('I Am The Sun') 64-bit _STATISTICS_WRITING_APP-eng: mkvmerge v20.0.0 ('I Am The Sun') 64-bit _STATISTICS_WRITING_DATE_UTC: 2020-03-07 04:20:25 _STATISTICS_WRITING_DATE_UTC-eng: 2020-03-07 04:20:25 _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES All in all great progress :). Will linking Kodi with this FFmpeg make it automagically work or is there something else I would need to do to make this work? I mostly have plain H264 content and that seems to work great already.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines