Excessive latency

David Jaggard davywj at gmail.com
Wed Feb 24 17:02:46 UTC 2016


Sorry, Found the 'set latency' function and it is possible to reduce this

On 24 February 2016 at 16:47, David Jaggard <davywj at gmail.com> wrote:

> Hi Tim,
>
> I am using zerolatency and I was aware of the 200ms in the rtpbin (which
> is perfectly acceptable) but not TSDemux! How do I force a lower latency on
> the pipeline?
>
> Thanks very much
>
> On 24 February 2016 at 16:38, Tim Müller <tim at centricular.com> wrote:
>
>> On Wed, 2016-02-24 at 16:06 +0000, David Jaggard wrote:
>>
>> Hi David,
>>
>> > The input of my stream is MPEG2 TS over RTP. The output is H264 video
>> > only.
>> >
>> > Pipeline:
>> > udpsrc->rtpbin->queue2->rtpMP2TDepay->TSDemux->(video)->queue2-
>> > >DecodeBin->queue2->Deinterlace->queue2->x264Enc->queue2->h264pay-
>> > >rtpbin->queue2->multiudpsink
>> >
>> > (I added all those queues to try and trace the bottleneck).
>> >
>> > The latency for the entire pipeline is set to a huge 1060ms.
>> >
>> > Every single queue other than the last is empty. The very last queue
>> > before the sink reports about 1100ms worth of data. This means that
>> > the entire pipeline is (virtually) latency free except when it
>> > arrives at the sink and has to buffer in order to synchronize to the
>> > clock. Why is it choosing such a high latency?
>>
>> Most of that (700ms) will be from tsdemux, which currently advertises
>> the worst-case scenario latency.
>>
>> Then there's an rtpjitterbuffer in rtpbin, which by default has a
>> latency of 200ms (you can configure this via the rtpbin "latency"
>> property).
>>
>> The rest is probably from deinterlace (one frame) and x264enc (try
>> x264enc tune=zerolatency if you're not using that yet).
>>
>> You should be able to force a lower latency on the pipeline than it
>> would configure by default.
>>
>> You could also modify tsdemux to advertise a lower latency (most
>> streams have much lower latency requirements, but we currently don't
>> analyse the stream to estimate that yet, but just announce the worst
>> case value).
>>
>> Cheers
>>  -Tim
>>
>> --
>> Tim Müller, Centricular Ltd - http://www.centricular.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/20160224/e1fe369e/attachment.html>


More information about the gstreamer-devel mailing list