gst_buffer_duration and v4l2src

[Iván Aponte]

So why does the DTS is correct ? Also I tried with the PTS but sometimes it
skips a frame and then send it way later.


On Tue, Sep 20, 2016 at 8:28 AM Nicolas Dufresne <nicolas.dufresne at gmail.com>
wrote:

> Le lundi 19 septembre 2016 à 22:43 +0000, Iván Aponte a écrit :
> > Hello,
> >
> > I have a pipeline that is something like this
> >
> >
> > v4l2--->omxh264enc -->queue --> mp4mux --> filesink
> >
> > If I put a probe in the queue sink I notice that every buffer comes
> > with a duration 0.016666 seconds even though my source is 12 fps
> > which is more like 0.083333 seconds each frame. If I put a
> > videotestsrc it does output buffers with the duration if 0.083333
> > seconds.  Why is this ?
>
> Camera firmware or driver reduce the framerate based on the light
> condition. This change is dynamic and is not reported through the Linux
> kernel API. In GStreamer, the duration is speculated from the negotiate
> framerate (in your case 60 fps). Hence, you cannot trust the duration.
> There is an element called videorate that has the capabilities to
> adjust those from the timestamp to be perfect.
>
> >
> > Regards,
> >
> > Ivan
> > --
> > Iván Aponte
> > +58 412 2774713
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-- 
Iván Aponte
+58 412 2774713
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160920/b47ab721/attachment.html>