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 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}
Removes use of global VP8EncoderFactory::use_simulcast_adapter which is
thread-unsafe. Also the code wasn't in use.
BUG=
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1598803005 .
Cr-Commit-Position: refs/heads/master@{#11370}
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}
The specializations for 4-byte reading did not return correct
values. This has to do with the order of casting and shifting. Also
adding a test to expose the bug (and verify the other byte sizes).
Review URL: https://codereview.webrtc.org/1615653011
Cr-Commit-Position: refs/heads/master@{#11364}
Once we have eliminated all non-monotonic clocks, revert this change.
BUG=webrtc:5452
Review URL: https://codereview.webrtc.org/1618333002
Cr-Commit-Position: refs/heads/master@{#11361}
In AEC, audio levels are calculated in frequency domain. This makes the calculation dependent on FFT. We now make the calculation performed in time domain. The complexity is the same, but the dependence on FFT is removed.
BUG=
Review URL: https://codereview.webrtc.org/1542573002
Cr-Commit-Position: refs/heads/master@{#11357}
While transitioning over to rtc::CriticalSection completely, this gives perf benefits that rtc::CriticalSection has on Mac to current users of CriticalSectionWrapper.
BUG=
Review URL: https://codereview.webrtc.org/1614373002
Cr-Commit-Position: refs/heads/master@{#11356}
Use PlatformThreadRef, CurrentThreadRef and IsThreadRefEqual instead of pthread_t, pthread_self and operator== (or !=).
BUG=
Review URL: https://codereview.webrtc.org/1619153003
Cr-Commit-Position: refs/heads/master@{#11355}
According to my measurements, it's about 100x faster than the native mutex implementation in OSX. Google "OSX mutex performance" for more info.
BUG=
Review URL: https://codereview.webrtc.org/1594723003
Cr-Commit-Position: refs/heads/master@{#11352}
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}
Also remove mischievous tab character!
This is a part of getting rid of CriticalSectionWrapper and makes the code slightly simpler.
BUG=
Review URL: https://codereview.webrtc.org/1607353002
Cr-Commit-Position: refs/heads/master@{#11346}
When the file was rewound, the remaining audio read was inserted at
the start of the destination array, not where the first reading
attempt ended.
R=ivoc@webrtc.org
Review URL: https://codereview.webrtc.org/1612053002
Cr-Commit-Position: refs/heads/master@{#11343}
Callers can just remember the return value of
RentACodec::RentEncoderStack instead.
BUG=webrtc:5028
Review URL: https://codereview.webrtc.org/1612713002
Cr-Commit-Position: refs/heads/master@{#11340}
The FFmpeg video decoder requires up to 8 additional bytes to be allocated for its encoded image buffer input, due to optimized byte readers over-reading on some platforms.
We plan to use FFmpeg for a soon-to-land H.264 enc/dec.
This CL adds support for padding encoded image buffers based on codec type, and makes sure calls to VCMEncodedFrame::VerifyAndAllocate use the padding.
All padding constants are 0 but making H.264 pad with 8 bytes will be a one-line change.
Also, added -framework CoreFoundation to webrtc_h264_video_toolbox which was missing.
BUG=chromium:468365
BUG=https://bugs.chromium.org/p/webrtc/issues/detail?id=5424
NOTRY=True
Review URL: https://codereview.webrtc.org/1602523004
Cr-Commit-Position: refs/heads/master@{#11337}
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}
