- Remove the minre and maxre parameters in favour of setting video
constraints directly.
- In order to support non-boolean values, have constraints passed as
key/value pairs, rather than the leading "-" syntax used earlier to
specify false.
TESTED=Verified that setting various audio and video constraints has
the desired effect, including "true" and "false". Verified that the "hd"
parameter still works.
R=fischman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2360005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4931 4adac7df-926f-26a2-2b94-8c16560cd09d
- Remove unneeded #defines and switch the remainder to consts.
- All AudioProcessing components are disabled by default, so remove
explicit disables.
- AudioProcessing uses a rational 16 kHz mono default, so no need to
explictly initialize.
- Add assert(false) to real-time errors which should not occur.
TESTED=trybots
R=bjornv@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2253005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4924 4adac7df-926f-26a2-2b94-8c16560cd09d
- These replace the media parameter, now removed.
- Organize the parameter getting a bit.
To describe the new parameters, I'll just copy the code comments here:
Use "audio" and "video" to set the media stream constraints. "true" and
"false" are recognized and interpreted as bools, for example:
"?audio=true&video=false" (start an audio-only call).
"?audio=false" (start a video-only call)
If unspecified, the constraint defaults to True.
audio-specific parsing:
To set certain constraints, pass in a comma-separated list of audio
constraint strings. If preceded by a "-", the constraint will be set to
False, and otherwise to True. There is no validation of constraint
strings. Examples:
"?audio=googEchoCancellation" (enables echo cancellation)
"?audio=-googEchoCancellation,googAutoGainControl" (disables echo
cancellation and enables gain control)
TESTED=Verified that passing true, false and various audio constraints
has the desired effect in apprtc.
R=vikasmarwaha@google.com
Review URL: https://webrtc-codereview.appspot.com/2345004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4919 4adac7df-926f-26a2-2b94-8c16560cd09d
Recent changes in GYP seem to have broken our previous
"hack" for getting the GYP rule for .isolate files
imported from the Chromium build/isolate.gypi.
The best solution for now is to remove the hack
and check in a copy of Chromium's src/build/isolate.gypi
in WebRTC's build/ dir instead. A similar approach is
used for our build/protoc.gypi file.
TEST=On Linux, I successfully ran:
gclient runhooks
ninja -C out/Release
and verified a bunch of .isolated files were created in
out/Release (which didn't happen before this patch).
I also renamed the build/isolate.gypi from Chromium to
ensure that our own is used and not that one (in case any
paths would be incorrect).
I also ran build/gyp_chromium in a Chromium checkout
with WebRTC in third_party/webrtc having this patch applied
to ensure GYP processing was still working.
Finally, I verified that the same project generation and
compilation from a Chromium checkout worked the way we build
our Android native tests, using:
. build/android/envsetup.sh
GYP_DEFINES="$GYP_DEFINES include_tests=1 enable_tracing=1" gclient runhooks
ninja -C out/Release android_builder_webrtc
BUG=1916
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2338004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4907 4adac7df-926f-26a2-2b94-8c16560cd09d
On Windows, sometimes the compare_videos.py script fails because
the inherited stdin handle from the parent process fails.
It seems we can work around this by passing null to stdin to
the subprocesses, since we're not using it anyway.
The errors looked like this:
Traceback (most recent call last):
File "C:\b\build\slave\Win7_Tester\build\src\third_party/webrtc/tools/compare_videos.py", line 116, in <module>
sys.exit(main())
File "C:\b\build\slave\Win7_Tester\build\src\third_party/webrtc/tools/compare_videos.py", line 91, in main
barcode_decoder = subprocess.Popen(cmd, stdout=sys.stdout, stderr=sys.stderr)
File "C:\b\depot_tools\python_bin\lib\subprocess.py", line 588, in __init__
errread, errwrite) = self._get_handles(stdin, stdout, stderr)
File "C:\b\depot_tools\python_bin\lib\subprocess.py", line 686, in _get_handles
p2cread = GetStdHandle(STD_INPUT_HANDLE)
WindowsError: [Error 6] The handle is invalid
Example from http://build.chromium.org/p/chromium.webrtc/builders/Win7%20Tester/builds/4498/steps/webrtc_manual_browser_tests_test/logs/stdio
BUG=302915
TEST=successful runs on Windows and Linux.
R=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2334005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4902 4adac7df-926f-26a2-2b94-8c16560cd09d
We encounter a sample-underrun if NetEq is initialized with a sampling rate fs =16000 and receive Opus packets with frame-size less than 5 ms. The reason is as follows.
Let say NetEq buffer has 4 packets of Opus each of size 2.5ms this means that internally timestamp of packets incremented by 80 (internally Opus treated as 32 kHz codec). Given the initial sampling rate of NetEq, at the first time that it wants to fetch packets, it targets to fetch 160 samples. Therefore, it will only extracts 2 packets. Decoding these packets give us exactly 160 samples (5 ms at 32 kHz), however, upon decoding the first packet the internal sampling rate will be updated to 32 kHz. So it is expected that sync buffer to deliver 320 samples while it does only have 160 samples (or maybe few more as it starts with some zeros). And we encounter and under-run.
Even if we ignore the under-run "assert(sync_buffer_->FutureLength() >= expand_->overlap_length())" (neteq_impl.cc::811) is trigered. I'm not sure what happens if we remove this assert perhaps NetEq will work fine in subsequent calls. However the first under-run is blocking ACM2 test to pass.
Here I have a solution to update sample rate as soon as a packet is inserted, if required. It not a very efficient approach as we do the same reset in NetEqImpl::Decode().
It is a bit tricky to reproduce this because the TOT ACM tests do not run ACM2. In https://webrtc-codereview.appspot.com/2192005/ I have a patch to run both ACMs. To reproduce the problem, one can patch that CL and run
$ out/Debug/modules_tests --gtest_filter=AudioCodingModuleTest.TestOpus
Note that we would not encounter any problem if NetEq4 is initiated with 32000 Hz sampling rate. You can test this by setting |kNeteqInitSampleRateHz| to 32000 in webrtc/modules/audio_coding/main/acm2/acm_receiver.cc
BUG=
R=andrew@webrtc.org, henrik.lundin@webrtc.org, kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2306004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4896 4adac7df-926f-26a2-2b94-8c16560cd09d
If there is audio in a codec's audio buffer and sample-rate or number of channels change the audio buffer has to reset. Otherwise, the amount of audio in the buffer is misinterpreted any syncronization between 10ms audio blocks and their associated timestamps is lost.
For instance, assume changing from stereo to mono when there is 10ms stereo in the buffer. The "new" codec will interpret this as 20 ms audio, therefore, 2 blocks of 10 ms, but there is only one timestamp. This will results in ACMGenericCodec::in_timestamp_ix_write_ updated to a negative number after an encode is performed.
The drawback with this solution is that if packet-size of the codec is changed then audio buffer is reset wich is not necessary. We accept this as it is a rare case in practice that clients of ACM re-register send codecs to change packet-size.
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2151006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4887 4adac7df-926f-26a2-2b94-8c16560cd09d
The untrusted delay mode provides an option to reduce the "known delay"
parameter passed down to the core AEC. This is necessary to handle the
very low latencies observed with the Chromium audio backend on Mac.
Prior to this change, it was possible to pass a negative value. The AEC
produced good output in practice, but it turned out this tripped a
heretofore unnoticed assert in ProcessBlock().
This change avoids the assert, and maintains the good output across a
set of Mac recordings. Bit-exact in some cases, and in the remaining,
quickly converging to identical output.
The assert was hit on the last webrtc roll in Chromium in
content_browsertests on Mac.
Corresponds to:
https://chromereviews.googleplex.com/9960013
TBR=bjornv
TESTED=Verified locally that "content_browsertests
--gtest_filter=WebrtcBrowserTest.*"" passes.
Review URL: https://webrtc-codereview.appspot.com/2328005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4886 4adac7df-926f-26a2-2b94-8c16560cd09d
