usual user
-
Posts
543 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by usual user
-
-
2 hours ago, iamdrq said:
so maybe gnome has some problem
I don't know if you run Gnome with Xwindow or Wayland backend
2 hours ago, iamdrq said:what is your desktop ?
With Xwindow backend I am running LXQt and with Wayland backend I use Plasma.
2 hours ago, iamdrq said:on the other hand, don't need disable rockchip-vpu node, gstreamer auto choose rkvdec when rockchip-vpu fail
This are the video resources my current kernel exposes: videoX-infos.txt Of course, HEVC support is missing because the LE patch cannot be applied.
-
6 hours ago, iamdrq said:
Could you test this glimagesink ?
As expected, no valid video-pipeline.pdf is created.
[plasma@trial-01 video]$ gst-play-1.0 --use-playbin3 --videosink="glimagesink" demo320x240.mp4.149ba2bb88584b89814a1c41b5feef77.mp4 Press 'k' to see a list of keyboard shortcuts. Now playing /home/plasma/workbench/video/demo320x240.mp4.149ba2bb88584b89814a1c41b5feef77.mp4 ERROR Driver did not report framing and start code method. for file:///home/plasma/workbench/video/demo320x240.mp4.149ba2bb88584b89814a1c41b5feef77.mp4 ERROR debug information: ../sys/v4l2codecs/gstv4l2codech264dec.c(212): gst_v4l2_codec_h264_dec_open (): /GstPlayBin3:playbin/GstURIDecodeBin3:uridecodebin3-0/GstDecodebin3:decodebin3-0/v4l2slh264dec:v4l2slh264dec0: gst_v4l2_decoder_get_controls() failed: Invalid argument Reached end of play list.Useing a mem to mem 3D accellerator in arm world with Wayland environment in a video-pipeline is a bad idea.
-
Plays flawless for me with this video-pipeline.pdf.
-
7 hours ago, jernej said:
Copy hevc-ctrl.h from patched kernel sources to ffmpeg sources (replace existing file) and rebuild ffmpeg.
hevc-ctrl.h does not exist, but hevc-ctrls.h are identical:
--- hevc-ctrls.h-kernel 2021-09-08 20:51:20.802970171 +0200 +++ hevc-ctrls.h-ffmpeg 2021-10-11 23:43:54.894127584 +0200 @@ -210,7 +210,7 @@ struct v4l2_ctrl_hevc_slice_params { __u16 short_term_ref_pic_set_size; __u16 long_term_ref_pic_set_size; - + __u32 num_entry_point_offsets; __u32 entry_point_offset_minus1[256]; __u8 padding[8]; -
2 hours ago, jernej said:
Note that final VP9 API, which landed in media repo, is slightly different than before and new ffmpeg patches will be needed.
I already use these patches since I build 5.15.0.
I switched to 5.17.0 preview to see what's currently missing when it comes out. AFAIS I have only to wait for a rebase of "Draft: v4l2codecs: Implement VP9 v4l2 decoder" for gstreamer and LE 0000-linux-2001-v4l-wip-rkvdec-hevc.patch for kernel to have all the basics for further experiments in place.
For now only mpv works to some extend. -
VP9 support has just landed in media staging, i.e. is in flight for 5.17.0. I moved to 5.16.0-rc2 with media staging patches applied. LE 0000-linux-0011-v4l2-from-list.patch and 0000-linux-1001-v4l2-rockchip.patch where also applied after resolving small merge conflicts or dropping already applied commits. 0000-linux-2001-v4l-wip-rkvdec-hevc.patch can no longer be applied, I will wait patiently until LE rebases. I'm not even sure if hevc works at all, because with 5.15.0 and the patch, mpv does not pick drm-copy as it does like for VP9.
Spoiler
-
1 hour ago, franco said:
how should I do the cups setting.
If I read the specification of the MFC-L2710DW correctly, it supports IPP (AirPrint). Therefore, IPP Everywhere is what to look for.
-
-
On 10/25/2021 at 11:12 PM, flagtrax said:
Brother HL-L3230CDW network printer. While there are Linux drivers, I could find none for ARM processors. Does anyone have any idea as to a solution.
If I read the specification of the HL-L3230CDW correctly, it supports IPP (AirPrint). Therefore, IPP Everywhere is what to look for.
-
Looks like the existing boot firmware on the emmc, for whatever reason, does not tolerate a valid MSDOS MBR on the emmc. If this is still valid, you can certainly replace the existing firmware with a suitable one, but since a functioning solution has already been worked out, it is certainly easier to use it.
-
1 hour ago, pista said:
I only inserted the 72 bytes at the end of the 1st block
AFAIS you have inserted a populated partition table. Maybe the boot firmware now changes the boot flow according these values. To confirm that the presence of an MSDOS MBR already triggers it, just add the boot signature "55AA" to the last two bytes of the sector.
If booting still does not work with an otherwise empty partition table, no MSDOS MBR can be used unless the existing boot firmware is also adapted. -
The first 440 bytes of the MBR are used for bootstrap executable code.
The partition management relevant data starts at 0x01B8 and lasts till 0x01FF.
Spoiler
Tools that create MSDOS master boot records usually insert code into the bootstap code area that is suitable for PC BIOS use, i.e. useless for Arm systems. Regardless of what you put in the first 440 bytes of the MBR, you still have a valid MBR with partition table entries. Only the last 72 bytes of the first sector have to be maintained therefor.
-
I am running at an entire different user space. But this doesn' t matter. Also the exact kernel version doesn' t matter. The only thing that is really important is that the elements that are needed by the hardware are also built. dmesg tells you which components are used. Looking at kernel config does only tell wich modules are build, but not if they are realy used. E.g. my kernel is built with a large number of modules. With the help of initramfs it is suitable for all devices with aarch64 architecture. When the kernel is booting it will either probe the hardware or know via devicetree wich modules are required. The customizieing I am aplying is to pull display support and everything to mount the rootfs as build-in. This way I have early display support and I can run without initramfs. Everything else will be loaded later as module.
In order to learn which components are needed, it is very helpful to have a dmesg from a running system. -
I run my NanoPC-T4 as a fully flagged desktop with all the bells and whistles. I have uploaded my dmesg so you have a reference what messages to expect. More components, not called HDMI, are required for display support.
27 minutes ago, JohnG said:The part I found about skipping the drm
This is user space that tries to load kernel modules and expected when the modules are built in or already loaded by the kernel.
-
1 hour ago, SteeMan said:
As for the kernel boot command line, I have never needed to change anything on that line so I don't have any clue on where to get more information.
1 hour ago, SteeMan said:Understand how the extlinux.conf file plays into the boot process
https://source.denx.de/u-boot/u-boot/-/blob/master/doc/README.distro
-
25 minutes ago, RetroFan90 said:
i'd like to test the new version and see if it is any better the last build
Then why not start, @jock has announced new versions and the links on the first page are already up?
-
On 9/22/2021 at 4:59 PM, AlwinLub said:
Kivy does not play nice with this version of Mesa (20.3.5).
I don't know what requirements Kivy places on the graphics stack, but since Panfrost achieves OpenGL ES 3.1 conformance on Mali-G52, it certainly makes sense to read this to understand what to expect from a lima-driven GPU. I still remember very well times when my GPU only reached almost 2.0 and the performance was quite moderate. With now 3.1 it's a big difference for daily desktop use, although my GPU isn't yet declared fully compliant. But since this is bleeding edge development, at least the current mesa mainline release is required in any case. If not even the main branch to use just implemented extentions. Kernel driver wise everything necessary should already be available and therefor mesa is where you are looking for GPU support improvements.
-
On 9/15/2021 at 10:39 PM, jernej said:
You'll wait for more than a month.
Thank you for sharing the schedule. But no hurry, my daily use cases are already working anyway. I'm only doing this for my own education and as a preview of maybe landing features in Mainline.
On 9/15/2021 at 10:50 PM, jock said:Also on my tests drm-copy is consuming more cpu power.
For me, it's the other way around. hwdec=drm yield high CPU utilisation for bbb_sunflower_2160p_30fps_normal.mp4 and hwdec=drm-copy yield low CPU utilisation.
As the values are fluctuating heavyly it is difficult to provide absolut numbers.But anyway here are some rough values:
bbb_sunflower_1080p_30fps_normal.mp4: gst-play-1.0 ~35% mpv --hwdec=none --hwdec-codecs=all ~40% mpv --hwdec=drm --hwdec-codecs=all ~38% mpv --hwdec=drm-copy --hwdec-codecs=all ~28% bbb_sunflower_2160p_30fps_normal.mp4: gst-play-1.0 ~35% mpv --hwdec=none --hwdec-codecs=all ~98% playing slow, sound out of sync mpv --hwdec=drm --hwdec-codecs=all ~98% playing jerky, sound out of sync mpv --hwdec=drm-copy --hwdec-codecs=all ~34% playing slow, sound out of syncThis is on plasma desktop with wayland backend. Desktop CPU usage fluctuates around 8 to 15% without playing a video, so it's uncertain which CPU cycles are really associated with video playback. The utilization is always distributed almost evenly over all cores. Frequency scaling is not considered here.
On 9/15/2021 at 10:50 PM, jock said:I didn't try gstreamer yet, but is it working smooth for you in X11 window?
For reference here the values for lxqt desktop with native xorg backend:
bbb_sunflower_1080p_30fps_normal.mp4: gst-play-1.0 ~25% mpv --hwdec=none --hwdec-codecs=all ~30% mpv --hwdec=drm --hwdec-codecs=all ~28% mpv --hwdec=drm-copy --hwdec-codecs=all ~18% bbb_sunflower_2160p_30fps_normal.mp4: gst-play-1.0 ~18% paying as diashow mpv --hwdec=none --hwdec-codecs=all ~98% playing slow, sound out of sync mpv --hwdec=drm --hwdec-codecs=all ~98% playing jerky, sound out of sync mpv --hwdec=drm-copy --hwdec-codecs=all ~22% playing slow, sound out of syncConlusion:
The VPU decoder is not the bottleneck, but setting up an efifcient video pipeline with proper interaction of the several involved hardware acellerators. For Xwindow with the modeset driver this seems not realy possible. -
1 hour ago, jock said:
If you're interested I can point the repository to you when I'm done.
Thank you for the offer @jock.
But 5.14.0 wise I had all VPU relevant LE patches and even the drm ones applied.
With gstreamer framework it is working, even for bbb_sunflower_2160p_30fps_normal.mp4 without any problem. It is mpv that seems not be able to cope with the hight data rate. Useing --hwdec=drm-copy makes the CPU utilization ramp up go away and the video plays smoothly, but to slow and the sound get out of sync. I don't think I am missing anything kernel wise.
Just tried to drop 2000-v4l-wip-rkvdec-vp9 in favour of this more recent patchset.Resolving a merge conflict to apply the LE patches on top was easy:
Spoiler--- linux-0011-v4l2-from-list.patch.orig<------>2021-09-08 20:04:26.000000000 +0200 +++ linux-0011-v4l2-from-list.patch<--->2021-09-15 19:00:00.000000000 +0200 @@ -756,9 +756,9 @@ index d31344c4acaa..d068383aeea8 100644 <----><------><------>return -EINVAL; .. <----><------>if (ctx->valid_fmt && ctx->valid_fmt != rkvdec_valid_fmt(ctx, ctrl)) -@@ -155,6 +151,9 @@ static const struct rkvdec_ctrls rkvdec_h264_ctrls = { +@@ -101,6 +151,9 @@ static const struct rkvdec_ctrls rkvdec_ .. - static const u32 rkvdec_h264_decoded_fmts[] = { + static const u32 rkvdec_h264_vp9_decoded_fmts[] = { <---->V4L2_PIX_FMT_NV12, +<---->V4L2_PIX_FMT_NV15, +<---->V4L2_PIX_FMT_NV16,But the kernel build drops out with this:
Spoilerdrivers/staging/media/hantro/imx8m_vpu_hw.c:145:27: error: ‘V4L2_PIX_FMT_NV12_4L4’ undeclared here (not in a function); did you mean ‘V4L2_PIX_FMT_NV12M’? 145 | .fourcc = V4L2_PIX_FMT_NV12_4L4, | ^~~~~~~~~~~~~~~~~~~~~ | V4L2_PIX_FMT_NV12MSo I will stay at the status quo of LE patches on 5.15.0-rc1 for now and wait till they rebase.
VPU wise everything from LE is in place and seems to work. -
On 9/11/2021 at 11:25 AM, usual user said:
Let's see what explodes when 5.15.0-rc1 is available next week.
Moved on to 5.15.0-rc1. But applying the LE patches makes the kernel unbootable for rockchip. I had now omitted 2001 also, as it no longer applies cleanly, and of course the cherry-picking 0010, which have landed.
Guess I have to take a closer look at which patches are really important to me and see if they are the cause.With only linux-0011-v4l2-from-list, linux-1001-v4l2-rockchip and 2000-v4l-wip-rkvdec-vp9 applied the kernel keeps working.
Although the drm patches seem interesting, I'll leave them out for now.
-
11 hours ago, jernej said:
Current master branch of gst-plugins-bad (what will land in next stable release) should already work pretty well with all stable codecs (MPEG2, H264 and VP8).
I'm currently at gstreamer1-1.19.1, which works for my daily use cases flawless with the distribution package. But as soon as a deficiency should show up, it would be no big deal for me to rebuild with current master or pull in in-flight patches. But till then I will let the improvements trickle in via the regular updates.
Out of curiosity, I just started two instances of gst-play-1.0 with different videos at the same time, and both videos play flawlessly at the same time. OK, the mixed sound is a bit confusing.
-
Thank you @jernej for your detailed background information.
3 hours ago, jernej said:AFAIK ffplay doesn't use HW acceleration. At least I never managed to force it. That's why I gave ffmpeg based test command. I can't help you with mpv...
In the past I didn't care much about ffmpeg driven video pipelines. I made several attempts, but because of the sparse documentation and not even the basic support in mainline, I gave up pretty quickly. I do this out of curiosity and for early use of future maninline support.
So as long as I can't find information on how to use it in daily use cases, I'll ignore it again. At least I have now some kernel patches that benefit gstreamer framework that I can track till they land in mainline. -
Thank you @jock for your detailed explanation. Since I use a different distribution, your instructions don't apply to my environment, but I know how to do it for myself. I just need to know what to do and @jernej has already pointed this out (needed patches and build requirements).
22 hours ago, jock said:One thing that always makes me have headaches are the userland kernel headers, which are not the same kernel headers used to compile modules
I haven't considered this aspect so far, as it hasn't been mentioned that LE patched headers are required. I just applied all the LE kernel patches and just omitted obviously not necessary ones. Because ffmpeg build flawless with the native headers, I moved on. I have installed round about twenty kernels at the same time and it will be decided at boot which one to use. Therefore, I only move in new headers when necessary.
gst-play-1.0, ffplay and mpv now play bbb_sunflower_1080p_30fps_normal.mp4 with similar achievement. For gst-play-1.0 I know how to visualize the composed video pipeline. And due to the v4l2slh264dec (V4L2 Stateless H.264 Video Decoder) component in gst-play-pipiline.pdf I know for sure that hardware acceleration is used. So I guess the ffmpeg video pipeline is also using hardware acceleration.
gst-play-1.0 plays bbb_sunflower_2160p_30fps_normal.mp4 with same CPU utilization.
For ffplay and mpv CPU utilization ramps up significantly and frame drops are reported. The video also plays jerky. I can't say which components of the ffmpeg video pipeline is the limiting factor here.
Because the kernel patches also benefit the gstreamer framework, I will probably continue to use them. Let's see what explodes when 5.15.0-rc1 is available next week.
-
My kernel has now 0010, 0011, 0020, 1000, 1001, 2000 and 2001 LE patch applied.
I don't see any significant change in behavior, so I can't say if the ffmpeg-driven video pipeline realy uses hardware acceleration.The mpv command of @kprasadvnsi is playing for me. In the mpv.log the Codec list mentions, "h264_v4l2m2m (h264) - V4L2 mem2mem H.264 decoder wrapper", but I don't know if this is used. Neither I don't know how to select which decoder (hantro, rkvdec) will be used, it's the first time I use mpv.
Mainline VPU
in Rockchip
Posted
This one is playing: video-pipeline.pdf