For lower resolution videos, we should be able to decode them well without storing too many video frames. So let's keep this mechanism for 4k+ video only.
Differential Revision: https://phabricator.services.mozilla.com/D118402
When we switch to the DecodedStream from AudioSink. AudioSink would store some frames in its own media queue before those audio frames get played. After AudioSink got shutdown, it doesn't push those frames back to the original audio queue.
Therefore, when DecodedStream starts, it try to retrieve audio data from the audio queue, but it doesn't know that there is already a gap between "the audio DecodedStream is going to play" and "the audio that AudioSink had played".
Differential Revision: https://phabricator.services.mozilla.com/D115749
Current `GetElementsAfter()` is wrong, the result array would still contain the element which end time is earlier or equal to the given time.
Differential Revision: https://phabricator.services.mozilla.com/D107170
This patch will do :
- add `MOZ_DIAGNOSTIC_ASSERT` to ensure the sample is valid to be accessed
The advantage :
- to ensure the sample is still valid when we push it to the queue or pop it out the queue
Differential Revision: https://phabricator.services.mozilla.com/D75871
We're rarely getting nullptrs out of MediaQueues. It's not clear where these are
coming from, as we have many guards against them. Upgrade this assert to a
diagnostic to help us track the source and determine if the value is null before
entering the queue.
Differential Revision: https://phabricator.services.mozilla.com/D28866
--HG--
extra : moz-landing-system : lando
This will allow to remove mFrames member and calculate from the size of the content, which will dynamically change depending on a cropping filter.
Differential Revision: https://phabricator.services.mozilla.com/D20165
--HG--
extra : moz-landing-system : lando
When entering 'loopingDecoding' state, we should ensure we would continue to decoding even if
the audio decoding has finished before.
Differential Revision: https://phabricator.services.mozilla.com/D12589
--HG--
extra : moz-landing-system : lando
We only have a interest in the data which is popped out from the front side of the queue.
Differential Revision: https://phabricator.services.mozilla.com/D9190
--HG--
extra : moz-landing-system : lando
When we cancel seamless looping, we should discard audio data whose time are later than the last
audio frame's time in the audio track.
Differential Revision: https://phabricator.services.mozilla.com/D9189
--HG--
extra : moz-landing-system : lando
Its return value is never used, and most implementations return nullptr anyway.
MozReview-Commit-ID: 8rxC053mmE8
--HG--
extra : rebase_source : 61a0b8b1373396182efd27d3c01b96e5e5541364
1. ensure the 'finish' event is notified only once.
2. assert pushing items to a finished queue.
MozReview-Commit-ID: 9lYWPANVz0m
--HG--
extra : rebase_source : c05b0c77fdee324798579e0e2ebec6ce6303cbf6
extra : intermediate-source : 80be35003c76fc9cc74f206576394b46317b7880
extra : source : 14f5d5c064fddbbcf5728fb4d19e9c0a4e45fac7
We can get out of A/V sync if the decode is struggling to keep up. This is
because of the loop in VideoSink::UpdateRenderedVideoFrames(). If this function
runs while there's only one frame in the video queue, we won't drop that one
frame if it's late. If we're struggling to keep up, it's increasingly likely
that we'll end up running this function with only one frame in the video queue.
That results in us entering VideoSink::RenderVideoFrames() with only 1 late
frame, which the compositor dutifully draws. Resulting in a late frame being
drawn, and thus broken A/V sync.
This change makes VideoSink::UpdateRenderedVideoFrames() drop all late
frames, even the last one in the video queue. We now keep A/V sync when the
decode is struggling to keep up. However, if I do this, we end up dropping
(and reporting that we drop) a lot more frames, and thus rendering a lot fewer.
But since we when we drop the frames we report them as dropped, a well written
MSE player can detect that we've failing miserably to keep up, and and lower
their bitrate.
MozReview-Commit-ID: ybkq48mKk2
--HG--
extra : rebase_source : f03c186059a365a45de698b2a30e632daae47fb8
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
CLOSED TREE
Backed out changeset 584d91ffdf88 (bug 1135424)
Backed out changeset d86806ea63f4 (bug 1135424)
Backed out changeset e52401d30a67 (bug 1135424)