strange pts dts when using v4l2src with raspberry pi camera module

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

strange pts dts when using v4l2src with raspberry pi camera module

nucleus_wind
Hi all,

My setup a raspberry pi 3 with pi camera module listed here:
https://www.amazon.com/Raspberry-Pi-Camera-Module-Megapixel/dp/B01ER2SKFS/ref=sr_1_3?ie=UTF8&qid=1540276869&sr=8-3&keywords=raspberry+pi+camera+module&dpID=41ocSRel7eL&preST=_SY300_QL70_&dpSrc=srch

My pipeline looks like following:
`gst-launch-1.0 v4l2src do-timestamp=TRUE device="/dev/video0"
extra-controls="foo,h264_profile=0" !
video/x-h264,stream-format=byte-stream,alignment=au,width=640,height=480 !
h264parse ! video/x-h264,stream-format=avc,alignment=au,profile=baseline !
appsink`
But I coded it up as a gstreamer application so that I can print out the dts
and pts for every frame.

The following is the output from my gstreamer application:


I set the "is header" and "isKey" base on GST_BUFFER_FLAG_IS_SET(buffer,
GST_BUFFER_FLAG_HEADER) and  !GST_BUFFER_FLAG_IS_SET(buffer,
GST_BUFFER_FLAG_DELTA_UNIT) for each frame buffer.

My questions are:
- why are the dts greater than pts? It seems to be the effect of
do-timestamp=TRUE. If I remove do-timestamp=TRUE, the dts seems to come
straight from the driver. The dts starts at 0 and increments by 33333333 for
every frame. The pts still get synced but pts are greater than dts for all
frames.
- why aren't pts == dts for key frames? They dont equal each other whether I
set do-timestamp=TRUE or not. I think I have disabled B frames by setting
h264 profile to baseline which should enforce pts == dts for key frames.

I'm new to gstreamer and I'm trying to get an understanding of what is going
on here. Any help is really appreciated.

Thanks




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: strange pts dts when using v4l2src with raspberry pi camera module

Nicolas Dufresne-5


Le mar. 23 oct. 2018 09 h 27, nucleus_wind <[hidden email]> a écrit :
Hi all,

My setup a raspberry pi 3 with pi camera module listed here:
https://www.amazon.com/Raspberry-Pi-Camera-Module-Megapixel/dp/B01ER2SKFS/ref=sr_1_3?ie=UTF8&qid=1540276869&sr=8-3&keywords=raspberry+pi+camera+module&dpID=41ocSRel7eL&preST=_SY300_QL70_&dpSrc=srch

My pipeline looks like following:
`gst-launch-1.0 v4l2src do-timestamp=TRUE device="/dev/video0"
extra-controls="foo,h264_profile=0" !
video/x-h264,stream-format=byte-stream,alignment=au,width=640,height=480 !
h264parse ! video/x-h264,stream-format=avc,alignment=au,profile=baseline !
appsink`
But I coded it up as a gstreamer application so that I can print out the dts
and pts for every frame.


The following is the output from my gstreamer application:


I set the "is header" and "isKey" base on GST_BUFFER_FLAG_IS_SET(buffer,
GST_BUFFER_FLAG_HEADER) and  !GST_BUFFER_FLAG_IS_SET(buffer,
GST_BUFFER_FLAG_DELTA_UNIT) for each frame buffer.

My questions are:
- why are the dts greater than pts? It seems to be the effect of
do-timestamp=TRUE. If I remove do-timestamp=TRUE, the dts seems to come


Using do-timestamp with v4l2src will result in invalid (dts > pts). You should leave the default, which will derive the hw timestamp to pts and leave the dts to none.

straight from the driver. The dts starts at 0 and increments by 33333333 for
every frame. The pts still get synced but pts are greater than dts for all
frames.
- why aren't pts == dts for key frames?

There should be no dts from v4l2src because it's not supported by drivers. For H264, be aware that pts == dts on B frames (not I frames), when B-Frames are enabled.

They dont equal each other whether I
set do-timestamp=TRUE or not. I think I have disabled B frames by setting
h264 profile to baseline which should enforce pts == dts for key frames.

v4l2src does not implement h264 profile negotiation. If this driver supports it now, then contributions are welcome of course.


I'm new to gstreamer and I'm trying to get an understanding of what is going
on here. Any help is really appreciated.

Thanks




--
Sent from: http://gstreamer-devel.966125.n4.nabble.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