In libavcodec 58 and later, the old avcodec_decode_video2 is broken and only return the first visible frame found after a VP9 super-frame.
This resulted in some YouTube videos for about 10% of the frames to never be returned.
Only the new API properly behaves so we upgrade our code to use it.
Differential Revision: https://phabricator.services.mozilla.com/D14682
--HG--
extra : moz-landing-system : lando
The value for mozAvSyncDelay has been broken since the branch 57 update
(Bug 1341285). We added SetCurrentSyncOffset() but never called it from
anywhere.
In the future we should be getting stats from AudioReceiveStream rather than
modifying the channel code, the delay_estimate_ms field provides almost the
same information.
Since we're attempting to get rid of moz prefixed stats, it makes sense to just
remove this code rather than fix it. The associated telemetry code has been
broken since Bug 1341285 as well so I think it is safe to remove.
Differential Revision: https://phabricator.services.mozilla.com/D14462
--HG--
extra : moz-landing-system : lando
CreateEncoderStreams is called from VideoStreamEncoder::ReconfigureEncoder
which does not check that at least one stream is returned prior to accessing
one of the streams. This would most likely result in a runtime check failing
in ReconfigureEncoder. This adds a runtime assertion in CreateEncodeStreams
that will check that at least one stream is created. This is better than
undefined behaviour in ReconfigureEncoder.
Differential Revision: https://phabricator.services.mozilla.com/D14281
--HG--
extra : moz-landing-system : lando
The RTCP timestamps have different timebases and reporting sources, this makes the source and timebase the same for all RTCP stats
Differential Revision: https://phabricator.services.mozilla.com/D7354
--HG--
extra : moz-landing-system : lando
The affected functions are only used by VCMJitterBuffer, which is the older
jitter buffer that is no longer in use. We can safely remove these
modifications.
Differential Revision: https://phabricator.services.mozilla.com/D14485
--HG--
extra : moz-landing-system : lando
This ends up calling VCMReceiver::Reset() which resets the
state of the VCMJitterBuffer. We no longer use VCMJitterBuffer,
which is the old jitter buffer implementation, so this code
no longer has any effect and can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D14185
--HG--
extra : moz-landing-system : lando
Update mp4parse-rust update script and pull the new version.
This update changes the mp4parse C-API. Specifically, each track can now
have multiple sample descriptions. Previously we'd just exposed the first for
the entire track, and if others were available they were not exposed via the
API. Because of the API change, we update the C++ interface with mp4parse-rust.
We now inspect the sample info to make sure they're consistent with the parsers
expectations:
- Only a single codec is present for a track, multiple codecs in a track will
result in us returning an error.
- Only 0 or 1 crypto info is present for a track, more than one set of info will
result in us returning an error.
We still generalize some of the first sample info to the samples of the track,
as we did before this patch. However, we will now catch the above cases
explicitly.
We now handle crypto information if it is not present on the first sample info.
The parser will iterate through sample infos and use the first set of crypto
info it finds (and fail if it finds 2+).
Differential Revision: https://phabricator.services.mozilla.com/D14107
--HG--
extra : moz-landing-system : lando
Update mp4parse-rust update script and pull the new version.
This update changes the mp4parse C-API. Specifically, each track can now
have multiple sample descriptions. Previously we'd just exposed the first for
the entire track, and if others were available they were not exposed via the
API. Because of the API change, we update the C++ interface with mp4parse-rust.
We now inspect the sample info to make sure they're consistent with the parsers
expectations:
- Only a single codec is present for a track, multiple codecs in a track will
result in us returning an error.
- Only 0 or 1 crypto info is present for a track, more than one set of info will
result in us returning an error.
We still generalize some of the first sample info to the samples of the track,
as we did before this patch. However, we will now catch the above cases
explicitly.
We now handle crypto information if it is not present on the first sample info.
The parser will iterate through sample infos and use the first set of crypto
info it finds (and fail if it finds 2+).
Differential Revision: https://phabricator.services.mozilla.com/D14107
--HG--
extra : moz-landing-system : lando
In Bug 919979 we added 100 bytes to the size returned by CalcBufferSize
to work around an error with the calculated buffer size with small
resolutions. I verified that this extra buffer is no longer required with
a modified mochitest. Given the age of the bug this was working around,
I don't think a permanent test is required to prevent regressions from
upstream.
Differential Revision: https://phabricator.services.mozilla.com/D14076
--HG--
extra : moz-landing-system : lando
These modifications are made to code which we do not use and so
can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D13989
--HG--
extra : moz-landing-system : lando
This removes disable_composition_ and instead uses the value of
composition_func_ to determine whether or not composition is
disabled. This is what is done by upstream webrtc.org.
We call options.set_disable_effects(false) in desktop_capture_impl.cc.
Differential Revision: https://phabricator.services.mozilla.com/D13839
--HG--
extra : moz-landing-system : lando
This test started failing after the 57 update and started passing
again after the 64 update, so we might as well enable it.
Differential Revision: https://phabricator.services.mozilla.com/D13803
--HG--
extra : moz-landing-system : lando
PlatformUIThread is only used by the video_engine code, so it makes sense to
move it there rather than maintain it as a diff against upstream webrtc.org.
Differential Revision: https://phabricator.services.mozilla.com/D13531
--HG--
extra : moz-landing-system : lando
This code was added by Bug 1196542 to fix a permanently failing test on our
Windows test machines. After this landed, upstream added a check for empty
windows in window_captuer_win.cc, so this should no longer be a problem on
Windows. As far as I know, this was never a problem on the other platforms,
so this code can be safely removed.
Differential Revision: https://phabricator.services.mozilla.com/D13448
--HG--
extra : moz-landing-system : lando
Port restriction is delegated to the io service. Port 0 is explicitly
unrestricted.
NS_CheckPortSafety emits a warning which pollutes the gtests a bit. It is only
tested if the port is not 0.
Differential Revision: https://phabricator.services.mozilla.com/D13187
--HG--
extra : moz-landing-system : lando
Assertions in NetEqImpl::SetSampleRateAndChannels prevent us from requesting
tones at 44100 Hz, so this code can be safely removed.
Differential Revision: https://phabricator.services.mozilla.com/D12982
--HG--
extra : moz-landing-system : lando
This enables support for the DirectX screen capturer. We use the default
DesktopCaptureOptions which do not set the option to use the DirectX screen
capturer so this change will have no effect with the current code.
For what it's worth, I tested enabling the DirectX option and it worked fine on my
system, but I don't see any reason to not follow the defaults provided by
webrtc.org in this case.
Differential Revision: https://phabricator.services.mozilla.com/D13303
--HG--
extra : moz-landing-system : lando
Historically this code was part of webrtc.org but has since been removed
from upstream. Rather than maintaining it as a local diff against upstream,
we should just move it to where it is used.
Differential Revision: https://phabricator.services.mozilla.com/D13092
--HG--
rename : media/webrtc/trunk/webrtc/video_engine/browser_capture_impl.h => dom/media/systemservices/video_engine/browser_capture_impl.h
rename : media/webrtc/trunk/webrtc/video_engine/desktop_capture_impl.cc => dom/media/systemservices/video_engine/desktop_capture_impl.cc
rename : media/webrtc/trunk/webrtc/video_engine/desktop_capture_impl.h => dom/media/systemservices/video_engine/desktop_capture_impl.h
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13193
--HG--
extra : moz-landing-system : lando
Make a cleaner distinction between having a recv stream that is inactive, and no recv stream at all. Requires some modification to local RTC extension configuration, because of a test-case that assumed StopReceiving/StartReceiving would re-create the recv stream as opposed to simply restarting it.
Differential Revision: https://phabricator.services.mozilla.com/D12936
--HG--
extra : moz-landing-system : lando