Currently, I420VideoFrame uses three webrtc::Plane to store pixel data, and WebRtcVideoFrame uses WebRtcVideoFrame::FrameBuffer/webrtc::VideoFrame. The two subclasses WebRtcTextureVideoFrame and TextureVideoFrame use a NativeHandle to store pixel data, and there is also a class WebRtcVideoRenderFrame that wraps an I420VideoFrame.
This CL replaces these classes with a new interface VideoFrameBuffer that provides the common functionality. This makes it possible to remove deep frame copies between cricket::VideoFrame and I420VideoFrame.
Some additional minor changes are:
* Disallow creation of 0x0 texture frames.
* Remove the half-implemented ref count functions in I420VideoFrame.
* Remove the Alias functionality in WebRtcVideoFrame
The final goal is to eliminate all frame copies, but to limit the scope of this CL, some planned changes are postponed to follow-up CL:s (see planned changes in https://webrtc-codereview.appspot.com/38879004, or https://docs.google.com/document/d/1bxoJZNmlo-Z9GnQwIaWpEG6hDlL_W-bzka8Zb_K2NbA/preview). Specifically, this CL:
* Keeps empty subclasses WebRtcTextureVideoFrame and TextureVideoFrame, and just delegates the construction to the superclass.
* Keeps the deep copies from cricket::VideoFrame to I420VideoFrame.
BUG=1128
R=mflodman@webrtc.org, pbos@webrtc.org, perkj@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42469004
Cr-Commit-Position: refs/heads/master@{#8580}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8580 4adac7df-926f-26a2-2b94-8c16560cd09d
This solution does not use the existing VAD/DTX logic of ACM, since Opus DTX is codec feature, while ACM VAD/DTX is mainly for setting the WebRTC VAD/DTX.
During the development of this CL, two old bugs were found and are fixed in this CL too.
They are in
webrtc/modules/audio_coding/test/Channels.cc
and webrtc/modules/audio_coding/main/acm2/acm_opus_unittest.cc
respectively.
BUG=webrtc:1014
R=henrik.lundin@webrtc.org, tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38469004
Cr-Commit-Position: refs/heads/master@{#8573}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8573 4adac7df-926f-26a2-2b94-8c16560cd09d
There exist devices with runtime checks for NEON, but where the device is not NEON. One such device is Tegra2 on which currently NEON code is running.
This fix adds a missing feature check when initializing the AEC.
BUG=4304
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42159004
Cr-Commit-Position: refs/heads/master@{#8559}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8559 4adac7df-926f-26a2-2b94-8c16560cd09d
This is useful for debugging h264 input when we don't have an h264 decoder, as the resulting file should be possible to play back using mplayer. It is also often convenient to dump rtp packets in an interleaved format where the size of a packet is inserted before the actual payload.
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42139004
Cr-Commit-Position: refs/heads/master@{#8558}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8558 4adac7df-926f-26a2-2b94-8c16560cd09d
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
(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 parantheses and style changes
BUG=3348, 3353
TESTED=locally on Mac and trybots
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39139004
Cr-Commit-Position: refs/heads/master@{#8544}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8544 4adac7df-926f-26a2-2b94-8c16560cd09d
> Ensure only temporary IPv6 address is selected as the best IP.
>
> The current logic of IPv6 selection could still have a small chance for non-temporary address to be selected for candidate. The scenario is that when there is no non-deprecated temporary IP, the global ones could be selected.
>
> Global ones don't necessarily carry MAC. However, instead of comparing whether it has the MAC in it (sometimes 5 out of 6 elements from a MAC are the same, only one diffs), we should just err on the safe side.
>
> BUG=4348
> R=juberti@webrtc.org, pthatcher@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/38289004TBR=guoweis@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38319004
Cr-Commit-Position: refs/heads/master@{#8534}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8534 4adac7df-926f-26a2-2b94-8c16560cd09d
The current logic of IPv6 selection could still have a small chance for non-temporary address to be selected for candidate. The scenario is that when there is no non-deprecated temporary IP, the global ones could be selected.
Global ones don't necessarily carry MAC. However, instead of comparing whether it has the MAC in it (sometimes 5 out of 6 elements from a MAC are the same, only one diffs), we should just err on the safe side.
BUG=4348
R=juberti@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38289004
Cr-Commit-Position: refs/heads/master@{#8532}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8532 4adac7df-926f-26a2-2b94-8c16560cd09d
After looking at how this class is used I discovered that the threading model isn't completely crazy and that we can remove a lock from a method that's causing the most contention in getStats right now (and probably many other places). IsFrameCallbackRegistered() looks innocent enough, but it contented with the frame encoder, which can make it wait for tens of milliseconds, unnecessarily.
In addition to removing the lock, I:
* Documented the threading model
* Added checks to guard against regressions
* Reduced lock scope in the Deregister function (not calling out to the notification while holding the lock).
* made virtual functions non-virtual (since they're not really being overriden) and removed unnecessary method that, if called by other threads than the ctor thread, returned a value that wasn't necessarily correct.
BUG=2822
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40859004
Cr-Commit-Position: refs/heads/master@{#8531}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8531 4adac7df-926f-26a2-2b94-8c16560cd09d
This reverts commit r8434.
Reason for revert: Introduced a race condition. If ViECaptureProcess() -> SwapCapturedAndDeliverFrameIfAvailable() is called twice without a call to OnIncomingCapturedFrame() in between (with both captured_frame_ and deliver_frame_ populated), an old frame will be delivered again, since captured_frame_->IsZeroSize() will never be true.
BUG=4352
TBR=perkj@webrtc.org, stefan@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40129004
Cr-Commit-Position: refs/heads/master@{#8530}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8530 4adac7df-926f-26a2-2b94-8c16560cd09d
* Added a way to notify a Module that it's been attached to a ProcessThread.
The benefit of this is to give the module a way to wake up the thread
when it needs work to happen on the worker thread, immediately.
Today, module instances are typically registered with a process thread
outside the control of the modules themselves. I.e. they typically
don't know about the process thread they're attached to.
* Improve ProcessThread's WakeUp algorithm to not call TimeUntilNextProcess
when a WakeUp call is requested. This is an optimization for the above
case which avoids the module having to acquire a lock or do an interlocked
operation before calling WakeUp(), which would ensure the module's
TimeUntilNextProcess() implementation would return 0.
BUG=2822
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39239004
Cr-Commit-Position: refs/heads/master@{#8527}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8527 4adac7df-926f-26a2-2b94-8c16560cd09d
Mostly, it's about moving constructors and descructors to the .cc
files, so that they won't be inlined everywhere.
The reason this CL is so big is that a lot of code was using
common_types.h without declaring a dependency on webrtc_common, which
broke the build once common_types.h started to depend on
common_types.cc.
BUG=163
R=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26089004
Cr-Commit-Position: refs/heads/master@{#8516}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8516 4adac7df-926f-26a2-2b94-8c16560cd09d
Add some const safety by DCHECK(HasOneRef()) in non-const GetYPlane. This CL also replaces all incorrect non-const calls with const calls for pixel data access in cricket::VideoFrame. It's easy to call the non-const version of e.g. GetYPlane by mistake, even if only const-access is needed. For example:
const scoped_ptr<cricket::VideoFrame> foo;
const uint8_t* y = foo->GetYPlane();
will actually call the non-const version of GetYPlane.
R=mflodman@webrtc.org, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39079004
Cr-Commit-Position: refs/heads/master@{#8507}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8507 4adac7df-926f-26a2-2b94-8c16560cd09d
TestScaler::ComputeAvgSequencePSNR is currently a complex NOP, that always returns kPerfectPSNR. Two frames are read from files into arrays, and then converted into I420VideoFrames. However, the incorrect function ConvertFromI420 is used instead of ConvertToI420, resulting in two empty I420VideoFrames. I420PSNR on empty frames returns kPerfectPSNR.
This CL replaces ConvertFromI420 with ConvertToI420 and actually measures the PSNR. Unfortunately, some tests do not pass when we use the real psnr. The tests that fail are the ones that scale back and forth to a different aspect ratio. webrtc::Scaler has been changed to preserve aspect ratio, and this means that we will end up with a cropped frame if scale and rescale to a different target aspect ratio. I simply removed those tests to make it pass. Having some working tests instead of a lot of dummy tests seems like a win.
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/35339004
Cr-Commit-Position: refs/heads/master@{#8506}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8506 4adac7df-926f-26a2-2b94-8c16560cd09d
Call to AudioEncoder::Encode fails only if fed bad input, so instead of handling failure, we can just CHECK.
There is also no need to handle case where size of encoded data is larger than allowed maximum, so we just CHECK.
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42099005
Cr-Commit-Position: refs/heads/master@{#8504}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8504 4adac7df-926f-26a2-2b94-8c16560cd09d
