We've had large numbers of shutdown hangs with the Windows H.264 decoder stuck
calling IMFTransform::ProcessOutput(), blocking shutdown. I can reproduce this
with videos with dimensions less than 32 pixels.
Chrome also encountered this with the WMF decoder:
https://bugs.chromium.org/p/chromium/issues/detail?id=373288
The WMF H.264 Decoder is documented to have a minimum resolution of 48x48 pixels.
So this patch causes us to reject H.264 files with either width or height less
than 48 pixels.
I have been able to play files down to 34x34 pixels on Windows 10, but it seems
safest to just follow the what's documented in MSDN, and reject files that are
smaller than the documented minimum.
MozReview-Commit-ID: 5peP6UGnAaB
--HG--
extra : rebase_source : 6e29812642bc3f8ca0f5b39b36064a6d50e09ea7
Change test files to specify the mime type of the file. This is checked
by media test manager so that changes in mochitest.ini are not needed.
MozReview-Commit-ID: 4hFQmRknBOY
--HG--
extra : rebase_source : b76a8dfe071dec320a7ebef8fc071e671278c1fa
This exercises the decoder update logic path that doesn't rely on
AudioSink to advance time.
MozReview-Commit-ID: EZ6lb8zsqTu
--HG--
extra : rebase_source : 36f8b33b1aaaba40ca378a4da4d9dfda311c571c
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 : 93e678aa762519d27444a57f8a12d2bd569b025d
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
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
Added a test WebM file containing resolution changes. This file has been added
to gPlayTests to test playback of such files. A new test has been added,
test_resolution_change.html, which reads a new test array,
gResolutionChangeTests, of media files containing resolution changes. This new
test check that after playing a file through at least one resolution change has
taken place.
MozReview-Commit-ID: 8yz1ccz8g6O
--HG--
extra : rebase_source : 3fddc9116e9a5d20afcf58d795d288875084a08e
Add tests to exercise seeking in cueless WebMs. These tests reproduce a subset
of the test_seek tests, namely the first 3. These tests have been added
separately from the test_seek ones to avoid additional logic required to handle
cueless WebMs in such test. Once random seeking for cueless WebMs is
implemented then these cases can be easily rolled into the existing test_seek
cases by moving the cueless WebM into the appropriate test array in the
manifest -- after which these tests can be removed.
MozReview-Commit-ID: DNwiSmMmALQ
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.
The once function should add and then remove an event listener after it is
invoked, but it appears to remove another event listener instead. This commit
adjusts that behaviour. Note that the dom/media/mediasource/test/mediasource.js
file has the same pattern and has been updated. This commit reflects using the
same changes to remedy the once function here.
MozReview-Commit-ID: DQ4bfxTQfjN
--HG--
extra : transplant_source : 7%8E%19%DB74e%23%1511%1C%89%7D5%98%DE%12%BA%A2
The owl.mp3 file and derivative is made of 128 0.026122s long samples , which gives us an actual duration of 3.343616s. However, when decoding those files, the first two samples are dropped by the CoreAudio and WMF decoder giving us an actual play time of 3.29s.
We have no way to determine the exact duration at the demuxing stage. External readers such as DirectShow or GStreamer would only report the decoded frames time, while the MediaFormatReader report the demuxed time.
There is no right answer here. So setting a duration that will allow all readers to pass the tests.
JW Wang
Kilik Kuo
Chris Pearce
Dan Glastonbury
Jean-Yves Avenard
Wes Kocher
ctai
Andrew McCreight
Bryce Van Dyk
Kaku Kuo
Louis Christie
Eugen Sawin
Sebastian Hengst
Carsten "Tomcat" Book
Randell Jesup
Maire Reavy