Since we can't know when a H264 frame really starts we instead group all packets together by timestamp when a frame seems to be complete (only in the case of H264).
BUG=webrtc:5514
Review-Url: https://codereview.webrtc.org/2675693002
Cr-Commit-Position: refs/heads/master@{#16419}
Proper error handling was missing, using VERIFY to crash in debug
builds, while release builds would ignore the error and leak the
attribute memory. The check of attribute type consistency was changed
to a RTC_DCHECK.
Also removes a large number of uses of the deprecated VERIFY macro.
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2665343002
Cr-Commit-Position: refs/heads/master@{#16413}
Adds ignore for all lint errors in Chromium code. Changes minimum SDK for
instrumentation tests to 16 from 14. Adds TargetApi annotations.
BUG=webrtc:6597
Review-Url: https://codereview.webrtc.org/2670473004
Cr-Commit-Position: refs/heads/master@{#16412}
It's currently not possible on Mac and iOS due to libtool. See webrtc:6418
for more info.
BUG=webrtc:6418
NOTRY=True
Review-Url: https://codereview.webrtc.org/2367313002
Cr-Commit-Position: refs/heads/master@{#16411}
Previously in the spec, there was a createDtmfSender method on
PeerConnection, but that's been replaced by a "dtmf" attribute
on RtpSender, which allows getting a DTMF sender without having
an audio track.
This also simplifies the code slightly, since tracks are now not
necessary for identification.
BUG=webrtc:4180
Review-Url: https://codereview.webrtc.org/2666853002
Cr-Commit-Position: refs/heads/master@{#16409}
BUG=webrtc:7097
TEST=Set "ptime=120", try WebRTC calls over custom build Chromium with and without Opus 120ms. Try both Chromium w <-> Chromium w and Chromium w <-> Chromium w/o
Review-Url: https://codereview.webrtc.org/2668633004
Cr-Commit-Position: refs/heads/master@{#16408}
Useful if bitrate probing is to be used with audio streams.
BUG=webrtc:7043
Review-Url: https://codereview.webrtc.org/2652893004
Cr-Commit-Position: refs/heads/master@{#16404}
Use AdaptDown/AdaptUp instead of ScaleDown/ScaleUp, since we may want to
adapt using other means than resolution.
Also, extend vie_encoder with unit test that actually uses frames scaled
to resolution as determined by VideoAdapter, since that seems to be the
default implementation.
BUG=webrtc:4172
Review-Url: https://codereview.webrtc.org/2652893015
Cr-Commit-Position: refs/heads/master@{#16402}
Note:
* PLR is calculated over all of the known packets.
* RPLR is calculated over all of the known packet *pairs*. That is, only over sets of subsequent packets where the reception status is known for both.
BUG=webrtc:7058
Review-Url: https://codereview.webrtc.org/2629883003
Cr-Commit-Position: refs/heads/master@{#16401}
(Or, in less flattering terms, fixing a performance issue introduced
a few months ago by me).
In GN release mode (is_debug = false), the version of the mixer code
before this CL generated code that multiplied each sample (tens of
thousands/second for each input stream) with a floating point number.
This number is almost always exactly 1.0f. The only situation when it's
not 1 is when an audio steam is added or removed.
For one input stream early return leads to a 30% improvement of audio
mixing time profiled on x86-64 under a release build (is_debug = false,
enable_profiling, enable_full_stack_frames_for_profiling) with 16kHz and no
APM limiter. There can be up to 3 streams.
BUG=chromium:687502
Review-Url: https://codereview.webrtc.org/2659423002
Cr-Commit-Position: refs/heads/master@{#16396}
Reason for revert:
due to failures on perf tests (not on perf stats, but fails running due to dcheck failures), see e.g., https://build.chromium.org/p/client.webrtc.perf/builders/Android32%20Tests%20(K%20Nexus5)
Original issue's description:
> Drop frames until specified bitrate is achieved.
>
> This CL fixes a regression introduced with the new quality scaler
> where the video would no longer start in a scaled mode. This CL adds
> code that compares incoming captured frames to the target bitrate,
> and if they are found to be too large, they are dropped and sinkWants
> set to a lower resolution. The number of dropped frames should be low
> (0-4 in most cases) and should not introduce a noticeable delay, or
> at least should be preferrable to having the first 2-4 seconds of video
> have very low quality.
>
> BUG=webrtc:6953
>
> Review-Url: https://codereview.webrtc.org/2630333002
> Cr-Commit-Position: refs/heads/master@{#16391}
> Committed: 83399caec5TBR=perkj@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,kthelgason@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6953
Review-Url: https://codereview.webrtc.org/2666303002
Cr-Commit-Position: refs/heads/master@{#16395}
Delete the calls from RtpStreamReceiver (for video) and
AudioReceiveStream.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2659563002
Cr-Commit-Position: refs/heads/master@{#16393}
This CL fixes a regression introduced with the new quality scaler
where the video would no longer start in a scaled mode. This CL adds
code that compares incoming captured frames to the target bitrate,
and if they are found to be too large, they are dropped and sinkWants
set to a lower resolution. The number of dropped frames should be low
(0-4 in most cases) and should not introduce a noticeable delay, or
at least should be preferrable to having the first 2-4 seconds of video
have very low quality.
BUG=webrtc:6953
Review-Url: https://codereview.webrtc.org/2630333002
Cr-Commit-Position: refs/heads/master@{#16391}
It appears that thread.cc was the only thing in the webrtc codebase that was
doing this incorrectly (platform_thread.cc, for instance, is ok).
BUG=chromium:687251
Review-Url: https://codereview.webrtc.org/2668693005
Cr-Commit-Position: refs/heads/master@{#16387}
If the frame buffer is cleared while the decoding thread is waiting to acquire
the lock in order to return the |next_frame_it| will be invalidated.
BUG=chromium:679306
Review-Url: https://codereview.webrtc.org/2668743002
Cr-Commit-Position: refs/heads/master@{#16384}
Reason for revert:
Relanding because breakage was not related to this change.
Original issue's description:
> Revert of Remove usage of deprecated g_type_init API (patchset #1 id:1 of https://codereview.webrtc.org/2660823003/ )
>
> Reason for revert:
> Reverting due to internal breakage. Will investigate and re-land
>
> Original issue's description:
> > Remove usage of deprecated g_type_init API
> >
> > BUG=webrtc:7024
> >
> > Review-Url: https://codereview.webrtc.org/2660823003
> > Cr-Commit-Position: refs/heads/master@{#16376}
> > Committed: b2caab7f60
>
> TBR=kjellander@webrtc.org,perkj@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:7024
>
> Review-Url: https://codereview.webrtc.org/2666103002
> Cr-Commit-Position: refs/heads/master@{#16379}
> Committed: d1685ab547TBR=kjellander@webrtc.org,perkj@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7024
Review-Url: https://codereview.webrtc.org/2666923002
Cr-Commit-Position: refs/heads/master@{#16380}
Reason for revert:
Reverting due to internal breakage. Will investigate and re-land
Original issue's description:
> Remove usage of deprecated g_type_init API
>
> BUG=webrtc:7024
>
> Review-Url: https://codereview.webrtc.org/2660823003
> Cr-Commit-Position: refs/heads/master@{#16376}
> Committed: b2caab7f60TBR=kjellander@webrtc.org,perkj@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7024
Review-Url: https://codereview.webrtc.org/2666103002
Cr-Commit-Position: refs/heads/master@{#16379}
This is the last CL in webrtc:7030, we have moved all the content
of the folder and we can get rid of it.
BUG=webrtc:7030
TBR=stefan@webrtc.org
NOTRY=True
Review-Url: https://codereview.webrtc.org/2661503004
Cr-Commit-Position: refs/heads/master@{#16369}
We read past the end of the initialized part of the buffer, seemingly
on purpose (no one knows the details of this code anymore). The right
thing to do is probably to zero that part of the buffer.
(The *right* right thing to would be to rewrite this so that it was
easier to see what data was supposed to be where when, but
priorities...)
BUG=chromium:683040
Review-Url: https://codereview.webrtc.org/2659383002
Cr-Commit-Position: refs/heads/master@{#16365}
This allows controllers to do internal logic upon the network metric changes, e.g., filtering.
BUG=webrtc:6303
Review-Url: https://codereview.webrtc.org/2643133003
Cr-Commit-Position: refs/heads/master@{#16363}
The main difference to the old computation is that the expected number of packets during an interval is now computed as the change in highest sequence number encountered, rather than the sequence number difference between the first and last packet in the interval.
BUG=webrtc:7046
Review-Url: https://codereview.webrtc.org/2656333002
Cr-Commit-Position: refs/heads/master@{#16361}
This should help pave the way for injectable audio codecs, since
external implementations need to be able to signal arbitrary fmtp
parameters.
BUG=webrtc:5806
Review-Url: https://codereview.webrtc.org/2661453003
Cr-Commit-Position: refs/heads/master@{#16360}
Also mark the render_time_ms getter function and the ntp timestamp
as deprecated.
BUG=webrtc:6977
Review-Url: https://codereview.webrtc.org/2633493002
Cr-Commit-Position: refs/heads/master@{#16354}
WebRTC's NO_RETURN definition conflicts with WebKit's. This can be avoided by
only defining it if not already defined.
BUG=webrtc:7054
Review-Url: https://codereview.webrtc.org/2657823004
Cr-Commit-Position: refs/heads/master@{#16353}
Since we can now have multiple H264 payload type, we need to move all of them to the beginning of the codec list, instead of greedily taking the first payload type that matches the preferred codec name.
BUG=webrtc:6738
Review-Url: https://codereview.webrtc.org/2658573009
Cr-Commit-Position: refs/heads/master@{#16349}
Video modules are added in reverse order to ensure that the padding order is the same as before, prioritizing high resolution streams.
BUG=webrtc:7043
Review-Url: https://codereview.webrtc.org/2655033002
Cr-Commit-Position: refs/heads/master@{#16329}
