If the encoder takes a long time to start up and emit frames the polling
interval of the quality scaler would get out of sync. This causes it to
sometimes make scaling decisions based on only a handful of frames.
This CL ensures that we have observed some minimum number of frames
before deciding to scale up or down.
BUG=b/36734056
Review-Url: https://codereview.webrtc.org/2789483002
Cr-Commit-Position: refs/heads/master@{#17523}
Reason for revert:
Suspect of breaking Chrome FYI bots.
See
https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/23065https://build.chromium.org/p/chromium.webrtc.fyi/builders/Android%20Builder
Example logs:
../../content/renderer/media/gpu/rtc_video_encoder_unittest.cc:18:46: fatal error: third_party/webrtc/video_encoder.h: No such file or directory
#include "third_party/webrtc/video_encoder.h"
^
Original issue's description:
> Move video_encoder.h and video_decoder.h to /api and create GN targets for them
>
> BUG=webrtc:5881
> # Because PRESUBMIT ignores LINT blacklist for moved files and these
> # headers have some not easy to resolve issues.
> NOPRESUBMIT=True
>
> Review-Url: https://codereview.webrtc.org/2780943003
> Cr-Commit-Position: refs/heads/master@{#17511}
> Committed: c42f540570TBR=solenberg@webrtc.org,sprang@webrtc.org,ilnik@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5881
Review-Url: https://codereview.webrtc.org/2794033002
Cr-Commit-Position: refs/heads/master@{#17514}
BUG=webrtc:5881
# Because PRESUBMIT ignores LINT blacklist for moved files and these
# headers have some not easy to resolve issues.
NOPRESUBMIT=True
Review-Url: https://codereview.webrtc.org/2780943003
Cr-Commit-Position: refs/heads/master@{#17511}
Finally we are able to remove this class entirely, along with the last
vestiges of it's use. I've also removed some legacy files that were only
used for windows XP support.
BUG=webrtc:7035
Review-Url: https://codereview.webrtc.org/2790533002
Cr-Commit-Position: refs/heads/master@{#17480}
These tests were disabled due to flakiness when running on the bots.
Hopefully synchronizing all operations that run on Task Queue will
fix this.
BUG=webrtc:6799
Review-Url: https://codereview.webrtc.org/2774643002
Cr-Commit-Position: refs/heads/master@{#17463}
Deletes left-over includes of trace.h and critical_section_wrapper.h.
BUG=webrtc:7035
Review-Url: https://codereview.webrtc.org/2784873002
Cr-Commit-Position: refs/heads/master@{#17460}
Improves current multi-threading performance (for the same number of threads) by:
5%-8% speedup for 2 threads, ~15% for 4 threads on Linux/Mac
with standalone libvpx.
~6% speedup on AppRTC on Linux/Mac with 4 threads.
BUG=None
Review-Url: https://codereview.webrtc.org/2776803002
Cr-Commit-Position: refs/heads/master@{#17432}
Decouples encode flags and calculates them the same for both default and
screencast temporal layers.
With this change encoders could start using TemporalReferences for
temporal-layers flags, but they can not be used by asynchronous encoders
(hardware encoders) yet.
Also removes 'timestamp' as a dead parameter to FrameEncoded().
BUG=chromium:702017, webrtc:7349
R=marpan@google.com, sprang@webrtc.org, marpan@webrtc.org
Review-Url: https://codereview.webrtc.org/2769263002 .
Cr-Commit-Position: refs/heads/master@{#17397}
Otherwise cpplint will trigger during presubmit for unrelated changes
in these files.
BUG=webrtc:5149
NOTRY=True
Review-Url: https://codereview.webrtc.org/2767393003
Cr-Commit-Position: refs/heads/master@{#17371}
Moves towards separating which layers may be referenced instead of
referencing libvpx flags directly. This will make strategies easier to
extract and usable from hardware encoders (RTCVideoEncoder, for
instance).
BUG=chromium:702017, webrtc:7349
R=brandtr@webrtc.org, marpan@webrtc.org. sprang@webrtc.org
Review-Url: https://codereview.webrtc.org/2747123005
Cr-Commit-Position: refs/heads/master@{#17349}
It depends on RTCP RPSI and SLI messages, which are being deleted.
TBR=stefan@webrtc.org # TODO comments added to common_types.h
BUG=webrtc:7338
Review-Url: https://codereview.webrtc.org/2753783002
Cr-Commit-Position: refs/heads/master@{#17314}
Reason for revert:
fix
Original issue's description:
> Revert of Save width/height of SPS nalus and restore them on the first packet of an IDR. (patchset #6 id:100001 of https://codereview.webrtc.org/2750633003/ )
>
> Reason for revert:
> Breaks build bots.
>
> Original issue's description:
> > Save width/height of SPS nalus and restore them on the first packet of an IDR.
> >
> > It appears that for some H264 streams that the width/height is not set for
> > the first packet of the IDR but in the packet containing the SPS/PPS.
> >
> > BUG=chromium:698088, webrtc:7139
> >
> > Review-Url: https://codereview.webrtc.org/2750633003
> > Cr-Commit-Position: refs/heads/master@{#17239}
> > Committed: 620d75f5be
>
> TBR=stefan@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:698088, webrtc:7139
>
> Review-Url: https://codereview.webrtc.org/2754543005
> Cr-Commit-Position: refs/heads/master@{#17250}
> Committed: be35a008efTBR=stefan@webrtc.org
BUG=chromium:698088, webrtc:7139
Review-Url: https://codereview.webrtc.org/2751843003
Cr-Commit-Position: refs/heads/master@{#17289}
This method isn't called and the value it represents, is made available
via the stats APIs.
BUG=none
Review-Url: https://codereview.webrtc.org/2760613002
Cr-Commit-Position: refs/heads/master@{#17287}
The implementation behind this method has been a noop for a long time.
BUG=none
Review-Url: https://codereview.webrtc.org/2757843002
Cr-Commit-Position: refs/heads/master@{#17286}
Reason for revert:
Breaks build bots.
Original issue's description:
> Save width/height of SPS nalus and restore them on the first packet of an IDR.
>
> It appears that for some H264 streams that the width/height is not set for
> the first packet of the IDR but in the packet containing the SPS/PPS.
>
> BUG=chromium:698088, webrtc:7139
>
> Review-Url: https://codereview.webrtc.org/2750633003
> Cr-Commit-Position: refs/heads/master@{#17239}
> Committed: 620d75f5beTBR=stefan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:698088, webrtc:7139
Review-Url: https://codereview.webrtc.org/2754543005
Cr-Commit-Position: refs/heads/master@{#17250}
It appears that for some H264 streams that the width/height is not set for
the first packet of the IDR but in the packet containing the SPS/PPS.
BUG=chromium:698088, webrtc:7139
Review-Url: https://codereview.webrtc.org/2750633003
Cr-Commit-Position: refs/heads/master@{#17239}
The getters are not used and the implementation cannot be guaranteed
to return a correct value except when called synchronously from
the decoding thread while decoding.
The methods as is imply that the implementation needs to offer some
sort of synchronization, and that's not desirable.
BUG=webrtc:7328
R=stefan@webrtc.org
Review-Url: https://codereview.webrtc.org/2741853008 .
Cr-Commit-Position: refs/heads/master@{#17233}
* The _receiveCallback member of VCMDecodedFrameCallback does actually not require locking now that the threading model is slightly clearer. Documentation and checks have been added.
* UserReceiveCallback() never returns null and must always be called on the decoder thread. Checks have been added and the two test suites that were failing to set this callback, have been fixed and a new mock class added. (looks like sakal@ may have hit some issues with flaky tests there).
* Changed VcmPayloadSink to use move semantics which I suspect was the intention at the time the code was written (when we didn't have move semantics).
* Added thread checker to a couple of classes and started adding thread checks for known behavior. There's more to be done there.
* Remove the |_decoder| member variable in VideoReceiver. It is not needed and as it could be used, left us open to a race.
* TODOs added for places where we can reduce locking. I suspect that we can get away with not needing a lock around _codecDataBase in VideoReceiver once we've got a clear picture of the threading model and ensured that all adhere to it.
BUG=webrtc:7328
Review-Url: https://codereview.webrtc.org/2744013002
Cr-Commit-Position: refs/heads/master@{#17226}
Since HW codecs are not as well-behaved as SW codecs, we need a
way to disable the EXPECT_EQ's in the VideoProcessor integration tests
for the former. This CL introduces such an ability.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/2710913004
Cr-Commit-Position: refs/heads/master@{#17166}
Prior to this CL, the encoding/decoding in the VideoProcessor integration
tests were run "online", in the sense that rate allocations could be
changed in between frames. This is useful for evaluating the rate control
of SW codecs, which is one of the reasons for the existence of these
integration tests in the first place.
This CL adds a batch mode, in which the tests are run "offline". The two
main differences to the original mode are: 1) rate control metrics are
calculated after the fact, and 2) no rate allocation changes are allowed
during the test. Difference 1) is the reason for this CL, as HW codecs
that are pipelining will not work well when rate control metrics are
calculated right after a frame has been sent for encode. Difference 2)
is a side effect of the introduction of the batch mode. If we want to
be able to support online rate allocation for pipelining HW codecs in
the future, this can be introduced by adding a delay between encoding
and rate allocation. This was not deemed necessary at this point in time,
and hence this CL does not do that.
The batch mode is only intended to be used for manual experimentation
on devices with HW codecs, and the integration tests running on the
bots should thus NOT use batch mode.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/2707023008
Cr-Commit-Position: refs/heads/master@{#17164}
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}
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:
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}
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}
