convert almost all of video/ (and the collateral)
Bug: webrtc:10335
Change-Id: Ic94e05937f54d11ee8a635b6b66fd146962d9f11
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/254601
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36192}
This change switches the sequence used by the FrameCadenceAdapter
to be the encoder_queue, enabling VideoStreamEncoder::OnFrame to be
invoked directly on the encoder_queue and eliminates the contained
PostTasks.
Bug: chromium:1255737
Change-Id: Ib86fc96ad2be9a38585fef2535855e3f9cc7e57c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238171
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35380}
VideoStreamEncoder receives frames on an undefined threading
context with the only requirement being that frames are serially
arriving. This CL changes this to post all frames arriving at the
FrameCadenceAdapter to the worker thread before further
processing, transitively leading to frame entry into the
VideoStreamEncoder on the worker thread.
Bug: chromium:1255737
Change-Id: I04d69cb4a5048d671d2dcd3bd6d669fbcda52b3f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237142
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35320}
This change introduces a new FrameCadenceAdapter class which takes the
role of being a VideoFrameSinkInterface<> instead of VideoStreamEncoder.
The FrameCadenceAdapter will see its functionality grow in future CLs
and eventually enable screenshare capture sources to have zero hertz as
the minimum capture frequency.
This CL moves logic related to UMA collection and constraints into the
adapter.
The adapter has two major modes. Future functionality is planned to be
added under the WebRTC-ZeroHertzScreenshare field trial. Unit tests are
added that verify passthrough operation when WebRTC-ZeroHertzScreenshare
isn't specified or disabled.
Just specifying the WebRTC-ZeroHertzScreenshare field trial isn't
enough to activate the feature, but the caller has to additionally
configure screen content type, minimum FPS 0, and maximum FPS > 0 for
the new mode.
go/rtc-0hz-present
Bug: chromium:1255737
Change-Id: I1799110ed40843152786ad80df10acfb83a608b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236682
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35315}
The sequences of threads entering the VideoStreamEncoder has been
unclear. Fix this by renaming the uninformational |main_queue_| to
|worker_queue_|, and introduce a new |network_queue_| which is set
on construction.
Bug: chromium:1255737
Change-Id: Ic4d3a5b8188b8cc98e60b72aee2c09c9afbc7356
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236523
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35283}
After a send stream is stopped, it can still be re-used and implicitly
restarted by activating layers. This change removes marking the flag
we use for async operations as 'not alive' inside Stop() and only doing
so when the send stream is stopped permanently.
The effect this has is that an implicit start via
UpdateActiveSimulcastLayers() will run and correctly update the states.
Before, if a stream had been stopped, the safety flag would prevent
the async operation from running.
Bug: chromium:1241213
Change-Id: Iebdfabba3e1955aafa364760eebd4f66281bcc60
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229304
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34809}
When implicit start/stop happens via activation/deactivation of layers
occurs, don't change the state of the 'alive' flag since further
activations following full de-activation need to be allowed to happen
when Stop() has not been called.
Bug: chromium:1234779
Change-Id: Ic3cae387990122eaa2f48de096ff9dafa7c34414
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228242
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34698}
When layers are activated/deactivated via UpdateActiveSimulcastLayers,
the flag wasn't being updated. This resulted in calls to Stop() getting
ignored after an implicit start via activating layers.
Bug: chromium:1234779
Change-Id: I4a72e624874526d27d3e97d6903112367c5e77fb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227700
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34654}
This change achieves an Idle Wakeup savings of 200 Hz.
ModuleRtcRtcpImpl2 had Process() logic only active if TMMBR() is
enabled in RtcpSender, which it never is. Hence the Module
inheritance could be removed. The change removes all known
dependencies of the module inheritance, and any related mentions
of ProcessThread.
Fixed: webrtc:11581
Change-Id: I440942f07187fdb9ac18186dab088633969b340e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222604
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34358}
UpdateActiveSimulcastLayers has been blocking
WebRtcVideoChannel::SetSend which may be called quite frequently during
negotiations. This CL changes UpdateActiveSimulcastLayers to not
synchronize with the transport's task queue to wait for the changes to
get applied.
This synchronization is quite costly, but so too are other remaining
things in VideoSendStream, so we should aim to get rid of the
`thread_sync_event_` in VideoSendStream.
Bug: webrtc:12840, webrtc:12854
Change-Id: Idb48d29b6b8382881c7c1e6f1d0f5e708dbca30f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221203
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34228}
* Make VideoSendStream and VideoSendStreamImpl construction non-blocking.
* Move ownership of the rtp video sender to VideoSendStream.
* Most state is constructed in initializer lists.
* More state is now const (including VideoSendStreamImpl ptr)
* Adding thread checks to classes that appear to have had a race before
E.g. RtpTransportControllerSend. The change in threading now actually
fixes an issue we weren't aware of.
* Moved from using weak_ptr to safety flag and made some PostTask calls
cancellable that could potentially have been problematic. Initalizing
the flag without thread synchronization is also simpler.
This should speed up renegotiation significantly when there are
multiple channels. A follow-up change will improve SetSend as well
which is another costly step during renegotiation.
Bug: webrtc:12840
Change-Id: If4b28da5a085643ce132c7cfcf80a62cd1a625c5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221105
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34224}
Also renaming 'worker_queue_' variables to 'rtp_transport_queue' to
avoid confusion with the worker thread.
Bug: webrtc:12840
Change-Id: Ia647a9a5ed8fdc59929f5b7ac222328ccd129a18
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221140
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34217}
Reland of commit a743303211b89bbcf4cea438ee797bbbc7b59e80
Previously, RTP header extensions with encryption had been filtered
if the encryption had been activated (not the other way around) which
was likely an unintended logic inversion.
In addition, it ensures that encrypted RTP header extensions are only
negotiated if RTP header extension encryption is turned on. Formerly,
which extensions had been negotiated depended on the order in which
they were inserted, regardless of whether or not header encryption was
actually enabled, leading to no extensions being sent on the wire.
Further changes:
- If RTP header encryption enabled, prefer encrypted extensions over
non-encrypted extensions
- Add most extensions to list of extensions supported for encryption
- Discard encrypted extensions in a session description in case encryption
is not supported for that extension
- Mark FindHeaderExtensionByUri without filter argument as deprecated
Bug: webrtc:11713
Change-Id: I52a5ade1b94bc01d1c2a35cb56023684fcaf9982
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219081
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34129}
This reverts commit 48a4d33719390b7bcaf8445a1581a00825f67bfb.
Reason for reland:
Relanding the original change but without the modification for
VideoSendStream::GetStats. Essentially there's a TODO there to fix
the downstream issue, which seems to be benign.
Original change's description:
> Revert "Remove Invoke from VideoChannel::FillBitrateInfo."
>
> This reverts commit 1a1795768e1bdb65054ebe15aa238c6edc78dd14.
>
> Reason for revert: Speculative revert (breaks downstream project).
>
> Original change's description:
> > Remove Invoke from VideoChannel::FillBitrateInfo.
> >
> > The method is relied upon by StatsCollector where it was called from the
> > signaling thread in a loop. Now there's at most one invoke (not N).
> >
> > Uncommenting thread checks and removing TODOs in SendStatisticsProxy,
> > VideoSendStream. Updating all related tests that fetched stats from
> > the wrong context.
> >
> > Bug: webrtc:12726
> > Change-Id: Ia7db1afd7e103ec4f9816f5647203c4e2495586e
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216688
> > Commit-Queue: Tommi <tommi@webrtc.org>
> > Reviewed-by: Niels Moller <nisse@webrtc.org>
> > Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33894}
>
> TBR=ilnik@webrtc.org,nisse@webrtc.org,tommi@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
>
> Change-Id: I2520957cdb33492d187f04320c7416788fd0f820
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:12726
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217240
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33898}
# Not skipping CQ checks because this is a reland.
Bug: webrtc:12726
Change-Id: I41cce3b11a29905cde982c22e82b9b1f5a98e654
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217222
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33902}
This reverts commit 1a1795768e1bdb65054ebe15aa238c6edc78dd14.
Reason for revert: Speculative revert (breaks downstream project).
Original change's description:
> Remove Invoke from VideoChannel::FillBitrateInfo.
>
> The method is relied upon by StatsCollector where it was called from the
> signaling thread in a loop. Now there's at most one invoke (not N).
>
> Uncommenting thread checks and removing TODOs in SendStatisticsProxy,
> VideoSendStream. Updating all related tests that fetched stats from
> the wrong context.
>
> Bug: webrtc:12726
> Change-Id: Ia7db1afd7e103ec4f9816f5647203c4e2495586e
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216688
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Niels Moller <nisse@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33894}
TBR=ilnik@webrtc.org,nisse@webrtc.org,tommi@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I2520957cdb33492d187f04320c7416788fd0f820
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:12726
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217240
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33898}
The method is relied upon by StatsCollector where it was called from the
signaling thread in a loop. Now there's at most one invoke (not N).
Uncommenting thread checks and removing TODOs in SendStatisticsProxy,
VideoSendStream. Updating all related tests that fetched stats from
the wrong context.
Bug: webrtc:12726
Change-Id: Ia7db1afd7e103ec4f9816f5647203c4e2495586e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216688
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33894}
This reverts commit a743303211b89bbcf4cea438ee797bbbc7b59e80.
Reason for revert: Breaks downstream tests that attempt to call FindHeaderExtensionByUri with 2 arguments. Could you keep the old 2-argument method declaration and just forward the call to the new 3-argument method with a suitable no-op filter?
Original change's description:
> Fix RTP header extension encryption
>
> Previously, RTP header extensions with encryption had been filtered
> if the encryption had been activated (not the other way around) which
> was likely an unintended logic inversion.
>
> In addition, it ensures that encrypted RTP header extensions are only
> negotiated if RTP header extension encryption is turned on. Formerly,
> which extensions had been negotiated depended on the order in which
> they were inserted, regardless of whether or not header encryption was
> actually enabled, leading to no extensions being sent on the wire.
>
> Further changes:
>
> - If RTP header encryption enabled, prefer encrypted extensions over
> non-encrypted extensions
> - Add most extensions to list of extensions supported for encryption
> - Discard encrypted extensions in a session description in case encryption
> is not supported for that extension
>
> Note that this depends on https://github.com/cisco/libsrtp/pull/491 to get
> into libwebrtc (cherry-pick or bump libsrtp version). Otherwise, two-byte
> header extensions will prevent any RTP packets being sent/received.
>
> Bug: webrtc:11713
> Change-Id: Ia0779453d342fa11e06996d9bc2d3c826f3466d3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177980
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Taylor <deadbeef@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33723}
TBR=deadbeef@webrtc.org,terelius@webrtc.org,hta@webrtc.org,lennart.grahl@gmail.com
Change-Id: I7df6b0fa611c6496dccdfb09a65ff33ae4a52b26
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11713
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215222
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33727}
Previously, RTP header extensions with encryption had been filtered
if the encryption had been activated (not the other way around) which
was likely an unintended logic inversion.
In addition, it ensures that encrypted RTP header extensions are only
negotiated if RTP header extension encryption is turned on. Formerly,
which extensions had been negotiated depended on the order in which
they were inserted, regardless of whether or not header encryption was
actually enabled, leading to no extensions being sent on the wire.
Further changes:
- If RTP header encryption enabled, prefer encrypted extensions over
non-encrypted extensions
- Add most extensions to list of extensions supported for encryption
- Discard encrypted extensions in a session description in case encryption
is not supported for that extension
Note that this depends on https://github.com/cisco/libsrtp/pull/491 to get
into libwebrtc (cherry-pick or bump libsrtp version). Otherwise, two-byte
header extensions will prevent any RTP packets being sent/received.
Bug: webrtc:11713
Change-Id: Ia0779453d342fa11e06996d9bc2d3c826f3466d3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177980
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Taylor <deadbeef@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33723}
It turned out that the negotiated rtp header extensions are not fully known in WebRtcVideoChannel::AddSendStream.
The cl also remove the unnecessary factory for creating VideoStreamEncoder.
Bug: webrtc:12000
Change-Id: If994c8deb69f3ce4212896d3ad757dac94c6e09f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/198840
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32916}
VideoBitrateAllocation is instead reported through the EncoderSink.
Enable VideoBitrateAllocation reporting from WebRtcVideoChannel::AddSendStream in preparation for
using the extension RtpVideoLayersAllocationExtension instead of RTCP XR.
Bug: webrtc:12000
Change-Id: I5ea8e4f237a1c4e84a89cbfd97ac4353d4c2984f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186940
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32347}
This CL adds AddAdaptationResource to Call and
AddAdaptationResource/GetAdaptationResources method to relevant
VideoSendStream and VideoStreamEncoder interfaces and implementations.
Unittests are added to ensure that resources can be added to the Call
both before and after the creation of a VideoSendStream and that the
resources always gets added to the streams.
In a follow-up CL, we will continue to plumb the resources all the way
to PeerConnectionInterface, and an integration test will then be added
to ensure that injected resources are capable of triggering adaptation.
Bug: webrtc:11525
Change-Id: I499e9c23c3e359df943414d420b2e0ce2e9b2d56
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177002
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31499}
MediaTransport is deprecated and the code is unused.
No-Try: True
Bug: webrtc:9719
Change-Id: I5b864c1e74bf04df16c15f51b8fac3d407331dcd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/160620
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Gustaf Ullberg <gustaf@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29923}
These are manual edits please verify there are no typos.
Feel free to auto-submit if there are no issues.
Bug: webrtc:10410
Change-Id: Iedb3be944828a1caba55bbbd4dc0b56c55bbb7d5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/127624
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27123}
This prepares for making AudioSendStream use its own task queue. In the
future more of the functionality that depends on running on the task
queue is planned to be moved directly into RtpTransportControllerSend.
They should instead get it from the transport controller. This affects
the media transport tests which previously assumed that the transport
controller could be missing. However, this is not something that is used
in production, so this is an improvement of the tests as they will
behave more like production code.
Bug: webrtc:9883
Change-Id: Ie32f4c2f6433ec37ac16a08d531ceb690ea9c0b5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126000
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27010}
This is a follow-up to
https://webrtc-review.googlesource.com/c/src/+/106280.
This time the whole code base is covered.
Some files may have not been fixed though, whenever the IWYU tool
was breaking the build.
Bug: webrtc:8311
Change-Id: I2c31f552a87e887d33931d46e87b6208b1e483ef
Reviewed-on: https://webrtc-review.googlesource.com/c/111965
Commit-Queue: Yves Gerey <yvesg@google.com>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25830}
Compared the original CL: https://webrtc-review.googlesource.com/c/src/+/94782
This new CL added backward compatible functions to WebRtcMediaEngineFactory so that internal projects will not be broken.
Because of that, now we can revert all the changes to SDK and PeerConnection and do it in following CLs. This makes this CL cleaner.
One temporary disadvantage of this is the media engine now need to take a dependency onto builtin video bitrate factory, but practically it just moved code around and should not result in a large binary size change. We can remove this dependency later if needed.
Bug: webrtc:9513
Change-Id: I38708762ff365e4ca05974b99fac71edc739a756
Reviewed-on: https://webrtc-review.googlesource.com/c/109040
Commit-Queue: Jiawei Ou <ouj@fb.com>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25574}
Followup to cl https://webrtc-review.googlesource.com/70880, which
introduced the interface.
Intended to enable tests using MockBitrateAllocator.
Bug: None
Change-Id: I0a784106acf37ff9aca118297233ebd2f2259ae4
Reviewed-on: https://webrtc-review.googlesource.com/c/107342
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25290}
This also moves the packet feedback tracking to RtpVideoSender.
Bug: webrtc:9517
Change-Id: Ifb1ff85051730108a0b0d1dd30f6f8595ad2af6e
Reviewed-on: https://webrtc-review.googlesource.com/c/95920
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25019}
Rename to better match what it does,
Adjust to support two-byte header extension
Bug: webrtc:7990
Change-Id: I2786d70e7cf9cd3d722f54fb1d07c9cfaafab947
Reviewed-on: https://webrtc-review.googlesource.com/103201
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Johannes Kron <kron@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24958}
Use in VideoQualityTest replaced by creating a wrapper for the encoder.
Bug: None
Change-Id: I5c5519e147ca7ddb97696b0d6958a8a1f5cc6e83
Reviewed-on: https://webrtc-review.googlesource.com/94152
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24533}
- Move PayloadRouter to RtpTransportControllerInterface.
- Move RetransmissionLimiter inside RtpTransportControllerSend from
VideoSendStreamImpl.
- Move video RTP specifics into PayloadRouter, in particular ownership
of the RTP modules.
- PayloadRouter now contains all video specific RTP code, and will be
renamed in a follow-up to VideoRtpSender.
- Introduce VideoRtpSenderInterface.
Bug: webrtc:9517
Change-Id: I1c7b293fa6f9c320286c80533b3c584498034a38
Reviewed-on: https://webrtc-review.googlesource.com/88240
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24009}
Running clang-format with chromium's style guide.
The goal is n-fold:
* providing consistency and readability (that's what code guidelines are for)
* preventing noise with presubmit checks and git cl format
* building on the previous point: making it easier to automatically fix format issues
* you name it
Please consider using git-hyper-blame to ignore this commit.
Bug: webrtc:9340
Change-Id: I694567c4cdf8cee2860958cfe82bfaf25848bb87
Reviewed-on: https://webrtc-review.googlesource.com/81185
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23660}
