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

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 766790
           Summary: v4l2src generates wrong timestamps for encoded video.
    Classification: Platform
           Product: GStreamer
           Version: 1.8.1
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: pmaersk at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

When v4l2src is used to get an encoded stream from a camera like a webcamera,
it timestamps the individual frames with the time of arrival as PTS rather than
a timestamp conforming to first arrived frame plus number of frames times frame
period.

This is not so much an issue when v4l2src is used to fetch raw frames, where
the frames most likely arrive with a rather similar period of time between
each, but this is not the case for encoded video. Encoded video arrive at the
module with an variable amount of time between and that will sometimes set the
DTS too early for a number of frames until later where there will be no frames
for up to 200-300ms.

Here is a plot of the how much the DTS is ahead of what it should be for a
Logitech C920 Camera connected to a laptop, using H264 and 30fps (33.33ms per
frame)
https://dl.dropboxusercontent.com/u/5573813/TimestampsAhead.png

See also this thread.
https://lists.freedesktop.org/archives/gstreamer-devel/2016-May/058465.html

This also affects the uvch264src module, where a fixed framerate can be set as
parameter.

Obviously, when fixing this calculating equal spaced timestamps, one should
take into account that the device can deliver a frame too late. When that
happen, the time for the too late frame should be used as basis for future
calculation rather than the first frame arrived.

Furthermore, when webcameras receive too little light, then when set to lets
say 30 fps, they may actually deliver less. The logitech C920 camera will
deliver H264 encoded video at 24fps or even 15 fps, if there is too little
light. I don't know if the v4l2src checks the call when setting the fps, but
apparently the fps change during stream if the light received is dimmed down.
To count for that, the v4l2src should check how many frames it receives per
second and fire an event telling that the frame rate has changed.

Regards
Peter Maersk-Moller

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