[Bug 766790] v4l2src generates wrong timestamps for encoded video.

[GStreamer (GNOME Bugzilla)]

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

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO
                 CC|                            |nicolas at ndufresne.ca

--- Comment #1 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
In v4l2src, we first try to trust the timestamp provided by the driver, which
should have been deduced from the firmware timestamp. Those timestamp are
extremely bogus and the UVC driver isn't so good at fixing them. The C920 is
also one with a very buggy firmware (timestamp go backward sometimes, even on
raw data). From my point of view, this is to be fixed at both firmware and
kernel module. There remains valid things that could somehow be done to improve
that.

In GST, assuming you are willing to provide patches:
- Better bad kernel timestamp detection
- Better timestamp interpolation

In Linux-media (out of scope for GST)
- Distinction between DTS and PTS

Creating timestamp from expected framerate is not acceptable, this would drift
too much. A v4l2src is a life source, it is completely acceptable if the frame
are not equally spaced. In fact, UVC camera behave like this. Trying to force
fixed duration will break other use cases (some camera can send frames when
something happen, movement detection, face detection, weapon detection etc).

If you have a plan to improve this clearly in GST, let me know, otherwise I
will close as not our bug. Especially that h264 over UVC is poorly implemented
buy most firmware and the Linux kernel.

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