gst_buffer_duration and v4l2src

[ivan aponte]

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 ?

Regards, 

Ivan 

--

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

[Jake Zhang]

What is your v4l2src buffer mode? I saw in the past that some buffer mode might have slower performance. 

On Mon, Sep 19, 2016 at 6:43 PM, Iván Aponte <[hidden email]> wrote:

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 ?

Regards, 

Ivan 

--

_______________________________________________
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

[Nicolas Dufresne-4]

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
> [phone]
> _______________________________________________
> 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

[ivan 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 <[hidden email]> 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
> [phone]
> _______________________________________________
> 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

--

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

[Nicolas Dufresne-5]

Le 20 sept. 2016 3:17 PM, "Iván Aponte" <[hidden email]> a écrit :
>
> 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.

The PTS is quite accurate moment of when the capture started or finished. It is provided buy the Linux kernel driver.

Check your code, since the PTS is always the same as the DTS when produced by v4l2src. The only way I see to break this, is to set do-timestamp=true, this is wrong and should not be set this way.

>  
>
> On Tue, Sep 20, 2016 at 8:28 AM Nicolas Dufresne <[hidden email]> 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
>> > [phone]
>> > _______________________________________________
>> > 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
>
> --
> Iván Aponte
> [phone]

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