bug: getStats was returning statistics for the shortlived, initial SSRC
now updating SSRC filter on statistics update callback to match audio channel ssrc
getStats API now returns statistics for correct SSRC: jitter, packets lost, etc.
MozReview-Commit-ID: WCd71WMkUW
--HG--
extra : rebase_source : 5d3a5a14e04313749173d264894e44411c3417bf
UniquePtr is more standard than ScopedDeletePtr; using standard
constructs whenever possible is preferable.
This patch merits a couple explanations:
- Where it made sense, I tried to convert:
T* foo() {
UniquePtr<T> x = ...;
...
return x.release();
}
into:
UniquePtr<T> foo()
with corresponding changes inside |foo|'s body.
- The attentive reader will note that:
auto x = MakeUnique<T>(...);
is used sometimes and:
UniquePtr<T> x(new T(...));
is used sometimes. I would prefer to use the former, but was stymied
in several places due to protected constructors. (MakeUnique doesn't
have access to those protected constructors, natch.)
Although 3rd parameter VideoEncodeer::InitEncode() is defiend as size_t, WebrtcIMXH264VideoCodec and WebrtcMediaCodecVP8VideoCodec uses uint32_t. This will cause build error for 64bit platform.
MozReview-Commit-ID: 20NgE5e7Cuz
--HG--
extra : rebase_source : 6da7b73504843b1062daff2b6977743114c2591e
ScopedFreePtrTraits is somewhat of an internal implementation detail of
Scoped.h, and it's not hard to write out the two static functions we
need from ScopedFreePtrTraits anyway. Removing this means that we can
clear the way for ScopedFreePtr to be removed.
The new routine actually multiplies by two for consistency with the other FFT
routines in use.
MozReview-Commit-ID: Hk2Dg3fR2cQ
--HG--
extra : rebase_source : 08bdbbd65d372a3d0eb69568313cec33ccea6af3
UniquePtr is more standard than ScopedDeletePtr; using standard
constructs whenever possible is preferable.
This patch merits a couple explanations:
- Where it made sense, I tried to convert:
T* foo() {
UniquePtr<T> x = ...;
...
return x.release();
}
into:
UniquePtr<T> foo()
with corresponding changes inside |foo|'s body.
- The attentive reader will note that:
auto x = MakeUnique<T>(...);
is used sometimes and:
UniquePtr<T> x(new T(...));
is used sometimes. I would prefer to use the former, but was stymied
in several places due to protected constructors. (MakeUnique doesn't
have access to those protected constructors, natch.)
This converts the individual cppunit gtests into the combined mozilla gtest
which has access to xpcom internals. The build file is simplified to reflect
this change, individual main functions are removed, and duplicate symbols are
removed.
This adds a base test for other mtransport tests to be derived from. It
handles common setup used by the mtransport tests and parses relevant env
vars.
This converts the individual cppunit gtests into the combined mozilla gtest
which has access to xpcom internals. The build file is simplified to reflect
this change, individual main functions are removed, and duplicate symbols are
removed.
This adds a base test for other mtransport tests to be derived from. It
handles common setup used by the mtransport tests and parses relevant env
vars.
The C++ standard, [facet.num.get.virtuals], defines the method to be
used for reading numeric values from an iterator. The core loop is
defined thusly in N3242 (the draft for the C++11 standard):
Stage 2: If in==end then stage 2 terminates. Otherwise a charT is
taken from in and local variables are initialized as if by
char_type ct = *in;
char c = src[find(atoms, atoms + sizeof(src) - 1, ct) - atoms];
if (ct == use_facet<numpunct<charT> >(loc).decimal_point())
c = '.';
bool discard =
ct == use_facet<numpunct<charT> >(loc).thousands_sep()
&& use_facet<numpunct<charT> >(loc).grouping().length() != 0;
where the values src and atoms are defined as if by:
static const char src[] = "0123456789abcdefxABCDEFX+-";
char_type atoms[sizeof(src)];
use_facet<ctype<charT> >(loc).widen(src, src + sizeof(src), atoms);
for this value of loc.
If discard is true, then if '.' has not yet been accumulated, then the
position of the character is remembered, but the character is
otherwise ignored. Otherwise, if '.' has already been accumulated, the
character is discarded and Stage 2 terminates.
If the character is either discarded or accumulated then in is
advanced by ++in and processing returns to the beginning of stage 2.
Stage 3: The sequence of chars accumulated in stage 2 (the field) is
converted to a numeric value by the rules of one of the functions
declared in the header <cstdlib>:
- For a signed integer value, the function strtoll.
- For an unsigned integer value, the function strtoull.
- For a floating-point value, the function strtold.
The important part for our purposes here is the line:
char c = src[find(atoms, atoms + sizeof(src) - 1, ct) - atoms];
which implies that we are to accumulate any and all characters that
might be numerical constituents. According to the spec text, we might
accumulate a long run of numeric constituents, only to decide in stage 3
that our accumulated string cannot be a valid number. Please note that
this includes characters like 'x' and 'X' which are only valid as part
of a hexadecimal prefix.
sdp_unittests has a number of tests that look like:
ParseInvalid<SdpImageattrAttributeList::XYRange>("[x", 1);
The test converts the input string to a stringstream, and attempts to
read an integer from the stream starting after the '[' character. The
test expects that no input from the string stream will be consumed, as
the character 'x' cannot begin any number, and thus the position of the
stream after failure will be 1. This behavior is consistent with MSVC's
standard library, libstdc++, and stlport.
However, libc++ uses a different algorithm that appears to hew more
closely to the letter of the spec, and consumes the 'x' character as
being a valid constituent character ("accumulates" in the above text).
The string is rejected as an invalid integer, yet the position of the
string stream afterwards is different from what the test expects, and we
therefore fail.
This patch therefore alters a number of tests to use a different invalid
character, 'v', that both the incremental algorithm (MSVC, libstdc++,
stlport) and the all-at-once algorithm (libc++) will recognize as not
being a valid constituent character and stop the parsing early, as
expected. You might think that specifying the base for numeric input as
std::dec would work, and it partially does, but reading floating-point
numbers still reads the 'x' characters (!).
