Use an explicit list and don't add X11 dependency to rtc_base.
Allow skipping code that depends on rarer extensions such as Xdamage, Xfixes.
Bug: None
Change-Id: Icb8d20a267358f5cd3f1ff2af31a669e0670d2f6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140865
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Oleh Prypin <oprypin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28204}
While reading inpùt files until their end, the assert should be
ASSERT_TRUE.
Change-Id: Ib60b68173b58b77d9789c544c7cb647a752a24d1
Bug: webrtc:10690
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140280
Commit-Queue: Pablo Barrera González <barrerap@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28202}
In short, the caller places a x-opaque line in SDP for each m= section that
uses datagram transport. If the answerer supports datagram transport, it will
parse this line and create a datagram transport. It will then echo the x-opaque
line into the answer (to indicate that it accepted use of datagram transport).
If the offer and answer contain exactly the same x-opaque line, both peers will
use datagram transport. If the x-opaque line is omitted from the answer (or is
different in the answer) they will fall back to RTP.
Note that a different x-opaque line in the answer means the answerer did not
understand something in the negotiation proto. Since WebRTC cannot know what
was misunderstood, or whether it's still possible to use the datagram transport,
it must fall back to RTP. This may change in the future, possibly by passing
the answer to the datagram transport, but it's good enough for now.
Negotiation consists of four parts:
1. DatagramTransport exposes transport parameters for both client and server
perspectives. The client just echoes what it received from the server (modulo
any fields it might not have understood).
2. SDP adds a x-opaque line for opaque transport parameters. Identical to
x-mt, but this is specific to datagram transport and goes in each m= section,
and appears in the answer as well as the offer.
- This is propagated to Jsep as part of the TransportDescription.
- SDP files: transport_description.h,cc, transport_description_factory.h,cc,
media_session.cc, webrtc_sdp.cc
3. JsepTransport/Controller:
- Exposes opaque parameters for each mid (m= section). On offerer, this means
pre-allocating a datagram transport and getting its parameters. On the
answerer, this means echoing the offerer's parameters.
- Uses a composite RTP transport to receive from either default RTP or
datagram transport until both offer and answer arrive.
- If a provisional answer arrives, sets the composite to send on the
provisionally selected transport.
- Once both offer and answer are set, deletes the unneeded transports and
keeps whichever transport is selected.
4. PeerConnection pulls transport parameters out of Jsep and adds them to SDP.
Bug: webrtc:9719
Change-Id: Ifcc428c8d76fb77dcc8abaa79507c620bcfb31b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140920
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28198}
This reverts commit 35d4e43f169e7cb237bce9501db29ea4b69820cd.
Reason for revert: Breaks downstream.
Original change's description:
> Reland "Cleanup of video packet overhead calculation."
>
> This is a reland of 890bc3069cbababa19b40ec02684253d60e051b2
>
> The calculation was rewritten using the new Frequency type to
> avoid the division by zero error introduced by the previous CL.
>
> Original change's description:
> > Cleanup of video packet overhead calculation.
> >
> > This CL updates the video packet overhead calculation to make it more
> > clear. This prepares for future work on improving the accuracy of the
> > calculation.
> >
> > Bug: webrtc:9883
> > Change-Id: I1d623a3e0de45be7b6e4a1f9e3cbe54fd2b8a45a
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138077
> > Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> > Reviewed-by: Erik Språng <sprang@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#28040}
>
> Bug: webrtc:10674
> Change-Id: Ib5cb6f05cfa7d097f89ac6fdcf198f2fc1b26b58
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138219
> Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> Reviewed-by: Niels Moller <nisse@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28194}
TBR=nisse@webrtc.org,sprang@webrtc.org,srte@webrtc.org
Change-Id: Ib6c3c123590b815c4be12966cdae02f91c61ab34
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10674
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140889
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28195}
This is a reland of 890bc3069cbababa19b40ec02684253d60e051b2
The calculation was rewritten using the new Frequency type to
avoid the division by zero error introduced by the previous CL.
Original change's description:
> Cleanup of video packet overhead calculation.
>
> This CL updates the video packet overhead calculation to make it more
> clear. This prepares for future work on improving the accuracy of the
> calculation.
>
> Bug: webrtc:9883
> Change-Id: I1d623a3e0de45be7b6e4a1f9e3cbe54fd2b8a45a
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138077
> Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28040}
Bug: webrtc:10674
Change-Id: Ib5cb6f05cfa7d097f89ac6fdcf198f2fc1b26b58
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138219
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28194}
All usages compare the budget usage to ratios, so we can skip a few
multiplications.
Bug: webrtc:10719
Change-Id: I0205d74762043d972c087c152915e4fdd9510057
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140289
Commit-Queue: Jonas Olsson <jonasolsson@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28190}
This reverts commit 71c6482baf0ff17141c635e6a7639493db68a65c.
Reason for revert: Lands too much at once and breaks downstream tests that need to implement new interfaces first.
Original change's description:
> Implement true negotiation for DatagramTransport with fallback to RTP.
>
> In short, the caller places a x-opaque line in SDP for each m= section that
> uses datagram transport. If the answerer supports datagram transport, it will
> parse this line and create a datagram transport. It will then echo the x-opaque
> line into the answer (to indicate that it accepted use of datagram transport).
>
> If the offer and answer contain exactly the same x-opaque line, both peers will
> use datagram transport. If the x-opaque line is omitted from the answer (or is
> different in the answer) they will fall back to RTP.
>
> Note that a different x-opaque line in the answer means the answerer did not
> understand something in the negotiation proto. Since WebRTC cannot know what
> was misunderstood, or whether it's still possible to use the datagram transport,
> it must fall back to RTP. This may change in the future, possibly by passing
> the answer to the datagram transport, but it's good enough for now.
>
> Negotiation consists of four parts:
> 1. DatagramTransport exposes transport parameters for both client and server
> perspectives. The client just echoes what it received from the server (modulo
> any fields it might not have understood).
>
> 2. SDP adds a x-opaque line for opaque transport parameters. Identical to
> x-mt, but this is specific to datagram transport and goes in each m= section,
> and appears in the answer as well as the offer.
> - This is propagated to Jsep as part of the TransportDescription.
> - SDP files: transport_description.h,cc, transport_description_factory.h,cc,
> media_session.cc, webrtc_sdp.cc
>
> 3. JsepTransport/Controller:
> - Exposes opaque parameters for each mid (m= section). On offerer, this means
> pre-allocating a datagram transport and getting its parameters. On the
> answerer, this means echoing the offerer's parameters.
> - Uses a composite RTP transport to receive from either default RTP or
> datagram transport until both offer and answer arrive.
> - If a provisional answer arrives, sets the composite to send on the
> provisionally selected transport.
> - Once both offer and answer are set, deletes the unneeded transports and
> keeps whichever transport is selected.
>
> 4. PeerConnection pulls transport parameters out of Jsep and adds them to SDP.
>
> Bug: webrtc:9719
> Change-Id: Id8996eb1871e79d93b7923a5d7eb3431548c798d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140700
> Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28182}
TBR=steveanton@webrtc.org,mellem@webrtc.org,sukhanov@webrtc.org
Change-Id: I0d502c4a6d27516c35ed85154f3fa5869f88b3b7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9719
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140822
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28188}
This fires in downstream tests when re-negotiation of a datagram
transport completes.
Bug: webrtc:9719
Change-Id: Ie7337e7dc33e41a83da37d3ef2fda596d9107256
No-Try: True
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140821
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28183}
In short, the caller places a x-opaque line in SDP for each m= section that
uses datagram transport. If the answerer supports datagram transport, it will
parse this line and create a datagram transport. It will then echo the x-opaque
line into the answer (to indicate that it accepted use of datagram transport).
If the offer and answer contain exactly the same x-opaque line, both peers will
use datagram transport. If the x-opaque line is omitted from the answer (or is
different in the answer) they will fall back to RTP.
Note that a different x-opaque line in the answer means the answerer did not
understand something in the negotiation proto. Since WebRTC cannot know what
was misunderstood, or whether it's still possible to use the datagram transport,
it must fall back to RTP. This may change in the future, possibly by passing
the answer to the datagram transport, but it's good enough for now.
Negotiation consists of four parts:
1. DatagramTransport exposes transport parameters for both client and server
perspectives. The client just echoes what it received from the server (modulo
any fields it might not have understood).
2. SDP adds a x-opaque line for opaque transport parameters. Identical to
x-mt, but this is specific to datagram transport and goes in each m= section,
and appears in the answer as well as the offer.
- This is propagated to Jsep as part of the TransportDescription.
- SDP files: transport_description.h,cc, transport_description_factory.h,cc,
media_session.cc, webrtc_sdp.cc
3. JsepTransport/Controller:
- Exposes opaque parameters for each mid (m= section). On offerer, this means
pre-allocating a datagram transport and getting its parameters. On the
answerer, this means echoing the offerer's parameters.
- Uses a composite RTP transport to receive from either default RTP or
datagram transport until both offer and answer arrive.
- If a provisional answer arrives, sets the composite to send on the
provisionally selected transport.
- Once both offer and answer are set, deletes the unneeded transports and
keeps whichever transport is selected.
4. PeerConnection pulls transport parameters out of Jsep and adds them to SDP.
Bug: webrtc:9719
Change-Id: Id8996eb1871e79d93b7923a5d7eb3431548c798d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140700
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28182}
As this is handled higher up the pipeline in a single
place for all encoders/decoders
Bug: webrtc:10460
Change-Id: I95b0a69aecaf07283c8776ac0d7e85d097e3576b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139882
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28172}
In several places VideoFrame::Builder is used to create a new VideoFrame
when intent is to change only one or two fields of a const VideoFrame&.
This approach is bad because each and every metadata field have to be
added to all the places.
Instead, this CL adds missing setters and refactors the code to use
full copy of a VideoFrame and update required fields only.
Along the way few actual bugs are fixed, e.g. when ColorSpace isn't copied
when frame rotation or buffer is cropped or converted.
Bug: webrtc:10460
Change-Id: I2895a473ca938b150eed2916c689060bdf58cb25
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140102
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28170}
Using this flag, an encoder may inform the RTP sender module that
the packet is not elligible for retransmission. Specifically, it
may not be retransmitted in response to a NACK message,
nor because of early loss detection (see CL #135881).
Bug: webrtc:10702
Change-Id: Ib6a9cc361cf10ea7214cf672e05940c27899a6be
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140105
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28169}
Some of the TODOs associated with webrtc:10336 which are
currently in the codebase have recently been resolved,
but not all relevant TODOs have been removed.
TBR=kwiberg@webrtc.org
Bug: webrtc:10336
Change-Id: Iff1d0fc94dee5bf49226f6ea3d9127fea77e9d68
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139902
Reviewed-by: Elad Alon <eladalon@webrtc.org>
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28167}
Replaced by separate methods
SendPictureLossIndication and SendFullIntraRequest.
The split SetKeyFrameRequestMethod/RequestKeyFrame implicitly
requires that the two methods are called on the same thread, to avoid a
data race. After downstream code is updated, both deprecated
methods and the member |ModuleRtpRtcpImpl::key_frame_req_method_| can
be deleted.
Bug: None
Change-Id: I454f6d16b667f2306cba0dec467ddc183ad449c8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140043
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28163}
Reset() is called each time the encoder is reconfigured, but then it
happens the target bitrate isn't reset in encoder. So it might produce a
frame before next bitrate estimate is propagated to the metadata writer.
The incorrect zero bitrate would be treated as a paused encoder and would
cause metadata to be dropped.
Also, added unittest for that scenario at VideoStreamEncoder level.
Bug: webrtc:10460
Change-Id: I28024a527f1fb8474b172e2c5c2394fd38d69a07
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140101
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28159}
