[Bug 796723] v4l2src + jpegdec dropping every second frame (timestamping / clocking / QoS issues?)

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796723

--- Comment #4 from Nicolas Dufresne (ndufresne) <nicolas at ndufresne.ca> ---
It's a problem with latency reporting apparently. v4l2src hardcodes 1 frames
latency (33ms for this test case). And jpegdec is suppose to declare another
frame latency (because it decodes the current frames when it find the start of
the next one). But the total latency is 33ms:

GST_DEBUG="bin:4" gst-launch-1.0 v4l2src device=/dev/video1 !
'image/jpeg,width=1280,height=720,framerate=30/1' ! jpegdec ! videoconvert !
fpsdisplaysink 
. . . 
New clock: GstSystemClock
0:00:01.041722891 26674 0x7ffad0004c00 INFO                     bin
gstbin.c:2778:gst_bin_do_latency_func:<pipeline0> configured latency of
0:00:00.033333333

If I manually fix the latency, it works fine:

GST_DEBUG="bin:4" gst-launch-1.0 pipeline. \( latency=66666666 v4l2src
device=/dev/video1 ! 'image/jpeg,width=1280,height=720,framerate=30/1' !
identity drop-allocation=1 ! jpegdec ! videoconvert ! fpsdisplaysink \)

So there is two things to work on, a) fix the latency reporting in jpegdec (and
avdec_mjpeg), and b) get v4l2src to signal jpegdec that the jpeg images are
already framed, so we get back this 1 frame latency. libv4l2 already knows the
jpeg are framed, hence the reason we didn't have this latency.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.