This CL is a baby step towards consolidating the timestamps in cricket::VideoFrame and webrtc::VideoFrame, so that we can unify the frame classes in the future.
The elapsed time functionality is not really used. If a video sink wants to know the elapsed time since the first frame they can store the first timestamp themselves and calculate the time delta to later frames. This is already done in all video sinks that need the elapsed time. Having redundant timestamps in the frame classes is confusing and error prone.
TBR=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1324263004
Cr-Commit-Position: refs/heads/master@{#10131}
To make this possible padding only packets will have the same timestamp
as the previously sent media packet, as long as RTX is not enabled. This
has the side effect that if we send only padding for a long time without
sending media, a receive-side jitter buffer could potentially overflow.
In practice this shouldn't be an issue, partly because RTX is recommended and
used by default, but also because padding typically is terminated before being
received by a client. It is also not an issue for bandwidth estimation as long
as abs-send-time is used instead of toffset.
BUG=chromium:425925
R=mflodman@webrtc.org, sprang@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1327933003 .
Cr-Commit-Position: refs/heads/master@{#9984}
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}
Part of work removing dependency on Chromium's base.
Only adds "= delete". From https://codereview.chromium.org/1151443003 :
"This will guarantee the error to be at compile time, and not rely on the call visibility (private)."
In consequence of that change, fixed an illegal copy and removed a bunch of unused variables.
Depends on https://codereview.webrtc.org/1345433002/
BUG=chromium:468375
(in particular comment #37)
NOTRY=true
Review URL: https://codereview.webrtc.org/1342543004
Cr-Commit-Position: refs/heads/master@{#9954}
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.
* DISALLOW_ASSIGN -> RTC_DISALLOW_ASSIGN
* DISALLOW_COPY_AND_ASSIGN -> RTC_DISALLOW_COPY_AND_ASSIGN
* DISALLOW_IMPLICIT_CONSTRUCTORS -> RTC_DISALLOW_IMPLICIT_CONSTRUCTORS
Related CL: https://codereview.webrtc.org/1335923002/
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1345433002
Cr-Commit-Position: refs/heads/master@{#9953}
I'm not super happy with the GetVoE() function added on MediaEngineInterface, but this will eventually be gone, once webrtc::Call owns the shared VoE state (or initially, maps ADM* to an implicitly created VoE).
BUG=webrtc:4690
R=pbos@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1269863005 .
Cr-Commit-Position: refs/heads/master@{#9939}
Incoming frames usually have an epoch of time since the capturer was
created or similar, not any fixed-time epoch. As such, setting a new
capturer resulted in delivering frames with older timestamps which
caused these frames to be dropped before encoding.
BUG=webrtc:4994
R=stefan@webrtc.orgTBR=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1345473002
Cr-Commit-Position: refs/heads/master@{#9934}
This functionality is not used internally in WebRTC. Also, it's not safe, because the frame is supposed to be read-only, and it will likely not work for texture frames.
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1296113002 .
Cr-Commit-Position: refs/heads/master@{#9753}
Essentially we are carrying over the capture timestamp to the encoded frame sent out, so the frame lengths will contain no noise.
Review URL: https://codereview.webrtc.org/1225153002
Cr-Commit-Position: refs/heads/master@{#9597}
(This reverts commit 3fbf3f8841b5460503fb646eaedcb063620434a8.)
The original submission was reverted because it broke the Chrome build. This is fixed in patch set 2 of this change by keeping the old MediaConstraintsInterface string kExperimentalEchoCancellation. It will be removed once the Chrome code has been updated.
Original description:
"We use this Config struct for enabling/disabling Extended filter mode in AEC. This change renames it to ExtendedFilter for readability reasons. The corresponding media constraint is also renamed to kExtendedFilterEchoCancellation.
The old Config is kept in parallel with the new during a transition period. This is to avoid problems with API breakages. During this period, if any of the two Configs are enabled, the extended filter mode is engaged in APM. That is, the two Configs are combined with an "OR" operation.
This change also renames experimental_aec in AudioOptions to extended_filter_aec."
BUG=webrtc:4696
R=bjornv@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1151573021.
Cr-Commit-Position: refs/heads/master@{#9401}
We use this Config struct for enabling/disabling Extended filter mode
in AEC. This change renames it to ExtendedFilter for readability
reasons. The corresponding media constraint is also renamed to
kExtendedFilterEchoCancellation.
The old Config is kept in parallel with the new during a transition
period. This is to avoid problems with API breakages. During this
period, if any of the two Configs are enabled, the extended filter
mode is engaged in APM. That is, the two Configs are combined with an
"OR" operation.
This change also renames experimental_aec in AudioOptions to extended_filter_aec.
BUG=4696
R=bjornv@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/54659004
Cr-Commit-Position: refs/heads/master@{#9378}
This change connects currentAccelerateRate and currentPreemptiveRate
in webrtc::NetworkStatistics, through corresponding variables in
VoiceReceiverInfo, to googAccelerateRate and googPreemptiveExpandRate.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50179004
Cr-Commit-Position: refs/heads/master@{#9350}
This CL connects RTCConfiguration::audioJitterBufferFastMode in
PeerConnection.java, through libjingle, down to
NetEq::Config::enable_fast_accelerate in native WebRTC.
When enabled, it will allow NetEq to do faster time-compression when
the buffer level is very high.
BUG=4691
R=henrika@webrtc.org, mflodman@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/55479004
Cr-Commit-Position: refs/heads/master@{#9344}
BUG=4690
Changes:
1. In MediaEngineInterface changed CreateChannel() to CreateChannel(const AudioOptions&). Plan is to eventually remove Get/SetAudioOptions and the cousins SetDelayOffset and SetDevices.
2. In ChannelManager changed CreateVoiceChannel(...) to CreateVoiceChannel(..., const AudioOptions&).
3. In ChannelManager removed SetEngineAudioOptions, because it is not used and we want to eventually remove SetAudioOptions.
4. Updated MediaEngineInterface implementations and unit tests accordingly.
5. In WebRtcVoiceEngine changed access of Set/ClearOptionOverrides to protected. These are only used by WebRtcVoiceMediaChannel (now a friend). Plan is to rethink the logic behind option overrides.
6. Cosmetics: replaced NULL with nullptr in touched code
R=solenberg@google.com, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/56499004
Cr-Commit-Position: refs/heads/master@{#9330}
This fixes a bug where, if the VideoCapturer failed to start under certain circumstances, the capture manager would cause a callback saying that the capturer stopped even though it never started in the first place. A VERIFY check in VideoSource::SetState would then cause a crash since the state was set to kEnded when it was already in state kEnded (SetState only allows being called when the state changes).
I only noticed this bug while doing a mistake in a separate CL. Not sure how to reliably reproduce said bug on a working build, but I have previously had camera hardware issues where it couldn't start the camera which resulted in the SetState kEnded -> kEnded crash. Hopefully this will fix that.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51039004
Cr-Commit-Position: refs/heads/master@{#9259}
When a frame being stretched, the original rotation information is lost. This is to ensure it's carried over.
Also removed StretchToBuffer function as it's not called and dangerous.
BUG=4366
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51869004
Cr-Commit-Position: refs/heads/master@{#9224}
