1000 hours offset in timestamp of h264 stream
Michael Gruner
michael.gruner at ridgerun.com
Tue Jun 1 15:16:32 UTC 2021
Hello, thanks for the report. Nicolas is correct, there are some values that are
being computed manually, that should use the segment instead. Precisely because
of these scenarios.
Let us take a look.
> On 1 Jun 2021, at 09:05, Nicolas Dufresne via gstreamer-devel <gstreamer-devel at lists.freedesktop.org> wrote:
>
>
>>
>> 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
>>
>
> _______________________________________________
> 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/2c30d49c/attachment.htm>
More information about the gstreamer-devel
mailing list