These factories suppose to replace set of old constexpr factories that
takes parameter as template rather than function parameter,
as well as fix function naming to follow style guide of the second set
of factory functions.
Bug: None
Change-Id: Icd76302b821b2a4027f9d6765cf91bc9190f551c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/167521
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30482}
This patch exposes webrtc::PeerConnectionDependencies c++-object
and makes it possible to supply one when creating a PeerConnection.
This makes it possible to e.g inject a VideoBitrateAllocatorFactory.
Bug: webrtc:10547
Change-Id: Ib7431bdcec1380e7903dc5f66f3583501aeab0a5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168307
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Anders Carlsson <andersc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30480}
This is a reland of 4f68f5398d7fa3d47c449e99893c9bea07bf7ca2
Original change's description:
> Remove PlayoutDelayOracle and make RtpSenderVideo guarantee delivery
>
> The PlayoutDelayOracle was responsible for making sure the PlayoutDelay
> header extension was successfully propagated to the receiving side. Once
> it was determined that the receiver had received a frame with the new
> delay tag, it's no longer necessary to propagate.
>
> The issue with this implementation is that it is based on max
> extended sequence number reported via RTCP, which makes it often slow
> to react, could theoretically fail to produce desired outcome (max
> received > X does not guarantee X was fully received and decoded), and
> added a lot of code complexity.
>
> The guarantee of delivery can in fact be accomplished more reliably and
> with less code by making sure to tag each frame until an undiscardable
> frame is sent.
>
> This allows containing the logic fully within RTPSenderVideo.
>
> Bug: webrtc:11340
> Change-Id: I2d1d2b6b67f4f07b8b33336f8fcfcde724243eef
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168221
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30473}
TBR=stefan@webrtc.org
Bug: webrtc:11340
Change-Id: I2fdd0004121b13b96497b21e052359e31d0c477a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168305
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30479}
This CL only includes the necessary changes in PhysicalSocketServer,
and doesn't include the Java or Objective C API.
Note that this is doing exactly the same thing as UDPSocketPosix
in chromium.
BUG=webrtc:5658
Change-Id: I295455eaccba2a83cdd1bc55848f325c310f8d32
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168260
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Commit-Queue: Taylor <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30478}
This is in preparation of an upcoming CL that will propagate this
information through the TransportFeedbackAdapter.
Bug: webrtc:10932
Change-Id: Ic2a026b5ef72d6bf01e698e7634864fedc659b4e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168220
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30476}
This reverts commit 4f68f5398d7fa3d47c449e99893c9bea07bf7ca2.
Reason for revert: Breaks downstream project
Original change's description:
> Remove PlayoutDelayOracle and make RtpSenderVideo guarantee delivery
>
> The PlayoutDelayOracle was responsible for making sure the PlayoutDelay
> header extension was successfully propagated to the receiving side. Once
> it was determined that the receiver had received a frame with the new
> delay tag, it's no longer necessary to propagate.
>
> The issue with this implementation is that it is based on max
> extended sequence number reported via RTCP, which makes it often slow
> to react, could theoretically fail to produce desired outcome (max
> received > X does not guarantee X was fully received and decoded), and
> added a lot of code complexity.
>
> The guarantee of delivery can in fact be accomplished more reliably and
> with less code by making sure to tag each frame until an undiscardable
> frame is sent.
>
> This allows containing the logic fully within RTPSenderVideo.
>
> Bug: webrtc:11340
> Change-Id: I2d1d2b6b67f4f07b8b33336f8fcfcde724243eef
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168221
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30473}
TBR=sprang@webrtc.org,stefan@webrtc.org,srte@webrtc.org
Change-Id: Ide922e680ae36bb69b95e58002482cf5ed57e254
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11340
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168304
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30475}
The PlayoutDelayOracle was responsible for making sure the PlayoutDelay
header extension was successfully propagated to the receiving side. Once
it was determined that the receiver had received a frame with the new
delay tag, it's no longer necessary to propagate.
The issue with this implementation is that it is based on max
extended sequence number reported via RTCP, which makes it often slow
to react, could theoretically fail to produce desired outcome (max
received > X does not guarantee X was fully received and decoded), and
added a lot of code complexity.
The guarantee of delivery can in fact be accomplished more reliably and
with less code by making sure to tag each frame until an undiscardable
frame is sent.
This allows containing the logic fully within RTPSenderVideo.
Bug: webrtc:11340
Change-Id: I2d1d2b6b67f4f07b8b33336f8fcfcde724243eef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168221
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30473}
This CL changes EncodeUsageResource and QualityScalerResource from
private inner classes of OveruseFrameDetectorResourceAdaptationModule to
standalone classes, moving them into separate files.
This CL does not intend to change any lines of code, only move them.
Except for removing an unused method quality_scaler().
Bug: webrtc:11222
Change-Id: I86bf7eb78c80031888c403ac43c2bdf9b24eaea6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168198
Reviewed-by: Evan Shrubsole <eshr@google.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30472}
The Resource interface (previously a skeleton not used outside of
testing) is updated to inform listeners of changes to resource
usage. Debugging methods are removed (Name, UsageUnitsOfMeasurements,
CurrentUsage). The interface is implemented by
OveruseFrameDetectorResourceAdaptationModule's inner classes
EncodeUsageResource and QualityScalerResource.
The new ResourceUsageListener interface is implemented by
OveruseFrameDetectorResourceAdaptationModule. In order to avoid adding
AdaptationObserverInterface::AdaptReason to the ResourceUsageListener
interface, the module figures out if the reason is "kCpu" or "kQuality"
by looking which Resource object triggered
OnResourceUsageStateMeasured(). These resources no longer need an
explicit reference to OveruseFrameDetectorResourceAdaptationModule and
could potentially be used by a different module.
In this CL, AdaptationObserverInterface::AdaptDown()'s return value is
still needed by QualityScaler. This is mirrored in the return value of
ResourceUsageListener::OnResourceUsageStateMeasured(). A TODO is added
to remove it and a comment explains how the current implementation
seems to break the contract of the method (as was the case prior to
this CL).
Follow-up work include:
- Move EncodeUsageResource and QualityScalerResource to separate files.
- Make resources injectable, allowing fake resources in testing and
removing OnResourceOveruseForTesting() methods.
(Investigate adding the necessary input signals to the Resource
interface or relevant sub-interfaces so that the module does not need
to know which Resource implementation is used.)
- And more! See whiteboard :)
Bug: webrtc:11222
Change-Id: I0a46ace4a2e617874e3ee97e67e3a199fef420a2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168180
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#30469}
This refactors the usage of OveruseFrameDetector in
OveruseFrameDetectorResourceAdaptationModule into an inner class of the
module, making the interaction between the detector and the module the
responsibility of this helper class instead.
Similarly, QualityScaler usage is moved into QualityScalerResource.
This takes us one step closer to separate the act of detecting
overuse/underuse of a resource and the logic of what to do when
overuse/underuse happens.
Follow-up CLs should build on this in order to materialize the concept
of having resources, streams and a central decision-maker deciding how
to reconfigure the streams based on resource usage state.
Bug: webrtc:11222
Change-Id: I99a08a42218a871db8f477f31447a6379433ad05
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168057
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30468}
This is a reland of af51be7869994a299451e22e6382ae641767b26d
Original change's description:
> Reland "Reland "Implemented screen enumeration and selection for desktop capture under X11 using the X Resize and Rotate extension version 1.5.""
>
> This is a reland of a0adf3d4409036d095480e9bfa0fc06990362f84
>
> Original change's description:
> > Reland "Implemented screen enumeration and selection for desktop capture under X11 using the X Resize and Rotate extension version 1.5."
> >
> > This is a reland of e7153012682ccd3d1eacc18f802cab7820e3bad3
> >
> > Original change's description:
> > > Implemented screen enumeration and selection for desktop capture under X11 using the X Resize and Rotate entension version 1.5.
> > >
> > > Bug: chromium:396091
> > > Change-Id: Ia1b36c771632c536bb8d15322461b479fabc409e
> > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/148768
> > > Commit-Queue: Sergey Ulanov <sergeyu@chromium.org>
> > > Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#29083}
> >
> > Bug: chromium:396091
> > Change-Id: I0d9171ae5f340e0489e4b45ce5d97bc52b0a4904
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/156067
> > Commit-Queue: Tommi <tommi@webrtc.org>
> > Reviewed-by: Tommi <tommi@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#29655}
>
> Bug: chromium:396091
> Change-Id: I47525911095fabc6cee613d03b0d83134b95b084
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158900
> Reviewed-by: Tomas Gunnarsson <tommi@chromium.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Commit-Queue: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30032}
Bug: chromium:396091
Change-Id: I03702c8ea935bb5fe1797defda1ba6b279b95217
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165724
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#30461}
This accessor seems to be unused, and has a name that we don't
want to support ("content_name").
Bug: none
Change-Id: I2f332176429dd8e1895f821d30e4beaaa4650ec2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168195
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30460}
This makes it safe to deliver frames to the sink from VideoProcessor
even after setSink has been called with null reference without danger
of use after free.
Bug: b/148063550
Change-Id: Ib78f75ac49fc6117f744c55da1a4e671bbdcdf22
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168160
Reviewed-by: Paulina Hensman <phensman@webrtc.org>
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30455}
Move definitions of mock classes to the only user, the unit tests for
the deprecated class vcm::VideoReceiver.
Bug: webrtc:7408
Change-Id: I05e38ed8ebbe615bb2db0b631ec914773fb0a520
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168182
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30451}
The AsyncTCPSocket is an AsyncPacketSocket which means it
emulates UDP-like (packet) semantics via a TCP stream. When
sending, if the entire packet could not be written then the
packet socket should indicate it wrote the whole thing and
flush out the remaining later when the socket is available.
The WriteEvent signal was already wired up but was not getting
fired (at least with the virtual sockets) since it would not
call Send() enough on the underlying socket to get an
EWOULDBLOCK that would register the async event.
This changes AsyncTCPSocket to repeatedly call Send() on the
underlying socket until the entire packet has been written
or EWOULDBLOCK was returned.
Bug: webrtc:6655
Change-Id: I41e81e0c106c9b3e712a8a0f792d28745d93f2d2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168083
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30449}
The specification of experiemental RTP header extensions have previously
been located at Github. Move the specs here and folloup with redirection
of the new website to this place to make sure that the existing URLs on
the format webrtc.org/experiements/rtp_hdrext continue to work.
Bug: webrtc:11335
Change-Id: I7735e259a7dd6cd2fa7bbc09fa3c0ff460057e52
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168126
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30447}
It would be nice for this to stay in video stream encoder,
but this feature is mostly related to quality scaling. Perhaps
something easier to understand is possible in the future.
Bug: webrtc:11222
Change-Id: I71705f33ff94bbcf2fb9b5c94226c8e76dcba94c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168051
Commit-Queue: Evan Shrubsole <eshr@google.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30446}
number of references can't be invalid if gof was correctly parsed
from a vp9 packet, but RtpFrameReferenceFinder still better be
protected from the invalid data.
Bug: chromium:1048013
Change-Id: I548f5c87199421b7736409cbcacbec760ad799ae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168124
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30444}
This will be used by WebRTC tests. It converts results exactly the
same as our downstream implementation (histogram_util).
This implementation should be pretty feature complete, or at least
enough to start testing the end-to-end flow. I will set up some
experimental recipe code and see if this actually makes it into the
dashboard.
Note: needs some catapult changes to land first and be rolled
into Chromium, and then WebRTC.
Bug: chromium:1029452
Change-Id: I939046929652fc27b8fcb18af54bde22886d9228
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166172
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30436}
