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}
