The MediaDecoderStateMachine treat seek's EOS as fatal errors, so instead we always resolve the seek promise, and let the next GetSample return EOS.
MozReview-Commit-ID: 6MGaJ3C8xrH
--HG--
extra : rebase_source : 50c111fb38f50e8a0c823aeef21e9635a88c0afc
into TrackInfoSharedPtr to better indicate what this class is about.
Adding cast operator to allow transparent conversion from TrackInfoSharedPtr to const TrackInfo*
MozReview-Commit-ID: 6RwXl5CG0fG
--HG--
extra : rebase_source : b5a7a0f06793c609e2eab60aacc4f76d96d6ec32
Fixed coding style of files encountered in P1 and P2.
MozReview-Commit-ID: LApVu9K2oto
--HG--
extra : rebase_source : e3bb296baaec9df2011ff312fec2eda19dd125e6
Thanks to the previous patch, MediaDataDemuxer::Seek and
SkipToNextRandomAccessPoint (and all overrides in derived demuxers) can now
take their TimeUnit parameter by const&.
MozReview-Commit-ID: 6CqfjAXZ7Yk
--HG--
extra : rebase_source : c3453e4432d9e0281cf5eba55217b0c1d6312f5b
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Both the WebM and mp4 demuxers need to pack this value into
the the CodecSpecificConfig, so move the shared implementation
to the OpusDecoder, near where it is unpacked so the two can
be kept in sync.
MozReview-Commit-ID: 2pQaruJoAWr
- WebMDemuxer will read crypto information from WebM metadata.
- WebMDemumer adds crypto information to samples.
- WebMDemuxer can now return encryption info from GetCrypto().
- WebMDexmuer will not attempt to peek encrypted frames as it
will give back garbage data. This means resolution changes
internal to encrypted WebM files will not work.
- WebMDecoder now exposes a single string version of
CanHandleMediaType. This is done in the same way as the
Mp4Decoder, so that the future update to MediaKeySystemAccess
for WebM handling can maintain the same conventions.
MozReview-Commit-ID: CU3JVi3t7Vn
--HG--
extra : transplant_source : %87gn%5Bm%B5t%EA%9F%5Bh%B4%3B%9D%5E%AE%AB%AF%12%0A
Bug 1224973 added a new usage of the MediaDataDemuxer where we would seek only inside the video track. So we can't use a common nestegg context for demuxing both the audio and video.
So instead we now use two different nestegg context.
MozReview-Commit-ID: 4G86Na5abe2
--HG--
extra : rebase_source : 4f296a649f73ef2f37a770db2c8a0f7f0e5c54a2
We want to add MediaRawDataQueue aOther at the front, not at the back.
MozReview-Commit-ID: 9icTWzRqS4u
--HG--
extra : rebase_source : 2713cbe952461c520a420925040be2de257f0596
Use the recently added nestegg_read_reset API to restore the demuxer to the
last valid state so that MSE can reattempt parsing the next packet as more
data is added to the stream.
Is is now up to the decoders to automatically determine the correct size of the decoded frame.
By leaving the original dimensions in the VideoInfo, it will allow automatic rescale of the cropping window according to the original dimensions.
MozReview-Commit-ID: FZM4YlataNz
Same after a reset or the first frame ever returned by the demuxer.
MozReview-Commit-ID: 6b7XlIk5GE4
--HG--
extra : rebase_source : 7e7b92c2ed7ea6973ad3869477b3110925a64525
Update the WebMDemuxer to detect changes in resolution. When it does so it
changes the streamID so that we get a new decoder created to handle the
resolution change. The demuxer will also update media info in these cases, so
the new decoder has the correct information. The demuxer will only handle
resolution changes on key frames, files that attempt changes other times are not
considered valid at this stage. If a resolution change cannot be performed
because nest_egg cannot read track info, or because the new resolution is
invalid, a change will not take place.
MozReview-Commit-ID: 1JKz3mGbEvi
--HG--
extra : rebase_source : aebd609651dfbd48d2f6ea3e33986a7e12b1495e
MediaDecoder previously had 3 states within GetSeekable(), media is either
seekable, seekable but not supported by transport, or not seekable. Due to
changes to make cueless webms playable, a 4th option is needed: a file that is
not fully seekable, but may support seeking from the transport, such as these
webms, should only be seekable in the buffered range.
MozReview-Commit-ID: ISeFkngtrGU
Previously if a seek time is specified outside of the buffered range for
certain WebMs (particularly those without cues) the WebMDemuxer would fail out
of SeekInternal() with an error code. However, this would lead to issues due to
inconsistent state (recovery was not made from a failed seek). This change
attemps to address this by instead seeking to the final available cluster.
MozReview-Commit-ID: GZLPZDWLcT1
It appears that the work to seek in WebMs that do not have cues has already been
done, however this functionality was gated by the IsSeekable() function still
returning that such WebMs were not seekable. This updates that function so that
WebMs without cues are now considered seekable. Tests are also updated to
reflect this.
