My understanding of bug 1531373 comment 10 is that the site has a path for using MSE, and a path for downloading the whole video as a blob and using <video src=blob>. It appears that on desktop Firefox we're hitting the blob path (r.MSE=false), downloading the whole 56/157mb video in a single chunk (which takes forever), and then playing it. If we switch to forcing the MSE path (by editing the script, or UA spoofing) then we can see the individual MSE chunks being download, but the video doesn't ever play. That suggests either a bug in our MSE implementation, or a bug in the sites usage of MSE (but one that doesn't break blink's impl). On GeckoView, it appears that the video doesn't ever load, but we don't have much information on why. It seems plausible that we're taking the r.MSE=true path (the condition shows in bug 1531373 does check for Android), which appears to be broken. So I think the next steps here are: * Debug the site on GeckoView to identify which path we're taking to see if the difference is due to the UA sniffing returning different results. * Force the MSE path on Desktop, debug why the MSE attempts are failing and figure out if there's a Gecko bug.
Bug 1529812 Comment 16 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
My understanding of bug 1531373 comment 10 is that the site has a path for using MSE, and a path for downloading the whole video as a blob and using <video src=blob>. It appears that on desktop Firefox we're hitting the blob path (r.MSE=false), downloading the whole 56/157mb video in a single chunk (which takes forever), and then playing it. If we switch to forcing the MSE path (by editing the script, or UA spoofing) then we can see the individual MSE chunks being downloaded, but the video doesn't ever play. That suggests either a bug in our MSE implementation, or a bug in the sites usage of MSE (but one that doesn't break blink's impl). On GeckoView, it appears that the video doesn't ever load, but we don't have much information on why. It seems plausible that we're taking the r.MSE=true path (the condition shows in bug 1531373 does check for Android), which appears to be broken. So I think the next steps here are: * Debug the site on GeckoView to identify which path we're taking to see if the difference is due to the UA sniffing returning different results. * Force the MSE path on Desktop, debug why the MSE attempts are failing and figure out if there's a Gecko bug.