Closed
Bug 874277
Opened 11 years ago
Closed 11 years ago
3GP and MP4 support for YouTube
Categories
(Tech Evangelism Graveyard :: Preinstalled B2G Apps, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: kward, Unassigned)
Details
(Whiteboard: [apps watch list1])
YouTube has told Mozilla to pull their app from Pre-load and Marketplace until 3GP is supported. 3GP is not currently in scope for v1.0.1.
Updated•11 years ago
|
Component: Preinstalled B2G Apps → Video/Audio
Product: Tech Evangelism → Core
Updated•11 years ago
|
Whiteboard: [apps watch list1] → [apps watch list]
Reporter | ||
Updated•11 years ago
|
Component: Video/Audio → Preinstalled B2G Apps
Product: Core → Tech Evangelism
Whiteboard: [apps watch list] → [apps watch list1]
Comment 1•11 years ago
|
||
3GP support would be implemented in the core video/audio component. It's not a tech evangelism bug. Also, this is a platform issue technically, which classifies itself as the general apps watch list. apps watch list1 is only for issues the app reviewers care about.
Component: Preinstalled B2G Apps → Video/Audio
Product: Tech Evangelism → Core
Comment 2•11 years ago
|
||
Note that we would prefer Youtube serve WebM or mp4 to their html5 app. Those are the supported video formats for the Firefox OS and the general web. I assume that was why it was marked evangelism?
Comment 3•11 years ago
|
||
(In reply to Ralph Giles (:rillian) from comment #2) > Note that we would prefer Youtube serve WebM or mp4 to their html5 app. > Those are the supported video formats for the Firefox OS and the general web. On v1.0.1 MP4 and 3GP are only supported in the B2G video application as it requires privileged access to the hardware decoder. Third party apps (presumably like YouTube) won't be able to play them.
Comment 4•11 years ago
|
||
To clarify: in b2g 1.0.1 only webm decoding is available to web pages and apps. In 1.1 we expect both WebM and mp4 to be supported.
Updated•11 years ago
|
Whiteboard: [apps watch list1] → [apps watch list]
Comment 5•11 years ago
|
||
(In reply to Ralph Giles (:rillian) from comment #2) > Note that we would prefer Youtube serve WebM or mp4 to their html5 app. > Those are the supported video formats for the Firefox OS and the general web. We would first need to solve bug 780821 first before considering this. YouTube under a Firefox OS user agent serves a mostly broken site. In Firefox OS, we are spoofing the user agent using a user agent override to get served the same content as Firefox for Android. As a result, we're getting the vnd protocol FxAndroid gets. Under this condition, we stream the media content derived from the vnd protocol directly in Gaia's video application. The long term solution to this problem that YouTube already supports is to get served a HTML 5 YouTube mobile site using h264 media content. This is along the lines of what IPhone gets served right now. (In reply to Chris Double (:doublec) from comment #3) > On v1.0.1 MP4 and 3GP are only supported in the B2G video application as it > requires privileged access to the hardware decoder. Third party apps > (presumably like YouTube) won't be able to play them. In YouTube's case though, the media content is playing within the context of Gaia Video's application, which is a certified application. Wouldn't that potentially mean we are able to play h264 content in this scenario? I believe we've had h264 decoder bugs in relation to YouTube, so that might explain why the YouTube case works if we're rendering the media content within a certified application. (In reply to Ralph Giles (:rillian) from comment #4) > To clarify: in b2g 1.0.1 only webm decoding is available to web pages and > apps. In 1.1 we expect both WebM and mp4 to be supported. Correct. Although see my discussion above - since we stream YouTube media content within the Gaia Video application, I think we are allowed to play h264 content derived from YouTube in the video app, given that the video app is a certified app. Keep in mind that this bug focuses on implementing a stable solution for 3GP media content on Firefox OS that YouTube can safely take advantage of. Based on my understanding of some initial testing that was done, 3GP media content did not play too well, which lead to the filing of this bug.
Comment 6•11 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #5) > Keep in mind that this bug focuses on implementing a stable solution for 3GP > media content on Firefox OS that YouTube can safely take advantage of. Based > on my understanding of some initial testing that was done, 3GP media content > did not play too well, which lead to the filing of this bug. Comment 0 says that they pulled their app because it doesn't play 3GP. Which would be correct, their app can't play 3GP because of permissions issues. I assume their app isn't handing off to the video app. I didn't think this bug was about playing 3GP in the browser.
Comment 7•11 years ago
|
||
(In reply to Chris Double (:doublec) from comment #6) > (In reply to Jason Smith [:jsmith] from comment #5) > > Keep in mind that this bug focuses on implementing a stable solution for 3GP > > media content on Firefox OS that YouTube can safely take advantage of. Based > > on my understanding of some initial testing that was done, 3GP media content > > did not play too well, which lead to the filing of this bug. > > Comment 0 says that they pulled their app because it doesn't play 3GP. Which > would be correct, their app can't play 3GP because of permissions issues. I > assume their app isn't handing off to the video app. I didn't think this bug > was about playing 3GP in the browser. Their app is handing off to the video app (if you want to test this, you can test this quickly by going to m.youtube.com site and play a video, as that's exactly the same content the app is). Whenever a user selects a video on YouTube, we get a vnd protocol served to us. We parse it, move to the Gaia video app, and stream the content from the parsed result. I'm not 100% sure if this is a permissions issue however if we're streaming the content within the context of a certified app. I thought the email threads that talked about the problem here was a stability problem, not a permissions problem.
Comment 8•11 years ago
|
||
Btw, there's a meeting at 8am PST to talk about this tomorrow, so I'll have a better grasp of the issue here after that meeting.
Comment 9•11 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #7) > > I'm not 100% sure if this is a permissions issue however if we're streaming > the content within the context of a certified app. I thought the email > threads that talked about the problem here was a stability problem, not a > permissions problem. Their existing m.youtube.com site does indeed hand off to the video app. The app I tried that this issue is about tries to play inline which fails due to a permissions issue. I just tested on v1.0.1.
Updated•11 years ago
|
Component: Video/Audio → Preinstalled B2G Apps
Product: Core → Tech Evangelism
Whiteboard: [apps watch list] → [apps watch list1]
Comment 10•11 years ago
|
||
Per talking in the meeting, the root cause of this problem is related to the fact that YouTube wants 3GP content served through their HTML 5 mobile site. The TE portion of this bug refers to getting a YouTube app that allow us to use that 3GP content. The app will plan on being a certified preinstalled app that uses an iframe to youtube's https m.youtube.com site. That will allow us to use the hardware codec to play 3GP media content.
Reporter | ||
Updated•11 years ago
|
Summary: 3GP support for YouTube → 3GP and MP4 support for YouTube
Comment 11•11 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #10) > > The app will plan on being a certified preinstalled app that uses an iframe > to youtube's https m.youtube.com site. That will allow us to use the > hardware codec to play 3GP media content. We need to be really, really careful here. In order to use the h264 decoder hardware, apps need the deprecated-hwvideo permission. Currently Camera, Gallery and Video have it. There is only one hardware decoder, however, so only one app can be playing a video at a time. This means until we have gecko support for sharing the hardware, apps that have this permission must bend over backward to play nice with each other. Generally, this means that when an app goes into the background, it releases the video hardware. In the Video app, I listen for mozvisiblitychange events and don't just pause the playing video. I actually replace the video with a still image and manually unload the video with code like this: player.removeAttribute('src'); player.load() This apparently releases the video hardware and allows other apps to use it. If we just put an iframe around youtube's mobile site, we can grant them the required permission, but we can't make them cooperate with the other apps that have the permission. So I fear that creating a youtube app like this will break other apps that need to use the video hardware. Chris, can you comment on this? Are my fears unfounded? Can we make gecko automatically release the hardare when it is hidden? (Or is that what Sotaro is working on doing for v1.1?)
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(chris.double)
Comment 12•11 years ago
|
||
> > Chris, can you comment on this? Are my fears unfounded? Can we make gecko > automatically release the hardare when it is hidden? (Or is that what > Sotaro is working on doing for v1.1?) For v1.1, I am implementing "gecko automatically release the hardware when it is hidden" capability in Bug 831747 and Bug 871485.
Flags: needinfo?(sotaro.ikeda.g)
Comment 13•11 years ago
|
||
(In reply to David Flanagan [:djf] from comment #11) > Chris, can you comment on this? Are my fears unfounded? Can we make gecko > automatically release the hardare when it is hidden? (Or is that what > Sotaro is working on doing for v1.1?) For v1.0.1 the app author will have to set the video element src to an empty url and call .load() to release it. Another approach is to close the app when they switch away from it.
Flags: needinfo?(chris.double)
we could make the packaged wrapper detect when the visibility of the app is set to hidden and then set the .src of the iframe to the empty URL. then set it back to the YouTube front page when the app is visible again. Jason, can you test that this works when switching between the YouTube wrapper and the video app and back?
Comment 15•11 years ago
|
||
(In reply to Jonas Sicking (:sicking) from comment #14) > we could make the packaged wrapper detect when the visibility of the app is > set to hidden and then set the .src of the iframe to the empty URL. then set > it back to the YouTube front page when the app is visible again. > > Jason, can you test that this works when switching between the YouTube > wrapper and the video app and back? This means, of course, that if you're watching a video and get a phone call, the video will be gone when you hang up. Any chance we could do anything clever in the shadow dom that goes along with the video element? I don't remember where the file is, but I'm thinking of the one that implements the video controls. If it could listen for visiblity changes, it could save the playback time, replace the video with a still image, and then restore the video when needed. This is what I do manually in the video app.
Comment 16•11 years ago
|
||
David, this is https://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/videocontrols.xml?force=1 I think that's an interesting idea, but probably out of scope for 1.0.1 unfortunately.
Comment 17•11 years ago
|
||
Please test with http://m.youtube.com/?player=html5 , confirmed MP4 working and showing video on 1.1. The URL I posted before with player=html5fs doesn't show the video when playing. I can verify with YT on what the difference is.
Comment 18•11 years ago
|
||
I tried the URL given in comment 17 with my test certified app. I'm getting a spinner spinning infinitely when I try to view a youtube video.
Comment 19•11 years ago
|
||
Note comment 18 is for 1.1 and 1.01.
Comment 20•11 years ago
|
||
Actually, bad network during testing in comment 18. Let me try on a better network....
Comment 21•11 years ago
|
||
Confirmed this time that the video played on 1.1 with my test app. Now retesting again on 1.01.
Comment 22•11 years ago
|
||
Also confirmed that the YouTube solution that is a certified app allows playing media content in mozbrowser iframe using the URL src from comment 17. Double checked that I couldn't play the videos in the browser. So our certified app solution with an mozbrowser iframe is on the table as a potential solution. I'll look into Jonas's idea shortly.
(In reply to David Flanagan [:djf] from comment #15) > This means, of course, that if you're watching a video and get a phone call, > the video will be gone when you hang up. I think that's something that we can live with for v1.0.1. We already have a better solution in place for v1.1. If we can think of a solution that doesn't have this problem then of course that's something we should evaluate. However given how late we are, our options are very limited. > Any chance we could do anything clever in the shadow dom that goes along > with the video element? I don't remember where the file is, but I'm > thinking of the one that implements the video controls. If it could listen > for visiblity changes, it could save the playback time, replace the video > with a still image, and then restore the video when needed. This is what I > do manually in the video app. This sounds too risky for v1.0.1.
Comment 24•11 years ago
|
||
Just for those who don't know the news - the certified app solution is completely off the table at this point. The only option left right now is to enable h264 content on the web.
Comment 25•11 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #24) > Just for those who don't know the news - the certified app solution is > completely off the table at this point. The only option left right now is to > enable h264 content on the web. why is the certified app solution off the table?
Comment 26•11 years ago
|
||
(In reply to Fabrice Desré [:fabrice] from comment #25) > (In reply to Jason Smith [:jsmith] from comment #24) > > Just for those who don't know the news - the certified app solution is > > completely off the table at this point. The only option left right now is to > > enable h264 content on the web. > > why is the certified app solution off the table? I'll forward you the email that explains this.
Comment 27•11 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #24) > Just for those who don't know the news - the certified app solution is > completely off the table at this point. The only option left right now is to > enable h264 content on the web. Jonas, Fabrice: does this make you want to re-consider my idea in comment #15? I made that hack work once in the Video app, so am willing to try doing the same thing in videocontrols.xml. I'll probably need Fabrice's help for gecko/chrome stuff.
Comment 28•11 years ago
|
||
> Jonas, Fabrice: does this make you want to re-consider my idea in comment
> #15? I made that hack work once in the Video app, so am willing to try
> doing the same thing in videocontrols.xml. I'll probably need Fabrice's help
> for gecko/chrome stuff.
I should add that if we can uplift the work Sotaro is doing for 1.1 that would obviously be a better solution.
Reporter | ||
Comment 29•11 years ago
|
||
Update from Rick Fant email (5/22): Andreas - first, let me say thanks to the team for the effort on this. Google has said no to an interim solution (i.e. Certified app) - essentially they see a lot of work for them to package and they worry about a security hole. They have been clear that they want to ship a permanent solution. The other option that was discussed, was a patch to the current version that allows the production version of YT to operate (downloaded from Marketplace - no pre-install). YT (and me) see that as the best option and so we need to know if uplift or patch is feasible
Comment 30•11 years ago
|
||
We resolved this TE situation - 1.01 is out now. For 1.1, we enabled 3GP in bug 876099 for 1.1 in the web. 1.1 also supports playing h264 content in the web.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•5 years ago
|
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•