including options related to experimental constraints which are
recognized but never applied.
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1642513002
Cr-Commit-Position: refs/heads/master@{#11424}
It's never used anywhere, so it only causes confusion between
itself and SessionDescriptionInterface::candidates.
Review URL: https://codereview.webrtc.org/1642733002
Cr-Commit-Position: refs/heads/master@{#11420}
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}
The plan is that this interface should be used by all classes which receive a stream of video frames, and replace the two generic classes webrtc::VideoRendererInterface and cricket::VideoRenderer.
And the list goes on, there's a dozen of different classes which act as video frame sinks.
At some point, we will likely add some method to handle sink properties like, e.g, maximum useful width and height. But hopefully this can be done while keeping the interface very simple.
BUG=webrtc:5426
R=perkj@webrtc.org, pthatcher@webrtc.org
Committed: https://crrev.com/a862d4563fbc26e52bed442de784094ae1dfe5ee
Cr-Commit-Position: refs/heads/master@{#11396}
Review URL: https://codereview.webrtc.org/1594973006
Cr-Commit-Position: refs/heads/master@{#11414}
This is somewhat easier than looking up the media type by iterating pc.getLocalStreams / pc.getRemoteStreams and all tracks. Temporary until stats get revamped to conform to the spec obviously.
BUG=webrtc:4117
Review URL: https://codereview.webrtc.org/1307633007
Cr-Commit-Position: refs/heads/master@{#11412}
The level of the error signal after linear echo cancellation was based on non-buffered signal while that of the near-end and far-end signal based on buffered signal. This discrepancy made the comparison of them unfair.
This CL is to make calculating the error level rely on the same buffering.
BUG=
Review URL: https://codereview.webrtc.org/1510873004
Cr-Commit-Position: refs/heads/master@{#11408}
Expose disableBuffering method on underlying log sink.
This will make every write to the stream immediately write to the disk.
Useful in crash situations so that buffered output is not lost.
BUG=
Review URL: https://codereview.webrtc.org/1638283003
Cr-Commit-Position: refs/heads/master@{#11407}
Before HW VP8 downscaling was triggered by frame drops only.
Also reset the encoder when it drops large amount of frames in a row.
BUG=b/26504665
Review URL: https://codereview.webrtc.org/1592883004
Cr-Commit-Position: refs/heads/master@{#11406}
Before this fix, it was required that the EGL context used as an argument was kept open until all PeerConnections using the context had been closed. With this fix, that is no longer required.
Also, if a released EGLContext (EGL_NO_CONTEXT) is used, harware codecs will fallback to use byte buffers for encoding and decoding.
BUG=b/26583522
R=glaznev@webrtc.org
Review URL: https://codereview.webrtc.org/1615153002 .
Cr-Commit-Position: refs/heads/master@{#11398}
Reason for revert:
Broke chrome build. Investigating.
First error relating to AddSink method in mock_peer_connection_dependency_factory.h
Original issue's description:
> New rtc::VideoSinkInterface.
>
> The plan is that this interface should be used by all classes which receive a stream of video frames, and replace the two generic classes webrtc::VideoRendererInterface and cricket::VideoRenderer.
>
> And the list goes on, there's a dozen of different classes which act as video frame sinks.
>
> At some point, we will likely add some method to handle sink properties like, e.g, maximum useful width and height. But hopefully this can be done while keeping the interface very simple.
>
> BUG=webrtc:5426
> R=perkj@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/a862d4563fbc26e52bed442de784094ae1dfe5ee
> Cr-Commit-Position: refs/heads/master@{#11396}
TBR=pthatcher@webrtc.org,pbos@webrtc.org,perkj@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1646463002
Cr-Commit-Position: refs/heads/master@{#11397}
The plan is that this interface should be used by all classes which receive a stream of video frames, and replace the two generic classes webrtc::VideoRendererInterface and cricket::VideoRenderer.
And the list goes on, there's a dozen of different classes which act as video frame sinks.
At some point, we will likely add some method to handle sink properties like, e.g, maximum useful width and height. But hopefully this can be done while keeping the interface very simple.
BUG=webrtc:5426
R=perkj@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1594973006 .
Cr-Commit-Position: refs/heads/master@{#11396}
SetRtpState function was updating only rtp_sender start timestamp.
Now it updates both rtp_sender and rtcp_sender start timestamps.
BUG=webrtc:5433
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1628323003 .
Cr-Commit-Position: refs/heads/master@{#11393}
socket_ in OpenSSLAdapter should be (and is in tests) an AsyncSocket but
doesn't have to be an AsyncSocketAdapter. In tests this is
rtc::VirtualSocket which is an rtc::AsyncSocket. This also matches the
BIO_new_socket type signature.
This fixes the remaining UBSan vptr bot errors.
BUG=webrtc:5124, webrtc:5226
R=tommi@webrtc.org, torbjorng@webrtc.org
Review URL: https://codereview.webrtc.org/1639883002 .
Cr-Commit-Position: refs/heads/master@{#11391}
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}
BasicNetworkManager attemps to connect an UDP socket and logs an error
when connect() fails, e.g. when internet is not connected. These
errors are not very useful in the logs, but apper there every time
it attemps to refresh network list. Replaced the log statement with
LOG(LS_INFO).
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1635823004 .
Cr-Commit-Position: refs/heads/master@{#11389}
This CL fixes compiler / linker errors that occur if HAVE_WEBRTC_VIDEO is
not defined and introduces a new class NullWebRtcVideoEngine to use in
that case.
BUG=
TEST=remove define HAVE_WEBRTC_VIDEO from talk/build/common.gypi, run gclient runhooks and compile
Review URL: https://codereview.webrtc.org/1621453005
Cr-Commit-Position: refs/heads/master@{#11387}
This will make it easier for future CLs to make them optional.
BUG=webrtc:5028
Review URL: https://codereview.webrtc.org/1625363002
Cr-Commit-Position: refs/heads/master@{#11381}
This structure is used outside Dlrr creating/parsing.
but RTCPReceiveTimeInfo structure doesn't follow naming style.
rtcp::ReceiveTimeInfo added to replace both Dlrr::SubBlock (when creating/parsing packets)
and RTCPReceiveTimeInfo (for other uses).
this CL is a split of https://codereview.webrtc.org/1557593002/
BUG=webrtc:5260
R=asapersson@webrtc.org, åsapersson
Review URL: https://codereview.webrtc.org/1631683002 .
Cr-Commit-Position: refs/heads/master@{#11380}
This should have been done in commit 11340, but it was left out by
mistake.
BUG=webrtc:5028
Review URL: https://codereview.webrtc.org/1631443002
Cr-Commit-Position: refs/heads/master@{#11378}
Issue may occur for very small input images (e.g. 4x4) when encoded image length > input image size.
BUG=chromium:571594
Review URL: https://codereview.webrtc.org/1626373002
Cr-Commit-Position: refs/heads/master@{#11376}
Real time clock may cause problems as they can move (even backwards) if
the clock is changed, eg updated by NTP.
Non-monotonic clocks still in use on some platform (I'm looking at you,
Apple) for timed waits, but that should be less of an issue than actual
timestamps.
BUG=webrtc:5452
Review URL: https://codereview.webrtc.org/1613013002
Cr-Commit-Position: refs/heads/master@{#11375}
