<div dir="ltr"><div>Hi niXman</div><div><br></div><div>You are in fact not retrieving JPEG encoded frames from your camera. Apparently your camera also supports a raw video format.</div><div><br></div><div>Most likely this raw format is some sort of YUV format. You can find out by adding '-v' to gst-launch-1.0 and look for the format accepted by the videoconvert sink pad.</div><div>There are tools to list your camera's capabilities (V4L2 tool) and Google is your friend. Getting the right pixel format can be a path to better quality.</div><div><br></div><div>In many cases, if cameras supports raw pixels formats, you will for quality select a raw format. JPEG will introduce artifacts that are mostly unwanted. You will use JPEG in cases where the desired picture geometry and framerate for a given raw format, exceeds the communications channel by which the computer and camera communicates (often USB with a maximum 480Mbps - in reality lower).</div><div><br></div><div>So to answer your question, your pipeline (most likely) converts from one YUV format (o not at all) to (most likely) I420 (a consumer YUV raw format) accepted by the encoder. Your encoder encodes H.264 video streams, most likely using the Baseline profile, but the '-v' mentioned earlier. To get your encoder to select a high profile .... such as 'High Profile" or just "Main profile", you have to set format/parameters between your encoder and your parser. If you want to encode using higher quality input, assuming your camera supports better raw formats than I420 or NV12 and assuming your v4l2h264encoder supports better input formats than I420, you can force before the encoder a format like Y444 or Y42B (Y422) . Your choice.</div><div><br></div><div>So no JPEG and you're encoding (probably baseline) H.264.</div><div><br></div><div>One tip though. Often a queue between input source and videoconvert is a good thing. Also a queue between videoconvert and encoder is often a good thing. And lastly, a queue between encoder and additional processing such as parsing and file or network operation is often a good thing. So is a queue on input to a muxer, if you are muxing audio and video together (here your are not).</div><div><br></div><div>Best regards</div><div>Peter Maersk-Moller<br></div><div><br></div><div><br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 16, 2021 at 10:43 AM 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!<br>
<br>
I am using a camera that is supported by the v4l2 subsystem. This camera <br>
uses the Omnivision OV5640 chip, which according to the documentation <br>
encodes frames in JPEG format.<br>
<br>
To be able to save the stream from this camera the following pipeline is <br>
offered:<br>
<br>
gst-launch-1.0 -e \<br>
     v4l2src device=/dev/video0 \<br>
     ! video/x-raw,width=1280,height=800,framerate=10/1 \<br>
     ! videoconvert \<br>
     ! v4l2h264enc \<br>
     ! h264parse \<br>
     ! mp4mux \<br>
     ! filesink location=/home/linaro/video.mp4<br>
<br>
my question is that since the camera is gives encoded frames, what kind <br>
of encoding does this pipeline perform?<br>
v4l2h264enc is especially interested.<br>
<br>
<br>
best!<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>