It served no purpose other than implementing the MSE spec by the letter. The spirit is preserved.
This allows to disable tail dispatching on the MediaSourceDemuxer's TaskQueue which prevents us from performing synchronous operation on the main thread.
MozReview-Commit-ID: G7aqfvGsf1e
The changes that follow may cause the active sourcebuffer list to be modified; which will trigger an assertion if the mediasource object is closed.
MozReview-Commit-ID: 8A1CMKAUyTq
mAppendRunning is set prior the append task being queued; so it is possible that the segment parser loop hasn't yet been started, yet mAppendRunning is true.
Separate this diagnostic with a new flag ON A CLOSED TREE.
MozReview-Commit-ID: GgTyyltKOJr
The W3C spec indicates that while everything in MSE is asynchronous, the abort() command is to interrupt the current segment parser loop and have the reset parser loop synchronously completes the frames present in the input buffer.
This causes a fundamental issue that abort() will never result in a deterministic outcome as the segment parser loop may be in different condition.
We used to really attempt to abort the current operation, however there could have been a race in the order in which tasks were queued. As such, we now simply wait for the current appendBuffer to complete.
This also simplifies the code greatly, as we don't need to worry about pending concurrent appendBuffer.
The actually happens to be similar to the Chromium behavior.
Similar to bug 1239983, we strongly assert should a segment parser loop be running when it must have completed.
MozReview-Commit-ID: 9772PLQEozf
It served no purpose other than implementing the MSE spec by the letter. The spirit is preserved.
This allows to disable tail dispatching on the MediaSourceDemuxer's TaskQueue which prevents us from performing synchronous operation on the main thread.
MozReview-Commit-ID: G7aqfvGsf1e
The changes that follow may cause the active sourcebuffer list to be modified; which will trigger an assertion if the mediasource object is closed.
MozReview-Commit-ID: 8A1CMKAUyTq
This is similar to bug 1239983, we strongly assert should a segment parser loop be running when it must have completed.
MozReview-Commit-ID: CXqGoq9Opq0
The W3C spec indicates that while everything in MSE is asynchronous, the abort() command is to interrupt the current segment parser loop and have the reset parser loop synchronously completes the frames present in the input buffer.
This causes a fundamental issue that abort() will never result in a deterministic outcome as the segment parser loop may be in different condition.
We used to really attempt to abort the current operation, however there could have been a race in the order in which tasks were queued. As such, we now simply wait for the current appendBuffer to complete.
This also simplifies the code greatly, as we don't need to worry about pending concurrent appendBuffer.
The actually happens to be similar to the Chromium behavior.
MozReview-Commit-ID: CHppUOGM1mk
The changes that follow may cause the active sourcebuffer list to be modified; which will trigger an assertion if the mediasource object is closed.
MozReview-Commit-ID: 8A1CMKAUyTq
YouTube sets the track ID at 1 for both audio and video tracks. Attempting to use mozCaptureStream would cause an assert as it always expect tracks to have a different track Id.
Added diagnostics around demuxer init/reset promises, to catch early cases
where TrackBuffersManager::mInputDemuxer is destroyed while an init/reset
promise is in flight, which would cause later issues when the 'Then' clause
assumes that mInputDemuxer still exists.
Note: This is *not* an actual fix for crashes linked to this bug, but it should
help identify unexpected situations, or instead eliminate these patched
locations as sources of crashes.
A new bug will be needed to examine the fallout from this patch and produce a
real fix, or continue investigating.
XPCOM when shutting down expects all tasks to be run synchronously. As such, we must ensure that the remaining MediaDecoder are shut down before continuing on the next task.
In particular destroying gfxPlatforms must only ever happen after, as it is possible for the MediaDecoderReader to make use of gfx resources during shutdown.
When seeking, the next keyframe time would always be set to the seek time (as the next sample to be retrieved would be a keyframe). This could lead to the next key frame logic to be activated too aggressively.
When seeking, the next keyframe time would always be set to the seek time (as the next sample to be retrieved would be a keyframe). This could lead to the next key frame logic to be activated too aggressively.
We assume that if we have 30s of data buffered ahead of the current position or up to the element's duration that we can play ahead without interruption.
We require a slightly variation on the default implementation as mediasource allows for gaps of up to 125ms between samples and often videos do not start with a time of 0.
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
This commit was generated using the following script, executed at the
top level of a typical source code checkout.
# Don't modify select files in mfbt/ because it's not worth trying to
# tease out the dependencies currently.
#
# Don't modify anything in media/gmp-clearkey/0.1/ because those files
# use their own RefPtr, defined in their own RefCounted.h.
find . -name '*.cpp' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
grep -v 'mfbt/RefPtr.h' | \
grep -v 'mfbt/nsRefPtr.h' | \
grep -v 'mfbt/RefCounted.h' | \
grep -v 'media/gmp-clearkey/0.1/' | \
xargs perl -p -i -e '
s/mozilla::RefPtr/nsRefPtr/g; # handle declarations in headers
s/\bRefPtr</nsRefPtr</g; # handle local variables in functions
s#mozilla/RefPtr.h#mozilla/nsRefPtr.h#; # handle #includes
s#mfbt/RefPtr.h#mfbt/nsRefPtr.h#; # handle strange #includes
'
# |using mozilla::RefPtr;| is OK; |using nsRefPtr;| is invalid syntax.
find . -name '*.cpp' -o -name '*.mm' | xargs sed -i -e '/using nsRefPtr/d'
# RefPtr.h used |byRef| for dealing with COM-style outparams.
# nsRefPtr.h uses |getter_AddRefs|.
# Fixup that mismatch.
find . -name '*.cpp' -o -name '*.h'| \
xargs perl -p -i -e 's/byRef/getter_AddRefs/g'
The LayersBackend can be defined at construction time, however if a parent MediaDecoder exists, the value will be overwritten by the MediaDecoderOwner value.
--HG--
extra : rebase_source : fefad83560d5bfa2aee9f665fe138397eb390019
When ffmpeg is enabled, it will use the FFmpeg's VPX decoder. FFmpeg appears to always buffer 15 frames before returning one (this is the same with h264) causing the waiting event to be fired much earlier than when using libvpx
A MediaDataDemuxer is now not to resolve the init promise until it has all the metadata.
Except MediaSource, all demuxers would be doing blocking read to scan for the metadata, and having partial metadata would be an error.
For MediaSource, we pass the NotifyDataArrived message which will cause the MediaSourceDemuxer to re-attempt to search for the metadata.
When used within MediaSource's TrackBuffersManager, a demuxer will never be created until we have received a complete init segment (this task is performed by the various ContainerParsers)
With H264, often the first frame of a media segment has no duration ; as such the time interval it represents is empty and will never intersect with anything.
We can know with certainty the duration of a block if we have a following one. We do not have to always rely on having a previous segment to estimate the duration.
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
This functionality is now replaced with a dedicated new MediaResourceIndex class.
This allows for concurrent Read/Seek use of the MediaResource without having side effects.
The try machines do not have Service Pack 1 installed, the WMF decoder doesn't output frames until a full second of data has been added. Rendering those tests invalid.
In test_HaveMetadataUnbufferedSeek_mp4, do endOfStream after appending 2nd buffer in case decoder doesn't output enough frames to seek to the target point.
Calculating intersections between two interval sets with different fuzz can lead to useless tiny intervals which could cause CheckNextInsertionIndex to fail.
Should a playback error occurs, the MediaSource element will be closed and will detach its sourcebuffers. Cancel any pending operations going in the sourcebuffers.
