- Allow padding to be sent on an ssrc which doesn't produce video, therefore
never having the last_packet_marker_bit_ set.
- Add the random timestamp offset to all padding packets.
- Store the capture time of padding packets to properly create an offset.
BUG=2258
TEST=trybots and a new test which will be committed separately.
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2060005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4566 4adac7df-926f-26a2-2b94-8c16560cd09d
As this breaks the FYI bots in
http://build.chromium.org/p/chromium.webrtc.fyi/waterfall
due to different path to isolate.gypi (which cannot easily
be resolved due to limitations in GYP)
> Isolate GYP target and .isolate files for tests
>
> Implemented according to the instructions at
> http://www.chromium.org/developers/testing/isolated-testing
>
> Workflow has been like this:
> 1. create _run GYP target
> 2. create a stripped down .isolate file
> 3. export GYP_DEFINES="$GYP_DEFINES test_isolation_mode=check"
> 4. runhooks
> 5. compile
> 6. test if the test would run (i.e. find it's dependencies) without
> actually executing it:
> tools/swarm_client/isolate.py run --isolated out/Release/testname.isolated
> 7. If failing, run the fix_test_cases.py script like this:
> tools/swarm_client/fix_test_cases.py --isolated out/Release/testname.isolated
>
> All tests that run on the bots for WebRTC has got _run target
> and .isolate file created.
>
> "Normal tests" that run fine on any machine:
> * audio_decoder_unittests
> * common_audio_unittests
> * common_video_unittests
> * metrics_unittests
> * modules_integrationtests
> * modules_unittests
> * neteq_unittests
> * system_wrappers_unittests
> * test_support_unittests
> * tools_unittests
> * video_engine_core_unittests
> * voice_engine_unittests
>
> Tests that requires bare-metal and audio/video devices:
> * audio_device_integrationtests
> * video_capture_integrationtests
>
> I also added the isolate boilerplate code for the following
> tests that are not yet pure gtest binaries (which means they
> cannot run isolated yet):
> * video_render_integrationtests
> * vie_auto_test
> * voe_auto_test
>
> TEST=running isolate.py as described above.
> BUG=1916
> R=tommi@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/1673004TBR=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2040004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4548 4adac7df-926f-26a2-2b94-8c16560cd09d
Implemented according to the instructions at
http://www.chromium.org/developers/testing/isolated-testing
Workflow has been like this:
1. create _run GYP target
2. create a stripped down .isolate file
3. export GYP_DEFINES="$GYP_DEFINES test_isolation_mode=check"
4. runhooks
5. compile
6. test if the test would run (i.e. find it's dependencies) without
actually executing it:
tools/swarm_client/isolate.py run --isolated out/Release/testname.isolated
7. If failing, run the fix_test_cases.py script like this:
tools/swarm_client/fix_test_cases.py --isolated out/Release/testname.isolated
All tests that run on the bots for WebRTC has got _run target
and .isolate file created.
"Normal tests" that run fine on any machine:
* audio_decoder_unittests
* common_audio_unittests
* common_video_unittests
* metrics_unittests
* modules_integrationtests
* modules_unittests
* neteq_unittests
* system_wrappers_unittests
* test_support_unittests
* tools_unittests
* video_engine_core_unittests
* voice_engine_unittests
Tests that requires bare-metal and audio/video devices:
* audio_device_integrationtests
* video_capture_integrationtests
I also added the isolate boilerplate code for the following
tests that are not yet pure gtest binaries (which means they
cannot run isolated yet):
* video_render_integrationtests
* vie_auto_test
* voe_auto_test
TEST=running isolate.py as described above.
BUG=1916
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1673004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4547 4adac7df-926f-26a2-2b94-8c16560cd09d
When VideoDecoder::Decode, Reset, or Release is called,
VideoCodingModuleImpl::_receiveCritSect may have been
acquired. Decode callback needs to acquire the same lock
in ViEChannel::FrameToRender. It is not a problem for
SW decode because decode callback is run on the same
WebRTC decoding thread and the lock is re-entrant. But
for HW decode, decode callback is run on a thread different
from WebRTC decoding thread. Decode callback gets the locks
in the opposite order. Deadlock can happen.
BUG=http://crbug.com/170345
TEST=Try apprtc.appspot.com/?debug=loopback on ARM Chromebook Daisy.
Run libjingle_peerconnection_unittest.
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1997005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4523 4adac7df-926f-26a2-2b94-8c16560cd09d
r4326 was mistakenly committed to stable, so this is to re-merge back to trunk.
Fixed the AGC and interface problems on the new path.
In order to make the AGC work properly, we need to cache the volume value passed
by the callback, compare it with the value returned by
shared->transmit_mixer()->CaptureLevel(). If they are the same, we need to
return 0 to indicate no volume needs changing, otherwise return the new volume.
By doing this, we avoid setting the volume all the same, which allows the users
to change the volume manually.
This patch also fixes some minor issues with the interfaces too: make the int
channel[] const, and correct the order of the input params in
channel::Demultiplex.
R=tommi@webrtc.org
BUG=[2134]
TEST=compile && manual AGC test
Review URL: https://webrtc-codereview.appspot.com/1921004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4450 4adac7df-926f-26a2-2b94-8c16560cd09d
r4326 was mistakenly committed to stable, so this is to re-merge back to trunk.
Add new interface to support multiple sources in webrtc.
CaptureData() will be called by chrome with a flag |need_audio_processing| to
indicate if the data needs to be processed by APM or not. Different from the old
interface that will send the data to all voe channels, the new interface will
specify a list of voe channels that the data is demultiplexing to.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1919004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4449 4adac7df-926f-26a2-2b94-8c16560cd09d
This is the conversation I had with Henrik Lundin regarding this problem.
Me:
In Expand::AnalyseSignal() we compute correlation and distortion, then calculate the ratio of correlation to distortion. There if distortion is zero we expect that correlation to be zero. Although in practice this might be true, I suppose we rarely hit into absolutely periodic signal, but in one of the tests the assertion in line 455 of expand.cc was triggered. The distortion is computed over a shorter length of the signal, while correlation is computed over longer segments. Therefore, I guess, if the signal has just enough zeros at the beginning we can end up in situation that distortion is zero but not the correlation. Do you agree? I didn't have time to attempt to solve this, but if my line of thought is correct, we should not have that assert. Perhaps, if correlation is zero we set the ratio to 0, otherwise, ratio would be the largest value of its own type. Any thoughts?
Henrik:
I agree with you. Go ahead with your solution.
R=minyue@google.com
Review URL: https://webrtc-codereview.appspot.com/1888006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4448 4adac7df-926f-26a2-2b94-8c16560cd09d
