<div dir="ltr"><div>See answers inline.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 17, 2021 at 12:19 PM niXman via gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hello Maersk-Moller!<br>
<br>
On 2021-07-16 15:28, Peter Maersk-Moller via gstreamer-devel wrote:<br>
> Well I can't see how you full system is put together, but I can see <br>
> than<br>
> one of the link you send is using CSI used to take in a camera feed<br>
> somewhat raw. And the other link lists it supports the following <br>
> formats:<br>
> <br>
>    -<br>
> <br>
>    support for output formats: *RAW RGB, RGB565/555/444, CCIR656,<br>
>    YUV422/420, YCbCr422*, and compression<br>
<br>
please tell me which page?<br></blockquote><div><br></div><div>Page 3: support for output formats: RAW RGB, RGB565/555/444, CCIR656, YUV422/420, YCbCr422, and compression</div><div>Page 4: output formats: 8-/10-bit RGB RAW output</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
and can you answer my previous question please?:<br>
if the camera actually sends uncompressed YUV, then each frame must be <br>
5MP * 12 = 60Mbit per frame? really?<br></blockquote><div><br></div><div>Where do you get this idea from. Geometry is 1280x800 and bytes per pixel for YUYV/YUY2/Y42B is 2.<br></div><div><br></div><div>1280x800x2 = 2048000 B/frame = 16384000 b/frame where B=byte, b=bits, <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
is there a way how i can save only one YUV frame without any processing? <br>
I just want to make sure.<br></blockquote><div><br></div><div>One way is listed below. Otherways is to use multifilesink of Gstreamer etc.</div><div><br></div><div>gst-launch-1.0 -e -v \<br>
     v4l2src device=/dev/video0 ! \<br>
     video/x-raw,format=Y42B,width=1280,height=800,framerate=10/1 ! \<br></div><div>     fdsink fd=3 3>&1 1>&2 | od  of=MyFile.yuv bs=16384000 count=1</div><div><br></div><div>Note that it is a raw format with no container and no meta data. just raw YUV in the Y42B format. You can pick others formats as well. If you want to have a container format like AVI or MP4 you need to use a muxer module in GStreamer, but then you need another method to chop up data.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Plenty of support for raw formats. Furthermore your output from <br>
> GStreamer<br>
> suggests your output (source of v4l2src) outputs YUY2. So the v4l2src<br>
> modules gets data and outputs raw video in the format YUY2. This is <br>
> similar<br>
> in quality to a Y422 og Y42B. This is better than I420 as it has twice <br>
> as<br>
> many bytes for colour information. While I420 is often for consumer<br>
> products, your format is what is usually used for Prosumer. A <br>
> compromise<br>
> between  cosumer and professionel level. This is good so what is the<br>
> problem? Why do you think you have a problem?<br>
> <br>
> That said, apparently the video encoder wants a nv12  comparable to <br>
> I420<br>
> (consumer level). Videoconvert converts and encodes the result. If you <br>
> want<br>
> better result, check if the encoder can support higher quality inputs. <br>
> But<br>
> that's outside the scope of your question. Fact is, you are not using<br>
> JPEG/MJPEG and that is often a good thing depending oin what you want. <br>
> So<br>
> what is the problem?<br>
<br>
long story in short:<br>
for my drone I bought a SOM based on Snapdragon 660 with Debian.<br>
according to the manufacturer this SOM has an h264 hardware encoder.<br>
I connected and configured this camera: [1]<br>
everything works, the load on the CPU is ~30%.<br>
after that I wanted to add a thermal camera.<br>
I chose this camera: [2]<br>
<br>
work with the camera is done through the SDK. I wrote an encoder program <br>
that reads 320x240 frames in ARGB from the camera, converts them to <br>
YUV422 and uses libx264 for encoding.<br>
<br>
I tested this program on a rather weak Intel processor N3710 and the <br>
program consumed ~30%.<br>
but when I ran this program on the SOM I realized that the program could <br>
not cope even with encoding five frames per second!<br></blockquote><div><br></div><div>Most Arm processors have a really weak software encoding performance compared to Intel platforms.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
after that I started a long and tedious communication with the support.<br>
the support convinces me that the hardware encoder is available only for <br>
cameras supported by v4l2 subsystem.<br>
<br>
in addition, in the SOM specification I do not see any separate <br>
chip/module that would be a hardware encoder.<br></blockquote><div><br></div><div>Are you trying to encode two separate streams or are you wanting to mix to streams into one stream and encode that?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
the SOM has GPU and DSP. in theory, the most resource-demanding part of <br>
the encoder (working with matrices) can be implemented both on the GPU <br>
and on the DSP.<br>
but all my requests for information about the encoder and the API that I <br>
can use are simply ignored.<br>
they give the only answer: your camera is not supported by v4l2 <br>
subsystem.<br></blockquote><div><br></div><div>I don't know your system. Assuming it is Linux, how much of the kernel can you compile/modify?</div><div>I don't understand your challenges as I don't know your limitations. If you can read images from a camera into a Linux compuer, you can always loop it using a V4L2 loopback interfacew making it into a V4L2 device. But usually normal camera using USB is available through V4L2 interfaces natively?<br></div><div>Linux V4L2 has a loopback interface where you can loo<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
this is what brought me here :)<br>
I don't understand how the hardware encoder can only be accessed by <br>
devices supported by the v4l2 subsystem ?!<br></blockquote><div><br></div><div>Well if you have documentation and a working compiler, you can do anything you brain can think of. That said and assuming your initial pipeline works - I don't think you answered if it does, then I am guessing you get access to the systems hardware encoder using the v4l2h264enc module of GStreamer. If that is true, then what they are telling you is that to use the hardware encode, you must use the V4L2 subsystem. And you are. You are using the GStreamer V4L2 encoder module called v4l2h264enc. It does not mean that you have to use a camera that uses V4L2, although in many cases you will. Do you understand the difference? You apparently have to use the V4L2 subsystem to access the hardware encoder and send raw video data to it and retrieve encoded video from it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
and I don't understand why SOM can cope with encoding 5 and 8 megapixel <br>
frames but can't cope with 320x240 encoding?<br></blockquote><div><br></div><div>It can .... well there maybe some limitations of choices of geometries, but asides from that, it can.</div><div><br></div><div>What are you trying that works (pipeline examples) and what doesn't work (pipeline examples)?</div><div><br></div><div>  <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
and I thought that other cameras were just sends compressed frames. <br>
(JPEG / MJPG)<br>
in this I want to understand and make sure.<br></blockquote><div><br></div><div>Many cameras can, including one of the camera you listed. But in the case of you original pipeline, you are not using JPEG, which is good.</div><div><br></div><div>P<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
thank you!<br>
<br>
best!<br>
<br>
<br>
[1] <br>
<a href="https://www.arducam.com/product/b0196arducam-8mp-1080p-usb-camera-module-1-4-cmos-imx219-mini-uvc-usb2-0-webcam-board-with-1-64ft-0-5m-usb-cable-for-windows-linux-android-and-mac-os/" rel="noreferrer" target="_blank">https://www.arducam.com/product/b0196arducam-8mp-1080p-usb-camera-module-1-4-cmos-imx219-mini-uvc-usb2-0-webcam-board-with-1-64ft-0-5m-usb-cable-for-windows-linux-android-and-mac-os/</a><br>
<br>
[2] <br>
<a href="https://www.digikey.com/en/products/detail/seek-thermal/S314SPX/13573823" rel="noreferrer" target="_blank">https://www.digikey.com/en/products/detail/seek-thermal/S314SPX/13573823</a><br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div></div>