Re: Allegro/VCU on Zynq-MP 2023+

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> 




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux