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}
I cannot even imagine this change is useful. But it consistently reduces average
capture time by 0.375% (4.07 -> 4.055), and average encode time by 0.313%
(8.042 -> 8.016) without other impacts. Considering this is a one-line change,
it's worthy to be added.
BUG=679523
Review-Url: https://codereview.webrtc.org/2743233002
Cr-Commit-Position: refs/heads/master@{#17235}
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}
different sample rate frequency.
BUG=webrtc:7327
Problems before the fix:
1. NetEqImpl::timestamp_ is inconsistent. Initially it is set to
the original RTP timestamp, but later gets updated with the
scaled timestamp.
2. NetEqImpl::InsertPacketInternal::main_timestamp is set with
the original RTP timestamp, but later gets compared with the
NetEqImpl::timestamp_ which may or may not be with the same
sample rate frequency and this results in major problems.
3. IncreaseEndTimestamp(main_timestamp - timestamp_) will be
incorrect when SSRC is changed and not the first packet.
4. delay_manager_->Update() may not be always invoked, since
the (main_timestamp - timestamp_) >= 0 will not be true when
the previous scaled timestamp_ is bigger than the main_timestamp
(current RTP timestamp) even if the current RTP timestamp is
bigger than the previous RTP timestamp.
5. delay_manager_->Update() parameters are main_timestamp
which increments with the RTP sample rate frequency and the
fs_hz_ which is the decoder sample rate frequency. When these
two frequencies are different as is the case with g.722, the
DelayManager::Update() will misfire and calculate incorrect
packet_len_ms and inter-arrival time (IAT) as a result. This
in effect will cause neteq to enter kPreemptiveExpand operation
and will keep expanding the jitter buffer even if the RTP packets
arrive with no jitter at all.
The fix corrects all these problems by making sure the
main_timestamp and the timestamp_ are always set with the scaled
timestamp and increment with the decoder sample rate frequency.
Review-Url: https://codereview.webrtc.org/2743063005
Cr-Commit-Position: refs/heads/master@{#17232}
* 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}
The only non-const operation was a one-time initialization of a member only used in this function. I've moved it to the ctor.
BUG=webrtc:5298
Review-Url: https://codereview.webrtc.org/2741733002
Cr-Commit-Position: refs/heads/master@{#17223}
A DCHECK added in a recent bugfix, which asserted that a signed 64->32
bit cast did not overflow, has been found to not always pass. We fix
this by saturating.
BUG=chromium:693868
Review-Url: https://codereview.webrtc.org/2746903002
Cr-Commit-Position: refs/heads/master@{#17209}
This was a trivial delegation wrapper, with only a single use.
BUG=None
Review-Url: https://codereview.webrtc.org/2741413003
Cr-Commit-Position: refs/heads/master@{#17205}
Previously we grab a run loop source and add a source with mode
kCFRunLoopDefaultMode. With this mode, it won't callback when context menu popup
(which needs the NSEventTrackingRunLoopMode), then screen capture can't get
refreshed frame with context menu until the context menu is gone.
The fix is to use kCFRunLoopComonModes, which includes default,modal and event
tracking modes by default.
BUG=chromium:697780
Review-Url: https://codereview.webrtc.org/2732393003
Cr-Commit-Position: refs/heads/master@{#17171}
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}
DisplayStream refresh rects are in display coordinates. When the whole screen is
being captured, the coordinates passed to the ScreenCapturerHelper need to be in
screen coordinates. This CL translates display coordinates to screen
coordinates for whole screen capture.
BUG=chromium:699672
Review-Url: https://codereview.webrtc.org/2740823002
Cr-Commit-Position: refs/heads/master@{#17153}
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}
