uvch264src bug. Variations of distance between timestamps with uvch264src

[Peter Maersk-Moller-2]

Hi.

I am using GStreamer 1.4.5 on a BeagleBone (small ARM based computer) with a Logitech C920 web camera. Here I use the GStreamer module uvch264src to fetch a H264 stream from the web camera and stream it. However instead of getting nicely evenly spaced timestamps with a nice duration of 1/framerate, I see presentation timestamps running ahead until adjusted every approximately 2 seconds, where I don't see any frames for a couple of hundred millesconds. A graph plotting how much each frames PTS timestamp is running ahead can be seen here:
https://dl.dropboxusercontent.com/u/5573813/TimestampsAhead.png

The expected framerate is 30fps. The script used to fetch the stream is this:

  ENCVIDEO='video/x-h264,width=1280,height=720,framerate=30/1,profile=(string)main'
  gst-launch-1.0 -v -e \
    uvch264src initial-bitrate=3000000 average-bitrate=3000000 \
    iframe-period=5000 device=/dev/video0 name=src \
    auto-start=true fixed-rate=true src.vidsrc ! \
    $ENCVIDEO ! identity silent=0 ! h264parse ! queue ! fakesink

Obviously when playing the stream, due to the jump in the PTS every 2 seconds, I see the video freezing for a couple of hundred milliseconds.

Is there a workaround for this bug? Apparently uvch264src does not generate evenly spaced time stamps, even though the fixed rate is enabled and the camera on an average generate the correct number of frames per second?

I tried to look at the timestamps after a h264parse and that generate nicely even spaced timestamps for DTS, but that is not going to help ad the PTS will be used for display.

I tried v4l2src with same result, but it seems uvch264src uses v4l2src somehow.

Thanks in advance

Peter Maersk-Moller

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Di, 2016-05-17 at 15:43 +0200, Peter Maersk-Moller wrote:
> 
> Is there a workaround for this bug? Apparently uvch264src does not
> generate evenly spaced time stamps, even though the fixed rate is
> enabled and the camera on an average generate the correct number of
> frames per second?
>
> I tried to look at the timestamps after a h264parse and that generate
> nicely even spaced timestamps for DTS, but that is not going to help
> ad the PTS will be used for display.

Can you file a bug about this? Would also be useful to know if v4l2src
is getting driver timestamps here or if we invent them ourselves, and
in case of the former if the driver actually gives correct (evenly
spaced) timestamps.

If we invent timestamps, they will be the ones when the frame arrived
in v4l2src. This depends a lot on the scheduler and as such you won't
get perfectly evenly spaced timestamps.

> I tried v4l2src with same result, but it seems uvch264src uses
> v4l2src somehow.

It's just a wrapper around v4l2src, yes.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Peter Maersk-Moller-2]

Hi Sebastian.

Bug has been filed for this.
https://bugzilla.gnome.org/show_bug.cgi?id=766790

Note that there are two related bugs. One is that the DTS is not calculated correctly and the other is that v4l2src fails to detect that the FPS from camera can change while streaming due to not enough light to provide the specified framerate.

kind regards

Peter MM

On Wed, May 18, 2016 at 2:33 PM, Sebastian Dröge <[hidden email]> wrote:

On Di, 2016-05-17 at 15:43 +0200, Peter Maersk-Moller wrote:
> 
> Is there a workaround for this bug? Apparently uvch264src does not
> generate evenly spaced time stamps, even though the fixed rate is
> enabled and the camera on an average generate the correct number of
> frames per second?
>
> I tried to look at the timestamps after a h264parse and that generate
> nicely even spaced timestamps for DTS, but that is not going to help
> ad the PTS will be used for display.

Can you file a bug about this? Would also be useful to know if v4l2src
is getting driver timestamps here or if we invent them ourselves, and
in case of the former if the driver actually gives correct (evenly
spaced) timestamps.

If we invent timestamps, they will be the ones when the frame arrived
in v4l2src. This depends a lot on the scheduler and as such you won't
get perfectly evenly spaced timestamps.

> I tried v4l2src with same result, but it seems uvch264src uses
> v4l2src somehow.

It's just a wrapper around v4l2src, yes.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel