In an attempt to help Kenny locate the evil Dr. Deo.
BUG=webrtc:7307
Review-Url: https://codereview.webrtc.org/2732193006
Cr-Commit-Position: refs/heads/master@{#17135}
1. GetTransportFeedbackVector will now return a vector which also explicitly states lost packets.
2. The returned vector is unsorted (uses default order - by sequence number). It's up to the users to sort otherwise, if they need a different order.
BUG=None
Review-Url: https://codereview.webrtc.org/2707383006
Cr-Commit-Position: refs/heads/master@{#17114}
Previusly errors from XServerPixelBuffer::CaptureRect() were not always
handled, which results in a black frame returned from the capturer
instead of an error.
BUG=webrtc:7305
Review-Url: https://codereview.webrtc.org/2738513005
Cr-Commit-Position: refs/heads/master@{#17101}
CurrentNtp return time by taking two output parameters by reference
(also breaks style guide)
CurrentNtpTime treat ntp time as single entity and returns it using NtpTime structure.
(making interface clearer)
BUG=None
Review-Url: https://codereview.webrtc.org/2733823002
Cr-Commit-Position: refs/heads/master@{#17088}
This CL removes most of the global frame state in VideoProcessor and
replaces that with a vector of frame states. This is useful for pipelining
codecs, where the encoded/decoded frame may not be immediately outputted
after it has been sent to the codec.
The callers (VideoProcessorIntegrationTest and video_quality_measurement)
still call VideoProcessor in a sequential fashion. A follow-up CL will be
submitted that enables batch mode in VideoProcessorIntegrationTest.
Note that VideoProcessor is still not thread safe. Currently, we can run
fairly well on Android due to the synchronicity of our MediaCodec wrapper,
but we still cannot run on iOS due to async issues. This will be fixed in
the future.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/2711133002
Cr-Commit-Position: refs/heads/master@{#17084}
Reason for revert:
The issue is now hopefully fixed.
Original issue's description:
> Revert of Add QP for FFmpeg H264 decoder. (patchset #4 id:200001 of https://codereview.webrtc.org/2649133007/ )
>
> Reason for revert:
> Let's revert this while we investigate a problem in H264 bitstream parser.
>
> Original issue's description:
> > Add QP for FFmpeg H264 decoder.
> >
> > BUG=webrtc:6541
> >
> > Review-Url: https://codereview.webrtc.org/2649133007
> > Cr-Commit-Position: refs/heads/master@{#16942}
> > Committed: 879f4f6c31
>
> TBR=sprang@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:6541, chromium:697795
>
> Review-Url: https://codereview.webrtc.org/2726973003
> Cr-Commit-Position: refs/heads/master@{#16974}
> Committed: 4c6df8893eTBR=sprang@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6541, chromium:697795
Review-Url: https://codereview.webrtc.org/2735733002
Cr-Commit-Position: refs/heads/master@{#17061}
DXGI capturer highly depends on video adapter and its driver, as well as Windows
itself. I recently found it cannot work on my virtualbox instance any more,
which indicates it may not work well on some specific systems. What worse is,
the APIs do not return a failure in such case.
So this change adds a BlankDetectorDesktopCapturerWrapper, which samples several
pixels in the frame returned by a DesktopCapturer implementation. If all the
pixels selected are blank, this wrapper returns a failure. A typical usage is to
combine BlankDetectorDesktopCapturerWrapper with FallbackDesktopCapturerWrapper,
and use GDI capturer in case of failure.
Usually less than 10000 pixels are checked, so the
BlankDetectorDesktopCapturerWrapper should not significant impact the capturer
performance.
This change is expected to resolve bug 682112 in another dimension.
BUG=682112
Review-Url: https://codereview.webrtc.org/2709523003
Cr-Original-Commit-Position: refs/heads/master@{#16984}
Committed: c4e9d210b3
Review-Url: https://codereview.webrtc.org/2709523003
Cr-Commit-Position: refs/heads/master@{#17024}
It generates json files to be used as APM configuration presets.
Useful to avoid manual editing of such files.
BUG=webrtc:7218
NOTRY=True
Review-Url: https://codereview.webrtc.org/2719853006
Cr-Commit-Position: refs/heads/master@{#17013}
New Opus version starts to support 120ms frame lengths. AudioEncoderOpusTest had an unnecessary check on the available frame lengths.
It is removed in this CL.
BUG=b/35415318
Review-Url: https://codereview.webrtc.org/2731583003
Cr-Commit-Position: refs/heads/master@{#17011}
Execution flag added to the .py and .sh scripts.
BUILD.gn files adapted (see :lib), APM config files moved.
BUG=webrtc:7218
NOTRY=True
Review-Url: https://codereview.webrtc.org/2715943002
Cr-Commit-Position: refs/heads/master@{#17007}
In short, what I did was to
* Remove acm_common_defs.h (the stuff in it was used only by
acm_codec_database.cc).
* Move audio_coding_module_typedefs.h to a new build target.
* Move the NetEqDecoder enum (and the associated
NetEqDecoderToSdpAudioFormat function) to a new file in a new
build target.
BUG=webrtc:7243, webrtc:7244
Review-Url: https://codereview.webrtc.org/2723253005
Cr-Commit-Position: refs/heads/master@{#17005}
A fuzzer run caused the operands of this multiplication to be 512 and
5000000, resulting in a product about 20% too large for int32_t. So
change this from a 16x32->32 to a 16x32->64 multiplication. Since we
right shift by 2 at the end, the end result will still fit in int32_t.
I also had to fix a few follow-on add/sub overflows found by the same
fuzzer input once the multiplication was fixed. I chose to saturate
these, since it wasn't just an intermediate value that overflowed.
BUG=chromium:693868
Review-Url: https://codereview.webrtc.org/2729573002
Cr-Commit-Position: refs/heads/master@{#17003}
This makes a few things a lot clearer when looking at perf trace data:
* What module instances (where they were created) are called
* On what thread
* How frequently
* For how long
ProcessThread will be replaced by TaskQueue moving forward and this is a step towards understanding the behavior of the affected code.
BUG=webrtc:7219
Review-Url: https://codereview.webrtc.org/2729053002
Cr-Commit-Position: refs/heads/master@{#16998}
Reason for revert:
Misses deps for RTC_HISTOGRAM in Chrome.
email sent separately.
Also see https://codereview.chromium.org/2725143004/.
Original issue's description:
> BlankDetectorDesktopCapturerWrapper to detect a blank DesktopFrame
>
> DXGI capturer highly depends on video adapter and its driver, as well as Windows
> itself. I recently found it cannot work on my virtualbox instance any more,
> which indicates it may not work well on some specific systems. What worse is,
> the APIs do not return a failure in such case.
>
> So this change adds a BlankDetectorDesktopCapturerWrapper, which samples several
> pixels in the frame returned by a DesktopCapturer implementation. If all the
> pixels selected are blank, this wrapper returns a failure. A typical usage is to
> combine BlankDetectorDesktopCapturerWrapper with FallbackDesktopCapturerWrapper,
> and use GDI capturer in case of failure.
>
> Usually less than 500 pixels are checked, so the
> BlankDetectorDesktopCapturerWrapper should not impact the capturer performance.
>
> This change is expected to resolve bug 682112 in another dimension.
>
> BUG=682112
>
> Review-Url: https://codereview.webrtc.org/2709523003
> Cr-Commit-Position: refs/heads/master@{#16984}
> Committed: c4e9d210b3TBR=sergeyu@chromium.org,zijiehe@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=682112
Review-Url: https://codereview.webrtc.org/2726983005
Cr-Commit-Position: refs/heads/master@{#16993}
DXGI capturer highly depends on video adapter and its driver, as well as Windows
itself. I recently found it cannot work on my virtualbox instance any more,
which indicates it may not work well on some specific systems. What worse is,
the APIs do not return a failure in such case.
So this change adds a BlankDetectorDesktopCapturerWrapper, which samples several
pixels in the frame returned by a DesktopCapturer implementation. If all the
pixels selected are blank, this wrapper returns a failure. A typical usage is to
combine BlankDetectorDesktopCapturerWrapper with FallbackDesktopCapturerWrapper,
and use GDI capturer in case of failure.
Usually less than 500 pixels are checked, so the
BlankDetectorDesktopCapturerWrapper should not impact the capturer performance.
This change is expected to resolve bug 682112 in another dimension.
BUG=682112
Review-Url: https://codereview.webrtc.org/2709523003
Cr-Commit-Position: refs/heads/master@{#16984}
Reason for revert:
Let's revert this while we investigate a problem in H264 bitstream parser.
Original issue's description:
> Add QP for FFmpeg H264 decoder.
>
> BUG=webrtc:6541
>
> Review-Url: https://codereview.webrtc.org/2649133007
> Cr-Commit-Position: refs/heads/master@{#16942}
> Committed: 879f4f6c31TBR=sprang@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6541, chromium:697795
Review-Url: https://codereview.webrtc.org/2726973003
Cr-Commit-Position: refs/heads/master@{#16974}
It's the faster, less strict cousin of checked_cast.
BUG=none
Review-Url: https://codereview.webrtc.org/2714063002
Cr-Commit-Position: refs/heads/master@{#16958}
Following files define the same classes
- modules/video_coding/codecs/interface/video_codec_interface.h
- modules/video_coding/include/video_codec_interface.h
The first one is deprecated. As long as it is not removed, both files
should provide consistent class declarations. Otherwise any donwstream
project that includes its own codecs could experience memory
corruption issues.
Before this CL member declarations and ctor definition for
webrtc::CodecSpecificInfo diverged between both header files.
BUG=webrtc:7280
Review-Url: https://codereview.webrtc.org/2727633002
Cr-Commit-Position: refs/heads/master@{#16944}
Use default temporal layers instead of the RealtimeTemporalLayers one.
When using low fps, having a single stream with much higher bitrate than
the lower simulcast stream causes poor rampup behavior.
Tested manually.
BUG=webrtc:4172
Review-Url: https://codereview.webrtc.org/2723983002
Cr-Commit-Position: refs/heads/master@{#16934}
