There are various differences between the new ogg player and the old OggReader that leads to inconsistencies on how durations are reported.
1- The old OggReader only use the end time as duration of the video, ignoring the start time of the first sample. This leads to incorrect duration calculation.
2- The OggReader do not ignore undecodable frames located at the beginning of the video, and those are used by the MDSM to calculate the start time. This leads to durations sometimes being shorter than they ought to.
MozReview-Commit-ID: 6yi1P4N6tPE
--HG--
extra : rebase_source : 31c0346c677f07e39c865d4f9f25dc0ebb70b18b
The OggReader always passed a complete ogg_packet to the vorbis decoder, ensuring that the right number of frames was be returned. In the conversion to the new architecture, this information got lost making the vorbis decoder always return more frames than normal on the last packet.
MozReview-Commit-ID: HYHxqXfYntJ
--HG--
extra : rebase_source : 3aa215576fe77357dd9a484626c0e5759aeedb3c
This is not the cleanest approach, but ensures identical behavior with the OggReader when it comes to firing loadedmetadata event and handling the change of seekability.
A more universal solution could be considered involving the MediaFormatReader and changing the MediaDataDemuxer API, of interest would be adding support for a new event fired whenever we have a change of content or metadata (useful with MSE or recorded webm of a WebRTC session
MozReview-Commit-ID: BojB2r1CtA3
--HG--
extra : rebase_source : 04704c13bfbdc83fe7c03505876deb8cda2043e6
A call to reset is always followed by a call to Seek; seeking is an heavy operation with ogg so let's minimize the number of times we are actually seeking.
MozReview-Commit-ID: Jz7dL9IFM14
--HG--
extra : rebase_source : b4c861b5963647292e3c8d8c8b8ac7ce097112fa
Note that the closest keyframes are for video 0.666667 and audio 0.645805, however the current OggReader still incorrectly seeks audio to an
earlier time as it seek to the index page boundary.
MozReview-Commit-ID: 5g7FHFmRQXD
--HG--
extra : rebase_source : cb105bafdf6aaa0f441da5130571b0b0b8e3a3f0
Fast seek in the old OggReader is broken: the audio track isn't seeked to the video track in order to preserve A/V sync and we end up always performing an accurate seek which explain why this test succeeded before.
The page index is only made of two entries, and so the first video frame returned after a seek, if within the first index will always have a time of 0.
MozReview-Commit-ID: 2EYzLMWRZAi
--HG--
extra : rebase_source : a7c73a757a841550cc7c5d2a0a7229a037a2bb9f
r?cpearce
A hack was in place to ensure that the first returned sample would have
a time of 0 so that the media start time would be 0. This was incorrect
for two primary reasons:
- The media start time is adjusted according to the first sample anyway.
- When seeking to 0, the first sample would have a time different to the
first sample decoded (when we want them to have the same time).
MozReview-Commit-ID: IyuT9O2F4EZ
--HG--
extra : rebase_source : 74b29eb5970c67aed6ca568d1882e3b6c54a6637
This ensure that the first sample demuxed will be identical to the first
one demuxed following a seek to the beginning.
Also, only demux the next packet when none is queued rather than all the time.
MozReview-Commit-ID: 5wtFVLiCAW
--HG--
extra : rebase_source : ce73d35f68fb800608a1182843de1d4abd469081
Not on by default yet. use media.format-reader.ogg preference
MozReview-Commit-ID: 7pH67XERTbW
--HG--
extra : rebase_source : 9868f07f622782b4859b95f237f7ee516345c2b2
In practice I'm pretty sure these cases wouldn't have a content docshell anyway.
We probably don't need more robust machinery here, since eventually we'll just
make stylo pref-based for every new prescontext regardless of type.
Use the new FrameStatistics members to report telemetry about inter-keyframe
timings.
MozReview-Commit-ID: 1ZWU2qpSWyC
--HG--
extra : rebase_source : f13fffc2bc81ad6090c3f494cc99e1d198f3256d
FrameStatisticsData can now store inter-keyframe information, which is
provided by the MediaFormatReader (based on live decoding).
MozReview-Commit-ID: HhBy6pgT6ZX
--HG--
extra : rebase_source : 6a072623e8a5b0f23b81307e8ea4b19a3e21b252
HTMLVideoElement can expose its thread-safe FrameStatistics object, so that
HTMLMediaElement can access more adequate data for its telemetry, without
having to use an intermediary (and potentially less accurate)
VideoPlaybackQuality object.
This will also help with accessing other/new FrameStatistics members later on.
MozReview-Commit-ID: AT7mEGy0zGr
--HG--
extra : rebase_source : 35bf6673cc0acd9d4e6e1a58c573749689614d43
Decoders now use FrameStatisticsData to gather data for their frame-related
notifications. This will ease introducing new members later on.
MozReview-Commit-ID: DWdOSPX3JM
--HG--
extra : rebase_source : a3e05f34353a397d1c82b3f4d935c0864f90556e
Decoders uses 64-bit values to count frames, so we should use the same type
in FrameStatistics.
Because VideoPlaybackQuality can only use 32 bits (as defined in W3C specs),
we need to ensure that imported FrameStatistics numbers can fit in 32 bits,
while keeping their ratios the same.
MozReview-Commit-ID: 3pUTGK0ekGv
--HG--
extra : rebase_source : 627fada111b51b8830fd38bf6d60a79b899ce603
Move FrameStatistics' data into separate struct, so that it can more easily be
changed and passed around, outside of the lock-controlled FrameStatistics
object.
MozReview-Commit-ID: TfsMRJhVfQ
--HG--
extra : rebase_source : 8c4c6a23c8c2d6ff4272f9f918c9510326691148
