These checks would help catching double-deletes, forgetting to destroy
streams and also catch if VideoEngine has held on to any stale
references.
BUG=1788
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42929004
Cr-Commit-Position: refs/heads/master@{#8866}
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}
If built-in Echo Cancellation is available on a device it is automatically enabled. The reason is that it in most cases performs better than the WebRTC software echo control for mobile. The drawback is that we can not develop, test and rollout the delay agnostic AEC (DA-AEC) on Android as for desktops.
This CL includes
- adding a media constraint to enable/disable DA-AEC.
- automatically turning on echo cancellation if DA-AEC is enabled.
- a fix in the AEC that enables delay estimation when DA-AEC is enabled, but delay metrics is disabled.
- sets the Config struct ReportedDelay, which controls DA-AEC internally in the AEC.
The test code to verify that it works in AppRTCDemo can be found here:
https://webrtc-codereview.appspot.com/50479004/
BUG=4472
TESTED=locally on N7, N6, Android One
R=glaznev@webrtc.org, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48699004
Cr-Commit-Position: refs/heads/master@{#8861}
AppRTCDemo is failing to cleanly exit a room because it sends a GET request to /bye. The request to /bye should be a POST request. Because the /bye request is failing, the room is still marked as "full" and rejoining will fail.
BUG=
R=tkchin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47759004
Patch from Chuck Hays <haysc@webrtc.org>.
Cr-Commit-Position: refs/heads/master@{#8860}
The macro is defined as
#define WEBRTC_SPL_MUL_16_16_RSFT(a, b, c) \
(WEBRTC_SPL_MUL_16_16(a, b) >> (c))
where the latter macro is in C defined as
#define WEBRTC_SPL_MUL_16_16(a, b) \
((int32_t) (((int16_t)(a)) * ((int16_t)(b))))
(For definitions on ARMv7 and MIPS, see common_audio/signal_processing/include/spl_inl_{armv7,mips}.h)
The replacement consists of
- avoiding casts to int16_t if inputs already are int16_t
- adding explicit cast to <type> if result is assigned to <type> (other than int or int32_t)
- minor cleanups like remove of unnecessary parentheses and style changes
BUG=3347, 3348, 3353
TESTED=locally on Linux for both fixed and floating point and trybots
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44799004
Cr-Commit-Position: refs/heads/master@{#8857}
The macro is defined as
#define WEBRTC_SPL_MUL_16_16_RSFT(a, b, c) \
(WEBRTC_SPL_MUL_16_16(a, b) >> (c))
where the latter macro is in C defined as
#define WEBRTC_SPL_MUL_16_16(a, b) \
((int32_t) (((int16_t)(a)) * ((int16_t)(b))))
(For definitions on ARMv7 and MIPS, see common_audio/signal_processing/include/spl_inl_{armv7,mips}.h)
The replacement consists of
- avoiding casts to int16_t if inputs already are int16_t
- adding explicit cast to <type> if result is assigned to <type> (other than int or int32_t)
- minor cleanups like remove of unnecessary parentheses and style changes
BUG=3348, 3353
TESTED=locally on Linux for both fixed and floating point and trybots
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/49499004
Cr-Commit-Position: refs/heads/master@{#8853}
This CL deletes VideoAdapter::AdaptFrame and replaces the remaining calls with AdaptFrameResolution instead.
I do not expect this CL to fix the flaky VideoAdapterTests yet. I intend to replace FileVideoCapturer with a deterministic FakeVideoCapturer in a follow-up CL.
BUG=4317
R=pbos@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44769004
Cr-Commit-Position: refs/heads/master@{#8848}
The key in codereview.settings only made sense for committing to SVN.
The drover.properties is of no use, since drover doesn't support Git.
BUG=chromium:412012
Review URL: https://webrtc-codereview.appspot.com/46669004
Cr-Commit-Position: refs/heads/master@{#8847}
And add a constructor for creating an uninitialized Buffer of a
specified size.
(I intend to follow up with more Buffer changes, but since it's rather
widely used, the rename is quite noisy and works better as a separate
CL.)
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48579004
Cr-Commit-Position: refs/heads/master@{#8841}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8841 4adac7df-926f-26a2-2b94-8c16560cd09d
I'm splitting the timer functions in EventWrapper into a separate interface.
- Users of the timer functions have different needs than users of a generic event
- Providing a default implementation for EventWrapper that simply uses rtc::Event.
This means that clients of WebRTC that don't use the relatively few classes, typically rendering classes, that depend on the event timer functionality, also don't pull in dependencies on multimedia timers.
R=mflodman@webrtc.org, mflodman
BUG=
Review URL: https://webrtc-codereview.appspot.com/48599004
Cr-Commit-Position: refs/heads/master@{#8833}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8833 4adac7df-926f-26a2-2b94-8c16560cd09d
In SDP, RED audio codec has its own sample rate. Currently, we offer RED/8000 (8 kHz). But the actual send codec can violate this sample rate. The way to solve it is to introduce more RED payload types, e.g., RED/16000, RED/32000.
As a first step towards that, we, in this CL, limit the current RED (RED/8000) to work only with 8 kHz codecs.
BUG=3619
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43849004
Cr-Commit-Position: refs/heads/master@{#8830}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8830 4adac7df-926f-26a2-2b94-8c16560cd09d
A codec's packet-loss concealer is called once from NetEq before
decoding the first packet after a packet loss. The purpose is not to
use the PLC output, but to prepare the state of the decoder such that
it may recover faster after the loss. However, this effect is not
achieved by calling iSAC's PLC. Also, there are some problems with the
fixed-point implementation of the PLC (see the associated bug).
BUG=4423
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42849004
Cr-Commit-Position: refs/heads/master@{#8827}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8827 4adac7df-926f-26a2-2b94-8c16560cd09d
I've kicked of a roll into Chromium with out the WebRtcVideoEngine2 change, to see if it was causing the roll problems, but re-landing in the meantime.
> Revert 8809 "Set WebRtcVideoEngine2 as the WebRtcMediaEngine."
> content_browsertests started failing around the time the change landed and rolls are failing now.
> I'm going to try rolling this back, start a roll, and then re-land.
>
> > Set WebRtcVideoEngine2 as the WebRtcMediaEngine.
> >
> > Removes the experiment launching WebRTC-NewVideoAPI. This field trial
> > has shown no major regressions on Chrome Canary/Dev that haven't been
> > addressed, so enabling it in time before feature freeze.
> >
> > BUG=1788
> > R=mflodman@webrtc.org
> >
> > Review URL: https://webrtc-codereview.appspot.com/44759004
>
> TBR=pbos@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/43889004TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50459004
Cr-Commit-Position: refs/heads/master@{#8817}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8817 4adac7df-926f-26a2-2b94-8c16560cd09d
