v4l2 video encoder
Locked
 
|
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? Regards, Bing _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Le mer. 24 févr. 2021 04 h 45, Bing Song <[hidden email]> a écrit :
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.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Can you share patch to me to test it on our platform. Regards, Bing From: gstreamer-devel <[hidden email]>
On Behalf Of Nicolas Dufresne Caution: EXT Email
Le mer. 24 févr. 2021 04 h 45, Bing Song <[hidden email]> a écrit :
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.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: [EXT] Re: v4l2 video encoder
|
|
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 <[hidden email]>On Behalf > Of Nicolas Dufresne > Sent: 2021年2月24日 21:02 > To: Discussion of the development of and with GStreamer < > [hidden email]> > Subject: [EXT] Re: v4l2 video encoder > > Caution: EXT Email > > Le mer. 24 févr. 2021 04 h 45, Bing Song <[hidden email]> 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 > > [hidden email] > > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
| Free forum by Nabble | Edit this page |