Bug 37390 - [GStreamer] Apple trailers not playing
Summary: [GStreamer] Apple trailers not playing
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-10 12:07 PDT by Bastien Nocera
Modified: 2010-05-26 00:19 PDT (History)
3 users (show)

See Also:


Attachments
proposed patch (2.40 KB, patch)
2010-05-11 07:18 PDT, Philippe Normand
gns: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bastien Nocera 2010-04-10 12:07:46 PDT
1. Go to any Apple trailers page like:
http://trailers.apple.com/trailers/paramount/dinnerforschmucks/
2. Click on "Watch now"
3. Gray area pops up, and no movie

Do the same thing in Firefox, with Totem's QuickTime-compatible NarrowSpace plugin, and it will work as expected.

The builtin video support should only kick in when:
- Playing in "full-screen" (when mode is NP_FULL)
or
- When a plug-in handling the mime-type is already available
or (obviously)
- When a video or audio tag is used
Comment 1 Philippe Normand 2010-05-10 10:07:45 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.
Comment 2 Philippe Normand 2010-05-11 07:18:26 PDT
Created attachment 55701 [details]
proposed patch
Comment 3 Bastien Nocera 2010-05-11 15:49:32 PDT
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.
Comment 4 Philippe Normand 2010-05-12 08:50:36 PDT
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?
Comment 5 Bastien Nocera 2010-05-13 08:56:43 PDT
(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.
Comment 6 Philippe Normand 2010-05-13 09:15:26 PDT
(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).
Comment 7 Bastien Nocera 2010-05-13 09:50:34 PDT
Right. So the last problem is whether you want to hard-code a user-agent for a website into the webkit code.
Comment 8 Gustavo Noronha (kov) 2010-05-25 21:21:13 PDT
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? =)
Comment 9 Philippe Normand 2010-05-26 00:19:11 PDT
Thanks for the review Gustavo.
Landed the patch in http://trac.webkit.org/changeset/60219