AW: AW: 1000 hours offset in timestamp of h264 stream

Nicolas Dufresne nicolas at ndufresne.ca
Tue Jun 1 15:05:27 UTC 2021 

Le mardi 01 juin 2021 à 09:28 +0000, Winand Appelhoff a écrit :
> Hi Nicolas,
> 
> could you elaborate on this a little bit more?
> I thought GstSegment was only relevant when processing seek events , at least
> that's how I interpreted the documentation

GstSegment contains the required information to interpret the following buffers
timestamp. I guess the doc could be improve, interpreting GstBuffer timestamp is
not that common, so it wasn't included there.

> 
> This helper structure holds the relevant values for tracking the region of
> interest in a media file, called a segment.
> The structure can be used for two purposes:
> * performing seeks (handling seek events)
> * tracking playback regions (handling newsegment events)
> 
> so, basically I should be using  gst_segment_to_stream_time(<GstSegment>,
> <timestamp of GstBuffer>) to get the "true" stream timestamp instead?

Correct, note I made a typo, most applicaiton will likely want to deal with
running-time. The stream-time is like the position within a stream (e.g. if you
are playing a file with a container like ISOMP4, it would translate the
timestamp into the position inside the current file). The running-time is the
time you pipeline have been playing. So starting from 0 as you asked for.

> 
> (sorry for hijacking this thread)
> Von: Nicolas Dufresne <nicolas at ndufresne.ca>
> Gesendet: Montag, 31. Mai 2021 15:55
> An: Discussion of the development of and with GStreamer <gstreamer-
> devel at lists.freedesktop.org>
> Cc: Winand Appelhoff <w.appelhoff at tv1.eu>; Marianna S. Buschle <msb at qtec.com>
> Betreff: Re: AW: 1000 hours offset in timestamp of h264 stream 
> Le lundi 31 mai 2021 à 10:27 +0000, Winand Appelhoff via gstreamer-devel a
> écrit :
> > 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
> 
> Same here, you application is likely ignoring the segment event, giving a
> meaning to timestamp is only possible while using the date in the segment
> event.
> 
> > 
> > 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
> > _______________________________________________
> > 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/20210601/f0d02d04/attachment-0001.htm>

More information about the gstreamer-devel mailing list