<div dir="ltr">Thank you very much for the info and the hep. In fact, those were the next steps that I did. The zero-latency had no effect since the same error was present, then I tried to set b-frames to 0, which solved the problem of the differences, so it seems that the muxer does not work properly with B frames. Anyway, I tried to analyze the resulting TS and the same errors (those shown in the screenshot attached to my first message) are still present in the analyzer.<div><br></div><div>Best regards,</div><div>Antonio.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-08-30 12:45 GMT+02:00 Arjen Veenhuizen <span dir="ltr"><<a href="mailto:arjen@moonlightmedia.nl" target="_blank">arjen@moonlightmedia.nl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not sure what is going wrong in mpegtsmux, but an h264 bitstream does not<br>
contain any timing information in itself (except for some time-base info).<br>
It is the container (in this case MPEG2TS) that adds such information. To<br>
debug the problem, you could start with tuning the encoder to use<br>
zero-latency mode, set profile to main and disable b-frames and see if the<br>
problem persists.<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://gstreamer-devel.966125.n4.nabble.com/" rel="noreferrer" target="_blank">http://gstreamer-devel.966125.<wbr>n4.nabble.com/</a><br>
______________________________<wbr>_________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.<wbr>freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/gstreamer-<wbr>devel</a><br>
</blockquote></div><br></div>