This makes more sense since logically it's a transport level feature,
not a media stream feature. Even if the implementation details forces it
to be an rtp stream detail, for the moment.
BUG=webrtc:7907
Review-Url: https://codereview.webrtc.org/2978503002
Cr-Commit-Position: refs/heads/master@{#18963}
I used a command like this to update the paths:
perl -pi -e "s/webrtc\/base/webrtc\/rtc_base/g" `find webrtc/rtc_base -name "*.cc" -o -name "*.h"`
BUG=webrtc:7634
NOPRESUBMIT=True # cpplint errors that aren't caused by this CL.
Review-Url: https://codereview.webrtc.org/2969623003
Cr-Commit-Position: refs/heads/master@{#18870}
Implementation owned by call, and passed to VideoSendStream and
AudioSendStream.
BUG=webrtc:6847, webrtc:7135
Review-Url: https://codereview.webrtc.org/2685673003
Cr-Commit-Position: refs/heads/master@{#17389}
New class ReceiveSideCongestionController, extracted from CongestionController, and responsible for the
OnReceivedPacket processing.
Rest of the CongestionController moved to a new class
SendSideCongestionController.
To avoid breaking applications, CongestionController is redefined
as a union of these two classes, with no intended change in behavior.
With one exception: CongestionController::SetBweBitrates used to call
remote_bitrate_estimator_.SetMinBitrate, but after remote_bitrate_estimator_ was moved to ReceiveSideCongestionController,
it no longer does this.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2752233002
Cr-Commit-Position: refs/heads/master@{#17321}
This avoids the situation where an encoder, not supporting certain
screen content settings, is created for a config where screencast is
off, and later ReconfigureEncoder() is called updating the configuration
but not the encoder instance, causing an inconsistency in the encoder's
InitEncode() call.
TBR=pthatcher@webrtc.org
BUG=webrtc:4172
Review-Url: https://codereview.webrtc.org/2710493008
Cr-Commit-Position: refs/heads/master@{#16921}
This lets the RTP code be unaware of lower layers, and the
SetTransportOverhead method is deleted from RTPSender and RtpRtcp.
Instead, that method is added to CongestionController and
TransportFeedbackAdapter, where it is more appropriate.
BUG=wertc:6847
Review-Url: https://codereview.webrtc.org/2589743002
Cr-Commit-Position: refs/heads/master@{#15995}
And delete the method CongestionController::packet_router.
BUG=None
Review-Url: https://codereview.webrtc.org/2516983004
Cr-Commit-Position: refs/heads/master@{#15323}
This removes the VideoSendStream::LoadObserver interface and the implementation in WebrtcVideoSendStream and replace it with VideoSinkWants through the VideoSourceInterface.
To do that that, some stats for CPU adaptation is moved into VideoSendStream. Also handling of the CVO rtp header extension is moved to VideoSendStreamImpl.
BUG=webrtc:5687
TBR=mflodman@webrtc.org
Review-Url: https://codereview.webrtc.org/2304363002
Cr-Commit-Position: refs/heads/master@{#14877}
The renaming is to reflect this class is only used for RTCP interaction
and not for other transports.
This Cl will be followed by multiple CLs moving all send-side RTP
functionality to a separate class, rtp module ownership away from
VideoSendStream and use TaskQueue instead of ProcessThread for RTP.
BUG=webrtc:6456
Review-Url: https://codereview.webrtc.org/2390463002
Cr-Commit-Position: refs/heads/master@{#14556}
Adds new method VideoSendStream::SetSource(rtc::VideoSourceInterface* and VieEncoder::SetSource(rtc::VideoSourceInterface*)
This is the first step needed in order for the ViEEncoder to request downscaling using rtc::VideoSinkWants instead of separately reporting CPU overuse and internally doing downscaling due to QP values
This cl
Revert "Revert of Replace interface VideoCapturerInput with VideoSinkInterface. (patchset #13 id:280001 of https://codereview.webrtc.org/2257413002/ )"
This reverts commit 9fdbda6aa3f66ea872344c22e79b23361047cbab.
and fix the problem in the original cl in video_quality_test.cc
BUG=webrtc:5687
TBR=mflodman@webrtc.org
Review-Url: https://codereview.webrtc.org/2348533002
Cr-Commit-Position: refs/heads/master@{#14265}
Reason for revert:
Fails on Mac and Linux webrtc_perf_tests
Original issue's description:
> Replace VideoCapturerInput with VideoSinkInterface.
> Adds new method VideoSendStream::SetSource(rtc::VideoSourceInterface* and VieEncoder::SetSource(rtc::VideoSourceInterface*)
>
> This is the first step needed in order for the ViEEncoder to request downscaling using rtc::VideoSinkWants instead of separately reporting CPU overuse and internally doing downscaling due to QP values.
>
> BUG=webrtc:5687
> // Android CQ seems broken.
> NOTRY=true
>
> Committed: https://crrev.com/95a226f55ae7e32b83a6ba96232fb105a014dc6c
> Cr-Commit-Position: refs/heads/master@{#14238}
TBR=nisse@webrtc.org,sprang@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2344923002
Cr-Commit-Position: refs/heads/master@{#14239}
Adds new method VideoSendStream::SetSource(rtc::VideoSourceInterface* and VieEncoder::SetSource(rtc::VideoSourceInterface*)
This is the first step needed in order for the ViEEncoder to request downscaling using rtc::VideoSinkWants instead of separately reporting CPU overuse and internally doing downscaling due to QP values.
BUG=webrtc:5687
// Android CQ seems broken.
NOTRY=true
Review-Url: https://codereview.webrtc.org/2257413002
Cr-Commit-Position: refs/heads/master@{#14238}
cl was originally reviewed here:
https://codereview.webrtc.org/2060403002/
- Add task queue to Call with the intent of replacing the use of one of the process threads.
- Split VideoSendStream in two. VideoSendStreamInternal is created and used on the new task queue.
- BitrateAllocator is now created on libjingle's worker thread but always used on the new task queue instead of both encoder threads and the process thread.
- VideoEncoderConfig and VideoSendStream::Config support move semantics.
- The encoder thread is moved from VideoSendStream to ViEEncoder. Frames are forwarded directly to ViEEncoder which is responsible for timestamping ? and encoding the frames.
TBR=mflodman@webrtc.org
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2250123002
Cr-Commit-Position: refs/heads/master@{#14014}
Reason for revert:
Failed on Win 10 Chrome FYI.
https://build.chromium.org/p/chromium.webrtc.fyi/builders/Win10%20Tester/builds/3847/steps/content_browsertests/logs/stdio
#
# Fatal error in e:\b\c\b\win_builder\src\third_party\webrtc\base\task_queue_win.cc, line 138
# last system error: 87
# Check failed: ((DWORD)0xFFFFFFFF) != result (4294967295 vs. 4294967295)
#
WebRtcBrowserTest
#
Original issue's description:
> - Add task queue to Call with the intent of replacing the use of one of the process threads.
>
> - Split VideoSendStream in two. VideoSendStreamInternal is created and used on the new task queue.
>
> - BitrateAllocator is now created on libjingle's worker thread but always used on the new task queue instead of both encoder threads and the process thread.
>
> - VideoEncoderConfig and VideoSendStream::Config support move semantics.
>
> - The encoder thread is moved from VideoSendStream to ViEEncoder. Frames are forwarded directly to ViEEncoder which is responsible for timestamping ? and encoding the frames.
>
> BUG=webrtc:5687
>
> Committed: https://crrev.com/cc168360f41322332860cb075edeb1cde21aa473
> Cr-Commit-Position: refs/heads/master@{#13767}
TBR=tommi@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org,sprang@webrtc.org,pbos@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2248713003
Cr-Commit-Position: refs/heads/master@{#13774}
- Split VideoSendStream in two. VideoSendStreamInternal is created and used on the new task queue.
- BitrateAllocator is now created on libjingle's worker thread but always used on the new task queue instead of both encoder threads and the process thread.
- VideoEncoderConfig and VideoSendStream::Config support move semantics.
- The encoder thread is moved from VideoSendStream to ViEEncoder. Frames are forwarded directly to ViEEncoder which is responsible for timestamping ? and encoding the frames.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2060403002
Cr-Commit-Position: refs/heads/master@{#13767}
When the target bitrate is zero, currently VideoSendStream.Stats.target_media_bitrate_bps show the last set rate before the target was set to zero.
BUG=webrtc::5687 b/29574845
Review-Url: https://codereview.webrtc.org/2122743003
Cr-Commit-Position: refs/heads/master@{#13386}
This CL changes the auto-pause logic to suspend a stream based on the
encoder target bitrate instead of the allocated bitrate for a stream,
to account for possible protection, e.g. FEC and NACK.
This CL also adds periodic logging of the current BWE and possibility
to run with suspension in video loopback test.
BUG=webrtc:5868
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2117493002 .
Cr-Commit-Position: refs/heads/master@{#13360}
This cl change so that VideoSendStream::Start adds the stream as a BitrateObserver and VideoSendStream::Stop removes the stream as observer.
That also means that start will trigger a VideoEncoder::SetRate call with the most recent bitrate estimate.
VideoSendStream::Stop will trigger a VideoEncoder::SetRate with bitrate = 0.
BUG=webrtc:5687 b/28636240
Review-Url: https://codereview.webrtc.org/2070343002
Cr-Commit-Position: refs/heads/master@{#13192}
1. It moves calculation of the needed padding to VideoSendStream instead of ViEEncoder and only does it once per send Stream instead of every time the network estimate changes.
2. The maximum amount of padding sent was prior to this cl calculated and updated based on network estimate changes. However, it can only change based on encoder configuration changes and if send streams are added or removed. This cl change the VideoSendStream/VieEncoder to notify the BitrateAllocator of changes to the needed padding bitrate and for BitrateAllocator to notify Call of these changes.
3. Fixed an issue in the SendPacer where it could send a padding packet before sending a real packet. This caused the test EndToEndTest.RestartingSendStreamPreservesRtpStatesWithRtx to fail with these refactorings since the pacer suddenly could send a padding packet before the encoder had produced its first frame.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/1993113003
Cr-Commit-Position: refs/heads/master@{#13149}
EncodedFrameCallbackAdapter was used VideoSendStream and
VideoReceiveStream, but there is no reason to have it as these classes
can call EncodedFrameObserver directly.
Review-Url: https://codereview.webrtc.org/2068463004
Cr-Commit-Position: refs/heads/master@{#13145}
This cl split the class MediaOptimization into two parts. One that deals with frame dropping and stats and one new class called ProtectionBitrateCalculator that deals with calculating the needed FEC parameters and how much of the estimated network bitrate that can be used by an encoder
Note that the logic of how FEC and the needed bitrates is not changed.
BUG=webrtc:5687
R=asapersson@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1972083002 .
Cr-Commit-Position: refs/heads/master@{#13018}
Also set the Configuration parameters in CreateRtpRtcpModules in the same order as the members are declared.
BUG=webrtc:5917
Review-Url: https://codereview.webrtc.org/2011433002
Cr-Commit-Position: refs/heads/master@{#12905}
SSRC knowledge is contained withing VideoSendStream. That also means that debug recording is moved to VideoSendStream.
I think that make sence since that allows debug recording with external encoder implementations one day.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/1936503002
Cr-Commit-Position: refs/heads/master@{#12632}
ViEChannel is now called VideoStreamReceiver.
There will be a follow up CL removing all rtp references from VideoReceiveStream, but that made this CL to big and it will be done separately.
BUG=webrtc:5079
Review-Url: https://codereview.webrtc.org/1929313002
Cr-Commit-Position: refs/heads/master@{#12619}
- "WebRTC.Video.SendDelayInMs"
Change so that PacketOption packet id is always set in RtpSender (if having a TransportSequenceNumberAllocator).
Add SendDelayStats class for computing delays.
Add SendPacketObserver to RtpRtcp config and register SendDelayStats as observer.
Wire up OnSentPacket to SendDelayStats.
BUG=webrtc:5215
Review-Url: https://codereview.webrtc.org/1478253002
Cr-Commit-Position: refs/heads/master@{#12600}
But keep #including scoped_ptr.h in .h files, so as not to break
WebRTC users who expect those .h files to give them rtc::scoped_ptr.
BUG=webrtc:5520
Review-Url: https://codereview.webrtc.org/1937693002
Cr-Commit-Position: refs/heads/master@{#12581}
ViEEncoder doesn't need a full VideoCodingModule since it only uses the
sender side either way.
BUG=webrtc:3608,webrtc:5687
R=perkj@webrtc.org
Review URL: https://codereview.webrtc.org/1904983002 .
Cr-Commit-Position: refs/heads/master@{#12456}
Reason for revert:
RTCVideoEncoder has been updated to not make assumptions on calling threads/post back to a worker thread. This should now be landable again.
Original issue's description:
> Revert of Initialize/configure video encoders asychronously. (patchset #4 id:60001 of https://codereview.webrtc.org/1757313002/ )
>
> Reason for revert:
> Breaks RTCVideoEncoder which has incorrect assumptions on where InitEncode etc. is called from. Temporarily reverting until RTCVideoEncoder has been updated.
>
> Original issue's description:
> > Initialize/configure video encoders asychronously.
> >
> > Greatly speeds up setRemoteDescription() by moving encoder initialization
> > off the main worker thread, which is free to move onto gathering ICE
> > candidates and other tasks while InitEncode() is performed. It also
> > un-blocks PeerConnection GetStats() which is no longer blocked on
> > encoder initialization.
> >
> > BUG=webrtc:5410
> > R=stefan@webrtc.org
> >
> > Committed: fb647a67be
>
> R=stefan@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=chromium:595274, chromium:595308, webrtc:5410
>
> Committed: https://crrev.com/81cbd924447d507559dbd6e6d1f9fe439fcf2716
> Cr-Commit-Position: refs/heads/master@{#12086}
TBR=stefan@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:595274, chromium:595308, webrtc:5410
Review URL: https://codereview.webrtc.org/1896413002
Cr-Commit-Position: refs/heads/master@{#12446}
Reason for revert:
Breaks RTCVideoEncoder which has incorrect assumptions on where InitEncode etc. is called from. Temporarily reverting until RTCVideoEncoder has been updated.
Original issue's description:
> Initialize/configure video encoders asychronously.
>
> Greatly speeds up setRemoteDescription() by moving encoder initialization
> off the main worker thread, which is free to move onto gathering ICE
> candidates and other tasks while InitEncode() is performed. It also
> un-blocks PeerConnection GetStats() which is no longer blocked on
> encoder initialization.
>
> BUG=webrtc:5410
> R=stefan@webrtc.org
>
> Committed: fb647a67beR=stefan@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:595274, chromium:595308, webrtc:5410
Review URL: https://codereview.webrtc.org/1821983002 .
Cr-Commit-Position: refs/heads/master@{#12086}
Greatly speeds up setRemoteDescription() by moving encoder initialization
off the main worker thread, which is free to move onto gathering ICE
candidates and other tasks while InitEncode() is performed. It also
un-blocks PeerConnection GetStats() which is no longer blocked on
encoder initialization.
BUG=webrtc:5410
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1757313002 .
Cr-Commit-Position: refs/heads/master@{#11983}
This CL will be followed up with a CL adding AudioSendStream to
BitrateAllocator, so this is a small CL to have the video connection to
BitrateAllocator "at the same level" as for audio.
BUG=webrtc:5079
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1785283002 .
Cr-Commit-Position: refs/heads/master@{#11955}
Makes VideoCaptureInput easier to test and enables running more things
outside VideoCaptureInput on the encoder thread in the future
(initializing encoders and reconfiguring them, for instance).
BUG=webrtc:5410, webrtc:5494
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1763693002 .
Cr-Commit-Position: refs/heads/master@{#11860}
Also moves and simplifies SetSendCodec from VideoSendStream to mostly
inside ViEEncoder. This is necessary for making
ReconfigureVideoEncoder asynchronous as we don't post any result back.
BUG=webrtc:5494
R=stefan@webrtc.orgTBR=mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1754283002 .
Cr-Commit-Position: refs/heads/master@{#11847}
Moves RtpRtcp module pointers into VideoSendStream and uses them for
simple calls that were only forwarded by ViEChannel.
BUG=webrtc:5494
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1693553002 .
Cr-Commit-Position: refs/heads/master@{#11709}
