This makes a few things a lot clearer when looking at perf trace data:
* What module instances (where they were created) are called
* On what thread
* How frequently
* For how long
ProcessThread will be replaced by TaskQueue moving forward and this is a step towards understanding the behavior of the affected code.
BUG=webrtc:7219
Review-Url: https://codereview.webrtc.org/2729053002
Cr-Commit-Position: refs/heads/master@{#16998}
Patchset 1 is patchset #5 id:80001 of https://codereview.webrtc.org/2717983003/
Patchset 2 fix call_perf_test dep on fake_audio_device.
This reverts commit 985371bda999c6db51286586c5850d2ff58f3511.
Original cl description:
Move fake_audio_device to its own target.
The purpose is to make it usefull for test targets that does not need or can use test_common.
For some reason this also triggered override issues in rtp module tests that are fixed in the same cl.
BUG=none
TBR=kjellander@webrtc.org
NOTRY=True
Review-Url: https://codereview.webrtc.org/2718363002
Cr-Commit-Position: refs/heads/master@{#16922}
Reason for revert:
Reland after fixing broken perf tests.
Original issue's description:
> Revert of Set scaling limit at 320 * 180 for all implementations. (patchset #2 id:20001 of https://codereview.webrtc.org/2709153002/ )
>
> Reason for revert:
> Looks like webrtc_perf_test started failing on linux, mac and windows after this cl landed.
>
> Example failure:
>
> https://build.chromium.org/p/client.webrtc.perf/builders/Linux%20Trusty/builds/1386/steps/webrtc_perf_tests/logs/stdio
>
> [ RUN ] CallPerfTest.ReceivesCpuOveruseAndUnderuse
> ../../webrtc/call/call_perf_tests.cc:522: Failure
> Value of: Wait()
> Actual: false
> Expected: true
> Timed out before receiving an overuse callback.
> [ FAILED ] CallPerfTest.ReceivesCpuOveruseAndUnderuse (120056 ms)
>
>
> Original issue's description:
> > Set scaling limit at 320 * 180 for all implementations.
> >
> > The MediaCodec decoder on android has trouble decoding video at
> > so low resolutions. We set the limit a bit higher for all implementations
> > pending a robust software fallback implementation for MediaCodec.
> >
> > BUG=webrtc:7206
> >
> > Review-Url: https://codereview.webrtc.org/2709153002
> > Cr-Commit-Position: refs/heads/master@{#16798}
> > Committed: 560ddb7321
>
> TBR=magjed@webrtc.org,sprang@webrtc.org,kthelgason@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:7206
>
> Review-Url: https://codereview.webrtc.org/2711913007
> Cr-Commit-Position: refs/heads/master@{#16839}
> Committed: 37510bf094TBR=magjed@webrtc.org,sprang@webrtc.org,tommi@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7206
Review-Url: https://codereview.webrtc.org/2718013002
Cr-Commit-Position: refs/heads/master@{#16853}
The new constructor introduces two new changes:
* Support specifying thread priority at construction time.
- Moving forward, the SetPriority() method will be removed.
* New thread function type.
- The new type has 'void' as a return type and a polling loop
inside PlatformThread, is not used.
The old function type is still supported until all places have been moved over.
In this CL, the first steps towards deprecating the old mechanism are taken
by moving parts of the code that were simple to move, over to the new callback
type.
BUG=webrtc:7187
Review-Url: https://codereview.webrtc.org/2708723003
Cr-Commit-Position: refs/heads/master@{#16779}
Reason for revert:
Downstream fixed
Original issue's description:
> Revert of Fixes a bug where a video stream can get stuck in the suspended state. (patchset #8 id:120001 of https://codereview.webrtc.org/2705603002/ )
>
> Reason for revert:
> Breaks downstream
>
> Original issue's description:
> > Fixes a bug where a video stream can get stuck in the suspended state.
> >
> > This happens if a lot of FEC is allocated when the stream becomes suspended. The required bitrate to unsuspend can then be too high so that the padding bitrate we are allowed to generate is not enough.
> >
> > This CL also switches the tests from using ISAC to OPUS as RampUpTest.UpDownUpAudioVideoTransportSequenceNumberRtx relies on audio BWE to work (which is only compatible with OPUS). I don't know why it didn't fail before.
> >
> > BUG=webrtc:7178
> >
> > Review-Url: https://codereview.webrtc.org/2705603002
> > Cr-Commit-Position: refs/heads/master@{#16739}
> > Committed: a518a39963
>
> TBR=mflodman@webrtc.org,terelius@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:7178
>
> Review-Url: https://codereview.webrtc.org/2703393002
> Cr-Commit-Position: refs/heads/master@{#16751}
> Committed: b80bdcafedTBR=mflodman@webrtc.org,terelius@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:7178
Review-Url: https://codereview.webrtc.org/2704323003
Cr-Commit-Position: refs/heads/master@{#16753}
Reason for revert:
Breaks downstream
Original issue's description:
> Fixes a bug where a video stream can get stuck in the suspended state.
>
> This happens if a lot of FEC is allocated when the stream becomes suspended. The required bitrate to unsuspend can then be too high so that the padding bitrate we are allowed to generate is not enough.
>
> This CL also switches the tests from using ISAC to OPUS as RampUpTest.UpDownUpAudioVideoTransportSequenceNumberRtx relies on audio BWE to work (which is only compatible with OPUS). I don't know why it didn't fail before.
>
> BUG=webrtc:7178
>
> Review-Url: https://codereview.webrtc.org/2705603002
> Cr-Commit-Position: refs/heads/master@{#16739}
> Committed: a518a39963TBR=mflodman@webrtc.org,terelius@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:7178
Review-Url: https://codereview.webrtc.org/2703393002
Cr-Commit-Position: refs/heads/master@{#16751}
This happens if a lot of FEC is allocated when the stream becomes suspended. The required bitrate to unsuspend can then be too high so that the padding bitrate we are allowed to generate is not enough.
This CL also switches the tests from using ISAC to OPUS as RampUpTest.UpDownUpAudioVideoTransportSequenceNumberRtx relies on audio BWE to work (which is only compatible with OPUS). I don't know why it didn't fail before.
BUG=webrtc:7178
Review-Url: https://codereview.webrtc.org/2705603002
Cr-Commit-Position: refs/heads/master@{#16739}
This avoids redoing RTP header parsing already done in Call, for video.
The next step is to convert other types of receive streams, i.e.,
audio and flexfec, to use a compatible OnRtpPacket method. We can then
introduce a shared base interface, and simplify media-independent
receive processing in Call.
BUG=webrtc:7135
Review-Url: https://codereview.webrtc.org/2681673004
Cr-Commit-Position: refs/heads/master@{#16583}
The current method with max_pixel_count and max_pixel_count_step_up,
where only one should be used at a time and this first signaling an
inclusive upper bound and other other an exclusive lower bound, makes
for a lot of confusion.
I've updated this to have a desired target and a maximum instead. The
source should select a resolution as close to the target as possible,
but no higher than the maximum.
I intend to also add similar frame rate settings in an upcoming cl.
BUG=webrtc:4172,webrtc:6850
Review-Url: https://codereview.webrtc.org/2672793002
Cr-Commit-Position: refs/heads/master@{#16533}
We can then drop the CongestionController and RemoteBitrateEstimator
completely from the receive streams.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2669463006
Cr-Commit-Position: refs/heads/master@{#16459}
Delete the calls from RtpStreamReceiver (for video) and
AudioReceiveStream.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2659563002
Cr-Commit-Position: refs/heads/master@{#16393}
This CL introduces a way for the VideoReceiveStreams to check whether
they are protected by any FlexfecReceiveStreams. This is done in the
VideoReceiveStream::Start() method, which then propagates this information
down to the jitter buffer adaptation logic.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2649973005
Cr-Commit-Position: refs/heads/master@{#16328}
This avoids issues where the bitrate produced by the codec is far lower than the target bitrate in the beginning, which causes the delay-based BWE to be initialized accordingly.
BUG=webrtc:5079
Review-Url: https://codereview.webrtc.org/2653883002
Cr-Commit-Position: refs/heads/master@{#16327}
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}
Reason for revert:
Speculative revert for perf regression related to ramp-up on android. See https://bugs.chromium.org/p/chromium/issues/detail?id=682611
Original issue's description:
> Move congestion controller processing to the pacer thread.
>
> Also rename it from pacer_thread_ to congestion_controller_thread_.
>
> BUG=webrtc:6847
>
> Review-Url: https://codereview.webrtc.org/2637783003
> Cr-Commit-Position: refs/heads/master@{#16134}
> Committed: b3dc2b7b1eTBR=danilchap@webrtc.org,stefan@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2644603003
Cr-Commit-Position: refs/heads/master@{#16163}
Also rename it from pacer_thread_ to congestion_controller_thread_.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2637783003
Cr-Commit-Position: refs/heads/master@{#16134}
This CL adds an RTP module to FlexfecReceiveStreamImpl, and wires it up
to send RTCP RRs. It further makes some methods take const refs instead
of values, to make it more clear where packet copies are made. This
change reduces the number of copies by one, for the case when media
packets are added to the FlexFEC receiver.
The end-to-end test is modified to check for RTCP RRs being sent.
Part of this modification involves some indentation changes, and the
diff thus looks bigger than it logically is.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2625633003
Cr-Commit-Position: refs/heads/master@{#16106}
That object will be used when we enable RTCP reporting from FlexfecReceiveStream.
Other related changes:
- Stop using FlexfecConfig (from config.h) at receive side in WebRtcVideoEngine2.
- Add a IsCompleteAndEnabled() method to FlexfecReceiveStream::Config, to be
used in WebRtcVideoEngine2.
- Centralize the construction of the FlexfecReceiveStream::Config in unit tests.
This will make future additions to the unit tests cleaner.
- Simplify setup for receiving FlexFEC in VideoQualityTest.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2589713003
Cr-Commit-Position: refs/heads/master@{#16059}
Reason for revert:
Doing a reland where systeminfo.cc includes basictypes.h so that CPU_X86 etc. are defined when they are checked/used.
Original issue's description:
> Revert of Replace basictypes.h with stdint.h for int_t types. (patchset #1 id:1 of https://codereview.webrtc.org/2604043002/ )
>
> Reason for revert:
> Very likely cause of Chromium import bot breakage (unused function '__cpuid'), TBD why.
>
> Original issue's description:
> > Replace basictypes.h with stdint.h for int_t types.
> >
> > Removes basictypes.h for types that only makes use of it for fixed-size-int
> > typedefs and replaces it with stdint.h.
> >
> > BUG=webrtc:6853
> > R=tommi@webrtc.org
> >
> > Review-Url: https://codereview.webrtc.org/2604043002
> > Cr-Commit-Position: refs/heads/master@{#15867}
> > Committed: 7fd1a75300
>
> TBR=tommi@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6853
>
> Review-Url: https://codereview.webrtc.org/2603203003
> Cr-Commit-Position: refs/heads/master@{#15869}
> Committed: 7eb0e23bcf
BUG=webrtc:6853
TBR=tommi@webrtc.org
Review-Url: https://codereview.webrtc.org/2609783002
Cr-Commit-Position: refs/heads/master@{#15873}
Reason for revert:
Very likely cause of Chromium import bot breakage (unused function '__cpuid'), TBD why.
Original issue's description:
> Replace basictypes.h with stdint.h for int_t types.
>
> Removes basictypes.h for types that only makes use of it for fixed-size-int
> typedefs and replaces it with stdint.h.
>
> BUG=webrtc:6853
> R=tommi@webrtc.org
>
> Review-Url: https://codereview.webrtc.org/2604043002
> Cr-Commit-Position: refs/heads/master@{#15867}
> Committed: 7fd1a75300TBR=tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6853
Review-Url: https://codereview.webrtc.org/2603203003
Cr-Commit-Position: refs/heads/master@{#15869}
Removes basictypes.h for types that only makes use of it for fixed-size-int
typedefs and replaces it with stdint.h.
BUG=webrtc:6853
R=tommi@webrtc.org
Review-Url: https://codereview.webrtc.org/2604043002
Cr-Commit-Position: refs/heads/master@{#15867}
- UpdateRtcpList
- RtpToNtp
class RtpToNtpEstimator
- UpdateMeasurements
- Estimate
List with rtcp measurements is now private.
BUG=none
Review-Url: https://codereview.webrtc.org/2574133003
Cr-Commit-Position: refs/heads/master@{#15762}
