RTP dynamic bitrate depending on network condition

[GStreamer-devel mailing list]

hello there !

I am currently building a project where we aim to:

"Live stream a drone video over 4G network in real time (~500 ms Latency)
and broadcast to a website".

The process is as follow:

*Gstreamer*[HDMI video feed -> H264 encode -> RTP -> UDP sink] --->
*Kurento*[rtp -> webRTC] --> browser

We successfully live streamed over WAN via ethernet and achieved required
latency. The result was good.
However when testing with 4G dongle (for real testing scenario), we are
facing the issues with UDP streams being halted due to poor network
condition depending on the location.

My question is: Is there a way to dynamically change the target bitrate of
omxh264encoder by checking the bandwidth of the sender? Would this require
writing a c++ application rather than a commandline pipeline?

This is my current pipeline:

'!', 'video/x-raw,width=1920,height=1080,framerate=30/1',
'!', 'videoconvert',
'!', 'omxh264enc control-rate=1, bitrate=800000',
'!', 'rtph264pay','config-interval=1','pt=96',
'!', 'udpsink',ipStr,portStr,'-v'];


Another question: It seems that Gstreamer stops streaming completely if the
network condition is too poor. Is there a way for Gstreamer to simply pause
and wait when the network is bad, and continue streaming when the signal
gets better?


Thanks guys !



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Michael Gruner]

Hi Justin

Most browsers have REMB congestion control built in. In REMB, the video receiver sends an estimate of the available bandwidth back to the sender. It does this by using the RTCP channel.

I’m not familiar with Kurento's WebRTC implementation but I’m pretty sure it uses GstRtpBin underneath, so you should be able to receive REMB estimates. First look for the REMB requests in your initial SDP offering:

  a=rtcp-fb:<payload type> goog-remb

Then you can read the incoming RTCP messages from the rtpbin. There’s a signal you can connect to. Filter the REMB statistics and you’ll have an estimate of the available bandwidth which you can use to configure your encoder's bitrate. 

I’d say an application would be easier. If you’d like to do it via plain cmdline you’ll need to modify, at least, the rtpbin and the encoder to communicate via messages.

Are you testing with gst-launch? If so, that would explain why it closes on poor network conditions. gst-launch listens to the pipeline bus and shuts down if an error is received. Your application may decide to react different. For example, pause waiting for the network to improve.

Michael

RidgeRun

On Feb 12, 2019, at 9:10 PM, justin via gstreamer-devel <[hidden email]> wrote:

hello there !

I am currently building a project where we aim to:

"Live stream a drone video over 4G network in real time (~500 ms Latency)
and broadcast to a website".

The process is as follow:

*Gstreamer*[HDMI video feed -> H264 encode -> RTP -> UDP sink] --->
*Kurento*[rtp -> webRTC] --> browser

We successfully live streamed over WAN via ethernet and achieved required
latency. The result was good.
However when testing with 4G dongle (for real testing scenario), we are
facing the issues with UDP streams being halted due to poor network
condition depending on the location.

My question is: Is there a way to dynamically change the target bitrate of
omxh264encoder by checking the bandwidth of the sender? Would this require
writing a c++ application rather than a commandline pipeline?

This is my current pipeline:

'!', 'video/x-raw,width=1920,height=1080,framerate=30/1',
'!', 'videoconvert',
'!', 'omxh264enc control-rate=1, bitrate=800000',
'!', 'rtph264pay','config-interval=1','pt=96',
'!', 'udpsink',ipStr,portStr,'-v'];


Another question: It seems that Gstreamer stops streaming completely if the
network condition is too poor. Is there a way for Gstreamer to simply pause
and wait when the network is bad, and continue streaming when the signal
gets better?


Thanks guys !



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

Hi

