v4l2src doesn't launch always - seems to be a clock issue

Sat Sep 16 15:50:31 UTC 2023

Le sam. 16 sept. 2023, 08 h 30, Dwight Kulkarni <dwight at realtime-7.com> a
écrit :

> Hi Nicolas,
>
> 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.
>

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.

> We have written a custom driver for the camera board. As these are
> gstreamer messages they would be downstream from the driver.
>

> There is a 4 lane MIPI signal and clock coming out of the camera sensor,
> which is then processed by the driver.
>
> 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.
>

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).

> 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.
>
> Another observation is that once the stream starts working, it stays
> working, and if it fails, it will stay failed.
>
> 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 ?
>

> 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.
>
> 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.
>

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.

Nicolas

>
>
>
> On Fri, Sep 15, 2023 at 6:42 PM Nicolas Dufresne <nicolas at ndufresne.ca>
> wrote:
>
>> Le vendredi 15 septembre 2023 à 17:18 -0400, Dwight Kulkarni via
>> gstreamer-devel a écrit :
>>
>> Hi all,
>>
>> With regards to earlier post about v4l2src, we have narrowed down the
>> problem to one set of logs.
>>
>> Going through the logs, I am finding this DEBUG message keeps repeating
>> when the pipeline stream* isn't playing.*
>>
>> 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> *position in wrong state, return -1*
>>
>>
>>
>> When the pipeline is working properly, I get the following message, instead
>>
>> 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
>>
>>
>>
>> Can anyone comment on what this error might mean ?  Seems like the stream
>> is not able to initialize the clock for some reason ?
>>
>>
>> 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 ?
>>
>> Nicolas
>>
>>
>>
>>
>>
>> --
>> Sincerely,
>>
>> Dwight Kulkarni
>>
>>
>>
>
> --
> Sincerely,
>
> Dwight Kulkarni
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230916/e3fa6fab/attachment-0001.htm>