As far as I observe, there are several reasons for this:
1. webrtc/modules/audio_coding/neteq4/neteq_impl.cc : 870
assert(new_codec_);
This is related to webrtc/modules/audio_coding/neteq4/decision_logic_normal.cc : 81
kUndefined can happen without new_codec_ being set
2. webrtc/modules/audio_coding/neteq4/neteq_impl.cc : 745
assert(sync_buffer_->FutureLength() >= expand_->overlap_length());
3. some other assert triggered.
The above happens not very often and goes away with no assertion.
3. (most common, this CL addresses this)
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc : 201
payload_data_length = payload_length - rtp_header->header.paddingLength;
There are situations that
payload_length < rtp_header->header.paddingLength;
OLD ACM + NetEq3 can handle this:
a) webrtc/modules/audio_coding/main/source/acm_neteq.cc : 477
int16_t payload_length = static_cast<int16_t>(length_payload);
payload_length becomes negative in this situation
b) webrtc/modules/audio_coding/neteq/recin.c
WebRtcNetEQ_RecInInternal() handles negative payload length
I do not want to touch VoE, so I tried to let ACM2 and NetEq4 handle negative payload length.
This CL does not follow the exact way of OLD ACM + NetEq3. I stopped negative payload length at ACM and did not allow it go to NetEq4.
To try this, apply my uploaded patch : https://webrtc-codereview.appspot.com/2281004/
Let me know if you see better solutions.
R=henrik.lundin@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2292005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4860 4adac7df-926f-26a2-2b94-8c16560cd09d
I mistakenly ommitted the checks when logging.h was ported from
libjingle to webrtc. This caused a significant CPU cost for logs which
were later filtered out anyway.
Verified with LS_VERBOSE logging in neteq4, running:
$ out/Release/modules_unittests \
--gtest_filter=NetEqDecodingTest.TestBitExactness \
--gtest_repeat=50 > time.txt
$ grep "case ran" time.txt | grep "[0-9]* ms" -o | sort
Results on a MacBook Retina, averaged over 5 runs:
Verbose logs disabled: 666 ms
Exisiting implementation, verbose logs enabled: 944 ms (1.42x)
New implementation, verbose logs enabled: 673 ms (1.01x)
BUG=2314
R=henrik.lundin@webrtc.org, henrike@webrtc.org, kjellander@webrtc.org, turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2160005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4682 4adac7df-926f-26a2-2b94-8c16560cd09d
- 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
- A bug was introduced in r4234 causing no paced packets to be sent.
- Only update the sequence number counter if a padding packet is actually going to be sent, to avoid packet loss.
- Have all packets go through the pacer if pacing is enabled to avoid reordering.
- Fix race condition on reading capture_time_ms_/timestamp_ in rtp_sender.cc.
BUG=1837
TEST=trybots and vie_auto_test --automated
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1682004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4246 4adac7df-926f-26a2-2b94-8c16560cd09d
This connects the pacer-based padding with the RTP modules, which will
generate padding packets roughly according to what the pacer suggests.
It will only generate padding packets of maximum size to keep the number
off padding packets as small as possible. This also sets a limit of how much
padding + media bitrate which the pacer is allowed to "request" from the
RTP modules.
Padding will for now only be generated by the first sending RTP module.
BUG=1837
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1612005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4234 4adac7df-926f-26a2-2b94-8c16560cd09d
A new test target named 'modules_integrationtests' is created
and the following test targets were merged into it:
* audio_coding_module_test
* test_fec
* video_coding_integrationtests
* vp8_integrationtests
A couple of other targets were merged into modules_unittests:
* audio_coding_unittests
* audioproc_unittest
* common_unittests
* video_coding_unittests
* video_processing_unittests
* vp8_unittests
I wasn't able to merge audio_decoder_unittests and neteq_unittests due to
conflicts with different defines in these tests.
Some tests that have special requirements aren't merged into
modules_integrationtests yet. I took the opportunity to rename them
since the bot configs will need to be update anyway:
* audio_device_test_api -> audio_device_integrationtests
* video_capture_module_test -> video_capture_integrationtests
* video_render_module_test -> video_render_integrationtests
Exclude files were added for modules_integrationtests to make sure
the memcheck and tsan bots doesn't tests that are too slow
(audio_coding_module_test and vp8_integrationtests were previously
disabled on those bots).
Suppressions for AudioCodingModuleTest needed to be added to get
modules_integrationtests to pass memcheck (even if the test is
excluded from execution).
BUG=1843
TEST=local execution on Linux and trybots (passing except the merged tests of course)
R=andrew@webrtc.org, tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1656004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4228 4adac7df-926f-26a2-2b94-8c16560cd09d