I am currently working on an implementation of GStreamer plugin for SCReAM
(https://tools.ietf.org/html/rfc8298). SCReAM has been developed with one of
the goals being to give good real time streaming experience in LTE networks.
For moment the plugin in a runnable condition wrapped in gstreamer
applications and I have done some testing of it both in Linux based laptops
as well as with the sender side congestion control running in a Raspberry Pi
3, there I have tried it with both omxh264enc and rpicamsrc.

The code for the SCReAM plugins are still in a bit too ugly shape to be
shared however.

/Ingemar



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

Have you tried decoupling your receiver pipeline, this would ensure that your
downstream pipeline still works if the upstream pipeline does not send any
data(as in your case). i implemented something similar, where the downstream
pipeline retains the old data and keeps showing the frozen image/video
instead of a black screen. Once the upstream pipeline has data, the
downstream pipeline resumes back to displaying the live video. The elements
intervideosink and intervideosrc can be used to achieve this.

This is how the pipeline would look, but you need to write an application to
get this working:

RX_PIPELINE_SRC = udpsrc -> caps -> rtph264depay -> h264parse -> h264_decode
-> intervideosink
RX_PIPELINE_SINK = intervideosrc -> autovideosink


Regards.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

FYI, you are not using RTP in that pipeline; simply payloading the
data in RTP format. If you do not link up your RTCP socket/rtpbin your
quality will be poor in less than ideal network conditions.

See:
https://github.com/mleeman/gst-plugins-rtp

Also (I still need to revert the boilerplate)
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/183
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[justin]

Hi Michael,

Thank you so much for the insightful reply.
REMB sounds very convincing, I will give my shot at writing some application
codes soon.
On the side note however, your suggestion seems to be checking network
condition on the end-client side (users watching the stream).
Whereas I am more concerned about the network condition of the sender itself
as we are streaming the video over a mobile network. In some remote
locations, the upload speed is too low for the target bitrate set by
omxh264enc.

Is there a REMB control method for checking the network condition of the
sender? That is:
Gstreamer starts streaming -> check network condition of the sender ->
adjusts bitrate dynamically.

And yes I am testing with gst-launch at this stage.
Once again I greatly appreciate your help.

Justin



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[sk_gst]

Hi Justin,

You can try accessing the sender report at the sender side, and get an idea
about the bandwidth by accessing the following fields :

|                 SSRC_1 (SSRC of first source)                 | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| fraction lost |       cumulative number of packets lost       |   1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           extended highest sequence number received           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      interarrival jitter                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         last SR (LSR)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   delay since last SR (DLSR)                  |


You still have to write a logic on how you would estimate the bandwidth
based on these parameters.

Have a look  here <https://www.freesoft.org/CIE/RFC/1889/19.htm>  .

Regards



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mercredi 20 février 2019 à 07:45 -0600, vk_gst a écrit :
> Hi Justin,
>
> You can try accessing the sender report at the sender side, and get an idea
> about the bandwidth by accessing the following fields :

Or just read the estimated bandwidth found in the stats. Something
closer to REMB would be to also use the variation of the round-trip-
time to do early detection of the remote queues filling.

  RTPSource of main RTP SSRC: see bitrate in stats structure
  RTPSource of the RTCP SSRC: see rb-round-trip in stats structure

You should increase the RTCP interval, as the default of 5s is not very
reactive for this type of measurement.

>
> >                 SSRC_1 (SSRC of first source)                 | report
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
> > fraction lost |       cumulative number of packets lost       |   1
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >           extended highest sequence number received           |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                      interarrival jitter                      |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                         last SR (LSR)                         |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                   delay since last SR (DLSR)                  |
>
> You still have to write a logic on how you would estimate the bandwidth
> based on these parameters.
>
> Have a look  here <https://www.freesoft.org/CIE/RFC/1889/19.htm>  .
>
> Regards
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ingemar Johansson]

Hi
Actually, an effort to do rate adaptation based on SR/RR is going to make
you disappointed (been there tried that).

I have made the SCReAM gstreamer code public and I do believe that this will
solve your congestion control problem better. The code is found at
https://github.com/EricssonResearch/scream/tree/master/code/gscream 
or by cloing the whole thing from
https://github.com/EricssonResearch/scream .

Currently you need to run it as sender and receiver applications that
execute the pipelines. This because the code is written to work with either
x264enc or rpicamsrc.

A rather ugly video with SCReAM implemented in a Raspberry PI 3 B+ is found
at https://www.youtube.com/watch?v=0-jwNf8kIMM , the budget could not afford
a BMW Z3 :-)

/Ingemar
 



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[sk_gst]

Nicolas Dufresne-5 wrote

> Le mercredi 20 février 2019 à 07:45 -0600, vk_gst a écrit :
>> Hi Justin,
>>
>> You can try accessing the sender report at the sender side, and get an
>> idea
>> about the bandwidth by accessing the following fields :
>
> Or just read the estimated bandwidth found in the stats. Something
> closer to REMB would be to also use the variation of the round-trip-
> time to do early detection of the remote queues filling.
>
>   RTPSource of main RTP SSRC: see bitrate in stats structure
>   RTPSource of the RTCP SSRC: see rb-round-trip in stats structure
>
> You should increase the RTCP interval, as the default of 5s is not very
> reactive for this type of measurement.
>
> Is there any property exposed by element rtpbin, that enables to change
> this time of 5seconds. I could not find any.
>
>>
>> >                 SSRC_1 (SSRC of first source)                 | report
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
>> > fraction lost |       cumulative number of packets lost       |   1
>> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >           extended highest sequence number received           |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >                      interarrival jitter                      |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >                         last SR (LSR)                         |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >                   delay since last SR (DLSR)                  |
>>
>> You still have to write a logic on how you would estimate the bandwidth
>> based on these parameters.
>>
>> Have a look  here &lt;https://www.freesoft.org/CIE/RFC/1889/19.htm&gt;  .
>>
>> Regards
>>
>>
>>
>> --
>> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
>> _______________________________________________
>> gstreamer-devel mailing list
>>

