This CL makes two changes to rtc::Buffer that have had to wait for
Chromium's use of it to be modernized:
1. Change default return type of rtc::Buffer::data() from char* to
uint8_t*. uint8_t is a more natural type for bytes, and won't
accidentally convert to a string. (Chromium previously expected
the default return type to be char, which is why
rtc::Buffer::data() initially got char as default return type in
9478437f, but that's been fixed now.)
2. Stop accepting void* inputs in constructors and methods. While
this is convenient, it's also dangerous since any pointer type
will implicitly convert to void*.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44269004
Cr-Commit-Position: refs/heads/master@{#9121}
Removes FixedSizeLockFreeQueue which isn't used anymore. This enabled
moving rtc::AtomicOps to webrtc/base/atomicops.h where they should be.
BUG=4330
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51789004
Cr-Commit-Position: refs/heads/master@{#9120}
This pattern (read-only base, writable subclass) was picked to maintain a *Buffer option that doesn't copy the source bits when parsing. ByteBuffer and Buffer both copy. I'm open to discussion on what the type relationship would be, though :)
Tests have been added to ensure the symmetric nature of read/write operations.
BUG=
R=bcornell@google.com, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45259005
Cr-Commit-Position: refs/heads/master@{#9107}
This class is being used from both libjingle and webrtc but we recently had a regression when we added dependency on libjingle's Thread class. This cleans that up and moves the implementation of CriticalSection and helper classes into the source file.
I'm also improving debugging facilities and constness.
BUG=
R=magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51769004
Cr-Commit-Position: refs/heads/master@{#9089}
In days of yore, move.h contained complicated macros for approximating
move-only behavior in C++03. But since we live in the future now, and
can rely on C++11 features---including real move semantics!---it makes
more sense to just write the handful of required lines by hand in each
move-only class.
(We only live in the near future, though, not in some sci-fi
intergalactic civilization singularity type future, so we have to
define Pass() methods for these classes since we're not allowed to use
std::move().)
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45099004
Cr-Commit-Position: refs/heads/master@{#9060}
Provides a read-only interface for reading byte and bit-sized data from
an underlying buffer in network/big-endian order. Also provides a method
for reading exponential golomb encoded values, which will be useful in
H.264 packet parsing (separate CL).
BUG=
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/49719004
Cr-Commit-Position: refs/heads/master@{#9046}
We used to accept void* (until 9478437f), and we'll have to continue
to do so for a little while longer, until Chromium doesn't need it
anymore.
TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48179004
Cr-Commit-Position: refs/heads/master@{#9035}
1. Constructors, SetData(), and AppendData() now accept uint8_t*,
int8_t*, and char*. Previously, they accepted void*, meaning that
any kind of pointer was accepted. I think requiring an explicit
cast in cases where the input array isn't already of a byte-sized
type is a better compromise between convenience and safety.
2. data() can now return a uint8_t* instead of a char*, which seems
more appropriate for a byte array, and is harder to mix up with
zero-terminated C strings. data<int8_t>() is also available so
that callers that want that type instead won't have to cast, as
is data<char>() (which remains the default until all existing
callers have been fixed).
3. Constructors, SetData(), and AppendData() now accept arrays
natively, not just decayed to pointers. The advantage of this is
that callers don't have to pass the size separately.
4. There are new constructors that allow setting size and capacity
without initializing the array. Previously, this had to be done
separately after construction.
5. Instead of TransferTo(), Buffer now supports swap(), and move
construction and assignment, and has a Pass() method that works
just like std::move(). (The Pass method is modeled after
scoped_ptr::Pass().)
R=jmarusic@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42989004
Cr-Commit-Position: refs/heads/master@{#9033}
Since the GYP variables use_openssl and build_ssl are both
enabled by default on Windows today, I believe we should be able
to clean up the GYP paths that build NSS for Windows.
BUG=4497
TESTED=Passing tryjobs with --clobber specified.
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50559004
Cr-Commit-Position: refs/heads/master@{#8945}
UDP case should not be changed.
Active TCPConnection will initiate Reconnect after OnClose and when Send or Ping fails.
Passive TCPConnection will prune itself as usual as the active side will create a new connection.
The Reconnect could make P2PCT choose a different best_connection in the case where connectivities exist b/w more than 1 Network.
Also, to avoid upper layer triggers ice restart, the WRITE_TIMEOUT caused by the socket disconnection is delayed to give the reconnect mechanism chance to kick in. The timeout event is only fired if the reconnect can't work in 5 sec. If the reconnect, there should be no ICE disconnected state trigger either in active or passive side.
BUG=1926
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31359004
Cr-Commit-Position: refs/heads/master@{#8929}
This cl uses the YV12 buffers from Java without a copy if no rotation is needed. Buffers are returned to the camera when the encoder and renderers no longer needs them.
This add a new frame type WrappedI420Buffer based in that allows for wrapping existing memory buffers and getting a notification when it is no longer used.
AndroidVideoCapturer::FrameFactory::CreateAliasedFrame wraps frame received from Java. For each wrapped frame a new reference to AndroidVideoCapturerDelegate is held to ensure that the delegate can not be destroyed until all frames have been returned.
Some overlap exist in webrtcvideoframe.cc and webrtcvideengine.cc with https://webrtc-codereview.appspot.com/47399004/ that is expected to be landed before this cl.
BUG=1128
R=glaznev@webrtc.org, magjed@webrtc.orgTBR=mflodman@webrtc.org // For changes in webrtc/common_video/video_frame_buffer
Review URL: https://webrtc-codereview.appspot.com/49459004
Cr-Commit-Position: refs/heads/master@{#8923}
This should fix the TODO in that header.
BUG=None
TEST=ninja -C out/Debug still compiles everything.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47919004
Patch from Thiago Farina <tfarina@chromium.org>.
Cr-Commit-Position: refs/heads/master@{#8921}
And remove pass-through stringdigest.h include.
This should fix the TODO in stringdigest.h that were that saying to update the callers to the new location.
BUG=None
TEST=ninja -C out/Debug still works fine
R=henrika@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48779004
Patch from Thiago Farina <tfarina@chromium.org>.
Cr-Commit-Position: refs/heads/master@{#8920}
Instead just use MD5Context type directly. In C++ it is unnecessary to
alias the types using typedef, unline C (where if you don't you have to
spell out struct or enum infront of the user-type everytime you want to make a
variable).
So since WebRTC's base API is C++, it seems unnecessay to keep this
typedef around.
BUG=None
TEST=rtc_unittests --gtest_filter=Md5*
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46799004
Patch from Thiago Farina <tfarina@chromium.org>.
Cr-Commit-Position: refs/heads/master@{#8916}
And add a constructor for creating an uninitialized Buffer of a
specified size.
(I intend to follow up with more Buffer changes, but since it's rather
widely used, the rename is quite noisy and works better as a separate
CL.)
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48579004
Cr-Commit-Position: refs/heads/master@{#8841}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8841 4adac7df-926f-26a2-2b94-8c16560cd09d
Mostly this consists of marking functions with override when
applicable, and moving function bodies from .h to .cc files.
Not inlining virtual functions with simple bodies such as
{ return false; }
strikes me as probably losing more in readability than we gain in
binary size and compilation time, but I guess it's just like any other
case where enabling a generally good warning forces us to write
slightly worse code in a couple of places.
BUG=163
R=kjellander@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47429004
Cr-Commit-Position: refs/heads/master@{#8656}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8656 4adac7df-926f-26a2-2b94-8c16560cd09d
The problem we were running into on the Mac 10.9 debug bot in Chrome turned out to be good ol'fashion memory corruption. Part of webrtc was being compiled with _DEBUG, another half without it. This caused the definition of some symbols to be out of sync (notably pthread_mutex_t) and would cause code built from common.gypi, to overwrite memory allocated via common types from base/base.gypi derived code. Fun stuff to track down. This was a problem in particular with base/criticalsection.h since it's inlined into multiple object files but will have different definitions of what a mutex is.
TBR=pbos,kjellander
BUG=
Review URL: https://webrtc-codereview.appspot.com/43659004
Cr-Commit-Position: refs/heads/master@{#8646}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8646 4adac7df-926f-26a2-2b94-8c16560cd09d
Local testing indicates that the pthread_t member variable might be causing alignment problems on the Chromium bots. After landing this (and once the Chromium tree is open again), I'll try a roll again to see if this has an effect.
R=magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48449004
Cr-Commit-Position: refs/heads/master@{#8644}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8644 4adac7df-926f-26a2-2b94-8c16560cd09d
Clang version changed 223108:230914
Details: e144d30..6fdb142/tools/clang/scripts/update.sh
Removes the OVERRIDE macro defined in:
* webrtc/base/common.h
* webrtc/typedefs.h
The majority of the source changes were done by running this in src/:
perl -0pi -e "s/virtual\s([^({;]*(\([^({;]*\)[^({;]*))(OVERRIDE|override)/\1override/sg" `find {talk,webrtc} -name "*.h" -o -name "*.cc*" -o -name "*.mm*"`
which converted all:
virtual Foo() OVERRIDE
functions to:
Foo() override
Then I manually edited:
* talk/media/webrtc/fakewebrtccommon.h
* webrtc/test/fake_common.h
Remaining uses of OVERRIDE was fixed by search+replace.
Manual edits were done to fix virtual destructors that were
overriding inherited ones.
Finally a build error related to the pure virtual definitions of
Read, Write and Rewind in common_types.h required a bit of
refactoring in:
* webrtc/common_types.cc
* webrtc/common_types.h
* webrtc/system_wrappers/interface/file_wrapper.h
* webrtc/system_wrappers/source/file_impl.cc
This roll should make it possible for us to finally re-enable deadlock
detection for TSan on the buildbots.
BUG=4106
R=pbos@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41069004
Cr-Commit-Position: refs/heads/master@{#8596}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8596 4adac7df-926f-26a2-2b94-8c16560cd09d
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
