What abs-send-time mainly used for?

982 views
Skip to first unread message

Tian Yong

unread,
Nov 28, 2016, 2:10:20 AM11/28/16
to discuss-webrtc
Hey

When we recording in our webrtc gateway, sometimes it went out of sync, it very difficult for us debug this, so we use the abs-send-time in audio(opus) rtp headers, it works very good.

So is this abs-send-time used for? or there's some other use?

Cheers!

Stefan Holmer

unread,
Nov 29, 2016, 4:37:25 AM11/29/16
to discuss-webrtc
They were once added to be used for audio bandwidth estimation. We decided to not pursue that solution and have therefore removed abs-send-time for audio in Chrome M56.

For synchronizing streams you should be using RTCP sender reports.

/Stefan

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/1ce0b853-475b-426f-976a-b52dd3655076%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

pablo platt

unread,
Nov 29, 2016, 5:34:54 AM11/29/16
to discuss...@googlegroups.com
What do you use instead of abs-send-time in Chrome M56?
Receiver side REMB seems to rely on the abs-send-time extension.

Maybe you don't include audio in REMB calculation in M56?

On Tue, Nov 29, 2016 at 11:37 AM, 'Stefan Holmer' via discuss-webrtc <discuss...@googlegroups.com> wrote:
They were once added to be used for audio bandwidth estimation. We decided to not pursue that solution and have therefore removed abs-send-time for audio in Chrome M56.

For synchronizing streams you should be using RTCP sender reports.

/Stefan

On Mon, Nov 28, 2016 at 8:10 AM Tian Yong <hass...@gmail.com> wrote:
Hey

When we recording in our webrtc gateway, sometimes it went out of sync, it very difficult for us debug this, so we use the abs-send-time in audio(opus) rtp headers, it works very good.

So is this abs-send-time used for? or there's some other use?

Cheers!

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAEdus3JmhX3JWa6oAswQOaT%3Dt6xUhOpZqEGOhKppFfyDG5XTGA%40mail.gmail.com.

Stefan Holmer

unread,
Nov 30, 2016, 2:46:40 AM11/30/16
to discuss...@googlegroups.com

We have never included audio in remb, that never launched. For audio BWE we recommend using send-side BWE which is default in M55 and uses these extensions:

a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01

a=rtcp-fb:100 transport-cc

Note that audio BWE is experimental and not enabled by default.

/Stefan

On Tue, Nov 29, 2016, 11:34 pablo platt <pablo...@gmail.com> wrote:
What do you use instead of abs-send-time in Chrome M56?
Receiver side REMB seems to rely on the abs-send-time extension.

Maybe you don't include audio in REMB calculation in M56?

On Tue, Nov 29, 2016 at 11:37 AM, 'Stefan Holmer' via discuss-webrtc <discuss...@googlegroups.com> wrote:
They were once added to be used for audio bandwidth estimation. We decided to not pursue that solution and have therefore removed abs-send-time for audio in Chrome M56.

For synchronizing streams you should be using RTCP sender reports.

/Stefan

On Mon, Nov 28, 2016 at 8:10 AM Tian Yong <hass...@gmail.com> wrote:
Hey

When we recording in our webrtc gateway, sometimes it went out of sync, it very difficult for us debug this, so we use the abs-send-time in audio(opus) rtp headers, it works very good.

So is this abs-send-time used for? or there's some other use?

Cheers!

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CANdLC8X0m_seySqqe5REy90HVY1YsQYM0d57QJ63Bw7AYkpbMg%40mail.gmail.com.

pablo platt

unread,
Nov 30, 2016, 3:08:25 AM11/30/16
to discuss...@googlegroups.com
Why audio wasn't included in REMB?
I'm including it in my implementation and wonder if I should ignore audio packets.

Where is the send-side BWE code?
I can see REMB but I can't find send-side.
https://chromium.googlesource.com/external/webrtc/+/master/webrtc/modules/remote_bitrate_estimator/


On Wed, Nov 30, 2016 at 9:46 AM, 'Stefan Holmer' via discuss-webrtc <discuss...@googlegroups.com> wrote:

We have never included audio in remb, that never launched. For audio BWE we recommend using send-side BWE which is default in M55 and uses these extensions:

a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01

a=rtcp-fb:100 transport-cc

Note that audio BWE is experimental and not enabled by default.

/Stefan

On Tue, Nov 29, 2016, 11:34 pablo platt <pablo...@gmail.com> wrote:
What do you use instead of abs-send-time in Chrome M56?
Receiver side REMB seems to rely on the abs-send-time extension.

Maybe you don't include audio in REMB calculation in M56?

On Tue, Nov 29, 2016 at 11:37 AM, 'Stefan Holmer' via discuss-webrtc <discuss-webrtc@googlegroups.com> wrote:
They were once added to be used for audio bandwidth estimation. We decided to not pursue that solution and have therefore removed abs-send-time for audio in Chrome M56.

For synchronizing streams you should be using RTCP sender reports.

/Stefan