> gstreamer-devel@.freedesktop

>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list

> gstreamer-devel@.freedesktop

> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> signature.asc (201 bytes)
> &lt;http://gstreamer-devel.966125.n4.nabble.com/attachment/4689764/0/signature.asc&gt;


Nicolas Dufresne-5 wrote

> Le mercredi 20 février 2019 à 07:45 -0600, vk_gst a écrit :
>> Hi Justin,
>>
>> You can try accessing the sender report at the sender side, and get an
>> idea
>> about the bandwidth by accessing the following fields :
>
> Or just read the estimated bandwidth found in the stats. Something
> closer to REMB would be to also use the variation of the round-trip-
> time to do early detection of the remote queues filling.
>
>   RTPSource of main RTP SSRC: see bitrate in stats structure
>   RTPSource of the RTCP SSRC: see rb-round-trip in stats structure
>
> You should increase the RTCP interval, as the default of 5s is not very
> reactive for this type of measurement.
>
>>
>> >                 SSRC_1 (SSRC of first source)                 | report
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
>> > fraction lost |       cumulative number of packets lost       |   1
>> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >           extended highest sequence number received           |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >                      interarrival jitter                      |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >                         last SR (LSR)                         |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >                   delay since last SR (DLSR)                  |
>>
>> You still have to write a logic on how you would estimate the bandwidth
>> based on these parameters.
>>
>> Have a look  here &lt;https://www.freesoft.org/CIE/RFC/1889/19.htm&gt;  .
>>
>> Regards
>>
>>
>>
>> --
>> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
>> _______________________________________________
>> gstreamer-devel mailing list
>>

> gstreamer-devel@.freedesktop

>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list

> gstreamer-devel@.freedesktop

> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> signature.asc (201 bytes)
> &lt;http://gstreamer-devel.966125.n4.nabble.com/attachment/4689764/0/signature.asc&gt;





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[sk_gst]

Would this also be compatible to NXP i.MX6, or do you have plans of extending
it for the NXP?



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le jeu. 21 févr. 2019 08 h 29, vk_gst <[hidden email]> a écrit :

Nicolas Dufresne-5 wrote
> Le mercredi 20 février 2019 à 07:45 -0600, vk_gst a écrit :
>> Hi Justin,
>>
>> You can try accessing the sender report at the sender side, and get an
>> idea
>> about the bandwidth by accessing the following fields :
>
> Or just read the estimated bandwidth found in the stats. Something
> closer to REMB would be to also use the variation of the round-trip-
> time to do early detection of the remote queues filling.
>
>   RTPSource of main RTP SSRC: see bitrate in stats structure
>   RTPSource of the RTCP SSRC: see rb-round-trip in stats structure
>
> You should increase the RTCP interval, as the default of 5s is not very
> reactive for this type of measurement.
>
> Is there any property exposed by element rtpbin, that enables to change
> this time of 5seconds. I could not find any.

It's a property on rtpsession, see get-session action signal. 

https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good/html/gst-plugins-good-plugins-rtpsession.html#GstRtpSession--rtcp-min-interval

>
>>
>> >                 SSRC_1 (SSRC of first source)                 | report
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
>> > fraction lost |       cumulative number of packets lost       |   1
>> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >           extended highest sequence number received           |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >                      interarrival jitter                      |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >                         last SR (LSR)                         |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >                   delay since last SR (DLSR)                  |
>>
>> You still have to write a logic on how you would estimate the bandwidth
>> based on these parameters.
>>
>> Have a look  here &lt;https://www.freesoft.org/CIE/RFC/1889/19.htm&gt;  .
>>
>> Regards
>>
>>
>>
>> --
>> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
>> _______________________________________________
>> gstreamer-devel mailing list
>>

> gstreamer-devel@.freedesktop

>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list

> gstreamer-devel@.freedesktop

> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> signature.asc (201 bytes)
> &lt;http://gstreamer-devel.966125.n4.nabble.com/attachment/4689764/0/signature.asc&gt;


