Bug 37390 – [GStreamer] Apple trailers not playing

• Component: Media
• Status: RESOLVED FIXED

[Bastien Nocera]

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

[Philippe Normand]

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.

[Philippe Normand]

Created attachment 55701 [details]
proposed patch

[Bastien Nocera]

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.

[Philippe Normand]

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?

[Bastien Nocera]

(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.

[Philippe Normand]

(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).

[Bastien Nocera]

Right. So the last problem is whether you want to hard-code a user-agent for a website into the webkit code.

[Gustavo Noronha (kov)]

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? =)

[Philippe Normand]

Thanks for the review Gustavo.
Landed the patch in http://trac.webkit.org/changeset/60219