1000 hours offset in timestamp of h264 stream

[Nicolas Dufresne]

Le lundi 31 mai 2021 à 02:01 -0500, Marianna S. Buschle via gstreamer-devel a
écrit :
> 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.

I'm guessing that interpipesink element, from RidgeRun do not handle the
GstSegment properly. It's been over 4 years now that x264enc add 1 day to the
timestamp in order to support negative DTS. The offset is balanced through the
GstSegment. Ignoring the segment is a bug, timestamp have no meaning without
their segment.

Please report to RidgeRun github.

> 
> 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