[EXT] Re: v4l2 video encoder

[Nicolas Dufresne]

Hi Bing,

Le jeudi 25 février 2021 à 02:55 +0000, Bing Song a écrit :
> Can you share patch to me to test it on our platform.

My WIP branches:
https://gitlab.freedesktop.org/ndufresne/gst-plugins-good/-/tree/master-v4l2videoenc-import
https://gitlab.freedesktop.org/ndufresne/gst-plugins-good/-/tree/1.18-v4l2videoenc-import

The coloromitry seems to get in the way, I just hacked it out for now, but I
need to find a cleaner solution. The problem is that we try and expose the
colorimetry so that videoconvert (and similar element) can fix the colors in
case of miss-match, but it takes several thousands ioctl calls to do so with
V4L2. I think I'll probably change strategy and go with a best match approach.
It will then be considered driver/hw problem if there is a combination that is
not well supported. We can alway maintain a warning when the colorimetry setting
on the V4L2 node wasn't a great match. Or send a reconfigure event, and fixate
our caps for the time being.

In practice, no one really want a fallback to videoconvert to fix colors, many
use cases would simply not work (too slow). If this becomes a real problem, the
kernel folks should add a proper API.

>  
> Regards,
> Bing
>  
> From: gstreamer-devel <gstreamer-devel-bounces at lists.freedesktop.org>On Behalf
> Of Nicolas Dufresne
> Sent: 2021年2月24日 21:02
> To: Discussion of the development of and with GStreamer <
> gstreamer-devel at lists.freedesktop.org>
> Subject: [EXT] Re: v4l2 video encoder
>  
> Caution: EXT Email
>  
> Le mer. 24 févr. 2021 04 h 45, Bing Song <bing.song at nxp.com> a écrit :
> > Hi,
> >  
> > Gst-transcoding will use v4l2videodec and v4l2videoenc. The default of
> > v4l2videoenc input is MMAP mode. It cause video frame copy in v4l2videoenc
> > input. How to avoid the video frame buffer copy?
>  
> This needs to be fixed inside v4l2videoenc class. Currently the import is not
> using the new try_import calls, so it is unsafe as it does not communicate
> padding and strides to the driver. I have a partial solution to this that I
> made last week, I need to cleanup and make an MR.
>  
> Now, it's partial as it only validate the very first buffer, it should keep
> validating in case something changes.
>  
> The next Todo before actually making it try to import by default is to figure
> out how we will handle copy fallback. We could reset the encoder and
> reallocate, but this method would not be reversible, and would produce a
> spurious keyframe (meaning the gops might not always be as requested). We need
> to decide if that would be good enough, in real app, we do hope we will not
> have to fallback. The alternative would be to have scratch buffers on the side
> as backup buffers, but the would use a big chunk of memory.
>  
> Meanwhile, one can always track the encoder being added to the pipeline (deep-
> element-added signal, or state transition message) and set the output-io-mode
> to dmabuf-import mode, and hope that buffers are properly aligned.
>  
> >  
> > Regards,
> > Bing
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel