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

Winand Appelhoff w.appelhoff at
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> im Auftrag von Marianna S. Buschle via gstreamer-devel <gstreamer-devel at>
Gesendet: Montag, 31. Mai 2021 12:49
An: gstreamer-devel at <gstreamer-devel at>
Cc: Marianna S. Buschle <msb at>
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:

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

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:
gstreamer-devel mailing list
gstreamer-devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gstreamer-devel mailing list