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
TextureVideoFrame is currently an empty shell that only provides a convenience constructor of I420VideoFrame with a texture buffer. This CL moves that constructor, and all unittests, of TextureVideoFrame into the base class. Then it's possible to completely remove TextureVideoFrame and all its files. Also, there is no point in having I420VideoFrame virtual anymore.
R=pbos@webrtc.org, perkj@webrtc.org, stefan@webrtc.org
TBR=mflodman
Review URL: https://webrtc-codereview.appspot.com/40229004
Cr-Commit-Position: refs/heads/master@{#8629}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8629 4adac7df-926f-26a2-2b94-8c16560cd09d
Clang version changed 223108:230914
Details: e144d30..6fdb142/tools/clang/scripts/update.sh
Removes the OVERRIDE macro defined in:
* webrtc/base/common.h
* webrtc/typedefs.h
The majority of the source changes were done by running this in src/:
perl -0pi -e "s/virtual\s([^({;]*(\([^({;]*\)[^({;]*))(OVERRIDE|override)/\1override/sg" `find {talk,webrtc} -name "*.h" -o -name "*.cc*" -o -name "*.mm*"`
which converted all:
virtual Foo() OVERRIDE
functions to:
Foo() override
Then I manually edited:
* talk/media/webrtc/fakewebrtccommon.h
* webrtc/test/fake_common.h
Remaining uses of OVERRIDE was fixed by search+replace.
Manual edits were done to fix virtual destructors that were
overriding inherited ones.
Finally a build error related to the pure virtual definitions of
Read, Write and Rewind in common_types.h required a bit of
refactoring in:
* webrtc/common_types.cc
* webrtc/common_types.h
* webrtc/system_wrappers/interface/file_wrapper.h
* webrtc/system_wrappers/source/file_impl.cc
This roll should make it possible for us to finally re-enable deadlock
detection for TSan on the buildbots.
BUG=4106
R=pbos@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41069004
Cr-Commit-Position: refs/heads/master@{#8596}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8596 4adac7df-926f-26a2-2b94-8c16560cd09d
These parameters are set by the x-google-*-bitrate SDP parameters. This
is implemented on a Call level instead of per-stream like the currently
underlying VideoEngine implementation to allow this refactoring to not
reconfigure the VideoCodec at all but rather adjust bandwidth-estimator
parameters.
Also implements SetMaxSendBandwidth in WebRtcVideoEngine2 as it's a SDP
parameter and allowing it to be dynamically readjusted in Call.
R=mflodman@webrtc.org, stefan@webrtc.org
BUG=1788
Review URL: https://webrtc-codereview.appspot.com/26199004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7746 4adac7df-926f-26a2-2b94-8c16560cd09d
r6654 changed RtpSender::Bytes() to return the number of bytes sent
instead of number of media bytes. This is used by VideoEngine for stats.
This change broke RTCP which sends this same count as the number of
payload bytes sent (excluding headers and padding).
BUG=
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/14959004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6691 4adac7df-926f-26a2-2b94-8c16560cd09d
A restarted VideoSendStream would previously be completely reset,
causing gaps in sequence numbers and potentially RTP timestamps as well.
This broke SRTP which requires fairly sequential sequence numbers.
Presumably, were this sent without SRTP, we'd still have problems on the
receiving end as the corresponding receiver is unaware of this reset.
Also adding annotation to RTPSender and addressing some unlocked
access to ssrc_, ssrc_rtx_ and rtx_.
BUG=
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/20819004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6612 4adac7df-926f-26a2-2b94-8c16560cd09d
Allows setting SSRCs for future simulcast layers even though no set send
codec uses them.
Also re-enabling CanSwitchToUseAllSsrcs as an end-to-end test, required
for bitrate ramp-up, instead of send-side only (resolving issue 3078).
This test was used to verify reserved modules' SSRCs are preserved
correctly.
To enable a multiple-stream end-to-end test test::CallTest was modified
to work on a vector of receive streams instead of just one.
BUG=3078
R=kjellander@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/15859005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6565 4adac7df-926f-26a2-2b94-8c16560cd09d
Benefits of this is that the send config previously had unclear locking
requirements, a lock was used to lock parts parts of it while
reconfiguring the VideoEncoder. Primary work was splitting out video
streams from config as well as encoder_settings as these change on
ReconfigureVideoEncoder. Now threading requirements for both member
configs are clear (as they are read-only), and encoder_settings doesn't
stay in the config as a stale pointer.
CreateVideoSendStream now takes video streams separately as well as the
encoder_settings pointer, analogous to ReconfigureVideoEncoder.
This change required changing so that pacing is silently enabled when
using suspend_below_min_bitrate rather than silently setting it.
R=henrik.lundin@webrtc.org, mflodman@webrtc.org, pthatcher@webrtc.org, stefan@webrtc.org
BUG=3260
Review URL: https://webrtc-codereview.appspot.com/20409004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6349 4adac7df-926f-26a2-2b94-8c16560cd09d
Modify bitrate controller to update bitrate based on process call and not
only whenever a RTCP receiver block is received.
Additionally:
Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
Did not touch decrease logic, however since it can be triggered more often it
may decrease much faster and closer to the original written cap of once every
300ms + rtt.
Note:
rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
BUG=3065
R=stefan@webrtc.org, mflodman@webrtc.org
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5794 4adac7df-926f-26a2-2b94-8c16560cd09d
This triggered an occasional TSAN failure in
CallTest.ReceivesPliAndRecoversWithNack e.g.:
http://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan/builds/1444/steps/memory%20test%3A%20video_engine_tests/logs/stdio
I managed to reproduce this locally and verified that reverting this CL
corrected it.
> Modify bitrate controller to update bitrate based on process call and not
> only whenever a RTCP receiver block is received.
>
> Additionally:
> Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
>
> Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
>
> Did not touch decrease logic, however since it can be triggered more often it
> may decrease much faster and closer to the original written cap of once every
> 300ms + rtt.
>
> Note:
> rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
> bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
>
> BUG=3065
> R=stefan@webrtc.org, mflodman@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/10529004TBR=andresp@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10079005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5785 4adac7df-926f-26a2-2b94-8c16560cd09d
only whenever a RTCP receiver block is received.
Additionally:
Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
Did not touch decrease logic, however since it can be triggered more often it
may decrease much faster and closer to the original written cap of once every
300ms + rtt.
Note:
rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
BUG=3065
R=stefan@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10529004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5775 4adac7df-926f-26a2-2b94-8c16560cd09d
Disabling as bots are turning red. This should be because
VideoSendStream::ReconfigureVideoCodec caps video_codec.startBitrate to
max bitrates and as the start bitrate is just enough to transmit there
might be some rounding errors here causing the top stream not to be
sent. Since no REMB is received (send-side test) this remains as the
transmit bitrate.
I need some more time to figure out if this is the case so I'm disabling
these for now to avoid reverting the big CL. VideoSendStreams aren't
used in production yet.
TBR=mflodman@webrtc.org
BUG=3078
Review URL: https://webrtc-codereview.appspot.com/10229005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5727 4adac7df-926f-26a2-2b94-8c16560cd09d
New interface uses two bitrates (max/min). The pace multiplier is also
removed from the interface and instead utilized outside. Min bitrate
will be filled with padding if there's not enough media to transmit.
Also fixes a bug in minimum transmission bitrate that made it ignore
REMBs. A regression test has been added to catch it.
BUG=3014
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10059004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5723 4adac7df-926f-26a2-2b94-8c16560cd09d
Replaces VideoCodec in VideoSendStream::Config with an EncoderSettings
struct. The EncoderSettings struct uses an external encoder for all
codecs. This means that external users, such as libjingle, will provide
the encoders themselves, removing the previous distinction of internal
and external codecs.
For now VideoSendStream translates to VideoCodec internally. In the
interrim (before the corresponding change is implemented in
VideoReceiveStream) tests convert EncoderSettings to VideoCodecs.
Removes Call::GetVideoCodecs().
Disables RampUpTest.WithPacingAndRtx as its further exposed with changes
to bitrates used in tests.
BUG=2854,2992
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/7919004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5722 4adac7df-926f-26a2-2b94-8c16560cd09d
