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
Moving functionality to get max payload length from default RTP module
to the payload router.
I'll make a follow up CL changing asserts to DCHECK in rtp_rtcp_impl.cc.
BUG=769
TEST=New unittest and existing sender mtu test
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36119004
Cr-Commit-Position: refs/heads/master@{#8345}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8345 4adac7df-926f-26a2-2b94-8c16560cd09d
ViECapturer is always calling DeliverFrame with an empty CSRC vector, so
this is basically a dead path already. I added a DCHECK in ViEEncoder to
verify this is true.
BUG=769
TEST=Manually verified in Chromium.
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39059004
Cr-Commit-Position: refs/heads/master@{#8335}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8335 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL moves the pacer out from the regular module process thread to
instead use one thread per pacer. This is to get better accuracy for the
paced packets and to avoid overusing the module process thread.
BUG=
TEST=existing tests
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41839004
Cr-Commit-Position: refs/heads/master@{#8308}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8308 4adac7df-926f-26a2-2b94-8c16560cd09d
sending RTP module for the specified simulcast layer a frame belongs to.
This CL also removes the corresponding functionality from the RTP RTCP
module and fixes lint warnings in the files touched.
BUG=769
TEST=New unittest and manual tests
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39629004
Cr-Commit-Position: refs/heads/master@{#8267}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8267 4adac7df-926f-26a2-2b94-8c16560cd09d
Packet queue in the paced sender is now based on a priority queue rather than having a separate fifo-queue per priority level. This allows more flexible sorting and cleaner usage.
Packets with earlier capture times are now prioritized higher. In situations with high packet loss, the queue might contain packets from several subsequent frames. Retransmit packets from the earlier frames first, since the later ones will probably be dependent on these.
Also, don't force sending of packets after a certain time of inactivity or when packets grow too old, since this was causing consistent overuse on poor connections. Instead, drop frames in vie encoder if pacer queue is too long.
BUG=
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/27869004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7617 4adac7df-926f-26a2-2b94-8c16560cd09d
