Summary: | [GStreamer] Apple trailers not playing | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Bastien Nocera <bugzilla> | ||||
Component: | Media | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | chpe, pnormand, xan.lopez | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | PC | ||||||
OS: | Linux | ||||||
Attachments: |
|
Description
Bastien Nocera
2010-04-10 12:07:46 PDT
It seems r56650 introduced this "bug". It enables proxying to a MediaElement. It actually works but the User-Agent is not set "apple-friendly" by the FrameLoader in this case and that's why you see nothing. Apple webserver sents a 302 response because of that ... user-agent filter they have. Created attachment 55701 [details]
proposed patch
I don't agree with that patch one bit. The patch still doesn't allow for the controls to be used in the display, because the web page expects a plugin compatible with QuickTime, not builtin HTML5 video support. If I wanted that sort of patches to get into WebKit, I would have mentioned what the work-around was. I want WebKitGTK to stop taking over <embed> and <object> mime-types that are handled by plugins. See http://trailers.apple.com/trailers/global/scripts/lib/ac_media.js // added a check for Google Chrome; until they fix their .mov wrapper bug we can't serve the <video> element 135 if (shouldBuildMediaSpecVideo && Media._isHTML5VideoAvailable() && 136 !Media.Detection.Firefox() && !Media.Detection.Mobile() && 137 !Media.Detection.Chrome()) { 138 // Create <video> player 139 return build(Media.Spec.Video); 140 } 141 142 if (shouldBuildMediaSpecQuickTime && 143 Media._isQuickTimeAvailable(Media.MIN_QUICKTIME_VERSION) || 144 Media.Detection.Mobile()) { 145 // Create QuickTime player 146 return build(Media.Spec.QuickTime); 147 } So the logic is to check if the browser supports HTML5 video and video/mp4. If so a video element is created instead of an <object>... So, not sure what I can actually do. I won't blacklist video/mp4 from our player. Have you tried the patch? (In reply to comment #4) > See http://trailers.apple.com/trailers/global/scripts/lib/ac_media.js > > // added a check for Google Chrome; until they fix their .mov wrapper bug we can't serve the <video> element <snip> > So the logic is to check if the browser supports HTML5 video and video/mp4. If so a video element is created instead of an <object>... So, not sure what I can actually do. I won't blacklist video/mp4 from our player. Have you tried the patch? Right, it's my mistake for thinking that WebKitGTK was taking over from the <embed> property. Are you sure that's what it's doing? I still don't understand why a User-agent matching *QuickTime* (as opposed to one matching the Safari version) would make a difference to the website, if you were using a <video> tag. (In reply to comment #5) > Right, it's my mistake for thinking that WebKitGTK was taking over from the <embed> property. Are you sure that's what it's doing? > Well yeah that's what I conclude. I could see in gdb that the video element is created from Javascript. I also tested with Chromium, no <video> element is created, likely because of the checks in that js script. I could be wrong but I didn't see any place in WebKit code where we replace an <object> with a <video> element. > I still don't understand why a User-agent matching *QuickTime* (as opposed to one matching the Safari version) would make a difference to the website, if you were using a <video> tag. That confused me too. I think we never correctly sent the "Quicktime" UA. I don't see how it could work in the current call order, there was no change in the frameloader changing the behavior. You currently only see a gray rectangle because our player get a 302 error from apple webserver, because we don't send the correct user-agent (I checked with wireshark). Right. So the last problem is whether you want to hard-code a user-agent for a website into the webkit code. Comment on attachment 55701 [details]
proposed patch
Can I suggest renaming this bug report before committing, and making sure the changed name is reflected in the ChangeLog, since your investigation concluded it has nothing to do with WebKitGTK+ taking over from plugins? =)
Thanks for the review Gustavo. Landed the patch in http://trac.webkit.org/changeset/60219 |