Also, remove no longer used code and update comments to properly reflect the current algorithms used.
MozReview-Commit-ID: GwsGC70xM85
--HG--
extra : rebase_source : 2c1a2cd449eac243d8e3d77cc1bf80c2adc64cdf
20MB appears to work, but just to be safe until we get confirmation from YouTube on what is a safe value to use.
MozReview-Commit-ID: BnGaVLeCRJ5
--HG--
extra : rebase_source : 6333dd4c8dbd6f846344218dd50124797fc5cb23
Bug 1216460 introduced a regression which would cause to always evict from both ends of the current track buffer.
MozReview-Commit-ID: 4f01tNQ2KU8
--HG--
extra : rebase_source : 7da96fc1cbca03d60705fce681ee9259dd81d173
It was possible for a TrackBuffersManager to have pending tasks currently running while the MediaSourceDemuxer was shutting down the task queue. This would cause an assertion upon resolution of the promise attempting to schedule a new runnable as the task queue was now shutdown.
The AutoTaskQueue only shuts down once it's no longer used.
MozReview-Commit-ID: IzPh2OdGbvN
--HG--
extra : rebase_source : 3b39ca72f1bbb1d64e7f9f7a376b5b9cb68da0f6
Just like TaskQueue, but doesn't require to be shutdown.
MozReview-Commit-ID: 9JR9mZZuP4w
--HG--
extra : rebase_source : c98aaafdad31e34afe7a58d1113f5835f777c1c0
We now longer require an abstraction layer with the TrackBuffersManager now that the old MSE has been removed.
MozReview-Commit-ID: 3uEejohvFQD
--HG--
extra : rebase_source : 2e89fe4c7b9d13910fb6f26f0090fca26d19726f
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
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
So far we've simply assumed that the first MPEG Layer 3 frame sync we find is automatically valid. However if the audio data has been improperly cut, parsing might start somewhere in mid-stream, so the first frame sync we hit upon might be a false positive. This naturally leads to problems if we try to check later frame syncs for consistency (same MPEG version, sample rate, etc.) with that first frame sync.
Therefore, this patch changes demuxer initialisation to only accept a frame sync if it is followed by a number of further frame syncs consistent with the initial frame.
There are a long tail of C4311 and C4312 warnings in VS2015. Rather than
wait until all of them are fixed to land VS2015, we're taking the easy
way out and disabling these warnings in every directory currently
exhibiting a warning. This is evil. But it is a lesser evil than
globally disabling C4311 and C4312. At least with this approach new
C4311 and C4312 warnings in directories that aren't suppressing them
shouldn't be introduced.
MozReview-Commit-ID: 2cwWrjMD6B9
--HG--
extra : rebase_source : 3e7b8ea042765fdf138f5ca93a0f9dab75a95fcd
BaseFirefoxTestCase inherits from unittest.TestCase and takes
advantage of super() to serve as a cooperative base class
for children of MarionetteTestCase.
This includes moving UpdateTestCase back into firefox-ui-harness
Also update external-media-tests and Firefox UI and Update tests to
use BaseFirefoxTestCase
MozReview-Commit-ID: 4gsKztEOFrt
--HG--
rename : testing/puppeteer/firefox/firefox_puppeteer/testcases/update.py => testing/firefox-ui/harness/firefox_ui_harness/testcases.py
extra : rebase_source : e3383f9633f26061af9521a719cae57db87ccf10
Following bug 1223599, NotifyDataArrived is called extremely often (every 32kB block downloaded). The combination of pinning the MediaResource with small cache reads while reading on another thread can causes incorrect read.
While this issue needs to be addressed, the special handling of NotifyDataArrived with DirectShow ultimately serves no purpose. By the time we have read the metadata, we have already identified if the MP3 has a known duration. If not, the duration will be amended as data is being returned to the MDSM.
Continually feeding new data to the MP3FrameParser only allow to account for the new data downloaded ahead of the last decoded sample and to get a slightly more accurate buffered range and duration.
The new MP3Demuxer doesn't do it, and ultimately this makes the DirectShowReader behaves like the new MP3Demuxer and gives us consistency across the readers.
MozReview-Commit-ID: HKNWWrofIqV
--HG--
extra : rebase_source : 88d8ef9206e8a16097b2d493681e88b4c174d0c5
* Move eviction handling out of SourceBuffer into TrackBuffersManager
* Separate audio and video eviction thresholds
* Reduce default audio eviction threshold to 15MB
Carsten "Tomcat" Book
JW Wang
Sotaro Ikeda
Randell Jesup
Kyle Huey
Jean-Yves Avenard
Alex Chronopoulos
Gerald Squelart
Bryce Van Dyk
Jan-Ivar Bruaroey
Chris Pearce
Jan Henning
Martin Thomson
Phil Ringnalda
Gregory Szorc
Maja Frydrychowicz
David Anderson
Wes Kocher
Syd Polk
Ruxton
Eugen Sawin