<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 16 sept. 2023, 08 h 30, Dwight Kulkarni <<a href="mailto:dwight@realtime-7.com">dwight@realtime-7.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Nicolas,</div><div dir="ltr"><br></div><div>The application is just the command line gst-launch-1.0 with pipeline of v4l2src ----> autovideosink. The earlier log files that we shared had some other pipeline elements also launched via gst-launch-1.0 at the command line which we can be removed because problem is originating at v4l2src.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Then you can ignore the position query failure, this is not a bug. It may be a sign that your driver is taking more time then average producing a signal when things falls apart. If it ever produce an image.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>We have written a custom driver for the camera board. As these are gstreamer messages they would be downstream from the driver. </div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>There is a 4 lane MIPI signal and clock coming out of the camera sensor, which is then processed by the driver.</div><div><br></div><div>There are actually 2 hardware components which is the CPU board and the camera board. If we change for example one CPU board with the same camera board, it will give a different result running the identical clone of the operating system.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">So if you change the HW, the unmodified software changes behavior. In debugging logic, this would point to a hardware issue (or wrong programming of it).</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>However, from same CPU board to camera board there is a statistical similarilty. For example, if one camera board works 7/10 times, it is consistently working 7/10 times if we try again another 10 times.</div><div><br></div><div>Another observation is that once the stream starts working, it stays working, and if it fails, it will stay failed.</div><div><br></div><div>This seems to indicate some issue during initialization or negotiation. One possibility is that there is maybe an unhandled exception or some data, and this occurs with some frequency during the stream startup but on some boards not all. Another possibility is there is clock or signal data that is barely within the operating parameters and during boot up some of the time it is outside those constraints, when the application or the driver is trying to sample the clock maybe it is not finding it in those cases ?</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>We had earlier found that our input clock was at 1.2 Volt logic level not 1.8 Volt, so this can cause a problem maybe in triggering the sensor, sometimes suble variations in the peaks could be triggering it and other times not. We then tried two hardware changes one with external oscillator at 1.8 volt and one drawing CPU clock boosted to 1.8 volt and it didn't make any difference.</div><div><br></div><div>However, we haven't yet ruled out the output clock coming from the camera board, or something going wrong in the driver, or downstream from the driver in gstreamer.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Understand that all the setup of clock frequency and line voltage is controlled by your V4L2 driver. GStreamer is a userspace application, all it does is ask through v4l2 interface for frames. I think you are reporting your issue to the wrong project. Yet, it's also hard to conclude considering how high level the information is. My recommandation is for you to start tracing from your driver, through v4l2 framework (there is sysfs API to enable these trace, and then keep tracking data through GStreamer with GST_DEBUG="v4l*:7,2". Sets your expectations, verify the behaviour and move to the next step until you are certain all your logic (HW / driver / userspace) is right.</div><div dir="auto"><br></div><div dir="auto">Nicolas</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 15, 2023 at 6:42 PM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca" target="_blank" rel="noreferrer">nicolas@ndufresne.ca</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"><div><div><div>Le vendredi 15 septembre 2023 à 17:18 -0400, Dwight Kulkarni via gstreamer-devel a écrit :</div><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>With regards to earlier post about v4l2src, we have narrowed down the problem to one set of logs. </div><div><br></div><div>Going through the logs, I am finding this DEBUG message keeps repeating when the pipeline stream<b> isn't playing.</b></div><div><br></div><div><pre style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0);font-size:14px">0:00:18.777042366 1895 0xaaaafba09600 DEBUG basesink gstbasesink.c:5408:default_element_query:<autovideosink0-actual-sink-wayland> position query in format time
0:00:18.777067992 1895 0xaaaafba09600 DEBUG basesink gstbasesink.c:5342:gst_base_sink_get_position:<autovideosink0-actual-sink-wayland> <b>position in wrong state, return -1</b></pre><pre style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0);font-size:14px"><br></pre><pre style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0);font-size:14px"><br></pre><pre style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0);font-size:14px"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">When the pipeline is working properly, I get the following message, instead</span>
<pre style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px">0:00:13.244891490 1917 0xaaab01cec600 DEBUG basesink gstbasesink.c:5408:default_element_query:<autovideosink0-actual-sink-wayland> position query in format time
0:00:13.244928990 1917 0xaaab01cec600 DEBUG basesink gstbasesink.c:5200:gst_base_sink_get_position:<autovideosink0-actual-sink-wayland> using clock and base time 0:41:42.435970707</pre></pre><pre style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0);font-size:14px"><br></pre><pre style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0);font-size:14px"><br></pre></div><div><div>Can anyone comment on what this error might mean ? Seems like the stream is not able to initialize the clock for some reason ?</div></div></div></blockquote><div><br></div><div>Its application fault, it means a position query was issued before the sink reached PAUSED state. Some application will just retry later, some actually wait properly for playing state to be reached. Maybe you could help us understand what your application is doing with this query ?</div><div><br></div><div>Nicolas</div><div><br></div><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div dir="ltr"><div><div><br></div><div><br></div><div><br></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><span style="font-size:12.8px">Sincerely,</span><div><br></div><div>Dwight Kulkarni </div><div><br></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div><span></span></div></div>
</div></blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><span style="font-size:12.8px">Sincerely,</span><div><br></div><div>Dwight Kulkarni </div></div></div></div></div></div></div></div>
</blockquote></div></div></div>