Reason for revert:
I will try to reland next week because it is causing some problems.
Original issue's description:
> To accommodate some downstream WebRTC users we need to loosen
> the coupling between our code and the //third_party/protobuf.
>
> This includes using typedefs to define strings instead of
> assuming std::string.
>
> After this refactoring it will be possible to link with other
> protobuf implementations than the current one.
>
> We moved the PRESUBMIT check to another CL [1]. The goal of this
> presubmit is to avoid the direct usage of google::protobuf outside
> of the webrtc/base/protobuf_utils.h header file.
>
> [1] - https://codereview.webrtc.org/2753823003/
>
> BUG=webrtc:7340
> NOTRY=True
>
> Review-Url: https://codereview.webrtc.org/2747863003
> Cr-Commit-Position: refs/heads/master@{#17466}
> Committed: 16ab93b952TBR=kjellander@webrtc.org,henrik.lundin@webrtc.org,kwiberg@webrtc.org,michaelt@webrtc.org,peah@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7340
Review-Url: https://codereview.webrtc.org/2786363002
Cr-Commit-Position: refs/heads/master@{#17483}
the coupling between our code and the //third_party/protobuf.
This includes using typedefs to define strings instead of
assuming std::string.
After this refactoring it will be possible to link with other
protobuf implementations than the current one.
We moved the PRESUBMIT check to another CL [1]. The goal of this
presubmit is to avoid the direct usage of google::protobuf outside
of the webrtc/base/protobuf_utils.h header file.
[1] - https://codereview.webrtc.org/2753823003/
BUG=webrtc:7340
NOTRY=True
Review-Url: https://codereview.webrtc.org/2747863003
Cr-Commit-Position: refs/heads/master@{#17466}
This CL is one in a series. To finish the work, the following CLs will be added:
1. CL for connecting RPLR as well
2. CL for RPLR-based FecController
3. CL for allowing experiment-driven configuration of the above (through both field-trials and protobuf)
BUG=webrtc:7058
Review-Url: https://codereview.webrtc.org/2638083002
Cr-Commit-Position: refs/heads/master@{#17365}
1. GetTransportFeedbackVector will now return a vector which also explicitly states lost packets.
2. The returned vector is unsorted (uses default order - by sequence number). It's up to the users to sort otherwise, if they need a different order.
BUG=None
Review-Url: https://codereview.webrtc.org/2707383006
Cr-Commit-Position: refs/heads/master@{#17114}
In this CL:
- Add message BweProbeCluster and BweProbeResult to rtc_event_log.proto.
- Add corresponding log functions to RtcEventLog.
- Add optional field |probe_cluster_id| to RtpPacket message and added
an overload function to log with this information.
- Propagate the probe_cluster_id to where RTP packets are logged.
BUG=webrtc:6984
Review-Url: https://codereview.webrtc.org/2666533002
Cr-Commit-Position: refs/heads/master@{#16857}
In order to not make this CL too large I have broken it down into at least two
steps. Previous CL: https://codereview.chromium.org/2628563003/
webrtc::PacedSender::Process <--- previous CL start here
webrtc::PacedSender::SendPacket
webrtc::PacketRouter::TimeToSendPacket
webrtc::ModuleRtpRtcpImpl::TimeToSendPacket <--- previous CL end here, this Cl start here
webrtc::RTPSender::TimeToSendPacket
webrtc::RTPSender::PrepareAndSendPacket
webrtc::RTPSender::AddPacketToTransportFeedback
webrtc::TransportFeedbackAdapter::AddPacket
webrtc::SendTimeHistory::AddAndRemoveOld <--- this CL end here
BUG=webrtc:6822
Review-Url: https://codereview.webrtc.org/2708873003
Cr-Commit-Position: refs/heads/master@{#16796}
Rename loss based and delay based bwe updates in proto (and correspondingly in the C++ code).
BUG=webrtc:6423
Review-Url: https://codereview.webrtc.org/2705613002
Cr-Commit-Position: refs/heads/master@{#16719}
In order to not make this CL too large I have broken it down into at least two steps. In this CL we only propagate the pacing information part of the way:
webrtc::PacedSender::Process <--- propagate from here
webrtc::PacedSender::SendPacket
webrtc::PacketRouter::TimeToSendPacket
webrtc::ModuleRtpRtcpImpl::TimeToSendPacket <--- to here
webrtc::RTPSender::TimeToSendPacket
webrtc::RTPSender::PrepareAndSendPacket
webrtc::RTPSender::AddPacketToTransportFeedback
webrtc::TransportFeedbackAdapter::AddPacket
webrtc::SendTimeHistory::AddAndRemoveOld <--- goal is to propagte it here
BUG=webrtc:6822
Review-Url: https://codereview.webrtc.org/2628563003
Cr-Commit-Position: refs/heads/master@{#16664}
The frame_analyzer which is used by compare_videos.py needs to handle
barcode errors. As before the reference and the test video can contain
repeated frames. When there are barcode decode errors in the test video,
then we should not let that contribute to the skipped frames score. When
there are barcode decode errors in the reference video, then we need to
take proper care to still calculate skipped barcodes when the
corresponding frames are not present in the test video and the test
video does not have a frame with a barcode decode error that could have
been the same frame as the one in the reference.
A new metric total number of skipped frames and for number of decode
errors is introduced. Barcodes that appears in the test video, but not
in the reference video are also listed.
BUG=webrtc:6967
Review-Url: https://codereview.webrtc.org/2666333003
Cr-Commit-Position: refs/heads/master@{#16638}
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}
