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

Winand Appelhoff w.appelhoff at tv1.eu
Mon May 31 11:16:38 UTC 2021


mpegtsmux interprets the first incoming timestamp as 0 ( the start-time-selection property defaults to zero)
same goes for flvmux
so basically both muxer offset the timestamps by default

________________________________
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 12:49
An: gstreamer-devel at lists.freedesktop.org <gstreamer-devel at lists.freedesktop.org>
Cc: Marianna S. Buschle <msb at qtec.com>
Betreff: Re: AW: 1000 hours offset in timestamp of h264 stream

After a lot of digging I have managed to find the bug related to this 1000
hours offset:
https://github.com/GStreamer/gst-plugins-ugly/blob/master/ext/x264/gstx264enc.c#L1383

So I can see how x264 is adding the offset and why.

But so far I haven't found how other elements are ignoring/removing this
offset.

I can see that if I add `mpegtsmux ! tsdemux` to the pipeline after the
`h264parse` the offset seems to be removed by the `mux` and things then work
as expected.

But I cant really see how it is doing it or how I should go about properly
fixing the interpipe elements.

So far my backup plan is to, as you say, to try re-timstamp the frames by
subtracting the offset...



--
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/f8111560/attachment.htm>


More information about the gstreamer-devel mailing list