This is a race that can happen if a nack arrives before media is
disabled, but the packet is not processed until after the disabling
is complete.
Bug: webrtc:10633, b/138636698
Change-Id: Ic90462b815163ab58c324e5cdb95c8d199c0b772
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147277
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28718}
Use the newly added total_decode_time_ms to get an accurate value
for the average decode time. The sparsely sampled decode_ms is
sensitive to the sampling instance.
Bug: chromium:980853
Change-Id: I9b63c8d1053fa95f74918807b83d1edb5cd726fb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147268
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28716}
It's planned to be deprecated so it should not be required.
Bug: webrtc:9883
Change-Id: I7daa922786d3cbf6bca38e205f4f57773f3f8448
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147275
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28715}
This field trial was read in RTPSender, and the altered packet size
passed along to the pacer. Now, the pacer packet queue looks directly
at the packet instance, so it needs to be aware of the experiment flag
in order to make the right decision.
Bug: webrtc:10633, b/138582168
Change-Id: If1148f39c463e11ad49a659913465f131cf9b526
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147270
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28714}
This change includes windows owned by the primary captured window in the
captured frames if these conditions are met:
1) The owned window (e.g. dialog) overlaps the primary window (in whole
or part)
2) The primary window is otherwise eligible for the crop-from-screen
path (CroppingWindowCapturer is being used, and other conditions in
ShouldUseScreenCapturer are met)
In practice, this means that dialog windows / message boxes are captured
in many cases where they aren't today. This seems beneficial to some
scenarios (e.g. demonstrating / recording how to do something, or
requesting help with something, that involves dialogs).
This is a logical revert of a change for https://crbug.com/webrtc/8062 .
There's some commentary in the newer bug that attempts to make a case
for revisiting that change. (In summary: cases where a dialog would be
substantialy clipped / partial seem relatively uncommon and have
workarounds. Clipping may already occur for menus & tooltips. Clipping
seems less surprising than complete absence.)
Changing the GA_ROOT flag back to GA_ROOTOWNER is sufficient to restore
the older behavior. The removal of the EnumChildWindows call is just a
minor optimization (it was unnecessary/superfluous, since every child
window would match the GA_ROOT check; dialogs are owned root windows,
not child windows).
Removing condition (2) above (capturing dialogs & other related
overlapping windows when not using the crop-from-screen path) is tracked
by https://crbug.com/980864 .
Bug: webrtc:10767
Change-Id: If7b418365685a7b96dc93901ef9367844f9ee99e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147421
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#28711}
We've observed a crash on Windows when the strings are empty, skipping the conversion seems reasonable in that case.
Bug: None
Change-Id: I3acf3060a88741fb750d7a0cc02e9422713c59cd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147380
Commit-Queue: Noah Richards <noahric@chromium.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28709}
The PacedSender is being reworked and will need an interface so we can
inject different implementations of it.
This CL introduces a new RtpPacketPacer interface inside the pacing
module. This interface handles the details of _how_ packets should be
paced, such as pacing rates/account for audio/max queue length etc.
The RtpPacketSender interface exposed from the rtp_rtcp module handles
only the actual sending of packets.
Some minor cleanups are included here.
Bug: webrtc:10809
Change-Id: I150b1a6262306d99e3f9d5f0b4afdb16a50e5ad8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145212
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28699}
That method will be retired, but some new tests managed to sneak in
usage again.
Bug: webrtc:10774
Change-Id: I354b4f5193625c8ddc75d54a252360810c3f60c8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146983
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28697}
This prepares for using VideoFrameBuffer::Type as
FrameGenerator::OutputType, which will reduce the
number of redundant enums in the code.
Bug: webrtc:9883
Change-Id: I253f5f1ea7181e02a5cf1a92925f51da8ada6aa2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146982
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28696}
Currently, apps using WebRTC for window capture only get the benefits of
using CroppingWindowCapturer on Windows (described below) after changing
calls to DesktopCapturer::CreateWindowCapturer to instead call
CroppingWindowCapturer::CreateCapturer. This change adds a new flag to
DesktopCaptureOptions to allow opting in to the faster capture-screen-
and-crop path via the older & more discoverable API.
Benefits of using CroppingWindowCapturer's capture-screen-and-crop path
when possible:
1) It's significantly faster, up to ~36ms/frame (~160x) faster than the
capture-window-contents path in my testing (more details are in the
bug). This difference increased with the recent fix for
https://crbug.com/webrtc/10734 .
2) It allows capture of menus & tooltips (plus dialogs if
https://crbug.com/webrtc/10767 is fixed), partially mitigating
https://crbug.com/980864 .
Downsides of using it:
1) It may inadvertently capture occluding windows that aren't detected
properly, e.g. some system UI: https://crbug.com/webrtc/10835 .
2) It may capture some neighboring regions when moving/resizing the
captured window.
The new flag is not enabled by default, so the default behavior is
unchanged. This could perhaps be revisited after addressing
https://crbug.com/webrtc/10835 .
Bug: webrtc:10825
Change-Id: Ib77e5facc7240c5df311fe1fe204d0d8ea22a96a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146823
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#28695}
This change makes CroppingWindowCapturer::CreateCapturer respect the
detect_updated_region flag if set in the options it's passed on Windows.
Frames captured by the created capturer will now make changes available
via DesktopFrame.updated_region().
Bug: webrtc:10833
Change-Id: Ib973bc58745ebf6e216a7b31f82abec3c6dc9556
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147002
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#28694}
Both test and prod setups may use several signaling threads,
this CL prevents race conditions on GenerateUniqueId().
Bug: webrtc:9849
Change-Id: Iaec98b7b4f99729a9ad0642873a5d87de252cb1a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147020
Commit-Queue: Yves Gerey <yvesg@google.com>
Commit-Queue: Seth Hampson <shampson@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28692}
By design:
* OnPacketAdded() is meant to be called on pacer thread.
* Reconfigure() is meant to be called on worker thread.
Thus we guard against race condition on config_ member.
Possible downside: packet filtering based on ssrc might be slowed down.
Bug: webrtc:9849
Change-Id: I734bb9b34b01db160705897adb1b58e866e12639
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146980
Commit-Queue: Yves Gerey <yvesg@google.com>
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28691}
This is experimental field trial to exclude transport sequence number from FEC packets and should only be used in conjunction with datagram transport. Datagram transport removes transport sequence numbers from RTP packets and uses datagram feedback loop to re-generate RTCP feedback packets, but FEC contorol packets are calculated before sequence number is removed and as a result recovered packets will be corrupt unless we also remove transport sequence number during FEC calculations.
This change is a bit embarrassing, but it was the easiest workaround we found to make FEC work with datagrams. Added TODO to find better long term solution.
TODO(sukhanov): We need to find find better way to implement FEC with datagram transport, probably moving FEC to datagram integration layter. Wealso remove special field trial once we switch datagram path from RTCConfiguration flags to field trial and use the same field trial for FECworkaround.
Bug: webrtc:9719
Change-Id: I1e23c56e3cbaa087460410942fb6c5b4921a763e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146221
Commit-Queue: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28686}
These RTP header extensions are used for Unified Plan SDP / BUNDLE and
replace SSRC signaling.
Previously, the RTPSender would attach these header extensions to every
packet when configured. Now, the header extensions will be attached to
every packet until the an RTCP RR is received on that SSRC which
indicates the receiver knows what MID/RID the SSRC is associated with.
This should reduce overhead by 2-4 bytes per packet when the MID header
extension is used and by 4-8 bytes when both header extensions are used.
Bug: webrtc:10078
Change-Id: I5fa3ce28a75224adf11d2792bf4ff8dc76e46d99
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146480
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28685}
packet_size() includes the size of padding, this means that the size
check might incorrectly not trigger even if the payload is empty. In
turn this means that the ReadBigEndian call might read out of bounds
memory.
Refactored the code to reuse the App parsing code more, eliminating
the risk of this particular kind of error.
Bug: chromium:987507
Change-Id: Id8f3e292c3d30460d3cdb551f0a45070fdf8f022
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146716
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28680}
Perf dashboard show a very minor change with the new pacer, for tests
that use flexfec. I have found that previously fec was in fact
prioritized at the same level as video, see eg PacketTypeToPriority()
in RTPSender.
With the new pacer we put fec in between video and padding.
Not sure if this is in fact an actual problem. In the non-loss case
the frame latency should actually be slighly lower, but on the other
hand if we have loss fec won't be applied until after the full frame
has been sent and so we may end up sending NACK before we apply the
FEC and recover a packet.
Just to avoid any problems let's revert to the old behavior.
Bug: webrtc:10633
Change-Id: I9a4210a64165a6e376c0c70ccaa07b0688cc58a5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146714
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28678}
This reverts commit fab3460a821abe336ab610c6d6dfc0d392dac263.
Reason for revert: fix downstream instead
Original change's description:
> Revert "Reland "Add plumbing of RtpPacketInfos to each AudioFrame as input for SourceTracker.""
>
> This reverts commit 9973933d2e606d64fcdc753acb9ba3afd6e30569.
>
> Reason for revert: breaking downstream projects and not reviewed by direct owners
>
> Original change's description:
> > Reland "Add plumbing of RtpPacketInfos to each AudioFrame as input for SourceTracker."
> >
> > This reverts commit 24192c267a40eb7d6b1850489ccdbf7a84f8ff0f.
> >
> > Reason for revert: Analyzed the performance regression in more detail.
> >
> > Most of the regression comes from the extra RtpPacketInfos-related memory allocations in every `NetEq::GetAudio()` call. Commit 1796a820f60cb9429bf4bcf13a40a41794ac8fb0 has removed roughly 2/3rds of the extra allocations from the impacted perf tests. Remaining perf impact is expected to be about "8 microseconds of CPU time per second" on the Linux benchmarking machines and "15 us per second" on Windows/Mac.
> >
> > There are options to optimize further but they are unlikely worth doing. Note for example that `NetEqPerformanceTest` uses the PCM codec while the real-world use cases would likely use the much heavier Opus codec. The numbers from `OpusSpeedTest` and `NetEqPerformanceTest` suggest that Opus decoding is about 10x as expensive as NetEq overall.
> >
> > Original change's description:
> > > Revert "Add plumbing of RtpPacketInfos to each AudioFrame as input for SourceTracker."
> > >
> > > This reverts commit 3e8ef940fe86cf6285afb80e68d2a0bedc631b9f.
> > >
> > > Reason for revert: This CL causes a performance regression in NetEq, see https://bugs.chromium.org/p/chromium/issues/detail?id=982260.
> > >
> > > Original change's description:
> > > > Add plumbing of RtpPacketInfos to each AudioFrame as input for SourceTracker.
> > > >
> > > > This change adds the plumbing of RtpPacketInfo from ChannelReceive::OnRtpPacket() to ChannelReceive::GetAudioFrameWithInfo() for audio. It is a step towards replacing the non-spec compliant ContributingSources that updates itself at packet-receive time, with the spec-compliant SourceTracker that will update itself at frame-delivery-to-track time.
> > > >
> > > > Bug: webrtc:10668
> > > > Change-Id: I03385d6865bbc7bfbef7634f88de820a934f787a
> > > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139890
> > > > Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> > > > Reviewed-by: Minyue Li <minyue@webrtc.org>
> > > > Commit-Queue: Chen Xing <chxg@google.com>
> > > > Cr-Commit-Position: refs/heads/master@{#28434}
> > >
> > > TBR=kwiberg@webrtc.org,stefan@webrtc.org,minyue@webrtc.org,chxg@google.com
> > >
> > > Bug: webrtc:10668, chromium:982260
> > > Change-Id: I5e2cfde78c59d1123e21869564d76ed3f6193a5c
> > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145339
> > > Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
> > > Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
> > > Cr-Commit-Position: refs/heads/master@{#28561}
> >
> > TBR=kwiberg@webrtc.org,stefan@webrtc.org,ivoc@webrtc.org,minyue@webrtc.org,chxg@google.com
> >
> > # Not skipping CQ checks because original CL landed > 1 day ago.
> >
> > Bug: webrtc:10668, chromium:982260
> > Change-Id: Ie375a0b327ee368317bf3a04b2f1415c3a974470
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146707
> > Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> > Commit-Queue: Chen Xing <chxg@google.com>
> > Cr-Commit-Position: refs/heads/master@{#28664}
>
> TBR=kwiberg@webrtc.org,stefan@webrtc.org,ivoc@webrtc.org,minyue@webrtc.org,chxg@google.com
>
> Change-Id: I652cb0814d83b514d3bee34e65ca3bb693099b22
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:10668, chromium:982260
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146712
> Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
> Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28671}
TBR=alessiob@webrtc.org,kwiberg@webrtc.org,stefan@webrtc.org,ivoc@webrtc.org,minyue@webrtc.org,chxg@google.com
Change-Id: Id43b7b3da79b4f48004b41767482bae1c1fa1e16
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10668, chromium:982260
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146713
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28672}
This reverts commit 9973933d2e606d64fcdc753acb9ba3afd6e30569.
Reason for revert: breaking downstream projects and not reviewed by direct owners
Original change's description:
> Reland "Add plumbing of RtpPacketInfos to each AudioFrame as input for SourceTracker."
>
> This reverts commit 24192c267a40eb7d6b1850489ccdbf7a84f8ff0f.
>
> Reason for revert: Analyzed the performance regression in more detail.
>
> Most of the regression comes from the extra RtpPacketInfos-related memory allocations in every `NetEq::GetAudio()` call. Commit 1796a820f60cb9429bf4bcf13a40a41794ac8fb0 has removed roughly 2/3rds of the extra allocations from the impacted perf tests. Remaining perf impact is expected to be about "8 microseconds of CPU time per second" on the Linux benchmarking machines and "15 us per second" on Windows/Mac.
>
> There are options to optimize further but they are unlikely worth doing. Note for example that `NetEqPerformanceTest` uses the PCM codec while the real-world use cases would likely use the much heavier Opus codec. The numbers from `OpusSpeedTest` and `NetEqPerformanceTest` suggest that Opus decoding is about 10x as expensive as NetEq overall.
>
> Original change's description:
> > Revert "Add plumbing of RtpPacketInfos to each AudioFrame as input for SourceTracker."
> >
> > This reverts commit 3e8ef940fe86cf6285afb80e68d2a0bedc631b9f.
> >
> > Reason for revert: This CL causes a performance regression in NetEq, see https://bugs.chromium.org/p/chromium/issues/detail?id=982260.
> >
> > Original change's description:
> > > Add plumbing of RtpPacketInfos to each AudioFrame as input for SourceTracker.
> > >
> > > This change adds the plumbing of RtpPacketInfo from ChannelReceive::OnRtpPacket() to ChannelReceive::GetAudioFrameWithInfo() for audio. It is a step towards replacing the non-spec compliant ContributingSources that updates itself at packet-receive time, with the spec-compliant SourceTracker that will update itself at frame-delivery-to-track time.
> > >
> > > Bug: webrtc:10668
> > > Change-Id: I03385d6865bbc7bfbef7634f88de820a934f787a
> > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139890
> > > Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> > > Reviewed-by: Minyue Li <minyue@webrtc.org>
> > > Commit-Queue: Chen Xing <chxg@google.com>
> > > Cr-Commit-Position: refs/heads/master@{#28434}
> >
> > TBR=kwiberg@webrtc.org,stefan@webrtc.org,minyue@webrtc.org,chxg@google.com
> >
> > Bug: webrtc:10668, chromium:982260
> > Change-Id: I5e2cfde78c59d1123e21869564d76ed3f6193a5c
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145339
> > Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
> > Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#28561}
>
> TBR=kwiberg@webrtc.org,stefan@webrtc.org,ivoc@webrtc.org,minyue@webrtc.org,chxg@google.com
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> Bug: webrtc:10668, chromium:982260
> Change-Id: Ie375a0b327ee368317bf3a04b2f1415c3a974470
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146707
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Commit-Queue: Chen Xing <chxg@google.com>
> Cr-Commit-Position: refs/heads/master@{#28664}
TBR=kwiberg@webrtc.org,stefan@webrtc.org,ivoc@webrtc.org,minyue@webrtc.org,chxg@google.com
Change-Id: I652cb0814d83b514d3bee34e65ca3bb693099b22
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10668, chromium:982260
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146712
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28671}
