Calls that directly access GetResource() don't work properly Media Source Extensions because they bypass the MediaDecoderReader. We need to find a way to correctly route these calls through the reader rather than directly accessing the resource.
This has rather a lot of overlap with bug 1063323.
Word on the street is that we need resources in this area. I know nothing about it but am happy to take a swing at it. I have a few other things on my plate to finish first, but I'll take a look at the code sometime this coming week barring unforeseen emergencies elsewhere that require my attention.
If you look carefully at MediaSourceResource you will notice that most of the methods are not implemented. The problem is that MediaDecoderStateMachine is expecting each reader to have a Resource returned by GetResource(). MediaSourceReader has a number of instances of SourceBufferResource instead of just having a single MediaSourceResource so the 1 to 1 assumption falls apart. The trick is to figure out the cleanest way to get that functionality out of MediaDecoderStateMachine and into Reader. This makes it possible for MedisSourceReader to delegate more sensibly to the underlying Readers to fix bug 1063323.
I've been focusing on bug 1063323, since it's a more concrete deliverable and gives direction to the refactoring here. We can re-evaluate this once that lands and see what more needs to be done.
This bug is necessary for basic playback of EME video on Windows.
(In reply to Chris Peterson (:cpeterson) from comment #5) > This bug is necessary for basic playback of EME video on Windows. Can you point to a more specific bug where this issue is the culprit? I'd prefer to have specific functionality deliverables (that we can check in tests for) rather than refactoring in the abstract.
3 years ago
Good point. Thanks for asking. I was trying to group the current EME bugs into playback, sandbox, and UI milestones, but I see this MSE bug is not causing any specific problem.
Can we close this now?
(In reply to Bobby Holley (:bholley) from comment #9) > Sure. Note that there still may be places where this is a problem, but I don't think it's worth addressing the problem in the abstract.