Packets recovered by ULPFEC enter through
RtpVideoStreamReceiver::OnRecoveredPacket, which does RTP
header extension parsing. Packets recovered by FlexFEC, however,
enter through Call::OnRecoveredPacket, which prior to this
CL did not do RTP header extension parsing.
The lack of RTP header extension parsing for FlexFEC packets is a
regression since https://codereview.webrtc.org/2886993005/.
TESTED=Using Android app with FlexFEC field trial enabled.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/3002023002
Cr-Commit-Position: refs/heads/master@{#19460}
Also, use it to save worst psnr frame in video quality tests. It is indented that these saved frames from perfbots will be uploaded to the cloud and will be available in chrome perf dashboard. Because of that size of the saved frame is somewhat an issue. Also, y4m is not convenient to view.
BUG=webrtc:8030
Review-Url: https://codereview.webrtc.org/2998143002
Cr-Commit-Position: refs/heads/master@{#19450}
Moved the headers video_receive_stream.h and video_send_stream.h from
webrtc/ into webrtc/call/ as part of the Slim and Modular work.
The GN target webrtc:video_stream_api has moved to
webrtc/call:video_stream_api.
There are headers left in webrtc/ with the same name including the
moved headers in webrtc/call/ for not breaking external projects
depending on WebRTC.
At the same time, some minor cleanup is done: Non-pure-virtual functions declared in the two affected headers now have definitions in the same target. After making this change, our 'chromium-style' plugin detected some style violations that have now been fixed: non-inlined constructors and destructors have been added to a number of classes, both inside the GN target of the two affected headers, and in other targets.
BUG=webrtc:8107
Review-Url: https://codereview.webrtc.org/3000253002
Cr-Commit-Position: refs/heads/master@{#19448}
DirectTransport has so far used its own thread, which led to a different threading-model for in the unit-tests than is used in actual WebRTC. Because of that, some critical-sections that weren't truly necessary in WebRTC could not be replaced with thread-checks, because those checks failed in unit-tests.
This CL introduces SingleThreadedTaskQueue - a TaskQueue which guarantees to run all of its tasks on the same thread (rtc::TaskQueue doesn't guarantee that on Mac) - and uses that for DirectTransport. CLs based on top of this will uncomment thread-checks which had to be commented out before, and remove unnecessary critical-sections.
Future work would probably replace the thread-checkers by more sophisticated serialized-access checks, allowing us to move from the SingleThreadedTaskQueue to a normal TaskQueue.
Related implementation notes:
* This CL has made DirectTransport::StopSending() superfluous, and so it was deleted.
BUG=webrtc:8113, webrtc:7405, webrtc:8056, webrtc:8116
Review-Url: https://codereview.webrtc.org/2998923002
Cr-Commit-Position: refs/heads/master@{#19445}
Reason for revert:
We are not certain this is the behavior we want.
Original issue's description:
> Fix the video buffer size should take rtt into consideration
>
> BUG=webrtc:8010
>
> Review-Url: https://codereview.webrtc.org/2980413002
> Cr-Commit-Position: refs/heads/master@{#19285}
> Committed: f1e08d0b58TBR=sprang@webrtc.org,gustavogb@gmail.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:8010
Review-Url: https://codereview.webrtc.org/3002033002
Cr-Commit-Position: refs/heads/master@{#19442}
Reason for revert:
Breaks webrtc.linux
Original issue's description:
> Add Jpeg frame writer for test support.
>
> Also, use it to save worst psnr frame in video quality tests. It is indented that these saved frames from perfbots will be uploaded to the cloud and will be available in chrome perf dashboard. Because of that size of the saved frame is somewhat an issue. Also, y4m is not convenient to view.
>
> BUG=webrtc:8030
>
> Review-Url: https://codereview.webrtc.org/2990563002
> Cr-Commit-Position: refs/heads/master@{#19414}
> Committed: 26e5cbd6bbTBR=stefan@webrtc.org,pbos@webrtc.org,sprang@webrtc.org,ilnik@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:8030
Review-Url: https://codereview.webrtc.org/2998133002
Cr-Commit-Position: refs/heads/master@{#19419}
Also, use it to save worst psnr frame in video quality tests. It is indented that these saved frames from perfbots will be uploaded to the cloud and will be available in chrome perf dashboard. Because of that size of the saved frame is somewhat an issue. Also, y4m is not convenient to view.
BUG=webrtc:8030
Review-Url: https://codereview.webrtc.org/2990563002
Cr-Commit-Position: refs/heads/master@{#19414}
Reason for revert:
iOS workaround.
Original issue's description:
> Revert of quest keyframes more frequently on stream start/decoding error. (patchset #2 id:170001 of https://codereview.webrtc.org/2996823002/ )
>
> Reason for revert:
> Causes iOS H264 calls received in the background to have increased delay before being able to decode stream from sender due to not having a keyframe.
>
> Original issue's description:
> > Reland of quest keyframes more frequently on stream start/decoding error. (patchset #1 id:1 of https://codereview.chromium.org/2994043002/ )
> >
> > Reason for revert:
> > Create fix CL.
> >
> > Original issue's description:
> > > Revert of Request keyframes more frequently on stream start/decoding error. (patchset #1 id:1 of https://codereview.webrtc.org/2993793002/ )
> > >
> > > Reason for revert:
> > > Broke downstream test that was waiting for 5 keyframes to be received within 10 seconds. Maybe the issue is that "stats_callback_->OnCompleteFrame(frame->num_references == 0, ..." was changed to "frame->is_keyframe()"?
> > >
> > > Original issue's description:
> > > > Request keyframes more frequently on stream start/decoding error.
> > > >
> > > > In this CL:
> > > > - Added FrameObject::is_keyframe() convinience function.
> > > > - Moved logic to request keyframes on decoding error from VideoReceived to
> > > > VideoReceiveStream.
> > > > - Added keyframe_required as a parameter to FrameBuffer::NextFrame.
> > > >
> > > > BUG=webrtc:8074
> > > >
> > > > Review-Url: https://codereview.webrtc.org/2993793002
> > > > Cr-Commit-Position: refs/heads/master@{#19280}
> > > > Committed: 26b4804358
> > >
> > > TBR=terelius@webrtc.org,stefan@webrtc.org,noahric@chromium.org,philipel@webrtc.org
> > > # Skipping CQ checks because original CL landed less than 1 days ago.
> > > NOPRESUBMIT=true
> > > NOTREECHECKS=true
> > > NOTRY=true
> > > BUG=webrtc:8074
> > >
> > > Review-Url: https://codereview.webrtc.org/2994043002
> > > Cr-Commit-Position: refs/heads/master@{#19295}
> > > Committed: 77a983185f
> >
> > TBR=terelius@webrtc.org,stefan@webrtc.org,noahric@chromium.org,deadbeef@webrtc.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > BUG=webrtc:8074
> >
> > Review-Url: https://codereview.webrtc.org/2996823002
> > Cr-Commit-Position: refs/heads/master@{#19324}
> > Committed: 628ac5964e
>
> TBR=terelius@webrtc.org,stefan@webrtc.org,noahric@chromium.org,deadbeef@webrtc.org,philipel@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:8074
>
> Review-Url: https://codereview.webrtc.org/2995153002
> Cr-Commit-Position: refs/heads/master@{#19392}
> Committed: 53959fcc2bTBR=terelius@webrtc.org,stefan@webrtc.org,noahric@chromium.org,deadbeef@webrtc.org,tkchin@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
BUG=webrtc:8074
Review-Url: https://codereview.webrtc.org/2996153003
Cr-Commit-Position: refs/heads/master@{#19410}
In preparation of running DirectTransport on a TaskQueue in unit-tests, change the thread-checkers to sequence-checkers. This is necessary for Mac and iOS, where the TaskQueue is guaranteed to run sequentially, but not guaranteed to do so on only one thread.
TODO: Add the relevant BUGs.
BUG=None
Review-Url: https://codereview.webrtc.org/2997853002
Cr-Commit-Position: refs/heads/master@{#19408}
Reason for revert:
Create reland CL to add fix to.
Original issue's description:
> Revert of Add a flags field to video timing extension. (patchset #15 id:280001 of https://codereview.webrtc.org/3000753002/ )
>
> Reason for revert:
> Speculative revet for breaking remoting_unittests in fyi bots.
> https://build.chromium.org/p/chromium.webrtc.fyi/waterfall?builder=Win7%20Tester
>
> Original issue's description:
> > Add a flags field to video timing extension.
> >
> > The rtp header extension for video timing shuold have an additional
> > field for signaling metadata, such as what triggered the extension for
> > this particular frame. This will allow separating frames select because
> > of outlier sizes from regular frames, for more accurate stats.
> >
> > This implementation is backwards compatible in that it can read video
> > timing extensions without the new flag field, but it always sends with
> > it included.
> >
> > BUG=webrtc:7594
> >
> > Review-Url: https://codereview.webrtc.org/3000753002
> > Cr-Commit-Position: refs/heads/master@{#19353}
> > Committed: cf5d485e14
>
> TBR=danilchap@webrtc.org,kthelgason@webrtc.org,stefan@webrtc.org,sprang@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:7594
>
> Review-Url: https://codereview.webrtc.org/2995953002
> Cr-Commit-Position: refs/heads/master@{#19360}
> Committed: f0f7378b05TBR=danilchap@webrtc.org,kthelgason@webrtc.org,stefan@webrtc.org,emircan@google.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7594
Review-Url: https://codereview.webrtc.org/2996153002
Cr-Commit-Position: refs/heads/master@{#19405}
Reason for revert:
Causes iOS H264 calls received in the background to have increased delay before being able to decode stream from sender due to not having a keyframe.
Original issue's description:
> Reland of quest keyframes more frequently on stream start/decoding error. (patchset #1 id:1 of https://codereview.chromium.org/2994043002/ )
>
> Reason for revert:
> Create fix CL.
>
> Original issue's description:
> > Revert of Request keyframes more frequently on stream start/decoding error. (patchset #1 id:1 of https://codereview.webrtc.org/2993793002/ )
> >
> > Reason for revert:
> > Broke downstream test that was waiting for 5 keyframes to be received within 10 seconds. Maybe the issue is that "stats_callback_->OnCompleteFrame(frame->num_references == 0, ..." was changed to "frame->is_keyframe()"?
> >
> > Original issue's description:
> > > Request keyframes more frequently on stream start/decoding error.
> > >
> > > In this CL:
> > > - Added FrameObject::is_keyframe() convinience function.
> > > - Moved logic to request keyframes on decoding error from VideoReceived to
> > > VideoReceiveStream.
> > > - Added keyframe_required as a parameter to FrameBuffer::NextFrame.
> > >
> > > BUG=webrtc:8074
> > >
> > > Review-Url: https://codereview.webrtc.org/2993793002
> > > Cr-Commit-Position: refs/heads/master@{#19280}
> > > Committed: 26b4804358
> >
> > TBR=terelius@webrtc.org,stefan@webrtc.org,noahric@chromium.org,philipel@webrtc.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=webrtc:8074
> >
> > Review-Url: https://codereview.webrtc.org/2994043002
> > Cr-Commit-Position: refs/heads/master@{#19295}
> > Committed: 77a983185f
>
> TBR=terelius@webrtc.org,stefan@webrtc.org,noahric@chromium.org,deadbeef@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> BUG=webrtc:8074
>
> Review-Url: https://codereview.webrtc.org/2996823002
> Cr-Commit-Position: refs/heads/master@{#19324}
> Committed: 628ac5964eTBR=terelius@webrtc.org,stefan@webrtc.org,noahric@chromium.org,deadbeef@webrtc.org,philipel@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:8074
Review-Url: https://codereview.webrtc.org/2995153002
Cr-Commit-Position: refs/heads/master@{#19392}
Make it possible for forced VP8 SW fallback encoder to set min_pixels_per_frame via GetScalingSettings().
Add a min required resolution (in addition to bitrate) before releasing forced SW fallback.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/3000693003
Cr-Commit-Position: refs/heads/master@{#19390}
Reason for revert:
Reland
Original issue's description:
> Revert of Make the acceptable queue in the cwnd experiment configurable. (patchset #1 id:1 of https://codereview.webrtc.org/2998753002/ )
>
> Reason for revert:
> Speculative revert to see if this caused regressions in android perf tests.
>
> Original issue's description:
> > Make the acceptable queue in the cwnd experiment configurable.
> >
> > BUG=webrtc:7926
> >
> > Review-Url: https://codereview.webrtc.org/2998753002
> > Cr-Commit-Position: refs/heads/master@{#19320}
> > Committed: 7c83c56b6d
>
> TBR=philipel@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:7926
>
> Review-Url: https://codereview.webrtc.org/2999893002
> Cr-Commit-Position: refs/heads/master@{#19337}
> Committed: c5d9e63c2bTBR=philipel@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7926
Review-Url: https://codereview.webrtc.org/2999083002
Cr-Commit-Position: refs/heads/master@{#19377}
Reason for revert:
Reland
Original issue's description:
> Revert of Add functionality which limits the number of bytes on the network. (patchset #26 id:500001 of https://codereview.webrtc.org/2918323002/ )
>
> Reason for revert:
> Speculative revert to see if this caused regressions in android perf tests.
>
> Original issue's description:
> > Add functionality which limits the number of bytes on the network.
> >
> > The limit is based on the bandwidth delay product, but also adds some additional slack to compensate for the sawtooth-like BWE pattern and the slowness of the encoder rate control. The delay is estimated based on the time from sending a packet until an ack is received. Since acks are received in bursts (feedback is only sent periodically), a min filter is used to estimate the rtt.
> >
> > Whenever the in flight bytes reaches the congestion window, the pacer is paused, which in turn will result in send-side queues growing. Eventually the encoders will be paused as the pacer queue grows large (currently 2 seconds).
> >
> > BUG=webrtc:7926
> >
> > Review-Url: https://codereview.webrtc.org/2918323002
> > Cr-Commit-Position: refs/heads/master@{#19289}
> > Committed: 8497fdde43
>
> TBR=terelius@webrtc.org,philipel@webrtc.org,tschumim@webrtc.org,gnish@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:7926
>
> Review-Url: https://codereview.webrtc.org/3001653002
> Cr-Commit-Position: refs/heads/master@{#19339}
> Committed: 64136af364TBR=terelius@webrtc.org,philipel@webrtc.org,tschumim@webrtc.org,gnish@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7926
Review-Url: https://codereview.webrtc.org/2994343002
Cr-Commit-Position: refs/heads/master@{#19373}
Reason for revert:
Speculative revet for breaking remoting_unittests in fyi bots.
https://build.chromium.org/p/chromium.webrtc.fyi/waterfall?builder=Win7%20Tester
Original issue's description:
> Add a flags field to video timing extension.
>
> The rtp header extension for video timing shuold have an additional
> field for signaling metadata, such as what triggered the extension for
> this particular frame. This will allow separating frames select because
> of outlier sizes from regular frames, for more accurate stats.
>
> This implementation is backwards compatible in that it can read video
> timing extensions without the new flag field, but it always sends with
> it included.
>
> BUG=webrtc:7594
>
> Review-Url: https://codereview.webrtc.org/3000753002
> Cr-Commit-Position: refs/heads/master@{#19353}
> Committed: cf5d485e14TBR=danilchap@webrtc.org,kthelgason@webrtc.org,stefan@webrtc.org,sprang@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7594
Review-Url: https://codereview.webrtc.org/2995953002
Cr-Commit-Position: refs/heads/master@{#19360}
The rtp header extension for video timing shuold have an additional
field for signaling metadata, such as what triggered the extension for
this particular frame. This will allow separating frames select because
of outlier sizes from regular frames, for more accurate stats.
This implementation is backwards compatible in that it can read video
timing extensions without the new flag field, but it always sends with
it included.
BUG=webrtc:7594
Review-Url: https://codereview.webrtc.org/3000753002
Cr-Commit-Position: refs/heads/master@{#19353}
Two bugs:
1) The max value should only be reported if the average is also
reported. Otherwise the max might become lower than average.
(On average).
2) When reporting that max value, actually use the max value.
BUG=webrtc:7420
Review-Url: https://codereview.webrtc.org/3002593002
Cr-Commit-Position: refs/heads/master@{#19352}
Reason for revert:
Speculative revert to see if this caused regressions in android perf tests.
Original issue's description:
> Add functionality which limits the number of bytes on the network.
>
> The limit is based on the bandwidth delay product, but also adds some additional slack to compensate for the sawtooth-like BWE pattern and the slowness of the encoder rate control. The delay is estimated based on the time from sending a packet until an ack is received. Since acks are received in bursts (feedback is only sent periodically), a min filter is used to estimate the rtt.
>
> Whenever the in flight bytes reaches the congestion window, the pacer is paused, which in turn will result in send-side queues growing. Eventually the encoders will be paused as the pacer queue grows large (currently 2 seconds).
>
> BUG=webrtc:7926
>
> Review-Url: https://codereview.webrtc.org/2918323002
> Cr-Commit-Position: refs/heads/master@{#19289}
> Committed: 8497fdde43TBR=terelius@webrtc.org,philipel@webrtc.org,tschumim@webrtc.org,gnish@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7926
Review-Url: https://codereview.webrtc.org/3001653002
Cr-Commit-Position: refs/heads/master@{#19339}
Reason for revert:
Speculative revert to see if this caused regressions in android perf tests.
Original issue's description:
> Make the acceptable queue in the cwnd experiment configurable.
>
> BUG=webrtc:7926
>
> Review-Url: https://codereview.webrtc.org/2998753002
> Cr-Commit-Position: refs/heads/master@{#19320}
> Committed: 7c83c56b6dTBR=philipel@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7926
Review-Url: https://codereview.webrtc.org/2999893002
Cr-Commit-Position: refs/heads/master@{#19337}
Reason for revert:
Create fix CL.
Original issue's description:
> Revert of Request keyframes more frequently on stream start/decoding error. (patchset #1 id:1 of https://codereview.webrtc.org/2993793002/ )
>
> Reason for revert:
> Broke downstream test that was waiting for 5 keyframes to be received within 10 seconds. Maybe the issue is that "stats_callback_->OnCompleteFrame(frame->num_references == 0, ..." was changed to "frame->is_keyframe()"?
>
> Original issue's description:
> > Request keyframes more frequently on stream start/decoding error.
> >
> > In this CL:
> > - Added FrameObject::is_keyframe() convinience function.
> > - Moved logic to request keyframes on decoding error from VideoReceived to
> > VideoReceiveStream.
> > - Added keyframe_required as a parameter to FrameBuffer::NextFrame.
> >
> > BUG=webrtc:8074
> >
> > Review-Url: https://codereview.webrtc.org/2993793002
> > Cr-Commit-Position: refs/heads/master@{#19280}
> > Committed: 26b4804358
>
> TBR=terelius@webrtc.org,stefan@webrtc.org,noahric@chromium.org,philipel@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:8074
>
> Review-Url: https://codereview.webrtc.org/2994043002
> Cr-Commit-Position: refs/heads/master@{#19295}
> Committed: 77a983185fTBR=terelius@webrtc.org,stefan@webrtc.org,noahric@chromium.org,deadbeef@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
BUG=webrtc:8074
Review-Url: https://codereview.webrtc.org/2996823002
Cr-Commit-Position: refs/heads/master@{#19324}
* EndToEndTest.InitialProbing had an uninitialized boolean.
* Both tests used RTC_DCHECK where one would normally expect an RTC_DCHECK.
BUG=webrtc:8085
Review-Url: https://codereview.webrtc.org/2998793002
Cr-Commit-Position: refs/heads/master@{#19309}
There exist a bug in the video_coding::PacketBuffer which triggers when a
frame is the same size as the buffer. A trivial workaround is to increase
the start size to something big so that this never happens in practice.
The bug has been fixed but we still want to test the workaround in ToT,
which is why this CL exist.
BUG=webrtc:8028, chromium:752886
R=stefan@webrtc.org
Review-Url: https://codereview.webrtc.org/2994093002 .
Cr-Commit-Position: refs/heads/master@{#19308}
Reason for revert:
Broke downstream test that was waiting for 5 keyframes to be received within 10 seconds. Maybe the issue is that "stats_callback_->OnCompleteFrame(frame->num_references == 0, ..." was changed to "frame->is_keyframe()"?
Original issue's description:
> Request keyframes more frequently on stream start/decoding error.
>
> In this CL:
> - Added FrameObject::is_keyframe() convinience function.
> - Moved logic to request keyframes on decoding error from VideoReceived to
> VideoReceiveStream.
> - Added keyframe_required as a parameter to FrameBuffer::NextFrame.
>
> BUG=webrtc:8074
>
> Review-Url: https://codereview.webrtc.org/2993793002
> Cr-Commit-Position: refs/heads/master@{#19280}
> Committed: 26b4804358TBR=terelius@webrtc.org,stefan@webrtc.org,noahric@chromium.org,philipel@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:8074
Review-Url: https://codereview.webrtc.org/2994043002
Cr-Commit-Position: refs/heads/master@{#19295}
The limit is based on the bandwidth delay product, but also adds some additional slack to compensate for the sawtooth-like BWE pattern and the slowness of the encoder rate control. The delay is estimated based on the time from sending a packet until an ack is received. Since acks are received in bursts (feedback is only sent periodically), a min filter is used to estimate the rtt.
Whenever the in flight bytes reaches the congestion window, the pacer is paused, which in turn will result in send-side queues growing. Eventually the encoders will be paused as the pacer queue grows large (currently 2 seconds).
BUG=webrtc:7926
Review-Url: https://codereview.webrtc.org/2918323002
Cr-Commit-Position: refs/heads/master@{#19289}
[This CL is work in progress.]
Wire up the rtp keep-alive in webrtc::Call::Config using new
SetRtpTransportParameters() method on RtpTransportInterface.
BUG=webrtc:7907
Review-Url: https://codereview.webrtc.org/2981513002
Cr-Commit-Position: refs/heads/master@{#19287}
In this CL:
- Added FrameObject::is_keyframe() convinience function.
- Moved logic to request keyframes on decoding error from VideoReceived to
VideoReceiveStream.
- Added keyframe_required as a parameter to FrameBuffer::NextFrame.
BUG=webrtc:8074
Review-Url: https://codereview.webrtc.org/2993793002
Cr-Commit-Position: refs/heads/master@{#19280}
This CL:
- Renames the ViEEncoder class to VideoStreamEncoder, according to discussions.
- Renames variables 'vie_encode' to 'video_stream_encoder'.
- Formatting to match style guide.
- No other changes.
BUG=webrtc:8064
Review-Url: https://codereview.webrtc.org/2995433002
Cr-Commit-Position: refs/heads/master@{#19237}
include/mock/mock_process_thread.h was not tracked by GN.
This cl creates a target for it. The target is testonly because it
depends on "webrtc/test:rtp_test_utils".
This means that dependencies to this header cannot fly under the
GN radar anymore. :)
BUG=webrtc:7652
NOTRY=True
Review-Url: https://codereview.webrtc.org/2881343003
Cr-Commit-Position: refs/heads/master@{#19234}
In preparation of making RTP packet demuxing many-to-one (one SSRC goes to one sink, but one sink may have multiple SSRCs), we need to remove FlexFEC's dependence on being able to register itself with the demuxer. Instead, we register FlexFEC streams with the streams they protect; when those streams get packets, they'll forward them to their associated FlexFEC streams, too.
BUG=webrtc:7135
Review-Url: https://codereview.webrtc.org/2974453002
Cr-Commit-Position: refs/heads/master@{#19219}
rtcp_sender accepts nullptr as indication statistics shouldn't be used,
Other uses of NullReceiveStatistcs were already deleted.
BUG=webrtc:8016
Review-Url: https://codereview.webrtc.org/2988143002
Cr-Commit-Position: refs/heads/master@{#19197}
MockRtpPacketSink has three identical implementations now, so time to move it to its own file.
BUG=None
Review-Url: https://codereview.webrtc.org/2988853002
Cr-Commit-Position: refs/heads/master@{#19183}
Rtcp sender now take smaller interface making it possible to simplify the fake
BUG=webrtc:8016
Review-Url: https://codereview.webrtc.org/2984283002
Cr-Commit-Position: refs/heads/master@{#19181}
These traces will be traced instead when getStats()
is called by JavaScript.
BUG=chromium:653087
Review-Url: https://codereview.webrtc.org/2972393002
Cr-Commit-Position: refs/heads/master@{#19124}
when creating RtpRtcp module for video send stream.
BUG=webrtc:8016
Review-Url: https://codereview.webrtc.org/2979363002
Cr-Commit-Position: refs/heads/master@{#19122}
All downstream code have been updated to the new location.
In PRESUBMIT.py:
* Remove webrtc/rtc_base from CPP_BLACKLIST
* Add webrtc/rtc_base to LEGACY_API_DIRS
Fix some duplicated paths in
webrtc/modules/audio_processing/test/conversational_speech/BUILD.gn
BUG=webrtc:7634
TBR=kwiberg@webrtc.org
Review-Url: https://codereview.webrtc.org/2976293002
Cr-Commit-Position: refs/heads/master@{#19094}
