Closed Bug 1399019 Opened 7 years ago Closed 5 years ago

Cannot play Facebook 360 video using Firefox

Categories

(Core :: Audio/Video: Playback, enhancement, P2)

enhancement

Tracking

()

RESOLVED WORKSFORME
Webcompat Priority ?
Tracking Status
platform-rel --- ?

People

(Reporter: JamesCheng, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [webcompat][testcoverage][platform-rel-facebook])

It seems Facebook did not allow Firefox to play 360 videos. I can change User Agent to play... Anyway, I consult with Daosheng of graphics team, he told me the performance has been improved. Shall we contact Facebook to do some change for Firefox?
Hi Blake or Anthony, Do you know which bug discussed this issue that Facebook prevent us from playing 360 videos? Could you please help to contact the Web-Compatibility team for help? Thanks
Flags: needinfo?(bwu)
Flags: needinfo?(ajones)
Whiteboard: [webcompat]
It used to work per Bug 1313305. I am going to contact FB and cc you.
Flags: needinfo?(bwu)
Flags: needinfo?(ajones)
Whiteboard: [webcompat] → [webcompat][testcoverage]
Priority: -- → P2
See Also: → 1322691
By testing https://www.facebook.com/360tube I can play it well on Windows. But I cannot play it on my Mac(I think it's websites problem). But I can play 360 videos by other sites searching from Facebook. So I think this issue has been solved.
BTW, I used Nightly for testing.
Mike, Per James' comment 3, it looks like web compat issue. Can we have your team's help on this?
Flags: needinfo?(miket)
For me, using 58/Nightly, 360 video on Windows works without any UA spoofing. On Mac, I get an error: Error: The manifest specifies content that cannot be displayed on this browser/platform. That comes from the following bit of code, in https://www.facebook.com/rsrc.php/v3/yX/r/0j2yMx99T9n.js: n.Na = function () { if (this.D) { var a = Error('Cannot call load() right now.'); a.type = 'app'; return Promise.reject(a) } if (!this.a || 0 == this.a.a.length) return a = Error('The manifest does not specify any content.'), a.type = 'stream', Promise.reject(a); ye(this.a.a); if (0 == this.a.a.length || 0 == this.a.a[0].a.length || !this.a.a[0].a.some(function (a) { return 'video' === a.contentType })) return a = Error('The manifest specifies content that cannot be displayed on this browser/platform.'), a.type = 'stream', Promise.reject(a); this.D = !0; this.ua || (this.g.initialStreamBufferSize = Math.max(this.g.initialStreamBufferSize || 0, this.a.c)); Ye(this); Ze(this); return Promise.resolve() }; Manually inspecting this.a.a[0].a, we've got an array of 2 objects (with a bunch of props... it's super huge! https://gist.github.com/miketaylr/b0a4ad86ee440e2788b035472eebb3a7) and one has contentType: "video", and the other contentType: "audio". So somewhere there's a manifest saying Firefox on Mac can't handle whatever audio stream this thing is trying? There's some mp4 stream info in that gist link above if someone wants to poke at that. > But I can play 360 videos by other sites searching from Facebook. James, can you give an example of a URL? Dennis, would you be able to try to hunt down this manifest (assuming there's some client side evidence of it existing)? I tried spoofing as Windows, and my Mac still threw this error.
Flags: needinfo?(miket)
Flags: needinfo?(jacheng)
Flags: needinfo?(dschubert)
I played video from https://www.facebook.com/360-Video-1717450378471285/ (randomly select 360 video searching from Facebook) But I can play https://www.facebook.com/360tube without error today......don't know why.
Flags: needinfo?(jacheng)
Yikes. So, hunting down this manifest actually lead towards nothing. It is not generated on the client, but it's also not really important. The original manifest only contains a list of audio tracks, video tracks and available metadata like subtitles. Most videos on Facebook are encoded in a lot of different video and audio codecs as well as different resolutions and framerates, so this makes sense. There is a function that then filters out video and audio tracks which can't be played by the browser. Facebook is not using any user agent based information, but rather calls out to `MediaSource.isTypeSupported()`. For some reason, some 360° videos are only available as `video/webm; codecs="vp9"`. `MediaSource.isTypeSupported('video/webm; codecs="vp9"')` returns false, and so the only available video stream gets removed from the manifest, which is why Facebook errors out. While we support webm via MSE, it's pref'ed off per default. There is bug 1261273 for that. Enabling `media.mediasource.webm.enabled` results in the video being played just fine. I don't really know the history or the current state of webm, but this is the way to go here. Surprisingly, when asking `HTMLMediaElement.canPlayType()` about webm with vp9, it returns 'probably', and in my tests, we can play webm just fine, even if MSE is disabled. However, I don't know if there is a second decoding path going on, but I assume so. Since Facebook is using MSE, they are doing the right thing here with using the MSE codec detection. Would be interesting to know why some videos are reencoded into h264 while others are not. An alternative solution could also be to have Facebook always deliver multiple codecs to us, not just webm.
Flags: needinfo?(dschubert)
Depends on: 1261273
Thank you Dennis! Let's let Media folks decide which avenue they want to take.
platform-rel: --- → ?
Whiteboard: [webcompat][testcoverage] → [webcompat][testcoverage][platform-rel-facebook]
(In reply to Dennis Schubert [:denschub] from comment #8) > Would be interesting to know why some videos are reencoded into h264 while > others are not. An alternative solution could also be to have Facebook > always deliver multiple codecs to us, not just webm. the decision on making webm/vp9 available in MSE is largely driven by the fact that currently only YouTube uses VP9. YouTube will always prefer VP9 over H264 if its available. On most platforms, VP9 is software decoded. In order to improve the overall user experience, we decided on slow machine to not make VP9 available, just so that H264 would be preferred. Hopefully, with the use of MediaCapabilities, one could determine if VP9 is available and will be power efficient, and if not use h264 instead. The would remove the need for such drastic decision
No longer depends on: 1261273
Depends on: 1261273

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

Testing with https://www.facebook.com/intothesky360/posts/299016847423495, this is working now on macOS.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.