ConvertSampleToAnnexB takes the sample's out of band extradata to prepend it to the data. It was theorically possible that the first sample would contain the SPS/PPS from the previous format.
Depends on D11559
Differential Revision: https://phabricator.services.mozilla.com/D11560
--HG--
extra : moz-landing-system : lando
keyframe was tracked in the CodecChangeMonitor in order to determine when to prepend the SPS/PPS to a sample for decoder using AnnexB format.
The assumption was that it was needed only once per the lifetime of the decoder (and indeed this is true with the Windows and Android decoder). However this causes issue with the Widevine H264 decoder and it will error on some content if the first sample passed following a flush doesn't contain a SPS/PPS.
Interestingly, this issue isn't observed with Netflix content or other Widevine sample videos. Only Amazon PrimeVideo content so far.
We instead use the global MediaChangeMonitor keyframe status that knows when the decoder has been drained or flushed.
Differential Revision: https://phabricator.services.mozilla.com/D11556
--HG--
extra : moz-landing-system : lando
Set markup view lines to use a precise 14px line-height, 16px total height.
Align markup badges more precisely with vertical-align:top and margin-top,
because vertical-align:middle is imprecise and has unwanted side effects.
Differential Revision: https://phabricator.services.mozilla.com/D9993
--HG--
extra : moz-landing-system : lando
In Bug 1479125 we put calls to .children that were intended to access child elements into the custom
method, which is a slower path. We may eventually want to remove itemChildren altogether and just assume
that all children are items, but that's out of scope for a perf fix like this.
Differential Revision: https://phabricator.services.mozilla.com/D10751
--HG--
extra : moz-landing-system : lando
The particular toolchain is somewhat arbitrary, but is what servo uses on master
right now, and is newer than the rust version we use everywhere else, which
wasn't the case.
Differential Revision: https://phabricator.services.mozilla.com/D11574
This change tries to ensure that we don't write telemetry data for mach
commands invoked recursively as part of other mach commands. The intent of
build system telemetry is to only collect data about commands that users are
invoking directly.
There are two ways that we found mach commands can be recursively invoked:
* By running a python subprocess to recursively invoke mach (used in
`mach bootstrap` to call `mach artifact toolchain`)
* By using `Registrar.dispatch` to delegate to a sub-command (used by many
build system commands to invoke `mach build`).
The subprocess case is handled here by having mach set a `MACH_MAIN_PID`
environment variable whose value is the current process' pid on startup if it
does not already exist in the environment. Telemetry code then checks that the
value of that variable matches the current pid and skips writing telemetry data
if not.
The dispatch case is handled by making `MachRegistrar` store the current depth
of the command stack and pass it to the `post_dispatch_handler` which will skip
writing telemetry data if depth != 1.
Additionally the `should_skip_dispatch` function in mach_bootstrap is renamed
to `should_skip_telemetry_submission`, which was its original intent. The
combination of checks added in this change should be sufficient for deciding
when to write telemetry data, and we were not collecting telemetry for the set
of mach commands in that function (which included `mach bootstrap`).
In order to facilitate writing a test for the dispatch case this change adds a
`mach python --exec-file` option to execute Python code directly in the context
of the `mach python` command.
Differential Revision: https://phabricator.services.mozilla.com/D11207
--HG--
extra : moz-landing-system : lando
The build telemetry code attempts to filter paths to avoid PII from usernames
and other things. It does this by converting every commandline argument to
an absolute path and then making them relative to topsrcdir or topobjdir and
omitting any that fail. This meant that running a mach command with a cwd
outside of the topsrcdir or objdir would omit all arguments since they were
converted to absolute paths from the cwd.
This change fixes this by adding the cwd to the list of paths used to create
relative paths. Additionally we add the user's home directory to that list
to try to avoid usernames sneaking through. Finally, instead of simply
removing these path prefixes, we replace them with sigils: $topsrcdir,
$objdir, $HOME.
Differential Revision: https://phabricator.services.mozilla.com/D11174
--HG--
extra : moz-landing-system : lando
After bug 1497638 the method by which build telemetry data gets written
to disk is slightly convoluted. Since we're now invoking `gather_telemetry`
from `post_dispatch_handler`, we just make that function return the data
it gathers and inline the contents of `telemetry_handler` after the call
to it.
Differential Revision: https://phabricator.services.mozilla.com/D11173
--HG--
extra : moz-landing-system : lando
This change adds python/mach/mach/test/test_telemetry.py which contains
a simple test that running mach with the build telemetry setting enabled
causes us to write a telemetry file. The test fixture in the file should
make it easy to write additional tests.
A necessary precursor to make the tests work was to change mach_bootstrap's
`should_skip_dispatch` function, which would refuse to write telemetry data
if stdout was not a terminal (which it isn't in the tests) and also in
automation. The latter test is moved to ensure that we don't *submit*
telemetry data from automation, but we can still write it to disk. Machines
in automation should never have the telemetry setting enabled outside of
these tests anyway, so this should not change anything in practice.
Differential Revision: https://phabricator.services.mozilla.com/D11172
--HG--
extra : moz-landing-system : lando
The concept of card types, supportedTypes, BasicCardType enum, were removed from the Basic Card spec.
Differential Revision: https://phabricator.services.mozilla.com/D10646
--HG--
extra : moz-landing-system : lando
Some standard algorithms detect an error, do some complicated error handling,
then re-throw the error. Before this patch, we implement this by leaving the
exception pending while doing the error handling. Then once the error handling
is done, we simply return false. This is incorrect if any of the intervening
code internally throws any error, then catches and clears it.
The right way to implement the standard is to store the pending exception in a
local variable and explicitly re-throw it later.
Depends on D11235
Differential Revision: https://phabricator.services.mozilla.com/D11236
--HG--
extra : moz-landing-system : lando
It only used to work as the H264Converter used to check that the conversion needed was != kNeedAVCC (the default being kNone)
Differential Revision: https://phabricator.services.mozilla.com/D11526
--HG--
extra : moz-landing-system : lando
It's best practice in chrome to not run code in the connectedCallback during parse
(see the comment above MozXULElement.delayConnectedCallback).
Differential Revision: https://phabricator.services.mozilla.com/D11520
--HG--
extra : moz-landing-system : lando
Also, remove the unused NS_BLOCK_MARGIN_ROOT flag set on nsColumnSetFrame.
Differential Revision: https://phabricator.services.mozilla.com/D8783
--HG--
extra : moz-landing-system : lando
byron jones
WR Updater Bot
Jean-Yves Avenard
Daniel Varga
Florens Verschelde
Brian Grinstead
Dorel Luca
Emilio Cobos Álvarez
Simon Sapin
Dão Gottwald
Ricky Rosario
shindli
William Lachance
Ted Mielczarek
Ed Lee
Brindusan Cristian
Geoff Brown
Cosmin Sabou
Marcos Cáceres
Jason Orendorff
Jared Wein
Ting-Yu Lin