When checking whether we need to release external decoder,
we have to do pointer comparison. We can't rely on payload
types, because payload types can be stale (e.g. before we
decode the first video frame after RegisterReceiveCodec).
This leaves a dangling pointer to external decoder, which
leads to crashes later, after we actually delete the
external decoder object.
This change has been verified in Chromecast code tree.
BUG=chromium:335539
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/12049004
Patch from Sergey Volk <servolk@chromium.org>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5922 4adac7df-926f-26a2-2b94-8c16560cd09d
Having this override in the .gypi file avoids having to set it for the bots, which I think is best if we can avoid.
This CL also reverts r5869 so video_capture_tests are compiled for Android again.
BUG=2974,3152
TEST=Successfully ran:
git try -t compile
git try --bot=win_baremetal,mac_baremetal,linux_baremetal -t video_capture_tests
git try --bot=android_apk,android_apk_rel
Verified the change in webrtc/build/apk_tests.gyp makes the build compile successfully from a Chromium+WebRTC configured checkout for Android APK tests.
R=fischman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/11939004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5919 4adac7df-926f-26a2-2b94-8c16560cd09d
The design of VoeNetEqStatsTest in voice_engine_unittests depended on
being able to inject a factory for the audio coding module into
voice engine. This functionality is now likely going away, which would
make this test fail to compile. Further, the functionality under test
is mostly ACM functionality, wherefore it makes better sense to test it
at ACM level.
BUG=2996
R=henrika@webrtc.org, turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/12029004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5912 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL brought to you by:
$ for d in $(for f in $(git ls-files '*gyp' '*gypi'); do dirname $f; done|sort|uniq|grep -v '^\.$'); do echo -e "\n# These are for the common case of adding or renaming files. If you're doing\n# structural changes, please get a review from a reviewer in this file.\nper-file *.gyp=*\nper-file *.gypi=*" >> $d/OWNERS; done
$ for d in $(for f in $(git ls-files '*gyp' '*gypi'); do dirname $f; done|sort|uniq|grep -v '^\.$'); do git add $d/OWNERS; done
(and then removed the talk/ impact)
R=niklas.enbom@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/11969004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5903 4adac7df-926f-26a2-2b94-8c16560cd09d
Also enables running video_capture_tests_apk on the WebRTC/Chromium APK bots,
assuming GYP_DEFINES includes include_tests=1 and
include_internal_video_capture=1.
This required running VideoCaptureAndroid's camera capture on a dedicated thread, matching other platform's video_capture impls.
BUG=2974,3152
R=wu@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/11359004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5868 4adac7df-926f-26a2-2b94-8c16560cd09d
Replace the two versions with a single DownConvertToCodecFormat. As
mentioned in comments, this could be further consolidated with
RemixAndResample but we should write a full audio converter class in
that case.
Along the way:
- Fix the bug present in Channel::Demultiplex with mono input and a
stereo codec.
- Remove the 32 kHz max from the OnDataAvailable path. This avoids a
48 -> 32 -> 48 conversion when VoE is passed 48 kHz audio; instead we
get a straight pass-through to ACM. The 32 kHz conversion is still
needed in the RecordedDataIsAvailable path until APM natively supports
48 kHz.
- Merge resampler improvements from ACM1 to ACM2. This allows ACM to
handle 44.1 kHz audio passed to VoE and was originally done here:
https://webrtc-codereview.appspot.com/1590004
- Reuse the RemixAndResample unit tests for DownConvertToCodecFormat.
- Remove unused functions from utility.cc.
BUG=3155,3000,b/12867572
TESTED=voe_cmd_test using both the OnDataAvailable and
RecordedDataIsAvailable paths, with a captured audio format of all
combinations of {44.1,48} kHz and {1,2} channels, running through all
codecs, and finally using both ACM1 and ACM2.
R=henrika@webrtc.org, turaj@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/11019005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5843 4adac7df-926f-26a2-2b94-8c16560cd09d
The tool RTPanalyze (used to process an input RTP dump into a
text file of RTP header info) was present in both the neteq and
neteq4 folders. This change pulls in changes from the old to the new
and renames the source file and tool to rtp_analyze.
Removing special code for dummy-rtp files (it is supported without
special code), and making the RED payload type settable using flags.
Moving from test/ to tools/ folder.
BUG=2692
R=turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10789004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5832 4adac7df-926f-26a2-2b94-8c16560cd09d
Modify bitrate controller to update bitrate based on process call and not
only whenever a RTCP receiver block is received.
Additionally:
Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
Did not touch decrease logic, however since it can be triggered more often it
may decrease much faster and closer to the original written cap of once every
300ms + rtt.
Note:
rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
BUG=3065
R=stefan@webrtc.org, mflodman@webrtc.org
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5794 4adac7df-926f-26a2-2b94-8c16560cd09d
This triggered an occasional TSAN failure in
CallTest.ReceivesPliAndRecoversWithNack e.g.:
http://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan/builds/1444/steps/memory%20test%3A%20video_engine_tests/logs/stdio
I managed to reproduce this locally and verified that reverting this CL
corrected it.
> Modify bitrate controller to update bitrate based on process call and not
> only whenever a RTCP receiver block is received.
>
> Additionally:
> Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
>
> Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
>
> Did not touch decrease logic, however since it can be triggered more often it
> may decrease much faster and closer to the original written cap of once every
> 300ms + rtt.
>
> Note:
> rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
> bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
>
> BUG=3065
> R=stefan@webrtc.org, mflodman@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/10529004TBR=andresp@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10079005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5785 4adac7df-926f-26a2-2b94-8c16560cd09d
