Reason for revert:
Downstream build is fixed.
Original issue's description:
> Revert of Ignore Camera and Flip bits in CVO when parsing video rotation (patchset #3 id:80001 of https://codereview.webrtc.org/2280703002/ )
>
> Reason for revert:
> Breaks downstream build.
>
> Original issue's description:
> > Ignore Camera and Flip bits in CVO when parsing video rotation
> >
> > Currently, if WebRTC receives a CVO byte where the Camera or Flip bit is
> > set, then rotation is incorrectly parsed as 0. This CL fixes that issue.
> > The Camera and Flip bit is still unimplemented and will just be ignored
> > though.
> >
> > BUG=webrtc:6120
> > R=danilchap@webrtc.org, pthatcher@webrtc.org, tommi@webrtc.org
> >
> > Committed: f9e1b922ef
>
> TBR=pthatcher@webrtc.org,danilchap@webrtc.org,tommi@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6120
>
> Committed: https://crrev.com/97667c7746282704acccd896e26175decee349c0
> Cr-Commit-Position: refs/heads/master@{#14035}
TBR=pthatcher@webrtc.org,danilchap@webrtc.org,tommi@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6120
Review-Url: https://codereview.webrtc.org/2320913003
Cr-Commit-Position: refs/heads/master@{#14124}
"WebRTC.Call.BitrateReceivedInKbps"
"WebRTC.Call.VideoBitrateReceivedInKbps"
"WebRTC.Call.AudioBitrateReceivedInKbps"
"WebRTC.Call.RtcpBitrateReceivedInBps"
Reports the average of periodically computed bitrates over a call (2 sec interval). Adds possibility to later modify the stats and use/report the periodic bitrates.
BUG=webrtc:5283
Review-Url: https://codereview.webrtc.org/2303763002
Cr-Commit-Position: refs/heads/master@{#14119}
This file defines webrtc::Config which was mostly used by modules/audio_processing. The files webrtc/common.h, webrtc/common.cc and webrtc/test/common_unittests.cc are moved to modules/audio_processing and the few remaining uses of webrtc::Config are replaced with simpler code.
- For NetEq and pacing configuration, a VoEBase::ChannelConfig is passed to VoEBase::CreateChannel().
- Removes the need for VoiceEngine::Create(const Config& config). No need to store the webrtc::Config in VoE shared state.
BUG=webrtc:5879
Review-Url: https://codereview.webrtc.org/2307533004
Cr-Commit-Position: refs/heads/master@{#14109}
Remove common_inherited_config from the targets and add it to the
template instead.
BUG=webrtc:6187
NOTRY=True
Review-Url: https://codereview.webrtc.org/2311843002
Cr-Commit-Position: refs/heads/master@{#14069}
Remove common_config from the targets' config and add
it to the template instead.
BUG=webrtc:6187
NOTRY=True
Review-Url: https://codereview.webrtc.org/2300413002
Cr-Commit-Position: refs/heads/master@{#14063}
This test failed on the memcheck bot:
https://build.chromium.org/p/client.webrtc/builders/Linux%20Memcheck/builds/6704/steps/video_engine_tests/logs/stdio
The test assumed that the absolute send time header extension can never
be zero. It's a timestamp truncated to 24 bits, and zero is not a
special value - so it can very rarely end up being precisely zero.
The fix makes the test wait for at least one packet having a non-zero send time.
I've considered changing the test to use a fake clock instead to ensure
that not only the value is non-zero, but that it indeed reflects the
system timestamp - but that involves changing a very large number of
files. Besides, other tests in this file don't verify values for header
extensions where zeroes are allowed.
NOTRY=true
Review-Url: https://codereview.webrtc.org/2307693002
Cr-Commit-Position: refs/heads/master@{#14056}
Defines the rtc_executable, rtc_source_set, rtc_test and
rtc_static_library templates.
These templates provide no functionality yet, but will enable common
configuration to be introduced, avoiding repetition in every target
Changes summary:
- Prepend rtc_ to test, source_set, executable and static_library targets
- Change "configs -= [" to "suppressed_configs += ["
- Include webrtc/build/webrtc.gni where it wasn't included yet
- Delete import("//testing/test.gni"), since rtc_test makes it unnecessary.
BUG=webrtc:6187
TBR=henrik.lundin@webrtc.org,tommi@webrtc.org
NOTRY=True
Review-Url: https://codereview.webrtc.org/2301053002
Cr-Commit-Position: refs/heads/master@{#14043}
Reason for revert:
Breaks downstream build.
Original issue's description:
> Ignore Camera and Flip bits in CVO when parsing video rotation
>
> Currently, if WebRTC receives a CVO byte where the Camera or Flip bit is
> set, then rotation is incorrectly parsed as 0. This CL fixes that issue.
> The Camera and Flip bit is still unimplemented and will just be ignored
> though.
>
> BUG=webrtc:6120
> R=danilchap@webrtc.org, pthatcher@webrtc.org, tommi@webrtc.org
>
> Committed: f9e1b922efTBR=pthatcher@webrtc.org,danilchap@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6120
Review-Url: https://codereview.webrtc.org/2300323002
Cr-Commit-Position: refs/heads/master@{#14035}
Currently, if WebRTC receives a CVO byte where the Camera or Flip bit is
set, then rotation is incorrectly parsed as 0. This CL fixes that issue.
The Camera and Flip bit is still unimplemented and will just be ignored
though.
BUG=webrtc:6120
R=danilchap@webrtc.org, pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2280703002 .
Cr-Commit-Position: refs/heads/master@{#14027}
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}
This CL adds an audio loopback to video_quality_test (only RunWithVideoRenderer)
BUG=
Review-Url: https://codereview.webrtc.org/2136573002
Cr-Commit-Position: refs/heads/master@{#13784}
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}
Also update existing perf tests to use send side bwe.
BUG=webrtc:4604, chromium:522001
Review-Url: https://codereview.webrtc.org/2227733004
Cr-Commit-Position: refs/heads/master@{#13726}
This CL removes (almost) the last RTP references in VideoReceiveStream.
There are still references to RTPFragmentationHeader and SSRCs, which
will be dealt with later.
There are also new GUARDED_BY and thred checker added to the
synchronization class.
When there are othre transports than RTP, there will instead be an
interface + inheritance for RtpStreamReceiver and
RtpStreamSynchronizattion in VideoReceiveStream. This work will be done
when we actually know how we want to make thee transport interface.
BUG=webrtc:5838
Review-Url: https://codereview.webrtc.org/2216533002
Cr-Commit-Position: refs/heads/master@{#13655}
double check rtp_sender in sending mode when altering sequence_number
adjust test to skip validating timestamp on rtx streams
fix test by waiting for all 3 media streams instead of 3 out 6 media and rtx streams.
BUG=webrtc:4332
Review-Url: https://codereview.webrtc.org/2177523002
Cr-Commit-Position: refs/heads/master@{#13587}
- Renamed variables and some function to comply with style guide.
- Removed default argument values.
- Removed some dead code.
- Cleaned up comments formatting in rtp_rtcp.h
R=danilchap@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2067673004 .
Cr-Commit-Position: refs/heads/master@{#13565}
This is an issue if the sequence numbers are to be used to compute packet loss statistics since it introduces gaps which are not related to loss.
Also making sure that the header extensions are properly guarded by the send crit sect.
Review-Url: https://codereview.webrtc.org/2190913002
Cr-Commit-Position: refs/heads/master@{#13557}
to be aware about rare situation where packet resend before sent:
Expectations reduced by validating frame was rendered after or before last
packet for that frame was dropped.
BUG=webrtc:5540
Review-Url: https://codereview.webrtc.org/2180903002
Cr-Commit-Position: refs/heads/master@{#13523}
Test was expecting no rtx packet before dropped packet.
Because of prober there might be some non-padding rtx packets before nack.
Those checks removed, test primary expectations are unaffected.
BUG=webrtc:5540
R=stefan@webrtc.org
Review-Url: https://codereview.webrtc.org/2180843002
Cr-Commit-Position: refs/heads/master@{#13522}
Now it check if rtp timestamp can be calculating instead of checking number of rtp packets. This way it works for reconfigured streams too.
It also moved deeper into rtcp_sender class to prevent SR no matter the reason it need to be genereated. This way it prevents creating compound rtcp packets that have to start with Sender Report and Sender Reports as response to (mostly theoretical) sr-request rtcp packet.
BUG=webrtc:1600
R=pbos@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1639253007 .
Cr-Commit-Position: refs/heads/master@{#13503}
This cl is in preparation for https://codereview.webrtc.org/2060403002/ Add task queue to Call.
In the coming cl the video_sender, and i420_buffer_pool will be used on a task queue and therefore SequencedTaskChecker is needed instead of a ThreadChecker.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2149553002
Cr-Commit-Position: refs/heads/master@{#13474}
The decode thread should be stopped before triggering shutdown of the
video receiver, so that the decoder doesn't try to insert a new frame
while the jitter buffer is being shut down.
BUG=webrtc:6102
Review-Url: https://codereview.webrtc.org/2146883002
Cr-Commit-Position: refs/heads/master@{#13467}
These arguments are not really known when calling SetEncodingData. They are still provided as argument to ProtectionBitrateCalculator::SetTargetRates though.
This cl is broken out from https://codereview.webrtc.org/2060403002/
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2121983002
Cr-Commit-Position: refs/heads/master@{#13429}
Reason for revert:
Breaks upstream code.
Original issue's description:
> Refactor NACK bitrate allocation
>
> Nack bitrate allocation should not be done on a per-rtp-module basis,
> but rather shared bitrate pool per call. This CL moves allocation to the
> pacer and cleans up a bunch if bitrate stats handling.
>
> BUG=
> R=danilchap@webrtc.org, stefan@webrtc.org, tommi@webrtc.org
>
> Committed: 5fc59e810bTBR=tommi@webrtc.org,danilchap@webrtc.org,stefan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2131913003
Cr-Commit-Position: refs/heads/master@{#13417}
