Jetson GStreamer mpegtsmux always starts PTS at 3600s (cannot reset to zero)

[umayak_3]

I’m using Jetson TX2 with the default L4T GStreamer stack (1.14.5). When I run the following pipeline:

gst-launch-1.0 videotestsrc num-buffers=100 ! video/x-raw,width=1920,height=1080,framerate=24/1 ! nvvidconv ! video/x-raw\(memory:NVMM\),format=NV12 ! nvv4l2h264enc insert-sps-pps=true iframeinterval=1 idrinterval=1 bitrate=11292672 ! h264parse ! mpegtsmux alignment=0 ! filesink location=test_align0.ts

the resulting MPEG-TS file always has the first video PTS at 3600 seconds, not zero. This happens regardless of the source or pipeline settings. I have tried using identity ts-offset and other tricks, but nothing changes the initial PTS.

This breaks HLS segmenting and seeking in media servers, since every segment (even after a seek) starts at 3600s.

Is there any way to force mpegtsmux to start PTS at zero, or is this a known bug/limitation on Jetson?
Any workaround or advice would be appreciated.

[DaneLLL]

Hi,
This may need other users to share experience. Not sure if it helps but you may try to set the properties to videotestsrc:

  do-timestamp        : Apply current stream time to buffers
                        flags: readable, writable
                        Boolean. Default: false
  is-live             : Whether to act as a live source
                        flags: readable, writable
                        Boolean. Default: false
  timestamp-offset    : An offset added to timestamps set on buffers (in ns)
                        flags: readable, writable
                        Integer64. Range: 0 - 9223372036854775807 Default: 0