On Mon, Nov 28, 2016 at 8:10 AM Tian Yong <hass...@gmail.com> wrote:
Hey

When we recording in our webrtc gateway, sometimes it went out of sync, it very difficult for us debug this, so we use the abs-send-time in audio(opus) rtp headers, it works very good.

So is this abs-send-time used for? or there's some other use?

Cheers!

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAEdus3KnLTxsqxNQVSZYMWb_YUn2zqUj2j%2BxF5qcLZMmJJo6Lw%40mail.gmail.com.

Stefan Holmer

unread,
Dec 1, 2016, 4:16:09 AM12/1/16
to discuss...@googlegroups.com
Most of the time you should be fine ignoring audio packets.

For send-side BWE it's probably easiest to follow the code from CongestionController. Take a look at for instance OnSentPacket and TransportFeedbackAdapter.

/Stefan

On Wed, Nov 30, 2016 at 9:08 AM pablo platt <pablo...@gmail.com> wrote:
Why audio wasn't included in REMB?
I'm including it in my implementation and wonder if I should ignore audio packets.

Where is the send-side BWE code?
I can see REMB but I can't find send-side.
https://chromium.googlesource.com/external/webrtc/+/master/webrtc/modules/remote_bitrate_estimator/


On Wed, Nov 30, 2016 at 9:46 AM, 'Stefan Holmer' via discuss-webrtc <discuss...@googlegroups.com> wrote:

We have never included audio in remb, that never launched. For audio BWE we recommend using send-side BWE which is default in M55 and uses these extensions:

a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01

a=rtcp-fb:100 transport-cc

Note that audio BWE is experimental and not enabled by default.

/Stefan

On Tue, Nov 29, 2016, 11:34 pablo platt <pablo...@gmail.com> wrote:
What do you use instead of abs-send-time in Chrome M56?
Receiver side REMB seems to rely on the abs-send-time extension.

Maybe you don't include audio in REMB calculation in M56?

On Tue, Nov 29, 2016 at 11:37 AM, 'Stefan Holmer' via discuss-webrtc <discuss...@googlegroups.com> wrote:
They were once added to be used for audio bandwidth estimation. We decided to not pursue that solution and have therefore removed abs-send-time for audio in Chrome M56.

For synchronizing streams you should be using RTCP sender reports.

/Stefan

On Mon, Nov 28, 2016 at 8:10 AM Tian Yong <hass...@gmail.com> wrote:
Hey

When we recording in our webrtc gateway, sometimes it went out of sync, it very difficult for us debug this, so we use the abs-send-time in audio(opus) rtp headers, it works very good.

So is this abs-send-time used for? or there's some other use?

Cheers!

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CANdLC8UdErZnb1XoZXVM%3Dx_XKvp0nzdQ-BP2HxtZBE4UL4M-bQ%40mail.gmail.com.

pablo platt

unread,
Dec 1, 2016, 5:56:52 AM12/1/16
to discuss...@googlegroups.com
Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAEdus3JUELN%3Dg6t2dKvvQmu616nM76%3D%3DZ6BOh7x8qKJ43F6nDw%40mail.gmail.com.

mparis

unread,
Dec 1, 2016, 8:30:34 AM12/1/16
to discuss-webrtc
Hello Stefan,
first of all thanks for clarifying this.

Anyway I don't know if I am missing something related to the send-side BWE, but I think that both audio and video RTP packets should be taken into account, because there can be several audio streams that can significantly affect the network bandwidth (and even in an ideal case DataChannels should be considered).
Hence, why do you decide to remove abs-send-time for audio?
If I am not wrong, both abs-send-time and transport-cc RTP header extensions are needed for the send-side BWE algorithm, aren't they?

So, if I am right, next extensions should be negotiated in audio and in video m-lines in the SDP:
http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
transport-cc

Best regards!!
Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

Stefan Holmer

unread,
Dec 9, 2016, 6:51:44 AM12/9/16
to discuss...@googlegroups.com
On Thu, Dec 1, 2016 at 2:30 PM mparis <mpari...@gmail.com> wrote:
Hello Stefan,
first of all thanks for clarifying this.

Anyway I don't know if I am missing something related to the send-side BWE, but I think that both audio and video RTP packets should be taken into account, because there can be several audio streams that can significantly affect the network bandwidth (and even in an ideal case DataChannels should be considered).

Agree.
 
Hence, why do you decide to remove abs-send-time for audio?

With send-side BWE, BWE is done using transport-wide-cc-extensions-01 instead of abs-send-time, therefore it's not needed any longer.
 
If I am not wrong, both abs-send-time and transport-cc RTP header extensions are needed for the send-side BWE algorithm, aren't they?

No, not abs-send-time.
 

mparis

unread,
Dec 16, 2016, 6:15:52 AM12/16/16
to discuss-webrtc
Thanks for the answers Stefan ;)

So, I suppose that you will support transport-wide-cc-extensions-01 for audio RTP packets too?
Reply all
Reply to author
Forward
0 new messages