Moves RtpRtcp module pointers into VideoSendStream and uses them for
simple calls that were only forwarded by ViEChannel.
BUG=webrtc:5494
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1693553002 .
Cr-Commit-Position: refs/heads/master@{#11709}
Since SSRCs can no longer change on the fly, SSRC code can be made a lot
simpler (and faster). Resulting code has less and shorter locking.
BUG=webrtc:5494
R=danilchap@webrtc.org
Review URL: https://codereview.webrtc.org/1713683003 .
Cr-Commit-Position: refs/heads/master@{#11691}
Also move some stats reporting from vie_channel to send stats proxy
BUG=
Review URL: https://codereview.webrtc.org/1669623004
Cr-Commit-Position: refs/heads/master@{#11688}
EncoderStateFeedback is now only connected to one encoder, so remove map
and other complexity to deliver feedback more directly.
BUG=webrtc:5494
R=danilchap@webrtc.org
Review URL: https://codereview.webrtc.org/1706803002 .
Cr-Commit-Position: refs/heads/master@{#11687}
Prevents allocating sequence numbers for packets that go out on the
network even though sending media is disabled.
This race caused a replay of sequence numbers when GetRtpState() on a
stopped stream would not return the last sequence number sent, since the
pacer thread could request and send padding on a later sequence number
before the modules are disconnected from the pacer.
BUG=webrtc:5543
R=stefan@webrtc.org
TEST=Repeating EndToEndTest.RestartingSendStreamPreservesRtpState 1000 times under TSan.
Review URL: https://codereview.webrtc.org/1715703002 .
Cr-Commit-Position: refs/heads/master@{#11685}
Makes DecodesRetransmittedFrame not flake/fail due to sent padding when
probing, which is correct behavior. Also removes hack that accepted this
only during the first n packets.
BUG=
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1698343003 .
Cr-Commit-Position: refs/heads/master@{#11648}
This started flaking due to allowing probes to restart if they were aborted due to insufficient packets. This is reasonable behavior.
TBR=pbos@webrtc.org
Review URL: https://codereview.webrtc.org/1701033002 .
Cr-Commit-Position: refs/heads/master@{#11638}
Reason for revert:
Disabling tests on memcheck that time out due to using real VP8 encoders.
Original issue's description:
> Revert of Don't send FEC for H.264 with NACK enabled. (patchset #5 id:80001 of https://codereview.webrtc.org/1687303002/ )
>
> Reason for revert:
> Broke the VerifyHistogramStatsWithRed test on the Windows DrMemory Full bot and Linux Memcheck bot. Please fix the test and reland.
>
> Original issue's description:
> > Don't send FEC for H.264 with NACK enabled.
> >
> > The H.264 does not contain picture IDs and are not sufficient to
> > determine that a packet may be skipped. This causes retransmission
> > requests for FEC that are currently dropped by the sender (since they
> > should be redundant).
> >
> > The receiver is then unable to continue without having the packet gap
> > filled (unlike VP8/VP9 which moves on since it has a consecutive stream
> > of picture IDs).
> >
> > Even if FEC retransmission did work it's a huge waste of bandwidth,
> > since it just adds additional overhead that has to be unconditionally
> > transmitted. This bandwidth is better used to send higher-quality
> > frames.
> >
> > BUG=webrtc:5264
> > R=stefan@webrtc.org
> >
> > Committed: https://crrev.com/25558ad819b4df41ba51537e26a77480ace1e525
> > Cr-Commit-Position: refs/heads/master@{#11601}
>
> TBR=stefan@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:5264
>
> Committed: https://crrev.com/29ffdc1a15e31bd81e806ff135c2100d811714f0
> Cr-Commit-Position: refs/heads/master@{#11607}
TBR=stefan@webrtc.org,deadbeef@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5264
Review URL: https://codereview.webrtc.org/1697093002 .
Cr-Commit-Position: refs/heads/master@{#11621}
Reason for revert:
Broke the VerifyHistogramStatsWithRed test on the Windows DrMemory Full bot and Linux Memcheck bot. Please fix the test and reland.
Original issue's description:
> Don't send FEC for H.264 with NACK enabled.
>
> The H.264 does not contain picture IDs and are not sufficient to
> determine that a packet may be skipped. This causes retransmission
> requests for FEC that are currently dropped by the sender (since they
> should be redundant).
>
> The receiver is then unable to continue without having the packet gap
> filled (unlike VP8/VP9 which moves on since it has a consecutive stream
> of picture IDs).
>
> Even if FEC retransmission did work it's a huge waste of bandwidth,
> since it just adds additional overhead that has to be unconditionally
> transmitted. This bandwidth is better used to send higher-quality
> frames.
>
> BUG=webrtc:5264
> R=stefan@webrtc.org
>
> Committed: https://crrev.com/25558ad819b4df41ba51537e26a77480ace1e525
> Cr-Commit-Position: refs/heads/master@{#11601}
TBR=stefan@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:5264
Review URL: https://codereview.webrtc.org/1692783005
Cr-Commit-Position: refs/heads/master@{#11607}
Removes protection-callback removal and makes ViEChannel outlive
ViEEncoder to not have races between BitrateAllocator and
VideoSendStream destruction.
BUG=
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1696693002 .
Cr-Commit-Position: refs/heads/master@{#11604}
The H.264 does not contain picture IDs and are not sufficient to
determine that a packet may be skipped. This causes retransmission
requests for FEC that are currently dropped by the sender (since they
should be redundant).
The receiver is then unable to continue without having the packet gap
filled (unlike VP8/VP9 which moves on since it has a consecutive stream
of picture IDs).
Even if FEC retransmission did work it's a huge waste of bandwidth,
since it just adds additional overhead that has to be unconditionally
transmitted. This bandwidth is better used to send higher-quality
frames.
BUG=webrtc:5264
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1687303002 .
Cr-Commit-Position: refs/heads/master@{#11601}
Prevents copying a vector to a list that gets copied back to a vector,
which makes calling code a bit easier.
BUG=webrtc:5494
R=danilchap@webrtc.org
Review URL: https://codereview.webrtc.org/1686323003 .
Cr-Commit-Position: refs/heads/master@{#11589}
Remove hops into ViEChannel for calls directly into RtpRtcp and
ViEReceiver from VideoReceiveStream.
Some calls are more complex and will be removed later.
BUG=webrtc:5494
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1671893002 .
Cr-Commit-Position: refs/heads/master@{#11526}
Removes scoped_ptrs and resets, preventing some heap allocation but also
overall showing that these objects won't be reconstructed on the fly.
BUG=webrtc:5494
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1670123002 .
Cr-Commit-Position: refs/heads/master@{#11503}
Extracts shared members outside the two objects, removing PayloadRouter
from receivers and the VCM for ViEChannel from senders.
Removes Start/StopThreadsAndSetSharedMembers that was used to set the
shared state between them.
Also adding DCHECKs to document what's only used by the
sender/receiver side.
BUG=webrtc:5494
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1654913002 .
Cr-Commit-Position: refs/heads/master@{#11500}
Permits measuring encoding time even when performed on another thread,
typically for hardware encoding, instead of assuming that encoding is
blocking the calling thread.
Permitted encoding time is increased for hardware encoders since they
can be timed to keep 30fps, for instance, without indicating overload.
Merges EncodingTimeObserver into EncodedFrameObserver to have one post-encode
callback.
BUG=webrtc:5042, webrtc:5132
R=asapersson@webrtc.org, mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1569853002 .
Cr-Commit-Position: refs/heads/master@{#11499}
This adds negotiation of both transport sequence number and transport
feedback. Only offers transport seq num if the
WebRTC-Audio-SendSideBwe finch experiment is enabled.
TBR=mflodman@webrtc.org
BUG=webrtc:5263
Review URL: https://codereview.webrtc.org/1604563002
Cr-Commit-Position: refs/heads/master@{#11487}
Sparse macro is replaced and new implementation in metrics.h is used.
BUG=webrtc:5283
Review URL: https://codereview.webrtc.org/1564923008
Cr-Commit-Position: refs/heads/master@{#11483}
There is a use case with external codec factories that only support
encoding but not decoding for a given type. This leads to a crash
due to null being registered as codec (after a DCHECK).
This CL adds a NullVideoDecoder that is used instead of the null to
not crash but log to LS_ERROR.
BUG=webrtc:5249
Review URL: https://codereview.webrtc.org/1657023002
Cr-Commit-Position: refs/heads/master@{#11475}
Adds negotiation of rtx codecs for red and vp9. To keep backwards
compatibility with older Chrome versions, this change includes two
hacks:
1. Red packets will be retransmitted over the rtx codec associated with
vp8 if no rtx codec is associated with red. This is how Chrome does
it today and ensures that we still can send red over rtx to older
versions.
2. If rtx packets associated with the media codec (vp8/vp9 etc) are
received and red has been negotiated, we will assume that the sender
incorrectly has packetized red inside the rtx header associated with
media. We will therefore restore it with the red payload type
instead, which ensures that we can still receive rtx associated with
red from old versions.
Offering multiple rtx codecs to older versions should not be a problem
since old versions themselves only try to negotiate rtx for vp8.
R=pbos@webrtc.orgTBR=mflodman@webrtc.org
BUG=webrtc:4024
TEST=Verified by running apprtc and emulating packet loss between Chrome with and without the patch.
Review URL: https://codereview.webrtc.org/1649493004 .
Cr-Commit-Position: refs/heads/master@{#11472}
A couple of mutables were added after last removal of mutables, so
removing those. rtc::CriticalSection is const-lockable.
BUG=
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1652983002
Cr-Commit-Position: refs/heads/master@{#11447}
Reason for revert:
May be the reason for mac_asan timeout
Original issue's description:
> Changed test to validate rtp timstamps not just in RTP packets but also in RTCP Sender Reports.
> Altered it to accept negative value since it is normal for RTCP packet coming before RTP packet to have slightly later time.
>
> BUG=webrtc:5433
>
> Committed: https://crrev.com/f4b9c775122b463db7eb2c4101603759a0d00caf
> Cr-Commit-Position: refs/heads/master@{#11417}
TBR=pbos@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5433
Review URL: https://codereview.webrtc.org/1652973002
Cr-Commit-Position: refs/heads/master@{#11446}
This makes it possible to handle send and receive streams with the same SSRC, which is currently the case in some peer connection tests.
Also moves sending transport feedback to the pacer thread.
BUG=webrtc:5263
Review URL: https://codereview.webrtc.org/1628683002
Cr-Commit-Position: refs/heads/master@{#11443}
We have seen an instance of flakiness of the perf tests where it looked
like timestamp wraparound could be an issue. Better safe...
BUG=
Review URL: https://codereview.webrtc.org/1645463002
Cr-Commit-Position: refs/heads/master@{#11440}
This argument is never used as a reference and the pointer that's bound
to the const reference may be nullptr. This is undefined behavior and
barks under UBSan.
BUG=webrtc:5124
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1642863003 .
Cr-Commit-Position: refs/heads/master@{#11418}
Altered it to accept negative value since it is normal for RTCP packet coming before RTP packet to have slightly later time.
BUG=webrtc:5433
Review URL: https://codereview.webrtc.org/1633843003
Cr-Commit-Position: refs/heads/master@{#11417}
It works on all platforms except Android and iOS (FFmpeg limitation).
Implemented behind compile time flags, off by default.
The plan is to have it enabled in Chrome (see bug), but not in Chromium/webrtc by default.
Flags to turn it on:
- rtc_use_h264 = true
- ffmpeg_branding = "Chrome" (or other brand that includes H.264 decoder)
Tests using H264:
- video_loopback --codec=H264
- screenshare_loopback --codec=H264
- video_engine_tests (EndToEndTest.SendsAndReceivesH264)
NOTRY=True
BUG=500605, 468365
BUG=https://bugs.chromium.org/p/webrtc/issues/detail?id=5424
Review URL: https://codereview.webrtc.org/1306813009
Cr-Commit-Position: refs/heads/master@{#11390}
Sparse macro replaced for all video histograms that have a constant name.
BUG=webrtc:5283
Review URL: https://codereview.webrtc.org/1616153005
Cr-Commit-Position: refs/heads/master@{#11368}
While doing this, I made a couple of minor changes:
* Removed unused variables (one lock and one video frame variable)
* Switched over to a scoped lock in remb.cc and removed an if() in a function where we can just return the expression being checked.
BUG=
R=mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1613053003 .
Cr-Commit-Position: refs/heads/master@{#11349}
Adds logging to RTPSender and RTCPSender, pushing an event log pointer from Channel through ModuleRtpRtcpImpl to the Sender objects.
BUG=webrtc:4741
Review URL: https://codereview.webrtc.org/1571283002
Cr-Commit-Position: refs/heads/master@{#11336}
Issue may occur for very small input images (e.g. 4x4) when encoded image length > input image size.
BUG=chromium:578193
Review URL: https://codereview.webrtc.org/1603643006
Cr-Commit-Position: refs/heads/master@{#11329}
