AW: AW: 1000 hours offset in timestamp of h264 stream
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
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel