Michael, > Therefore, you can't use the VCU control software or any of the related GStreamer elements, but you should use a user space that handles V4L2 mem2mem devices. For example, you may > use the v4l2videoenc elements (they show up as v4l2h264enc/v4l2h265enc in the running system), which are part of gst-plugins-good. It all makes sense, and we now get the whole picture.This is very very cool, we will get rid of Xilinx's gstream fork and rely on the official v4l2h264enc. I confirm we have a new video entry that I did not spot, which is the Allegro DVT. Now we need to learn how to operate the new pluggin. Unfortunately, it turns out to be one of the few not documented in gstreamer.. Thanks so much for your help. I will keep you updated with our results. We will then get more familiar with allegro dvt and may submit patches in the future, if some of our requirements are not fulfilled. Anyways, these a great steps taken towards more software stability -----Message d'origine----- De : Michael Tretter <m.tretter@xxxxxxxxxxxxxx> Envoyé : mercredi 10 avril 2024 09:36 À : BRES, Guillaume <guillaume.bres@bertin.group> Cc : kernel@xxxxxxxxxxxxxx; linux-media@xxxxxxxxxxxxxxx; ORIOT DE LA CHAPELLE, DAVID <david.oriot@bertin.group>; DUMAS, Victor <victor.dumas@bertin.group> Objet : Re: Allegro/VCU on Zynq-MP 2023+ [WARNING] This message comes from an external organization. Be careful of embedded links and attached files. On Wed, 10 Apr 2024 06:46:09 +0000, BRES, Guillaume wrote: [...] > I can confirm that your driver is probed successfully, and so is > xlnx-vcu. Unfortunately the /dev/allegroIP entry point is not > created, therefore gstreamer has no means to operate this part. > > Is your driver supposed to create a /dev/allegroIP entry point like > the previous out-of-tree solution? Would you have ideas what we might > be missing (probably v4l related) that would cause the /dev entry not > to appear, while everything seems sane at the kernel level ? /dev/allegroIP is not a standard Linux API. The upstream driver creates a V4L2 device node as /dev/videoX. Therefore, you can't use the VCU control software or any of the related GStreamer elements, but you should use a user space that handles V4L2 mem2mem devices. For example, you may use the v4l2videoenc elements (they show up as v4l2h264enc/v4l2h265enc in the running system), which are part of gst-plugins-good. > > > This node doesn't follow the documented binding. There should be > > only two clocks and no interrupt. > > Is it clk/xlnx-vcu that we are talking about here? Yes, that's the related driver. Michael > > The driver is able to do h.264 and h.265 encoding with a few options > > for quality and rate control. In contrast to the downstream driver, > > it exposes a standard V4L2 video encoder interface to userspace. > > Which features do you need? I'm very open to review and test patches > > that add more features to improve and extend the upstream driver. > > I'm not advanced enough to correctly answer that question at the > moment. All I can say, is our first goal is to compress SDI-HD/SDI3G > standard formats, and our ultimate goal, once we master the VCU, would > be to compress slightly off standard formats, Like a couple of lines > or columns truncated. IMO this is feasible considering the VCU is said > to work on multiple of 4 pixels, it is not particularly limited to > standard formats. I presume we will tweak gstreamer to do that. Yet > we're not able to achieve step 1 and I personally have no clue how far > we are from that >
