Appsink stops (pauses/freezes) after 2 frames.

[Hjalmar Turesson]

Not only does it work on two laptops with built-in cameras, but it even
works using the same camera (Logitech C920) on another computer. A very
frustrating and probably not solvable problem.

Thanks for the help,
Hjalmar

On Sat, Mar 28, 2015 at 6:47 PM, Hjalmar Turesson <hturesson at gmail.com>
wrote:

> Hi,
>
> I tested the same code on my laptop using the in-built camera, and it
> worked fine. The camera supports the same formats except for H264.
> I.e. (laptop webcam):
> $ v4l2-ctl --list-formats
> ioctl: VIDIOC_ENUM_FMT
>     Index       : 0
>     Type        : Video Capture
>     Pixel Format: 'YUYV'
>     Name        : YUV 4:2:2 (YUYV)
>
>     Index       : 1
>     Type        : Video Capture
>     Pixel Format: 'MJPG' (compressed)
>     Name        : MJPEG
>
> However, the camera I want to use is a Logitech C920 webcam. What is the
> difference? Why does it work on one camera but not on the other (even
> though it works when streaming h264)?
>
> Best regards,
> Hjalmar
>
> On Fri, Mar 27, 2015 at 12:12 PM, Hjalmar Turesson <hturesson at gmail.com>
> wrote:
>
>> Thanks for the advice Arjen.
>>
>> I tried setting the format. It doesn't seem to help. I used format=YUV2,
>> which I think corresponds to Pixel Format: 'YUYV'. In either case, it
>> doesn't seem critical, bc when I change sink to a filesink (encode and save
>> the stream), it works fine.
>>
>> $ v4l2-ctl --list-formats
>> ioctl: VIDIOC_ENUM_FMT
>>     Index       : 0
>>     Type        : Video Capture
>>     *Pixel Format: 'YUYV'*
>>     Name        : YUV 4:2:2 (YUYV)
>>
>>     Index       : 1
>>     Type        : Video Capture
>>     Pixel Format: 'H264' (compressed)
>>     Name        : H.264
>>
>>     Index       : 2
>>     Type        : Video Capture
>>     Pixel Format: 'MJPG' (compressed)
>>     Name        : MJPEG
>>
>> I've looked at the debug output but it doesn't say much (at least not to
>> me). GST_DEBUG='3' does nothing. At 4 I see a lot, but no errors or
>> warnings. The last line is completely normal:
>> 0:00:11.181339628 13055      0x2f6e850 INFO                 v4l2src
>> gstv4l2src.c:737:gst_v4l2src_create:<v4l2src0> sync to 0:00:00.133333332
>> out ts 0:00:00.287874714
>>
>> At debug threshold 5 I just don't understand much anymore. The last few
>> lines look like this:
>> 0:00:31.297802714 12103      0x3d79c50 DEBUG               basesink
>> gstbasesink.c:2114:gst_base_sink_wait_clock:<appsink0> sync disabled
>> 0:00:31.297813795 12103      0x3d79c50 DEBUG               basesink
>> gstbasesink.c:2489:gst_base_sink_do_sync:<appsink0> clock returned 4,
>> jitter  0:00:00.000000000
>> 0:00:31.297828235 12103      0x3d79c50 DEBUG               basesink
>> gstbasesink.c:3411:gst_base_sink_chain_unlocked:<appsink0> rendering object
>> 0x3aa0780
>> 0:00:31.297840457 12103      0x3d79c50 DEBUG               basesink
>> gstbasesink.c:936:gst_base_sink_set_last_buffer_unlocked:<appsink0> setting
>> last buffer to 0x3aa0780
>> 0:00:31.297853893 12103      0x3d79c50 DEBUG                appsink
>> gstappsink.c:710:gst_app_sink_render:<appsink0> pushing render buffer
>> 0x3aa0780 on queue (0)
>> 0:00:31.297892613 12103      0x3d79c50 DEBUG                appsink
>> gstappsink.c:1181:gst_app_sink_pull_sample:<appsink0> trying to grab a
>> buffer
>> 0:00:31.297907333 12103      0x3d79c50 DEBUG                appsink
>> gstappsink.c:656:dequeue_buffer:<appsink0> dequeued buffer 0x3aa0780
>> 0:00:31.297919138 12103      0x3d79c50 DEBUG                appsink
>> gstappsink.c:1196:gst_app_sink_pull_sample:<appsink0> we have a buffer
>> 0x3aa0780
>> 0:00:31.298086959 12103      0x3d79c50 DEBUG               basesink
>> gstbasesink.c:3450:gst_base_sink_chain_unlocked:<appsink0> object unref
>> after render 0x3aa0780
>> 0:00:31.298110134 12103      0x3d79c50 DEBUG                basesrc
>> gstbasesrc.c:2441:gst_base_src_get_range:<v4l2src0> calling create offset
>> 18446744073709551615 length 4096, time 0
>> 0:00:31.298126123 12103      0x3d79c50 DEBUG                   v4l2
>> gstv4l2bufferpool.c:1146:gst_v4l2_buffer_pool_acquire_buffer:<v4l2src0:pool:src>
>> acquire
>>
>>
>>
>> On Fri, Mar 27, 2015 at 6:09 AM, Arjen Veenhuizen <
>> arjen.veenhuizen at tno.nl> wrote:
>>
>>> Dome pointers:
>>> * Did you check the GST debug logs (e.g. export GST_DEBUG-3 or 4).
>>> * Perhaps you need to specify the stream format as well in the
>>> capsfilter.
>>> (E.g. I420 or something)
>>>
>>> Hjalmar Turesson wrote
>>> >  I tried using videoparse, but this crashes python
>>>
>>> This is not what I would have expected. I guess the pipeline stalls and
>>> the
>>> python program becomes unresponsive, possibly due to a caps negotiation
>>> problem.
>>> Please inspect and/or share your GStreamer logs.
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://gstreamer-devel.966125.n4.nabble.com/Appsink-stops-pauses-freezes-after-2-frames-tp4671355p4671356.html
>>> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150330/8766e666/attachment.html>