Extremely small encoded image sizes should be considered corrupt data.
Drive-by improvement: make sure to cast the encoded image data length
to uint32_t for use with `CreateEmptyFrame`
The problem here is that we use move assignment on a hash table entry that
is not live. Although all entries are constructed by
`HashTable::createTable`, they may subsequently be destroyed by
`HashTableEntry::destroyStoredT()`.
Therefore it is not safe to call any methods on a non live entry.
This causes a problem for GC barrier wrappers which assume that the object
state is valid (and presumably anything that does more than just write the
assigned data into memory).
The fix is to construct a new entry in-place.
Based on work by Jon Coppeard <jcoppeard@mozilla.com> in Bug 2009608
This is based on BZ 1820504, which notes that running `GetEmojiPresentation()` before checking `prevWasZwj` adds load time to all text, as opposed to more efficiently making `prevWasZwj` the precursor to categorizing the character.
The original patch uses an enum for `baseIsEmojiStatus`; I figured I'd simplify things with numeric values (0 = unset, 1 = yes, 2 = no).
This fixes warning spew because warnings are thrown in case of mixed use
of cairo_status_t and cairo_int_status_t, which is a hack in cairo
because C99 doesn't support real enums (it's mapped to uint8 internally).
The "register" storage type is no longer a thing in C++17, which would
also warn; just letting the compiler decide is best, so just removing
the keyword is the proper solution in cairoint.h
Now that we can check if the first frame has been decoded thanks to Issue #2953
we should ensure that the first frame actually has not been decoded before
checking if the media errored out.
An internal seek occurs when we've reached a data gap, EOS or a previous error got skipped.
During this time, the decoder has been either flushed or shut down.
When we have no future keyframe and an error occurred, we can't skip over
anything and we shouldn't try to simply decode the next video frame; so we
abort early.
The Windows VP9 hardware decoder currently does not support anything else than
profiles 0 and 2 (YUV420) and return garbage when decoding.
We error on those streams allowing to fall back on the ffvp9 software decoder.
Unlike the original patch we don't have the infrastructure provided by Mozilla
BZ 1363668 yet to determine if we've decoded the first frame. This is not
required for checking whether we've errored out on hardware decoding though.
Based on Mozilla bug 1371290's part 2.
The VP9 decoder doesn't properly set the sample duration, leading to all
samples being marked as having a zero duration. The compositor drops those
frames incorrectly.
roytam1
Moonchild
Brian Smith
Job Bautista
Basilisk-Dev
Brad Werth
Andy
Jazzzny