AW: 1000 hours offset in timestamp of h264 stream

Mon May 31 10:27:20 UTC 2021

Hi!

You are right
Noticed an timestamp offset using  x264enc connected through an appsink/appsrc pair quite a while a ago
The only way I found to "fix" it was by subtracting 3600.000.000.000.000ns from the timestamp prior to pushing it into an appsrc

the only documentation I found was following statement in the 1.18 release notes:

avvidenc: shift output buffer timestamps and output segment by 1h just like x264enc does, to allow for negative DTS.

________________________________
Von: gstreamer-devel <gstreamer-devel-bounces at lists.freedesktop.org> im Auftrag von Marianna S. Buschle via gstreamer-devel <gstreamer-devel at lists.freedesktop.org>
Gesendet: Montag, 31. Mai 2021 09:01
An: gstreamer-devel at lists.freedesktop.org <gstreamer-devel at lists.freedesktop.org>
Cc: Marianna S. Buschle <msb at qtec.com>
Betreff: 1000 hours offset in timestamp of h264 stream

I have the following pipeline (using interpipesrc/sink from RidgeRun):

gst-launch-1.0 videotestsrc is-live=true pattern=ball !
video/x-raw,framerate=30/1,format=NV12 ! timeoverlay ! tee name=t ! queue !
videoconvert ! ximagesink sync=0 t. ! queue ! x264enc key-int-max=30
speed-preset=1 tune=zerolatency ! video/x-h264,profile=high ! h264parse !
queue ! interpipesink name=vtest1 sync=true async=false interpipesrc
listen-to=vtest1 name=vselect is-live=true stream-sync=passthrough-ts !
queue ! fakesink dump=1 sync=1  --gst-debug=*:3,*interpipe*:5

When sync=1 in the fakesink it doesn't dump any data, if I change to sync=0
it does.

If I remove the encoder (use RAW data) it dumps data for both cases.
The same is true if I remove the interpipesrc/sink and just plug the
fakesink directly into the encoder.

Also if I use recorded h264 data from a multifilesrc, instead of having an
encoder, it dumps data for both cases.

gst-launch-1.0 multifilesrc loop=1 name=replay location=/home/msb/test.ts !
identity sync=true ! tsdemux : identity sync=true ! h264parse ! queue !
interpipesink name=vreplay sync=false async=false interpipesrc
listen-to=vreplay is-live=true stream-sync=passthrough-ts ! fakesink dump=1
sync=1 --gst-debug=*:3,*interpipe*:5

The debug information from the interpipe elements reports timestamps with
1000 hours offset which I think it is the cause of the problem:

0:00:01.714147464 1339403 0x55b0aa657520 INFO           interpipesink
gstinterpipesink.c:542:gst_inter_pipe_sink_forward_event:<vtest1> Incoming
serialized event tag
0:00:01.714232382 1339403 0x55b0aa657520 INFO           interpipesink
gstinterpipesink.c:547:gst_inter_pipe_sink_forward_event:<vtest1> Event
timestamp 1000:00:01.633333333
0:00:01.714275617 1339403 0x55b0aa657520 DEBUG           interpipesrc
gstinterpipesrc.c:729:gst_inter_pipe_src_push_event:<vselect> Event tag with
calculated timestamp 1000:00:01.633333333 enqueued on serial pending events
0:00:02.030453992 1339403 0x55b0aa657700 INFO           interpipesink
gstinterpipesink.c:389:gst_inter_pipe_sink_intersect_listener_caps:<vtest1>
Listener vselect caps: ANY
0:00:02.030554449 1339403 0x55b0aa657700 INFO           interpipesink
gstinterpipesink.c:443:gst_inter_pipe_sink_get_caps:<vtest1> Caps
negotiated: video/x-h264, profile=(string)high, framerate=(fraction)[ 0/1,
2147483647/1 ], width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ],
parsed=(boolean)true, stream-format=(string){ avc, avc3, byte-stream },
alignment=(string){ au, nal }
0:00:02.047439856 1339403 0x55b0aa657520 INFO           interpipesink
gstinterpipesink.c:542:gst_inter_pipe_sink_forward_event:<vtest1> Incoming
serialized event tag
0:00:02.047497306 1339403 0x55b0aa657520 INFO           interpipesink
gstinterpipesink.c:547:gst_inter_pipe_sink_forward_event:<vtest1> Event
timestamp 1000:00:01.966666666
0:00:02.047530207 1339403 0x55b0aa657520 DEBUG           interpipesrc
gstinterpipesrc.c:729:gst_inter_pipe_src_push_event:<vselect> Event tag with
calculated timestamp 1000:00:01.966666666 enqueued on serial pending events

If I use RAW data the offset is not present, and if I use h264 encoded data
coming from the multifilesrc the offset is not present either:

0:00:01.911863974 1339557 0x559c28433d20 DEBUG           interpipesrc
gstinterpipesrc.c:481:gst_inter_pipe_src_create:<interpipesrc0> Got event
with timestamp 0:00:01.258333333
0:00:01.911912193 1339557 0x559c28433d20 DEBUG           interpipesrc
gstinterpipesrc.c:489:gst_inter_pipe_src_create:<interpipesrc0> Sending
Serial Event tag
0:00:02.111425433 1339557 0x559c28433d80 INFO           interpipesink
gstinterpipesink.c:542:gst_inter_pipe_sink_forward_event:<vreplay> Incoming
serialized event tag
0:00:02.111489516 1339557 0x559c28433d80 INFO           interpipesink
gstinterpipesink.c:547:gst_inter_pipe_sink_forward_event:<vreplay> Event
timestamp 0:00:01.458333333
0:00:02.111523291 1339557 0x559c28433d80 DEBUG           interpipesrc
gstinterpipesrc.c:729:gst_inter_pipe_src_push_event:<interpipesrc0> Event
tag with calculated timestamp 0:00:01.458333333 enqueued on serial pending
events

I think that the problem is that the interpipe elements are not handling
properly the timestamp offset caused by the encoder.
My question is, how can they (or maybe I) fix it? How to handle this offset
properly?
Some existing elements must be doing it, where can I look?

--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210531/a3d6b7a6/attachment-0001.htm>