1. we move clone related methods to BaseMediaResource which is the only cloneable sub-class of MediaResource.
2. add CanClone() to ChannelMediaDecoder to reduce the dependency on MediaResource for HTMLMediaElement.
MediaResource should be internal details to MediaDecoder.
MozReview-Commit-ID: Hl2nAiuyTO0
Since we will remove ChannelMediaDecoder from HLSDecoder's base class, we can't
create HLSDecoder in InstantiateDecoder which returns a ChannelMediaDecoder.
MozReview-Commit-ID: 9wcrIVIOZFp
Since inf can be encoded in MDSM::mDuration, we don't need an additional flag
in MediaDecoder to indicate 'infinite' anymore. Note duration change from infinite
to finite is handled by MDSM, so we can remove the explicit calls to SetInfinite(false).
MozReview-Commit-ID: EoxwZJzPAJl
While "debugger" is not available yet, we can enable these debugging APIs for
extensions that have the "tabs" privilege, which includes the Media Panel
Devtools extension, so we/webdev will get better media-playback information.
MozReview-Commit-ID: I0MAZH9g0HU
The MediaStreamGraph relies on having at least one message sent to its message
queue on creation, or it will just sit there and do nothing, and block shutdown
because its not running its rendering loop, so it's not progressing in the
MediaStreamGraph life cycle state machine.
This patch makes sure the `captureStream` will succeed before creating an MSG.
MozReview-Commit-ID: CN1arWydmxC
MSE specs require that the readyState be modified during either the Initialization Segment Received or the Coded Frame Processing algorithms.
At this stage, we only handle the Initialization Segment part (readyState moving from HAVE_NOTHING to HAVE_METADATA)
MozReview-Commit-ID: KBnnWuHJ6Om
The spec says that we don't need to change the ready state when getting the error.
If the ready state is "HAVE_METADATA", it means we could get the video's duration
at that time.
However, if we shutdown decoder too early, we won't get the correct duration.
In addition, since we remove old decoder prior to create new one in the function
HTMLMediaElement::SetDecoder(), we can remove the decoder checking assertion
in HTMLMediaElement::InitializeDecoderForChannel().
MozReview-Commit-ID: CHRJHng8Xm0
In order to facilitate the movement of code with side-effects called by Element::SetAttr to Element::BeforeSetAttr and Element::AfterSetAttr, Element::AfterSetAttr should have access to the old value of the attribute. This includes information about whether there was previously a value set or not.
Accomplishing this involved passing an additional argument through functions that find and change the old attribute value in order to ensure that we can differentiate between an empty old value and an absent old value (attribute was not set).
Note that while I tried to ensure that accurate values (and their absence) are reported to Element::AfterSetAttr, I largely ignored SVG. While the old value reported for SVG values should be however accurate the value already being reported to SetAttrAndNotify was, SVG elements do not currently report unset values properly because they will never pass a null pointer to SetAttrAndNotify.
MozReview-Commit-ID: K1mha8CNFZP
Since we don't want to show media control for media without audio track (eg. GIFV),
it's no need to register audio agent for them.
MozReview-Commit-ID: 22YrMkpNrcP
The part is mainly to set urgent-start for loading media when it's initiated by
user interaction. For the HTMLMedia element, it has its algorithm to pre-load
the media and users will get feedback once they play the media. Thus, I only
set urgent-start when the media element has autoplay attribute since the sooner
enough resource is loaded the sooner the media will be played.
MozReview-Commit-ID: 7nu3PUt8iYo
Otherwise we will fail the assertion (!mDecoder, "Shouldn't have a decoder")
in HTMLMediaElement::InitializeDecoderForChannel().
MozReview-Commit-ID: 1zShp0th3Uv
