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
Replace README_MOZILLA with moz.yaml, various fixups for update.py, and create
a missing patch file from Bug 1491848.
Differential Revision: https://phabricator.services.mozilla.com/D11891
--HG--
extra : moz-landing-system : lando
This removes DecodedStream's use of MediaStreamListener in favor of
MediaStreamTrackListener. This change has however rippled through to a lot
more cleanup, per below.
This moves the MediaStreamTrack lifetime ownership for captured
HTMLMediaElements from the media element to DecodedStream, where the
MediaStreamGraph-side tracks are already created and ended today.
This makes MediaStreamTrack creation explicit across the entire codebase and
lets us remove the MediaStreamTrackSourceGetter class and the infrastructure
of adding MediaStreamTracks after they've already been created in the graph
from DOMMediaStream.
With track ownership, and thus TrackID allocation ownership, happening
exclusively in DecodedStream for its output tracks, we also stop throwing
away and recreating the SourceMediaStream to which we feed data on seek.
This is one step closer to fixing bug 1172394 and spec compliance of
HTMLMediaElement.captureStream().
Differential Revision: https://phabricator.services.mozilla.com/D12273
--HG--
extra : moz-landing-system : lando
Dorel Luca
Bryce Van Dyk
Dan Minor
Sylvestre Ledru
Alex Chronopoulos
Jean-Yves Avenard
Jan-Ivar Bruaroey
Andreea Pavel
Andreas Pehrson
Paul Vitale
Nico Grunbaum
Gabriele Svelto
Nils Ohlmeier [:drno]
Ehsan Akhgari
Byron Campen [:bwc]
Thomas Daede
Coroiu Cristina
byron jones