<div dir="ltr"><div>Hello Nicolas,</div><div><br></div><div>thank you for your explanations. I'm still working on this subject. There is a lot I need to understand.</div><div><br></div><div>If I come to any conclusions I will post the to the list.</div><div><br></div><div>thx</div><div>Joao</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 5, 2019 at 3:16 PM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca">nicolas@ndufresne.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le vendredi 05 avril 2019 à 12:37 +0100, Joao Miguel Ferreira a écrit :<br>
> Hello list,<br>
> <br>
> I am facing a problem using gstreamer on Azure VMs. I have no previous experience with Gstreamer, and maybe that is the real problem. But I need to get this up&running and I'm finding these issues specifically in Azure VMs.<br>
> <br>
> We are using a python based wrapper for gstreamer which also plays as REST API. It's here: <a href="https://github.com/bbc/brave" rel="noreferrer" target="_blank">https://github.com/bbc/brave</a>. It's a fine software and it helps us a lot.<br>
> <br>
> So... my problem: we are overlaying a PNG file onto an RTMP stream and then pushing the result to an RTMP server (nginx for tests, twitch TV too). It works well on my laptop at 720p and 1080p. The setup runs on Docker, both on Debian OS and also on ubuntu VMs.<br>
> <br>
> But it never works well on Azure VMs. I have tried several VM families (even with GPU) and I always get some issue. The most frequent one is:<br>
> <br>
> GStreamer error: clock problem<br>
> <br>
> The logs show additional information concerning latency:<br>
> <br>
>  WARNING: [32m[   output1] [0m GStreamer warning from mux: gst-core-error-quark: GStreamer error: clock problem. (13)<br>
>  WARNING: [32m[   output1] [0m GStreamer warning debug: gstaggregator.c(1731): gst_aggregator_query_latency_unlocked (): /GstPipeline:pipeline2/GstFlvMux:mux:<br>
> Impossible to configure latency: max 0:00:02.000000000 < min 0:00:02.100000000. Add queues or other buffering elements.<br>
>  WARNING: [32m[   output1] [0m GStreamer warning message: GStreamer error: clock problem.<br>
<br>
This warning indicates a severe defect in your live pipeline. It means<br>
that the sum of requested latency of each plugins is bigger then the<br>
latency available at your muxer (aggregator). In this message, it says<br>
that the maximum latency your pipeline can accumulate is 2s, but the<br>
minimum latency (the amount of requested latency) is 2.1s. This<br>
indicates that stream synchronization isn't possible. Typically that<br>
happens when two branches have latency that is too different. E.g.:<br>
<br>
   videotestsrc is-live=1 ! x264enc ! mux.<br>
   audiotestsrc is-live-1 ! avenc_aac ! mux.<br>
<br>
In this case, x264enc, which has pretty high quality default<br>
configuration will requires around 1s (or more) of latency, while<br>
avenc_aac will likely need less then 0.1s. So the audio will reach the<br>
muxer earlier then video, which means audio need to be buffered. The<br>
maximum latency is also an amount of buffering capability.<br>
<br>
By default, flvmux is configured for non-live procession, hence have 0<br>
latency. So it is expected the upstream branches have large enough<br>
queues to buffer. In life scenarios, adding queues isn't very nice,<br>
because generic 'queue' are not really latency aware. Fortunatly,<br>
flvmux (GstAggregator) have a queuing mechanism. The size if configured<br>
though the 'latency' property in nanosecond. In special cases, like<br>
dynamic pipeline, flvmux might not be able to query the appropriate<br>
latency. As an example, the latency of an up-coming branch might be<br>
bigger then any of the initial branches. We have added "min-upstream-<br>
latency" in order to accommodate this use case.<br>
> <br>
> This does not happen at lower resolutions like 640x360<br>
> <br>
> Could this be related to the fact that these are VMs ? Because on my laptop (Lenovo thinkpad) it works fine.<br>
<br>
Laptop usually have a system tick running at higher frequency (or on<br>
demand tick / tick less) which reduce latency and makes your desktop<br>
more reponsive. While servers usually have slower tick to improves<br>
throughput, but often increase scheduling latency. This type of latency<br>
(along with processing latency) is quite variable, so GStreamer cannot<br>
perfectly accommodate them.<br>
<br>
> <br>
> I would appreciate any suggestions you might have or sharing anyone's experience with this kind of deploy.<br>
> <br>
> Thank you<br>
> João<br>
> <br>
> _______________________________________________<br>
> gstreamer-devel mailing list<br>
> <a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div>