It makes sense it's closer to the source code of the actual test.
Fix a bug that caused --help to fail.
BUG=webrtc:7034
NOTRY=True
Review-Url: https://codereview.webrtc.org/2681833007
Cr-Commit-Position: refs/heads/master@{#16505}
The main difference to the old computation is that the expected number of packets during an interval is now computed as the change in highest sequence number encountered, rather than the sequence number difference between the first and last packet in the interval.
BUG=webrtc:7046
Review-Url: https://codereview.webrtc.org/2656333002
Cr-Commit-Position: refs/heads/master@{#16361}
Reason for revert:
Downstream project relied on changed struct.
Transition made possible by https://codereview.webrtc.org/2655243006/.
Original issue's description:
> Revert of Make RTX pt/apt reconfigurable by calling WebRtcVideoChannel2::SetRecvParameters. (patchset #7 id:160001 of https://codereview.webrtc.org/2646073004/ )
>
> Reason for revert:
> Breaks internal downstream project.
>
> Original issue's description:
> > Make RTX pt/apt reconfigurable by calling WebRtcVideoChannel2::SetRecvParameters.
> >
> > Prior to this CL, received RTX (associated) payload types were only configured
> > when WebRtcVideoChannel2::AddRecvStream was called. In the same method, the RTX
> > SSRC was set up.
> >
> > After this CL, the RTX (associated) payload types are set in
> > WebRtcVideoChannel2::SetRecvParameters, which is the appropriate place to set
> > them. The RTX SSRC is still set in WebRtcVideoChannel2::AddRecvStream, since
> > that is the code path that sets other SSRCs.
> >
> > As part of this fix, the VideoReceiveStream::Config::Rtp struct is changed.
> > We remove the possibility for each video payload type to have an associated
> > specific RTX SSRC. Although the config previously allowed for this, all payload
> > types always had the same RTX SSRC set, and the underlying RtpPayloadRegistry
> > did not support multiple SSRCs. This change to the config struct should thus not
> > have any functional impact. The change does however affect the RtcEventLog, since
> > that is used for storing the VideoReceiveStream::Configs. For simplicity,
> > this CL does not change the event log proto definitions, instead duplicating
> > the serialized RTX SSRCs such that they fit in the existing proto definition.
> >
> > BUG=webrtc:7011
> >
> > Review-Url: https://codereview.webrtc.org/2646073004
> > Cr-Commit-Position: refs/heads/master@{#16302}
> > Committed: fe2bef39cd
>
> TBR=stefan@webrtc.org,magjed@webrtc.org,terelius@webrtc.org,brandtr@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:7011
>
> Review-Url: https://codereview.webrtc.org/2649323010
> Cr-Commit-Position: refs/heads/master@{#16307}
> Committed: e4974953ceTBR=stefan@webrtc.org,magjed@webrtc.org,terelius@webrtc.org,kjellander@webrtc.org,kjellander@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
# NOTREECHECKS=true
# NOTRY=true
BUG=webrtc:7011
Review-Url: https://codereview.webrtc.org/2654163006
Cr-Commit-Position: refs/heads/master@{#16322}
Reason for revert:
Breaks internal downstream project.
Original issue's description:
> Make RTX pt/apt reconfigurable by calling WebRtcVideoChannel2::SetRecvParameters.
>
> Prior to this CL, received RTX (associated) payload types were only configured
> when WebRtcVideoChannel2::AddRecvStream was called. In the same method, the RTX
> SSRC was set up.
>
> After this CL, the RTX (associated) payload types are set in
> WebRtcVideoChannel2::SetRecvParameters, which is the appropriate place to set
> them. The RTX SSRC is still set in WebRtcVideoChannel2::AddRecvStream, since
> that is the code path that sets other SSRCs.
>
> As part of this fix, the VideoReceiveStream::Config::Rtp struct is changed.
> We remove the possibility for each video payload type to have an associated
> specific RTX SSRC. Although the config previously allowed for this, all payload
> types always had the same RTX SSRC set, and the underlying RtpPayloadRegistry
> did not support multiple SSRCs. This change to the config struct should thus not
> have any functional impact. The change does however affect the RtcEventLog, since
> that is used for storing the VideoReceiveStream::Configs. For simplicity,
> this CL does not change the event log proto definitions, instead duplicating
> the serialized RTX SSRCs such that they fit in the existing proto definition.
>
> BUG=webrtc:7011
>
> Review-Url: https://codereview.webrtc.org/2646073004
> Cr-Commit-Position: refs/heads/master@{#16302}
> Committed: fe2bef39cdTBR=stefan@webrtc.org,magjed@webrtc.org,terelius@webrtc.org,brandtr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7011
Review-Url: https://codereview.webrtc.org/2649323010
Cr-Commit-Position: refs/heads/master@{#16307}
Prior to this CL, received RTX (associated) payload types were only configured
when WebRtcVideoChannel2::AddRecvStream was called. In the same method, the RTX
SSRC was set up.
After this CL, the RTX (associated) payload types are set in
WebRtcVideoChannel2::SetRecvParameters, which is the appropriate place to set
them. The RTX SSRC is still set in WebRtcVideoChannel2::AddRecvStream, since
that is the code path that sets other SSRCs.
As part of this fix, the VideoReceiveStream::Config::Rtp struct is changed.
We remove the possibility for each video payload type to have an associated
specific RTX SSRC. Although the config previously allowed for this, all payload
types always had the same RTX SSRC set, and the underlying RtpPayloadRegistry
did not support multiple SSRCs. This change to the config struct should thus not
have any functional impact. The change does however affect the RtcEventLog, since
that is used for storing the VideoReceiveStream::Configs. For simplicity,
this CL does not change the event log proto definitions, instead duplicating
the serialized RTX SSRCs such that they fit in the existing proto definition.
BUG=webrtc:7011
Review-Url: https://codereview.webrtc.org/2646073004
Cr-Commit-Position: refs/heads/master@{#16302}
This script is similar to header_usage.sh, but it counts usage (number
of files) of each class defined in some header file.
E.g., the following classes appear unused,
AsyncHttpsProxyServerSocket
CompositeMediaEngineWithFakeVoiceEngine
DesktopId
RtpDataCallback
ScopedMessageData
ScreencastEventCatcher
NOTRY=true
BUG=None
Review-Url: https://codereview.webrtc.org/2649103002
Cr-Commit-Position: refs/heads/master@{#16204}
This is a first step towards it. I plan to refactor modules_unittests before continuing with this.
BUG=webrtc:6626
NOTRY=True
Review-Url: https://codereview.webrtc.org/2626163004
Cr-Commit-Position: refs/heads/master@{#16109}
This tool takes list of video file names as input and calculates freezing metrics score for the video files without having reference to original video by comparing the PSNR and SSIM values of current and previous frame.
BUG=webrtc:6759
Review-Url: https://codereview.webrtc.org/2515253004
Cr-Commit-Position: refs/heads/master@{#15386}
And delete the method CongestionController::packet_router.
BUG=None
Review-Url: https://codereview.webrtc.org/2516983004
Cr-Commit-Position: refs/heads/master@{#15323}
Issue: This API was calculating the file_header and frame_header offset only for the first frame which is not the right logic. We need to skip the file and frame header every time we extract a new frame.
Also added a unit test case which compares the extracted frame with the frame stored in text file.
NOPRESUBMIT=true
NOTRY=true
BUG=webrtc:6761
Review-Url: https://codereview.webrtc.org/2532963002
Cr-Commit-Position: refs/heads/master@{#15288}
Reason for revert:
Unfortunately, this change breaks internal projects. Specifically the change to the CongestionController interface means anything implementing it will be forced to change in lock-step.
Original issue's description:
> Pass time constanct to bwe smoothing filter.
>
> BUG=webrtc:6443, webrtc:6303
>
> Committed: https://crrev.com/9abbf5ae4ec7d688a9b4aa03a405f3faadb74b90
> Cr-Commit-Position: refs/heads/master@{#15266}
TBR=minyue@webrtc.org,stefan@webrtc.org,solenberg@webrtc.org,michaelt@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6443, webrtc:6303
Review-Url: https://codereview.webrtc.org/2532993002
Cr-Commit-Position: refs/heads/master@{#15272}
Reason for revert:
Breaking some trybots due to memory error.
Original issue's description:
> Fixed bug in ExtractFrameFromY4mFile API which was not extracting the frames correctly.
>
> Issue: This API was calculating the file_header and frame_header offset only for the first frame which is not the right logic. We need to skip the file and frame header every time we extract a new frame.
>
> Also added a unit test case which compares the extracted frame with the frame stored in text file.
>
> BUG=webrtc:6761
>
> NOPRESUBMIT=true
> NOTRY=true
>
> Committed: https://crrev.com/b7636b4656d7f8c368963f2256dc2ef7b7ba89c8
> Cr-Commit-Position: refs/heads/master@{#15260}
TBR=phoglund@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6761
Review-Url: https://codereview.webrtc.org/2535783002
Cr-Commit-Position: refs/heads/master@{#15262}
Issue: This API was calculating the file_header and frame_header offset only for the first frame which is not the right logic. We need to skip the file and frame header every time we extract a new frame.
Also added a unit test case which compares the extracted frame with the frame stored in text file.
BUG=webrtc:6761
NOPRESUBMIT=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/2529923002
Cr-Commit-Position: refs/heads/master@{#15260}
Introduce a convention on categorizing GN targets:
1. Production code
2. Tests
3. Examples
4. Tools
The first two have targets spread out all over the tree,
while the latter are isolated to examples/ and tools/ directories.
Another new convention: Each directory's BUILD.gn file shall contain
a target named similar to the directory name. This target shall
contain the 'most common' production code, i.e. so that most
consumers of the directory can depend on only the directory
(which implicitly means that target in GN).
//webrtc:webrtc_tests is changed to depend on all WebRTC tests.
From now on, it's necessary to add new test targets to this dependency
tree in order to get them compiled.
Two new group targets are created:
//webrtc/modules/audio_coding:audio_coding_tests
//webrtc/modules/audio_processing:audio_processing_tests
to reduce the long list of tests in //webrtc:webrtc_tests.
Visibility on //webrtc:webrtc and //webrtc:webrtc_tests is restricted
to the root target, to avoid circular dependencies due to the monolithic
property of these targets (a problem we've had in the past).
The 'root' target at the top level is renamed to 'default', which means GN will
build this target instead of _all_ generated targets
(see https://chromium.googlesource.com/chromium/src/+/master/tools/gn/docs/faq.md#Can-I-control-what-targets-are-built-by-default).
This target now depends on everything we want to build, meaning all targets now
explicitly needs to be wired up from the root target in order to get build.
Having this, the number of compiled objects on Android is decreased from 8855 to 6276. It also gives us better control over our build.
BUG=webrtc:6440
TESTED=git cl try --clobber
NOTRY=True
Review-Url: https://codereview.webrtc.org/2441383002
Cr-Commit-Position: refs/heads/master@{#14821}
This helps a lot to avoid reducing the bitrate too quickly when there's a short period of very few packets delivered, followed by the rate resuming at the regular rate. It specifically avoids the BWE going down to super low values as a response delay spikes.
BUG=webrtc:6566
R=terelius@webrtc.org
Review URL: https://codereview.webrtc.org/2422063002 .
Cr-Commit-Position: refs/heads/master@{#14802}
This change trims the potentially longer array to the size of the smaller one.
NOTRY=True
BUG=none
Review-Url: https://codereview.webrtc.org/2357883002
Cr-Commit-Position: refs/heads/master@{#14657}
The RtcEventLog headers need to be accessible from any place which needs
logging, and the implementation needs access to data structures that are
logged.
After a discussion in the code review, we all agreed to move the RtcEventLog implementation into its own top level directory - which I called "logging/" in expectation that other types of logging may have similar requirements. The directory contains two main build targets - "rtc_event_log_api", which is just rtc_event_log.h, that has no external dependencies and can be used from anywhere, and "rtc_event_log_impl" which contains the rest of the implementation and has many dependencies (more in the future).
The "api" target can be referenced from anywhere, while the "impl" target is only needed at the place of instantiation (currently Call, soon to be moved to PeerConnection by https://codereview.webrtc.org/2353033005/).
This change allows using RtcEventLog in the p2p/ directory, so that we
can log STUN pings and ICE state transitions.
BUG=webrtc:6393
R=kjellander@webrtc.org, kwiberg@webrtc.org, solenberg@webrtc.org, stefan@webrtc.org, terelius@webrtc.org
Review URL: https://codereview.webrtc.org/2380683005 .
Cr-Commit-Position: refs/heads/master@{#14485}
To achieve this some refactoring was done to make it possible to synchronize
access to the DelayBasedBwe in TransportFeedbackAdapter:
- The callback was removed from DelayBasedBwe, it now instead returns its
result.
- TransportFeedbackAdapter was moved to modules/congestion_controller to avoid
unnecessary dependencies.
Reenables previously disabled flaky test. Can no longer reproduce flakiness with gtest-parallel and asan/tsan builds.
BUG=webrtc:6427, webrtc:6422
R=terelius@webrtc.org
Review URL: https://codereview.webrtc.org/2378103005 .
Cr-Commit-Position: refs/heads/master@{#14452}
Reason for revert:
Caused issues with webrtc_perf_tests on build bots.
Original issue's description:
> Fix race / crash in OnNetworkRouteChanged().
>
> To achieve this some refactoring was done to make it possible to synchronize
> access to the DelayBasedBwe in TransportFeedbackAdapter:
> - The callback was removed from DelayBasedBwe, it now instead returns its
> result.
> - TransportFeedbackAdapter was moved to modules/congestion_controller to avoid
> unnecessary dependencies.
>
> Reenables previously disabled flaky test. Can no longer reproduce flakiness with gtest-parallel and asan/tsan builds.
>
> BUG=webrtc:6427, webrtc:6422
>
> Committed: https://crrev.com/fd0d42669204e6dd92a60736bca7ae0196663024
> Cr-Commit-Position: refs/heads/master@{#14430}
TBR=terelius@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6427, webrtc:6422
Review-Url: https://codereview.webrtc.org/2377303002
Cr-Commit-Position: refs/heads/master@{#14433}
To achieve this some refactoring was done to make it possible to synchronize
access to the DelayBasedBwe in TransportFeedbackAdapter:
- The callback was removed from DelayBasedBwe, it now instead returns its
result.
- TransportFeedbackAdapter was moved to modules/congestion_controller to avoid
unnecessary dependencies.
Reenables previously disabled flaky test. Can no longer reproduce flakiness with gtest-parallel and asan/tsan builds.
BUG=webrtc:6427, webrtc:6422
Review-Url: https://codereview.webrtc.org/2366333003
Cr-Commit-Position: refs/heads/master@{#14430}
This is done to ensure GN targets are placed in the same directory as of the source files.
BUG=webrtc:6412
NOTRY=True
Review-Url: https://codereview.webrtc.org/2365383004
Cr-Commit-Position: refs/heads/master@{#14411}
