RTP dynamic bitrate depending on network condition

[Nicolas Dufresne]

Le jeu. 21 févr. 2019 08 h 29, vk_gst <venkateshkuppan26 at gmail.com> 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 <https://www.freesoft.org/CIE/RFC/1889/19.htm>
> .
> >>
> >> Regards
> >>
> >>
> >>
> >> --
> >> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> >> _______________________________________________
> >> gstreamer-devel mailing list
> >>
>
> > gstreamer-devel at .freedesktop
>
> >> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> > _______________________________________________
> > gstreamer-devel mailing list
>
> > gstreamer-devel at .freedesktop
>
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> > signature.asc (201 bytes)
> > <
> 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 <https://www.freesoft.org/CIE/RFC/1889/19.htm>
> .
> >>
> >> Regards
> >>
> >>
> >>
> >> --
> >> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> >> _______________________________________________
> >> gstreamer-devel mailing list
> >>
>
> > gstreamer-devel at .freedesktop
>
> >> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> > _______________________________________________
> > gstreamer-devel mailing list
>
> > gstreamer-devel at .freedesktop
>
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> > signature.asc (201 bytes)
> > <
> 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
> 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/20190221/9f0fe8e3/attachment-0001.html>