This CL adds the ability to configure RTPSender to include the
MID header extension when sending packets. The MID will be
included on every packet at the start of the stream until an RTCP
acknoledgment is received for that SSRC at which point it will
stop being included. The MID will be included on regular RTP
streams as well as RTX streams.
Bug: webrtc:4050
Change-Id: Ie27ebee1cd00a67f2b931f5363788f523e3e684f
Reviewed-on: https://webrtc-review.googlesource.com/60582
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22574}
This moves it from an API directory (system_wrappers/include/) to a
non-API directory, which is exactly what we want for utilities like
this.
BUG=webrtc:8445
Change-Id: I51dfe8879c28c91bd1c667fc47b4892373671e0f
Reviewed-on: https://webrtc-review.googlesource.com/21540
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22569}
This is a reland of 6328d7cbbc
Original change's description:
> Rework rtp packet history
>
> This CL rewrites the history from the ground up, but keeps the logic
> (mostly) intact. It does however lay the groundwork for adding a new
> mode where TransportFeedback messages can be used to remove packets
> from the history as we know the remote end has received them.
>
> This should both reduce memory usage and make the payload based padding
> a little more likely to be useful.
>
> My tests show a reduction of ca 500-800kB reduction in memory usage per
> rtp module. So with simulcast and/or fec this will increase. Lossy
> links and long RTT will use more memory.
>
> I've also slightly update the interface to make usage with/without
> pacer less unintuitive, and avoid making a copy of the entire RTP
> packet just to find the ssrc and sequence number to put into the pacer.
>
> The more aggressive culling is not enabled by default. I will
> wire that up in a follow-up CL, as there's some interface refactoring
> required.
>
> Bug: webrtc:8975
> Change-Id: I0c1bb528f32eeed0fb276b4ae77ae3235656980f
> Reviewed-on: https://webrtc-review.googlesource.com/59441
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#22347}
Bug: webrtc:8975
Change-Id: I162cb9a1eccddf567bdda7285f8296dc2f005503
Reviewed-on: https://webrtc-review.googlesource.com/60900
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Original-Commit-Position: refs/heads/master@{#22356}
Reviewed-on: https://webrtc-review.googlesource.com/61661
Cr-Commit-Position: refs/heads/master@{#22438}
Also delete the method RTPPayloadRegistry::red_payload_type() and
remnants of RED support in RTPReceiverAudio.
Bug: webrtc:8995,webrtc:5922
Change-Id: Iee310f5a8628ba70942e8c0277a856d2ca1f9b35
Reviewed-on: https://webrtc-review.googlesource.com/61500
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22425}
If 10ms delayed report is scheduled at 1.9ms (truncated by TaskQueue clock to 1ms)
it may run at 11.1ms (truncated to 11ms, i.e. first time it look like 10ms passed).
But (test) clock with different time offset may see passed time as 9ms
which result in a test failure for a wrong reason.
Relaxing period expectation by 1ms should mitigate the issue
Bug: webrtc:8945
Change-Id: I902d8af436fc74d4a3a0ad8ffdb5a6d3565adb7d
Reviewed-on: https://webrtc-review.googlesource.com/58095
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22361}
This reverts commit 7bb37b884b.
Reason for revert: Breaks downstream projects
Original change's description:
> Reland "Rework rtp packet history"
>
> This is a reland of 6328d7cbbc
>
> Original change's description:
> > Rework rtp packet history
> >
> > This CL rewrites the history from the ground up, but keeps the logic
> > (mostly) intact. It does however lay the groundwork for adding a new
> > mode where TransportFeedback messages can be used to remove packets
> > from the history as we know the remote end has received them.
> >
> > This should both reduce memory usage and make the payload based padding
> > a little more likely to be useful.
> >
> > My tests show a reduction of ca 500-800kB reduction in memory usage per
> > rtp module. So with simulcast and/or fec this will increase. Lossy
> > links and long RTT will use more memory.
> >
> > I've also slightly update the interface to make usage with/without
> > pacer less unintuitive, and avoid making a copy of the entire RTP
> > packet just to find the ssrc and sequence number to put into the pacer.
> >
> > The more aggressive culling is not enabled by default. I will
> > wire that up in a follow-up CL, as there's some interface refactoring
> > required.
> >
> > Bug: webrtc:8975
> > Change-Id: I0c1bb528f32eeed0fb276b4ae77ae3235656980f
> > Reviewed-on: https://webrtc-review.googlesource.com/59441
> > Commit-Queue: Erik Språng <sprang@webrtc.org>
> > Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#22347}
>
> Bug: webrtc:8975
> Change-Id: Ibbdbcc3c13bd58d994ad66f789a95ef9bd9bc19b
> Reviewed-on: https://webrtc-review.googlesource.com/60900
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#22356}
TBR=danilchap@webrtc.org,sprang@webrtc.org
Change-Id: Id698f5dbba6f9f871f37501d056e2b8463ebae50
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:8975
Reviewed-on: https://webrtc-review.googlesource.com/61020
Reviewed-by: Oleh Prypin <oprypin@webrtc.org>
Commit-Queue: Oleh Prypin <oprypin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22358}
This is a reland of 6328d7cbbc
Original change's description:
> Rework rtp packet history
>
> This CL rewrites the history from the ground up, but keeps the logic
> (mostly) intact. It does however lay the groundwork for adding a new
> mode where TransportFeedback messages can be used to remove packets
> from the history as we know the remote end has received them.
>
> This should both reduce memory usage and make the payload based padding
> a little more likely to be useful.
>
> My tests show a reduction of ca 500-800kB reduction in memory usage per
> rtp module. So with simulcast and/or fec this will increase. Lossy
> links and long RTT will use more memory.
>
> I've also slightly update the interface to make usage with/without
> pacer less unintuitive, and avoid making a copy of the entire RTP
> packet just to find the ssrc and sequence number to put into the pacer.
>
> The more aggressive culling is not enabled by default. I will
> wire that up in a follow-up CL, as there's some interface refactoring
> required.
>
> Bug: webrtc:8975
> Change-Id: I0c1bb528f32eeed0fb276b4ae77ae3235656980f
> Reviewed-on: https://webrtc-review.googlesource.com/59441
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#22347}
Bug: webrtc:8975
Change-Id: Ibbdbcc3c13bd58d994ad66f789a95ef9bd9bc19b
Reviewed-on: https://webrtc-review.googlesource.com/60900
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22356}
This reverts commit 6328d7cbbc.
Reason for revert: Breaks downstream build, due to use of std::pair constructor that some compilers appear to not support yet. See comment.
Original change's description:
> Rework rtp packet history
>
> This CL rewrites the history from the ground up, but keeps the logic
> (mostly) intact. It does however lay the groundwork for adding a new
> mode where TransportFeedback messages can be used to remove packets
> from the history as we know the remote end has received them.
>
> This should both reduce memory usage and make the payload based padding
> a little more likely to be useful.
>
> My tests show a reduction of ca 500-800kB reduction in memory usage per
> rtp module. So with simulcast and/or fec this will increase. Lossy
> links and long RTT will use more memory.
>
> I've also slightly update the interface to make usage with/without
> pacer less unintuitive, and avoid making a copy of the entire RTP
> packet just to find the ssrc and sequence number to put into the pacer.
>
> The more aggressive culling is not enabled by default. I will
> wire that up in a follow-up CL, as there's some interface refactoring
> required.
>
> Bug: webrtc:8975
> Change-Id: I0c1bb528f32eeed0fb276b4ae77ae3235656980f
> Reviewed-on: https://webrtc-review.googlesource.com/59441
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#22347}
TBR=danilchap@webrtc.org,sprang@webrtc.org
Change-Id: I2fa7efc7d008c56f7a8f77bc9958c19119f69de8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:8975
Reviewed-on: https://webrtc-review.googlesource.com/60880
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22350}
This CL rewrites the history from the ground up, but keeps the logic
(mostly) intact. It does however lay the groundwork for adding a new
mode where TransportFeedback messages can be used to remove packets
from the history as we know the remote end has received them.
This should both reduce memory usage and make the payload based padding
a little more likely to be useful.
My tests show a reduction of ca 500-800kB reduction in memory usage per
rtp module. So with simulcast and/or fec this will increase. Lossy
links and long RTT will use more memory.
I've also slightly update the interface to make usage with/without
pacer less unintuitive, and avoid making a copy of the entire RTP
packet just to find the ssrc and sequence number to put into the pacer.
The more aggressive culling is not enabled by default. I will
wire that up in a follow-up CL, as there's some interface refactoring
required.
Bug: webrtc:8975
Change-Id: I0c1bb528f32eeed0fb276b4ae77ae3235656980f
Reviewed-on: https://webrtc-review.googlesource.com/59441
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22347}
It holds the same information as codecType, but in different format.
Bug: webrtc:8830
Change-Id: Ia83e2dff4fd9a5ddb489501b7a1fe80759fa4218
Reviewed-on: https://webrtc-review.googlesource.com/56100
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22307}
Pass pointer to application_data from RtpPacketToSend arriving via RtpSender::SendToNetwork through to Transport::SendRtp, in PacketOptions.
Bug: webrtc:8906
Change-Id: Ie75013ed472710f4efcfbcc160e46a6119a1f41d
Reviewed-on: https://webrtc-review.googlesource.com/55600
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Dino Radaković <dinor@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22174}
Using a mock of rtp transport controller send in audio send stream unit
tests. This reduces the dependencies and makes the tests more focused
on testing the functionality of audio send stream itself.
Bug: webrtc:8415
Change-Id: Ia8d9cf47d93decc74b10ca75a6771f39df658dc2
Reviewed-on: https://webrtc-review.googlesource.com/56600
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22161}
Flakiness of the test reveals this assumption doesn't hold and shouldn't be rely on.
Currently there is no code that use it. Plans to rely on it silently adjusted.
Bug: webrtc:8610
Change-Id: Id24f2a36c8fb188b518f5301c4b278836885d140
Reviewed-on: https://webrtc-review.googlesource.com/56860
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22160}
Mark functions with override instead of virtual.
Add explicit non-trivial constructors/assign operators/destructors.
Define them in .cc files instead of inlining
use auto* instead of auto when deduced type is raw pointer
Bug: webrtc:163
Change-Id: I4d8a05d6a64fcc2ca16d02c5fcf9488fda832a6d
Reviewed-on: https://webrtc-review.googlesource.com/48781
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21927}
Rtp Packets in webrtc expected to be less that 1500,
i.e. way less that 2^16 bytes for extensions block.
This CL explicitly discards longer extension.
Bug: chromium:809046
Change-Id: Ibed33b51bafc3fd4804ec135f66110c6d2796734
Reviewed-on: https://webrtc-review.googlesource.com/48061
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Alex Loiko <aleloi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21910}
This is a reland of bbdabe50db.
Original change's description:
> Rename stereo video codec to multiplex
>
> This CL only does the rename from"stereo" to multiplex". With this we have a
> better name that doesn't clash with audio's usage of stereo.
>
> Bug: webrtc:7671
> Change-Id: Iebc3fc20839025f1bc8bcf0e16141bf9744ef652
> Reviewed-on: https://webrtc-review.googlesource.com/43242
> Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
> Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21769}
TBR=niklas.enbom@webrtc.org
Bug: webrtc:7671
Change-Id: I6f38dc46126f279f334d52b56339b40acdc30511
Reviewed-on: https://webrtc-review.googlesource.com/45820
Reviewed-by: Emircan Uysaler <emircan@webrtc.org>
Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21794}
This reverts commit 4954a77cf8.
Reason for revert: Breaks downstream build which was depending on the name "kVideoCodecStereo". Will need to do some sort of trickery to make this change without breaking the relevant code. Sorry. :(
Original change's description:
> Reland "Rename stereo video codec to multiplex"
>
> This is a reland of bbdabe50db.
> This was reverted because of breaking internal build. I contacted sheriff
> and looked at logs but cannot find anything related to this CL. This was landed
> with #3850 build which caused exception, but 3847-3855 seem to all have failed.
> I am relanding to see if it will work this time or it will give some related
> error message that can guide me.
>
> Original change's description:
> > Rename stereo video codec to multiplex
> >
> > This CL only does the rename from"stereo" to multiplex". With this we have a
> > better name that doesn't clash with audio's usage of stereo.
> >
> > Bug: webrtc:7671
> > Change-Id: Iebc3fc20839025f1bc8bcf0e16141bf9744ef652
> > Reviewed-on: https://webrtc-review.googlesource.com/43242
> > Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
> > Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#21769}
>
> TBR=niklas.enbom@webrtc.org
>
> Bug: webrtc:7671
> Change-Id: I5934abad1ce28acf02842ea8ee2af7768a826eb8
> Reviewed-on: https://webrtc-review.googlesource.com/44520
> Reviewed-by: Emircan Uysaler <emircan@webrtc.org>
> Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21780}
TBR=sprang@webrtc.org,niklas.enbom@webrtc.org,qiangchen@chromium.org,emircan@webrtc.org
Change-Id: I0a71327c2ddfdd030b1e058cd6a41b1689836719
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:7671
Reviewed-on: https://webrtc-review.googlesource.com/44621
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21783}
This is a reland of bbdabe50db.
This was reverted because of breaking internal build. I contacted sheriff
and looked at logs but cannot find anything related to this CL. This was landed
with #3850 build which caused exception, but 3847-3855 seem to all have failed.
I am relanding to see if it will work this time or it will give some related
error message that can guide me.
Original change's description:
> Rename stereo video codec to multiplex
>
> This CL only does the rename from"stereo" to multiplex". With this we have a
> better name that doesn't clash with audio's usage of stereo.
>
> Bug: webrtc:7671
> Change-Id: Iebc3fc20839025f1bc8bcf0e16141bf9744ef652
> Reviewed-on: https://webrtc-review.googlesource.com/43242
> Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
> Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21769}
TBR=niklas.enbom@webrtc.org
Bug: webrtc:7671
Change-Id: I5934abad1ce28acf02842ea8ee2af7768a826eb8
Reviewed-on: https://webrtc-review.googlesource.com/44520
Reviewed-by: Emircan Uysaler <emircan@webrtc.org>
Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21780}
This reverts commit bbdabe50db.
Reason for revert: This breaks the internal build.
Original change's description:
> Rename stereo video codec to multiplex
>
> This CL only does the rename from"stereo" to multiplex". With this we have a
> better name that doesn't clash with audio's usage of stereo.
>
> Bug: webrtc:7671
> Change-Id: Iebc3fc20839025f1bc8bcf0e16141bf9744ef652
> Reviewed-on: https://webrtc-review.googlesource.com/43242
> Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
> Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21769}
TBR=sprang@webrtc.org,niklas.enbom@webrtc.org,qiangchen@chromium.org,emircan@webrtc.org
Change-Id: Icf019cb09e07de45821d31d7d8ea7707d01346ee
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:7671
Reviewed-on: https://webrtc-review.googlesource.com/44360
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21774}
This CL only does the rename from"stereo" to multiplex". With this we have a
better name that doesn't clash with audio's usage of stereo.
Bug: webrtc:7671
Change-Id: Iebc3fc20839025f1bc8bcf0e16141bf9744ef652
Reviewed-on: https://webrtc-review.googlesource.com/43242
Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21769}
This CL is a followup to https://webrtc-review.googlesource.com/c/src/+/38481.
With the new approach we can just use the generic RTP packetizer to pass frames
over the wire as the specific info is contained within the bitstream. This makes
the new codec more modular and reduces its footprint.
Bug: webrtc:7671
Change-Id: Ib07f72a9d338e3cbfdbf39cba9891a959b5f7552
Reviewed-on: https://webrtc-review.googlesource.com/43220
Reviewed-by: Niklas Enbom <niklas.enbom@webrtc.org>
Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21753}
This prevents us from prematurely overwriting the packets in the history
if the RTT is underestimated.
Bug: webrtc:8766
Change-Id: I042e8ce74cdce2a0451596f4217779fc856b51f4
Reviewed-on: https://webrtc-review.googlesource.com/42960
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21735}
Prior to this change, in certain circumstances the RTP header length
used when creating a RedPacket was incorrect. This was due to an
assumption that a new media packet would _always_ be added to the
UlpfecGenerator's internal media packet buffer. This is not correct,
and the fix is to keep track of whatever RTP header length that is
currently correct.
Bug: webrtc:8767
Change-Id: I6d61429a19d4693dde9330f0469d13c5dfbeac52
Reviewed-on: https://webrtc-review.googlesource.com/40600
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21720}
With an extra interface it will allow to add both RtpRtcp module
and RtcpTransceiver as feedback sender to PacketRouter
Though hacky, this is very similar to currently used implementation
in the RTCPSender::SendFeedbackPacket
Bug: webrtc:8239
Change-Id: I237b422ae1594dede78cb63daa4aa42b6774d6fe
Reviewed-on: https://webrtc-review.googlesource.com/32680
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21274}