Nicolas Dufresne-5 wrote
> Le mercredi 20 février 2019 à 07:45 -0600, vk_gst a écrit :
>> Hi Justin,
>>
>> You can try accessing the sender report at the sender side, and get an
>> idea
>> about the bandwidth by accessing the following fields :
>
> Or just read the estimated bandwidth found in the stats. Something
> closer to REMB would be to also use the variation of the round-trip-
> time to do early detection of the remote queues filling.
>
>   RTPSource of main RTP SSRC: see bitrate in stats structure
>   RTPSource of the RTCP SSRC: see rb-round-trip in stats structure
>
> You should increase the RTCP interval, as the default of 5s is not very
> reactive for this type of measurement.
>
>>
>> >                 SSRC_1 (SSRC of first source)                 | report
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
>> > fraction lost |       cumulative number of packets lost       |   1
>> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >           extended highest sequence number received           |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >                      interarrival jitter                      |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >                         last SR (LSR)                         |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >                   delay since last SR (DLSR)                  |
>>
>> You still have to write a logic on how you would estimate the bandwidth
>> based on these parameters.
>>
>> Have a look  here &lt;https://www.freesoft.org/CIE/RFC/1889/19.htm&gt;  .
>>
>> Regards
>>
>>
>>
>> --
>> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
>> _______________________________________________
>> gstreamer-devel mailing list
>>

> gstreamer-devel@.freedesktop

>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list

> gstreamer-devel@.freedesktop

> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> signature.asc (201 bytes)
> &lt;http://gstreamer-devel.966125.n4.nabble.com/attachment/4689764/0/signature.asc&gt;





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[justin]

Hello Ingemar,

Thanks for your kind reply and also thank you for sharing your codes to the
public. Really appreciate it.
Do you mind if I send you an email regarding SCReAM to further clarify some
points?
By the way, saw your youtube video (the one with multi cams on mobile car
driving around the campus) and it looks awesome !

kind regards,
Justin Choi



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ingemar Johansson]

Hi
and thanks for the interest. You can find my email address in
https://tools.ietf.org/html/rfc8298

Yes, that small car demo was a bit fun to make.
One particular problem we had with these IP cameras was that they transmit
real large key frames at regular intervals, which could make the playout
choppy when bandwith is limited, another issue is that the coder bitrate
sometimes lags behind the target bitrate by up to 5 seconds.

The main challenge with all this is actually to get the video coders to
behave reasonably well. It does not need to be an exact match to the target
rate but the response time to rate changes should be relatively short and
periodic intra-refresh is also on the wish-list. My exeperience so far is
that x264enc provides the best tuning options for low latency rate adaptive
video over cellular (e.g tune=zerolatency).
I have not yet had time to try out other coders like omxh264enc.

/Ingemar




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[chakra]

I am using GStreamer WebRTCbin in send only mode to send videos to browser

On the Webrtc TRANSCEIVER I have enabled:
       / trans->direction = GST_WEBRTC_RTP_TRANSCEIVER_DIRECTION_SENDONLY;
        g_object_set(trans, "fec-type", GST_WEBRTC_FEC_TYPE_ULP_RED, NULL);
        g_object_set(trans, "do-nack", TRUE, NULL);
/
But in the SDP generated as offer from GStreamer to Browser I could see
only,

               / "type":"offer",
                "sdp":"
                v=0\r\no=- 8618982146125398909 0 IN IP4 0.0.0.0\r\n
                s=-\r\n
                t=0 0\r\n
                a=ice-options:trickle\r\n
                a=group:BUNDLE video0\r\n
                m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100\r\n
                c=IN IP4 0.0.0.0\r\n
                a=setup:actpass\r\n
                a=ice-ufrag:UPTOWGnTMt68LX4oLCOYv6xVOFEEOzpM\r\n
                a=ice-pwd:lkvHifShkaD2rzwQZMBENmlsCdmO2Lhz\r\n
                a=rtcp-mux\r\n
                a=rtcp-rsize\r\n
                a=sendonly\r\n
                a=rtpmap:96 H264/90000\r\n
                a=rtcp-fb:96 nack\r\n
                a=rtcp-fb:96 nack pli\r\n
                a=rtpmap:97 red/90000\r\n
                a=rtpmap:98 ulpfec/90000\r\n
                a=rtpmap:99 rtx/90000\r\n
                a=fmtp:99 apt=97\r\n
                a=rtpmap:100 rtx/90000\r\n
                a=fmtp:100 apt=96\r\n/

So there is no rtcp-fb of payload type goog-remb/transport-cc

Is the congestion control/REMB implemeted by GStreamer? I see a issue,
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/1009 where
in one of the comments its mentioned - "don't implement any congestion
control / automatic bitrate adaptation yet"

So is it that GStreamer does not support REMB/Transport CC/TMMBR congenstion control mechanism yet and need to depend on stats like packets-received, packets-lost to get information close to it?




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[e-mail]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mathieu Duponchelle]

Hey, webrtcbin indeed doesn't implement any form of congestion control,
this is already identified as an opportunity for future improvement. Note that
besides goog-remb, other congestion mechanisms are currently in contention
in the WebRTC working group, work is ongoing to implement support for one of
those @ https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/merge_requests/377

--
Mathieu Duponchelle · https://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel