The video_capture module includes remnants of support for cameras
producing encoded frames. However, this seems to be unused, and is
explicitly not supported by VideoCaptureImpl::IncomingFrame.
BUG=None
Review-Url: https://codereview.webrtc.org/2668693008
Cr-Commit-Position: refs/heads/master@{#16732}
The first unsignalled SSRC creates a default receive channel.
Any unsignalled SSRC changes after that replace the default SSRC.
Add unit tests for changing unsignalled SSRCs.
BUG=webrtc:5208
Review-Url: https://codereview.webrtc.org/2692993009
Cr-Commit-Position: refs/heads/master@{#16682}
This feature is unused. We can then also delete the header file
video_capture_delay.h.
BUG=None
Review-Url: https://codereview.webrtc.org/2665113006
Cr-Commit-Position: refs/heads/master@{#16666}
The codecs expected by HasCorrectCodecs now depends which codecs were
enabled by build flags.
SendSideBweWithOverheadTest.MinAndMaxBitrate now expects different
values for min bitrate depending on if we support 120 ms frames for
Opus.
BUG=b/35415435
Review-Url: https://codereview.webrtc.org/2691343008
Cr-Commit-Position: refs/heads/master@{#16643}
Makes sure video decoder software fallback handles InitDecode()
failures, and properly releases the pointer after ::Release() so that
another decode failure will properly reinitialize the decoder.
Also makes sure to not call Decode() without a previous InitDecode()
succeeding.
BUG=webrtc:7154
R=noahric@chromium.org, sophiechang@chromium.org
Review-Url: https://codereview.webrtc.org/2690183004 .
Cr-Commit-Position: refs/heads/master@{#16594}
This helps show where ownership is transfered between objects.
Specifically, this CL wraps cricket::VideoCapturer, MediaEngineInterface
and DataEngineInterface in unique_ptr.
BUG=None
TBR=magjed@webrtc.org
Review-Url: https://codereview.webrtc.org/2685093002
Cr-Commit-Position: refs/heads/master@{#16548}
The current method with max_pixel_count and max_pixel_count_step_up,
where only one should be used at a time and this first signaling an
inclusive upper bound and other other an exclusive lower bound, makes
for a lot of confusion.
I've updated this to have a desired target and a maximum instead. The
source should select a resolution as close to the target as possible,
but no higher than the maximum.
I intend to also add similar frame rate settings in an upcoming cl.
BUG=webrtc:4172,webrtc:6850
Review-Url: https://codereview.webrtc.org/2672793002
Cr-Commit-Position: refs/heads/master@{#16533}
These methods relate to typing detection but are not used anymore. Typing detection is enabled through the VoiceDetection module on the APM.
BUG=webrtc:4690
Review-Url: https://codereview.webrtc.org/2684933008
Cr-Commit-Position: refs/heads/master@{#16527}
It's currently only used to ensure transport-cc is enabled for the format in question. It might be used to toggle more things in future.
BUG=webrtc:5806
Review-Url: https://codereview.webrtc.org/2669583002
Cr-Commit-Position: refs/heads/master@{#16514}
Replaced by assigning value to a local variable, followed by a DCHECK.
Also deletes dead test code under the always false TEST_DIGEST define.
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2623473004
Cr-Commit-Position: refs/heads/master@{#16476}
This is not implemented yet in any of the decoders.
BUG=webrtc:6541
Review-Url: https://codereview.webrtc.org/2649133005
Cr-Commit-Position: refs/heads/master@{#16475}
Reason for revert:
Perf test broke as it made assumptions that quality scaling was turned off. This turns out not to be the case. Fixed by turning quality scaling off for the tests.
Original issue's description:
> Revert of Drop frames until specified bitrate is achieved. (patchset #12 id:240001 of https://codereview.webrtc.org/2630333002/ )
>
> 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: 83399caec5
>
> TBR=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}
> Committed: 35fc2aa82fTBR=perkj@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,minyue@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6953
Review-Url: https://codereview.webrtc.org/2675223002
Cr-Commit-Position: refs/heads/master@{#16473}
These structs will be used for ORTC objects (and their WebRTC
equivalents).
This CL also introduces some minor changes to the existing implemented
structs:
- max_bitrate_bps uses rtc::Optional instead of "-1 means unset"
- "mime_type" turned into "name"/"kind" (which can be used to form the
MIME type string, if needed).
- clock_rate and channels changed to rtc::Optional, since they will
need to be for RtpSender.send().
- Renamed "channels" to "num_channels" (the ORTC name, which I prefer).
BUG=webrtc:7013, webrtc:7112
Review-Url: https://codereview.webrtc.org/2651883010
Cr-Commit-Position: refs/heads/master@{#16437}
Fix: Order of assignments is now correct, after being incorrect
due to an incorrect merge between
https://codereview.webrtc.org/2617373002/ and
https://codereview.webrtc.org/2589713003.
Improvement: Set parameters in more places, allowing for
correct reconfiguration. Add TODOs to point of minor issues
with current configuration.
TESTED=By locally patching an application using this code.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2660403004
Cr-Commit-Position: refs/heads/master@{#16431}
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}
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}
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}
This CL introduces a way for the VideoReceiveStreams to check whether
they are protected by any FlexfecReceiveStreams. This is done in the
VideoReceiveStream::Start() method, which then propagates this information
down to the jitter buffer adaptation logic.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2649973005
Cr-Commit-Position: refs/heads/master@{#16328}
Reason for revert:
Downstream project relied on changed struct.
Transition made possible by https://codereview.webrtc.org/2655243006/.
Original issue's description:
> Revert of Make RTX pt/apt reconfigurable by calling WebRtcVideoChannel2::SetRecvParameters. (patchset #7 id:160001 of https://codereview.webrtc.org/2646073004/ )
>
> Reason for revert:
> Breaks internal downstream project.
>
> Original issue's description:
> > Make RTX pt/apt reconfigurable by calling WebRtcVideoChannel2::SetRecvParameters.
> >
> > Prior to this CL, received RTX (associated) payload types were only configured
> > when WebRtcVideoChannel2::AddRecvStream was called. In the same method, the RTX
> > SSRC was set up.
> >
> > After this CL, the RTX (associated) payload types are set in
> > WebRtcVideoChannel2::SetRecvParameters, which is the appropriate place to set
> > them. The RTX SSRC is still set in WebRtcVideoChannel2::AddRecvStream, since
> > that is the code path that sets other SSRCs.
> >
> > As part of this fix, the VideoReceiveStream::Config::Rtp struct is changed.
> > We remove the possibility for each video payload type to have an associated
> > specific RTX SSRC. Although the config previously allowed for this, all payload
> > types always had the same RTX SSRC set, and the underlying RtpPayloadRegistry
> > did not support multiple SSRCs. This change to the config struct should thus not
> > have any functional impact. The change does however affect the RtcEventLog, since
> > that is used for storing the VideoReceiveStream::Configs. For simplicity,
> > this CL does not change the event log proto definitions, instead duplicating
> > the serialized RTX SSRCs such that they fit in the existing proto definition.
> >
> > BUG=webrtc:7011
> >
> > Review-Url: https://codereview.webrtc.org/2646073004
> > Cr-Commit-Position: refs/heads/master@{#16302}
> > Committed: fe2bef39cd
>
> TBR=stefan@webrtc.org,magjed@webrtc.org,terelius@webrtc.org,brandtr@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:7011
>
> Review-Url: https://codereview.webrtc.org/2649323010
> Cr-Commit-Position: refs/heads/master@{#16307}
> Committed: e4974953ceTBR=stefan@webrtc.org,magjed@webrtc.org,terelius@webrtc.org,kjellander@webrtc.org,kjellander@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
# NOTREECHECKS=true
# NOTRY=true
BUG=webrtc:7011
Review-Url: https://codereview.webrtc.org/2654163006
Cr-Commit-Position: refs/heads/master@{#16322}
Reason for revert:
Breaks internal downstream project.
Original issue's description:
> Make RTX pt/apt reconfigurable by calling WebRtcVideoChannel2::SetRecvParameters.
>
> Prior to this CL, received RTX (associated) payload types were only configured
> when WebRtcVideoChannel2::AddRecvStream was called. In the same method, the RTX
> SSRC was set up.
>
> After this CL, the RTX (associated) payload types are set in
> WebRtcVideoChannel2::SetRecvParameters, which is the appropriate place to set
> them. The RTX SSRC is still set in WebRtcVideoChannel2::AddRecvStream, since
> that is the code path that sets other SSRCs.
>
> As part of this fix, the VideoReceiveStream::Config::Rtp struct is changed.
> We remove the possibility for each video payload type to have an associated
> specific RTX SSRC. Although the config previously allowed for this, all payload
> types always had the same RTX SSRC set, and the underlying RtpPayloadRegistry
> did not support multiple SSRCs. This change to the config struct should thus not
> have any functional impact. The change does however affect the RtcEventLog, since
> that is used for storing the VideoReceiveStream::Configs. For simplicity,
> this CL does not change the event log proto definitions, instead duplicating
> the serialized RTX SSRCs such that they fit in the existing proto definition.
>
> BUG=webrtc:7011
>
> Review-Url: https://codereview.webrtc.org/2646073004
> Cr-Commit-Position: refs/heads/master@{#16302}
> Committed: fe2bef39cdTBR=stefan@webrtc.org,magjed@webrtc.org,terelius@webrtc.org,brandtr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7011
Review-Url: https://codereview.webrtc.org/2649323010
Cr-Commit-Position: refs/heads/master@{#16307}
Prior to this CL, received RTX (associated) payload types were only configured
when WebRtcVideoChannel2::AddRecvStream was called. In the same method, the RTX
SSRC was set up.
After this CL, the RTX (associated) payload types are set in
WebRtcVideoChannel2::SetRecvParameters, which is the appropriate place to set
them. The RTX SSRC is still set in WebRtcVideoChannel2::AddRecvStream, since
that is the code path that sets other SSRCs.
As part of this fix, the VideoReceiveStream::Config::Rtp struct is changed.
We remove the possibility for each video payload type to have an associated
specific RTX SSRC. Although the config previously allowed for this, all payload
types always had the same RTX SSRC set, and the underlying RtpPayloadRegistry
did not support multiple SSRCs. This change to the config struct should thus not
have any functional impact. The change does however affect the RtcEventLog, since
that is used for storing the VideoReceiveStream::Configs. For simplicity,
this CL does not change the event log proto definitions, instead duplicating
the serialized RTX SSRCs such that they fit in the existing proto definition.
BUG=webrtc:7011
Review-Url: https://codereview.webrtc.org/2646073004
Cr-Commit-Position: refs/heads/master@{#16302}
The original CL was reverted because of a bug discovered by the
chromium bots. Description of that CL:
> Review-Url: https://codereview.webrtc.org/2636443002
> Cr-Commit-Position: refs/heads/master@{#16135}
> Committed: a28e971e3b
The first patch set of this CL is the same as r16135.
Subsequence patch sets are the fixes applied.
Some new test cases have been added, which reveal a few more bugs that
have also been fixed.
BUG=webrtc:4172
Review-Url: https://codereview.webrtc.org/2641133002
Cr-Commit-Position: refs/heads/master@{#16299}
Bulk of the changes were done using
git grep -l '#include "webrtc/base/common.h"' | \
xargs sed -i '\,^#include.*webrtc/base/common\.h,d'
followed by adding back the include in the few places where it is
still needed, and in one case (pseudotcp.cc) instead deleting its use
of RTC_UNUSED.
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2644103002
Cr-Commit-Position: refs/heads/master@{#16263}
... As opposed to DtlsTransportInternal.
The code is suboptimal right now, storing two pointers to the different
interfaces. This will all be cleaned up when we have an "RtpTransport"
abstraction that BaseChannel can use.
This CL also cleans up the "fake transport" classes a bit, and gives
them their own header files.
BUG=None
Review-Url: https://codereview.webrtc.org/2648233003
Cr-Commit-Position: refs/heads/master@{#16258}
webrtcvoiceengine.cc ensured that if the bitrate set for ISAC was 0,
it was changed to -1 so that the codec could manage the bitrate
itself.
webrtcsdp.cc ensured that if the bitrate set for ISAC was 0, it was
explicitly set to default values to avoid the codec's built in bitrate
management.
Eventually, there'll be no codec specific code like this in these
layers. This is one step towards that goal.
BUG=webrtc:5806
Review-Url: https://codereview.webrtc.org/2642923003
Cr-Commit-Position: refs/heads/master@{#16220}
Without this, every time WebRtcVideoEngine2 calls supported_codecs(),
the codec list grows.
BUG=webrtc:7020
Review-Url: https://codereview.webrtc.org/2639423006
Cr-Commit-Position: refs/heads/master@{#16178}
This CL adds an RTP module to FlexfecReceiveStreamImpl, and wires it up
to send RTCP RRs. It further makes some methods take const refs instead
of values, to make it more clear where packet copies are made. This
change reduces the number of copies by one, for the case when media
packets are added to the FlexFEC receiver.
The end-to-end test is modified to check for RTCP RRs being sent.
Part of this modification involves some indentation changes, and the
diff thus looks bigger than it logically is.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2625633003
Cr-Commit-Position: refs/heads/master@{#16106}
The existence of FlexfecConfig is due to a naive design. Now when it
is not used on the receiving side (see https://codereview.webrtc.org/2542413002),
it is time to remove it from the sending side as well.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2621573002
Cr-Commit-Position: refs/heads/master@{#16097}
