We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
Alternative solutions:
* Check if we already have defined e.g. CHECK, and don't define them in that case. This makes us depend on include order in Chromium, which is not acceptable.
* Don't allow using the macros in WebRTC headers. Error prone since if someone adds it there by mistake it may compile fine, but later break if a header in added or order is changed in Chromium. That will be confusing and hard to enforce.
* Ensure that headers that are included by an embedder don't include our macros. This would require some heavy refactoring to be maintainable and enforcable.
* Changes in Chromium for this is obviously not an option.
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1335923002
Cr-Commit-Position: refs/heads/master@{#9964}
Remove start_bitrate_bps which is no longer used and return the current
allocated bitrate instead of having it as an out parameter, removing the
previous return value which is no longer used.
Permits removing bitrate controller usage from ViEEncoder.
BUG=webrtc:1695
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1343783006 .
Cr-Commit-Position: refs/heads/master@{#9942}
The uint8_t in the log string is interpreted as a char, causing a
character to be logged if the loss is non-zero and terminates the string
with a '\0' in the zero case.
R=sprang@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/53449004
Cr-Commit-Position: refs/heads/master@{#9242}
Replaces interface usage with direct calls on ViEEncoder removing a
layer of indirection. Also removing some methods from ViEImageProcess
that were only added for Video{Send,Receive}Stream usage.
BUG=1695
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45319004
Cr-Commit-Position: refs/heads/master@{#9111}
Without this, external encoders with internal sources (i.e. don't use the normal camera path) won't trigger ViEEncoder::DeliverFrame, so time_of_last_incoming_frame_ms_ will always be 0.
BUG=
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44099004
Cr-Commit-Position: refs/heads/master@{#9010}
This CL makes ViEFrameCallback::DeliverFrame const and removes the potential frame copy in ViEFrameProviderBase by moving it to ViEEncoder::DeliverFrame instead, for clients that use the FrameCallback functionality to modify the frame content.
BUG=1128
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43949004
Cr-Commit-Position: refs/heads/master@{#8934}
This CL avoids changing the mentioned callbacks during a call, to avoid
a potential deadlock when acquiring _sendCritSect and calling
_mediaOpt.SetTargetRates.
Moving the critsect revealed a race for the FEC parameters in RtpVideoSender, so the CL grew a bit to avoid this. I also cleaned up some code here at the same time, but tried to keep it at a minimum since this CL had already increased a lot in size.
BUG=769
R=pbos@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42939004
Cr-Commit-Position: refs/heads/master@{#8899}
This means all channels within the same group will share the same pacing queue and scheduler. It also means padding will be computed and sent by a single pacer. To accomplish this I also introduce a PacketRouter which finds the RTP module which owns the packet to be paced out.
BUG=4323
R=mflodman@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45549004
Cr-Commit-Position: refs/heads/master@{#8864}
Instead of setting bitrates based on codec target settings (which may
have previously been capped by a codec max bitrate), fetch the last
bandwidth allocated for this channel. This fixes broken low start bitrates
due to QCIF being set as default codec in WebRtcVideoEngine2 which caps
the max bitrate to 200kbps.
BUG=1788
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43789004
Cr-Commit-Position: refs/heads/master@{#8780}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8780 4adac7df-926f-26a2-2b94-8c16560cd09d
Original cl description:
This removes the none const pointer entry and SwapFrame.
Since frames delivered using VideoSendStream no longer use the external capture module, VideoSendStream will not get an incoming framerate callback. VideoSendStream now uses a rtc::RateTracker.
Also, the video engine must ensure that time stamps are always increasing.
With this, time stamps (ntp, render_time and rtp timestamps ) are checked and set in ViECapturer::OnIncomingCapturedFrame
This cl was previously reverted in https://webrtc-codereview.appspot.com/46549004/.
Patchset 1 contains the original patch after rebase.
Patshet 2 fix webrtc_perf_tests reported in chromium:465306
Note that chromium:465287 is being fixed in https://webrtc-codereview.appspot.com/43829004/
BUG=1128
R=magjed@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47629004
Cr-Commit-Position: refs/heads/master@{#8776}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8776 4adac7df-926f-26a2-2b94-8c16560cd09d
This removes the none const pointer entry and SwapFrame.
Since frames delivered using VideoSendStream no longer use the external capture module, VideoSendStream will not get an incoming framerate callback. VideoSendStream now uses a rtc::RateTracker.
Also, the video engine must ensure that time stamps are always increasing.
With this, time stamps (ntp, render_time and rtp timestamps ) are checked and set in ViECapturer::OnIncomingCapturedFrame
BUG=1128
R=magjed@webrtc.org, mflodman@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46429004
Cr-Commit-Position: refs/heads/master@{#8633}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8633 4adac7df-926f-26a2-2b94-8c16560cd09d
This cl just moves the logic form the default module
SetTargetSendBitrates to PayloadRouter. There might be glitch / mismatch
in size between trate the vector and rtp modules. This was the same in
the default module and is quite hard to protect from before we have the
new video API.
I also removed some test form rtp_rtcp_impl_unittest that were affected
by this change. The test tests code that isn't implemented, hence the
DISABLED_, and this will never be implemented in the RTP module, rather
the payload router in the future.
BUG=769
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42419004
Cr-Commit-Position: refs/heads/master@{#8453}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8453 4adac7df-926f-26a2-2b94-8c16560cd09d
There is a potential race when deleting a channel and there is a frame
in the encoder. ViEEncoder::SendData can be called after
ViEEncoder::StopThreadsAndRemovePayloadRouter and payload_router is
then already removed.
Until we have the new API in place, use scoped_refptr in ViEChannel and
ViEEncoder and deregister channel/encoder before deleting.
BUG=769
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42019004
Cr-Commit-Position: refs/heads/master@{#8443}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8443 4adac7df-926f-26a2-2b94-8c16560cd09d
Fetching the current codec for sake of gathering stats, is frequently blocked since it's done by acquiring the same lock as is held while encoding frames. This can mean tens of milliseconds.
To improve this, I'm taking advantage of the fact that the codec information is set on the same thread as is used to query the information. This means that locking isn't needed for querying this information. I'm adding checks to make sure debug builds will crash if this isn't followed.
An alternative to this approach could be to add one more lock that is specifically used for the codec information variable. This would also decouple querying codec information from the encoder itself, but still requires a lock.
This patch depends on making ThreadChecker part of rtc_base_approved:
https://webrtc-codereview.appspot.com/40539004/
BUG=2822
R=mflodman@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37779004
Cr-Commit-Position: refs/heads/master@{#8435}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8435 4adac7df-926f-26a2-2b94-8c16560cd09d
