Uses to reduce latency of a pipeline

[Jack]

Le 30/01/2019 à 04:08, Nicolas Dufresne a écrit :
> Le mercredi 30 janvier 2019 à 00:10 +0100, Jack a écrit :
>> Hello Nicolas,
>>
>> Le 29/01/2019 à 17:46, Nicolas Dufresne a écrit :
>>> Le lundi 28 janvier 2019 à 13:04 +0100, Jack a écrit :
>>>> Hello,
>>>>
>>>> I would like to know if you have recommandations on how to reduce
>>>> latency on a running pipeline using gstwebrtc ?
>>>>
>>>> For instance, a pipeline 1 like (using Python) :
>>>>
>>>> webrtcbin name=sendrecv bundle-policy=max-bundle
>>>
>>> You can configured the jitterbuffer latency using child proxy
>>> properties. But default it's 200ms (rtpbin latency property is in ms),
>>> this example would be 20ms:
>>>
>>>   webrtcbin rtpbin::latency=20
>>
>> If you can develop a little bit more your answer or give me a url with
>> an example or explanation I will be fine :)
>>
>> Why using your solution on the first pipeline, which is working fine,
>> will solve my problem on the second pipeline ?
>> Thanx.
>> ++
> 
> It felt you you where asking general question from the subject,
> configuring the jitterbuffer latency is a general way to reduce
> webrtcbin (or rtpbin) latency.

Yes, it is always good to know general behavior of gstreamer. I am quite
a beginner with this toolkit so... And if your solution can help to
reduce latency, I am very interested for sure ! And if you can develop a
little bit I will be very happy ! ;)

My original question was more about : why there is so much difference in
latency between my pipeline 1 and my pipeline 2, is it because I use
deinterleave/interleave/queue ? And how I could reduce it in the second
pipeline (if it is doable).
++

Jack




> 
>>
>> Jack
>>
>>
>>
>>>> filesrc location=my_stereo_sound.wav ! wavparse ! volume name="vol0"
>>>> volume=0.5 ! opusenc frame-size=10 ! rtpopuspay pt=96 !
>>>> application/x-rtp,media=audio,encoding-name=OPUS,payload=96,clock-rate=48000
>>>> ! sendrecv.
>>>>
>>>> and a pipeline 2 like (always with Python) :
>>>>
>>>> webrtcbin name=sendrecv bundle-policy=max-bundle
>>>> filesrc location=my_stereo_sound.wav ! wavparse ! deinterleave name=d
>>>> d.src_0 ! queue ! volume name="vol0" volume=0.5 ! i.sink_0 d.src_1 !
>>>> queue ! volume name="vol1" volume=0.5 ! i.sink_1 interleave name=i !
>>>> audiopanorama ! opusenc frame-size=10 ! rtpopuspay pt=96 !
>>>> application/x-rtp,media=audio,encoding-name=OPUS,payload=96,clock-rate=48000
>>>> ! sendrecv.
> 
> In this case, the problem is likely related to having a non-live source
> sent to webrtcbin. I'd first ask to give a try with a live source to
> confirm (audiotestsrc is-live=1 as an example), then I might elaborate.
> 
>>>>
>>>> If I change dynamically the value on "vol0" on the first pipeline (with
>>>> set_property()), I can hear the modification 1 second later (for me it
>>>> is acceptable). But if I do the same on the pipeline 2, the modification
>>>> is heard 2 seconds later ! Huge difference ! It is normal regarding the
>>>> "complexity" of the second pipeline (compare to the first) ? What do you
>>>> advise to reduce latency on the second pipeline ?
>>>> ++
>>>>
>>>> Jack
>>>>
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> gstreamer-devel at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> gstreamer-devel at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>