This reverts commit 815522782a92e168b80edc760b2e53e4d0e4ea0d.
Reason for revert: Breaks a downstream project.
The internal investigation is still in-progress.
Original change's description:
> sdp: add rtcp-fb:* lines for common feedback
>
> which potentially allows switching to that pattern in the future.
> Video FEC mechanisms (ulpfec, flexfec-03, RED) that currently
> do not have any feedback parameters but will still be considered "common" and feedback may be sent for them.
>
> For audio this causes rtcp-feedback to be sent for G711 and G722 if negotiated.
>
> BUG=webrtc:14802
>
> Change-Id: I54852d39e176f918d4b36462526ceb40617b8fbe
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290702
> Commit-Queue: Philipp Hancke <phancke@microsoft.com>
> Reviewed-by: Per Kjellander <perkj@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39224}
Bug: webrtc:14802
Change-Id: I4dc3c0c53ad1bc06050c0d73b088303312ac58b2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293020
Owners-Override: Jeremy Leconte <jleconte@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#39296}
Call operators do not improve code clarity, and usage was moderate.
Bug: None
Change-Id: I8d86bd7d435ce88e99f4abee8ab95a336d47dc22
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292960
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39294}
When I run these tests locally, Gmock complained about the incorrect
mock function call and caused the test to fail.
Bug: None
Change-Id: I37c9168650471b171a5d7f7b4e3a4c6c6225d618
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292920
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Cr-Commit-Position: refs/heads/main@{#39292}
Also move the frame_transformer_factory_unittest build target into the
if(rtc_include_tests) block, so it's not compiled without the mock.
Bug: chromium:1414370
Change-Id: I12653b173b419ec20bfad904e24a4d965e7e7830
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292863
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Auto-Submit: Tony Herre <herre@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39288}
The elements of the fps_allocation vector are fractions of the maximum
frame rate. Each fraction is represented as an 8-bit unsigned integer,
where 0 = 0% and 255 = 100%.
The original code (added in
https://webrtc-review.googlesource.com/c/src/+/201384) sets the elements
of the fps_allocation vector to frame rates rather than frame rate
fractions. Perhaps fps_allocation could be renamed to avoid this kind of
confusion.
modules_unittests --gtest_filter=LibaomAv1EncoderTest.*
Tested:
Change-Id: Icd050da3b3c2cff31913c3430f7b6b6e9829b9fa
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292784
Commit-Queue: Wan-Teh Chang <wtc@google.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39286}
During code review, kFullFramerate was renamed kMaxFramerateFraction but
the uses of kFullFramerate in a comment were not updated. See
https://webrtc-review.googlesource.com/c/src/+/117900/3..4
Change-Id: I6b3c06b4c5b302e8ba40bde4ba722b94aab191eb
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292801
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Wan-Teh Chang <wtc@google.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39285}
This allows MediaChannel to know whether it's being used
for sending, receiving, or both. This is a preparatory CL
for landing the split of MediaChannel usage into sending and
receiving objects.
Bug: webrtc:13931
Change-Id: If518c8b53d5256771200a42e1b5f2b3321d26d8c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292860
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39283}
Today the default 3 encodings path for VP9 is to trigger legacy SVC,
which is tested by "SendingThreeEncodings_VP9_LegacySVC".
This CL adds another test that does not rely on the default
`scalability_mode` and instead explicitly asks for simulcast (3 x L1T3).
When VP9 simulcast is supported (https://crbug.com/webrtc/14884), this
API pattern will allow the app to ask for standard behavior while the
default path still exists for backwards-compatibility.
Because we don't support VP9 simulcast yet, this test still triggers
legacy fallback which is wrong so this test mostly serves to document
current behavior, but see Patch Set 1 for side-by-side comparison of
what we want to EXPECT and what we currently EXPECT.
In the meantime, this CL helps exercise code paths that are possible
to trigger as of M111. The TODOs will be addressed as part of
https://crbug.com/webrtc/14884.
Bug: webrtc:14884
Change-Id: Id901eea8f399223afd5a1731a3323e5134686134
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292720
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39281}
When asking for 3 encodings of VP9, which the spec says is simulcast,
you don't get simulcast but instead you get one RTP stream sending SVC.
This results in a single "outbound-rtp" but GetParameters() still says
3 encodings are used. We know we get SVC because the scalabilityMode
from getStats() says "L3T3_KEY".
In a future CL we will add simulcast VP9 support when
`scalability_mode` is specified in the API but we'll need to continue
to support the legacy SVC code paths until that has been deprecated
and removed (https://crbug.com/webrtc/14889).
Bug: webrtc:14884
Change-Id: Ibeca44b7a0b93097ad9525e45ebbca3b7663c686
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292581
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39278}
If we are notified of the destruction of the window before a
CaptureFrame call can fail, then we may end up attempting to destroy the
underlying WGC object inside it's own event handler. This can be
problematic, as the class itself may want to run other code. Instead,
we just unsubscribe and signal that any future CaptureFrame calls should
reject.
This also removes setting "is_capture_started_=false" in the item closed
handler, as all that served to do is cause the WgcCapturerWin code to
attempt to restart the capturer, and somewhat muddies up our metrics.
Bug: chromium:1413005
Change-Id: Ibccb7a2e7ce531ba80b4b331b9bc2cda0ff75f4e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292762
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39275}
Explicitly configure VP8 and verify the codec and scalability mode makes
sense. In preparation for doing the same with VP9 when VP9 simulcast is
supported.
Bug: webrtc:14885, webrtc:14884
Change-Id: If0c89e9b5de4fc63a59e17412fe4f0317fd61229
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292580
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39272}
Previous tests only asserted that O/A succeeded and that the number of
encodings was as expected. This test goes further and also asserts that
bytesSent eventually becomes non-zero (after an initial ramp-up time).
Let's get testing straight before we add VP9 simulcast support.
Bug: webrtc:14885, webrtc:14884
Change-Id: Idccce66698a077264fa0df2c448c8474d2439aea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291960
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39271}
This will be used by third_party/blink/renderer/platform/peerconnection/webrtc_video_track_source.cc to provide capture_time_identifier_ms_ from
media::VideoFrame.
This identifier would then be passed to webrtc::EncodedFrame and
webrtc::TransformableVideoSenderFrame (in the future CLs) to be used as
an identifier for encoded frames.
Bug: webrtc:14878
Change-Id: I1d8a27891323d86fdc2f014988a8da572df84119
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291805
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Palak Agarwal <agpalak@google.com>
Cr-Commit-Position: refs/heads/main@{#39270}
In the previous commit, I changed to modify deps_content,
but it was no-op since the content was already written to the DEPS file.
Bug: None
Change-Id: I278fbbb628422a42e616708f00529e935d75cd1f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292660
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Christoffer Jansson <jansson@google.com>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Cr-Commit-Position: refs/heads/main@{#39268}
By making this change, we ensure that these variables are not outdated.
Also, remove unnecessary list calls to python generators.
Bug: None
Change-Id: I53babe03da1cb78cf5dc127b7e1f753b63be20de
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292620
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Cr-Commit-Position: refs/heads/main@{#39267}
This allows callers to modify an encoded video frame's SSRC via the
setMetadata() call, which we'd like to do from Chrome, to allow using
an encoded frame from one PC on a different one.
Bug: webrtc:14709
Change-Id: Ia6b33761a3f63038f6eabbcd848916877e24454b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292380
Auto-Submit: Tony Herre <herre@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39266}
Absolute capture time extension did not work in tests that use test_audio_device. This change add capture timestamp to test audio device so absolute capture timestamp extensions can be sent in tests.
This make it possible to write tests for absolute header extension in Hamrit, and possible other test platforms as well.
Bug: None
Change-Id: Ie237f516ce0cccf43c32fe40da76a9d31f9fba53
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292340
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39265}
addressing feedback from
https://github.com/w3c/webrtc-extensions/issues/130
and aligning the behavior with setCodecPreferences.
BUG=chromium:1051821
Change-Id: If0c29e1e16781b6898814e2f888ad08a079fc609
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/286780
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39264}
Also added an enum for unknown reason.
New value uses a macro-like name rather than a constant-like name for consistency.
Bug: chromium:1369096, webrtc:14131
Change-Id: Ib315584ec40d8c1cd9a6f0ff44587c0d92c735d5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292341
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Sameer Vijaykar <samvi@google.com>
Cr-Commit-Position: refs/heads/main@{#39262}
This verifies that receiving two RTCP SR packets is enough to get
a defined capture start time stat.
Bug: webrtc:13931
Change-Id: Ib5f7c2954eab6500917f25c44f523d3aedae5e94
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291520
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39261}
This records high level errors, or success, encountered across the entire capture flow in the DXGI based capturer.
Using the same style as for WebRTC.DesktopCapture.Win.WgcCapturerResult
Bug: chromium:1400204
Change-Id: I7096d1790d7c2a23bbe29761b7dbf40426ce1e6a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291707
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39259}
Passing of ownership of codecs to tester is not strictly needed. We may need to continue using a codec after test. For example, to check codec state or to use the same codec instance in next test.
Bug: b/261160916, webrtc:14852
Change-Id: I179b262116d7de76b8171f0409f943ad6d87433e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291802
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39256}
Step 1 of combining the sender and receiver types
Also moved the RtpFrameObject to rtp_rtcp/source, as it's heavily used
by the transformable receiver frame, I couldn't work out a better way
of managing the dependencies, and everything else seemed to work fine.
Bug: chromium:1412687
Change-Id: I55e816a0d7aa2962560ff9ebaf30ad63ab0b9810
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291710
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tony Herre <herre@google.com>
Cr-Commit-Position: refs/heads/main@{#39255}
This change adds below test cases:
1. Keep most recent config events on start.
2. Rewrite all previous config events on restart.
3. Do not drop events when far more events than max event history logged
on logging start.
Bug: chromium:1288710
Change-Id: Ifc227e8be788d33dc2ed65f49281b3d0809231c6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291739
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39253}
In current state, the SDP parser in webrtc is not backward compatible with clients that might still be using RTP data channels.
Obviously, this isn't there is no such usecase in webrtc since the code is deleted, but in Meta we still use it and would like
to be able to negotiate between clients that offer RTP data channels.
Instead of erroring the parsing procedure, we can parse it as unsupported media in the client that no longer supports RTP data channels.
Replaced the existing test that expects parsing failures with a test that validates that the content was parsed as unsupported media.
Bug: webrtc:14872
Change-Id: I4c105cf55e33b8c19b2849e16148b8175053c40c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291190
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39252}
