In this patch, we assign the Media Engine Id to the format reader, and append that Id into CreateDecoderParams when we want to create a decoder.
That Id would be used as a hint in order to find a correct decoder to send the data to the remote media engine in following patches.
Depends on D139204
Differential Revision: https://phabricator.services.mozilla.com/D140153
In this patch, we assign the Media Engine Id to the format reader, and append that Id into CreateDecoderParams when we want to create a decoder.
That Id would be used as a hint in order to find a correct decoder to send the data to the remote media engine in following patches.
Depends on D139204
Differential Revision: https://phabricator.services.mozilla.com/D140153
In future parts, TaskQueue will require extra initialization to be performed
which cannot happen in a constructor, as it takes references to the TaskQueue
object itself, which will require the introduction of a helper method. This
patch switches all callers of the TaskQueue constructor to use the new method.
Differential Revision: https://phabricator.services.mozilla.com/D142604
This is closer to the place where we decide to actually
skip decoding. Eventually, we can flesh this marker out
with information about the decision to skip as needed.
Differential Revision: https://phabricator.services.mozilla.com/D142698
Add media.rdd-process.max-crashes preference value to control how many times we restard RDD process before we throw decoding error message.
Differential Revision: https://phabricator.services.mozilla.com/D142326
- If decoding fails on Linux (with NS_ERROR_DOM_MEDIA_DECODE_ERR), give it another try without HW decoder.
- If RDD/GPU process crashed on Linux, give it another try without HW decoder.
Differential Revision: https://phabricator.services.mozilla.com/D138271
Improve the readability of the check and remove the next key frame check for the internal seek target because it's not related.
Differential Revision: https://phabricator.services.mozilla.com/D118401
If the decoded video MDSM received is already late, then it indicates that video decoding is too slow.
If we keep decoding but in the same speed, it's very likely all following decoded videos would still be behind the clock and need to be discarded.
The reader has its own mechanism to seek to the next keyframe, but that will only happen when the time of next keyframe is behind the given time threshold, which is the current time.
When the video has pretty long keyframe interval (eg. 5s), then that mechanism won't be triggered because the even if the decoded video frames are late, the next keyframe still far exceeds the current time, so the reader doesn't think it's necessary to skip.
Therefore, MDSM should force the reader to seek to the next keyframe directly, because it know both the decoded time of video frames and the current playback time.
Differential Revision: https://phabricator.services.mozilla.com/D117242
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
We also ensure that the MediaFormatReader will only shutdown once the CreateDecoderPromise has been resolved (or rejected)
This makes a few of the earlier changes redundant; as we can now guarantee all the objects provided to the PDMFactory will stay valid for the entire lifetime of the decoder. So we could do away with P4 and P7.
It's better that we keep those however, as it greatly simplify other usage of the PDMFactory. Ensuring that the user of the PDMFactory survives any decoder isn't a trivial affair.
Differential Revision: https://phabricator.services.mozilla.com/D96369
P4 introduced a cycle between the MediaFormatReader and the onWaitingForKeyEvent lambda.
Normally, this cycle would be broken by a call to Shutdown.
However, should the MediaFormatReader shuts down before the CreateDecoderPromise be resolved, it would have no way of shutting down the decoder keeping the cycle alive.
Theoretically, keeping a plain pointer to the MFR::mOnTrackWaitingForKey like we did before P4 is safe, as the EME code making use of it, only does so while we are decoding data and the MFR has the ability to properly shutdown the decoder.
However, for the sake of clarity and simplification, we introduce an easier way to check of the MFR has been deleted already by making it support SafeThreadWeakPtr; and the OnWaitingForKey keep a weak pointer to it and checking the value before calling it.
Differential Revision: https://phabricator.services.mozilla.com/D96367
PDMFactory::CreateDecoder is changed to return a MozPromise that will contain the MediaDataDecoder once created.
This will allow to later make RemoteDecoderManager fully asynchronous and no longer require an IPC sync call to start the RDD process.
We also modify the WebrtcMediaDataDecoderCodec to never create a decoder on the main thread, which could cause deadlocks under some circumstances.
Differential Revision: https://phabricator.services.mozilla.com/D96364
Passing a pointer to an object across several thread was dubious at best to ensure a use after free was never in place.
This complexity becomes even greater should we want to create the decoder asynchronously.
So we pass instead a lambda that holds a strong reference to the object that holds the event producer.
Differential Revision: https://phabricator.services.mozilla.com/D96360
We also ensure that the MediaFormatReader will only shutdown once the CreateDecoderPromise has been resolved (or rejected)
This makes a few of the earlier changes redundant; as we can now guarantee all the objects provided to the PDMFactory will stay valid for the entire lifetime of the decoder. So we could do away with P4 and P7.
It's better that we keep those however, as it greatly simplify other usage of the PDMFactory. Ensuring that the user of the PDMFactory survives any decoder isn't a trivial affair.
Differential Revision: https://phabricator.services.mozilla.com/D96369
P4 introduced a cycle between the MediaFormatReader and the onWaitingForKeyEvent lambda.
Normally, this cycle would be broken by a call to Shutdown.
However, should the MediaFormatReader shuts down before the CreateDecoderPromise be resolved, it would have no way of shutting down the decoder keeping the cycle alive.
Theoretically, keeping a plain pointer to the MFR::mOnTrackWaitingForKey like we did before P4 is safe, as the EME code making use of it, only does so while we are decoding data and the MFR has the ability to properly shutdown the decoder.
However, for the sake of clarity and simplification, we introduce an easier way to check of the MFR has been deleted already by making it support SafeThreadWeakPtr; and the OnWaitingForKey keep a weak pointer to it and checking the value before calling it.
Differential Revision: https://phabricator.services.mozilla.com/D96367
Randell Jesup
alwu
Cristian Tuns
Alexandre Lissy
Nika Layzell
Paul Adenot
Jeff Muizelaar
stransky
Bryce Seager van Dyk
Noemi Erli
Butkovits Atila
Alexandru Michis
Simon Giesecke
Gerald Squelart
Razvan Maries
Sylvestre Ledru
Jean-Yves Avenard
Bogdan Tara