Closed Bug 719694 Opened 12 years ago Closed 11 years ago

Video's do not play on Vimeo

Categories

(Web Compatibility :: Site Reports, defect)

ARM
Android
defect
Not set
normal

Tracking

(blocking-kilimanjaro:+, firefox17 affected, firefox18 affected, firefox19 affected, blocking-fennec1.0 -)

RESOLVED WORKSFORME
blocking-kilimanjaro +
Tracking Status
firefox17 --- affected
firefox18 --- affected
firefox19 --- affected
blocking-fennec1.0 --- -

People

(Reporter: aaronmt, Unassigned)

References

Details

(Whiteboard: [website-compatibility][H.264])

Could not find any equivalent bug searching for 'Vimeo'. They serve Fennec a mobile site, upon tap of the big play button on their videos, nothing happens.

<video id="cu" src="http://player.vimeo.com/play_redirect?quality=mobile&amp;clip_id=30203159&amp;time=1327028987&amp;sig=1d2bfd898673613e054e759a60c40feb&amp;type=mobile_site" x-webkit-airplay="allow"></video>

Example URL: http://vimeo.com/m/30203159

--
Samsung Galaxy SII (Android 2.3.4)
Mozilla/5.0 (Android; Linux armv7l; rv:12.0a1) Gecko/20120119 Firefox/12.0a1 Fennec/12.0a1
Mozilla/5.0 (Android; Linux armv7l; rv:11.0a2) Gecko/20120119 Firefox/11.0a2 Fennec/11.0a2
Whiteboard: [website-compatibility]
Component: General → Evangelism
QA Contact: general → evangelism
Spoofing the Fennec UA in Chromium at video.com/m/ and attempting to play a video doesn't work.

Uncaught Error: INVALID_STATE_ERR: DOM Exception 11 @ 

window.vimeo.playVideo
window.vimeo.initPage

I'm guessing it fails with this below? I'm not sure

"android"==this.browser&&a.webkitEnterFullscreen&&a.webkitEnterFullscreen()
Moving back to General for a dev to see if it's really an evangelism issue here
Component: Evangelism → General
QA Contact: evangelism → general
blocking-fennec1.0: --- → ?
Brian - we need to dig into what the problem is here.
Assignee: nobody → bnicholson
blocking-fennec1.0: ? → +
It looks like they're giving us h264 videos, which we don't support.

Changing the UA in desktop Firefox to Fennec also makes the video not play. Changing the UA in Chrome to Fennec *does* play the video for me, in contrast to Aaron's findings in comment #1.
Assignee: bnicholson → nobody
Component: General → Evangelism
QA Contact: general → evangelism
Nominating for k9o - This is regards to the h264 support k9o user story.
blocking-kilimanjaro: --- → ?
Re-noming since this is an evangelism issue it probably shouldn't block fennec release.
blocking-fennec1.0: + → ?
blocking-fennec1.0: ? → -
blocking-kilimanjaro: ? → +
Depends on: 748351
With patches from bug 714408 on b2g the audio plays but I get no video - the poster image stays there and the play button stays as 'play'.
Whiteboard: [website-compatibility] → [website-compatibility][H.264]
Update: Tested on mozilla-inbound (w/bug 759945 enabled), and playback functionality is still inoperable on Vimeo. Tapping the 'Play' control simply does nothing.
(In reply to Aaron Train [:aaronmt] from comment #11)
> Update: Tested on mozilla-inbound (w/bug 759945 enabled), and playback
> functionality is still inoperable on Vimeo. Tapping the 'Play' control
> simply does nothing.

Aaron - Can you provide more detail why this is evangelism issue with h264? What's failing exactly? A webkit prefix?
As mentioned prior, their player is failing to detect or recognize our implementation and or browser user-agent. Digging through their code did not yield any exact pin-point cause. Unfortunately, they seem to not respond to email as it has been two weeks now without a reply.
aaronmt - What e-mail address did you use to contact Vimeo? Can you confirm that spoofing the UA results in a functional Vimeo player?
Component: Evangelism → Mobile
Product: Firefox for Android → Tech Evangelism
Version: Trunk → unspecified
The issue is still reproducible on Firefox Mobile 17.0b3 using the Samsung Galaxy Tab 2 7.0 (Android 4.0.4) on both the mobile and desktop website(got desktop by requesting the desktop version). On mobile you actually get a play button but it does not work. On desktop you just get an image placeholder for the video. The issue also affects websites that use embedded vimeo videos like: http://films.bybrettjohnson.com/ where instead of the video the user just gets a black screen.
tracking-fennec: --- → ?
Summary: Video's do not play on mobile Vimeo → Video's do not play on Vimeo
Not tracking evangelism.
tracking-fennec: ? → ---
The Firefox Flicks team is talking to Vimeo today. Is someone able to summarize the issue for me so I can explain exactly what we need from them during our conversation?
In Firefox, Vimeo displays the message "This video won't work on this device". This is likely due to Vimeo UA detection that does not recognize Firefox as a browser capable of playing H.264 content.
(In reply to Lawrence Mandel [:lmandel] from comment #18)
> In Firefox, Vimeo displays the message "This video won't work on this
> device". This is likely due to Vimeo UA detection that does not recognize
> Firefox as a browser capable of playing H.264 content.

You get this on Firefox desktop and Firefox for Android builds that don't have H.264 support built in. On a nightly build on vimeo, when I click the video the poster image stays there but audio plays. The video does not.

This seems to indicate they are sending H.264 successfully but something is wrong with them detecting it is playing and updating their UI/controls. Or we have a bug in this area.
Looking at the 'logcat' when trying to play a video on Vimeo it does show that the H.264 decoder is being created and used which explains the audio playing.
(In reply to Chris Double (:doublec) from comment #20)
> Looking at the 'logcat' when trying to play a video on Vimeo it does show
> that the H.264 decoder is being created and used which explains the audio
> playing.

I confirm the audio playback comes through but no video playback on a galaxy S3, firefox 17 build.
(In reply to Tony Chung [:tchung] from comment #21)
> (In reply to Chris Double (:doublec) from comment #20)
> > Looking at the 'logcat' when trying to play a video on Vimeo it does show
> > that the H.264 decoder is being created and used which explains the audio
> > playing.
> 
> I confirm the audio playback comes through but no video playback on a galaxy
> S3, firefox 17 build.

Tony, can you confirm that this is vimeo specific?
Updates from Brad (from Vimeo, not blassey):

- Our mobile site allows SD files to be played if the window.devicePixelRatio is 2 or more. I'll be changing this slightly, but it looks like Firefox does not support this property in the current version (17), so videos will only work if there is a mobile version.

Chris, can you confirm?

- On the mobile site if there is a mobile version, it will play but it does so in the background. I will push out a quick update that will call mozRequestFullScreen so you can actually see the video.

I think this explains comments 21 and 22. I can confirm that some Vimeo videos now play in Firefox for Android.
window.devicePixelRatio (bug 564815) is supported in Firefox 18 which was released today.  However, it always returns 1 on Android because of bug 794056.

Even after that bug is fixed, many Android phones have a devicePixelRatio of 1.5, and many Android tablets have a devicePixelRatio of 1.0, so Vimeo still may not serve SD files to Firefox on those devices.
(Confirming full-screen video playback on a bunch of front-page videos for me is indeed working on my Nexus 7)
Got VIMEO working (cannot download videos in the window though) from VIMEO's interface though).
Short answer, with FIREFOX open, in C:\WINDOWS\ do a search for NPSWF32*.DLL
Then delete that file while FIREFOX remains open (you may be able to just re-register the file though).
Go to Adobe's website and download the Flash installer -- http://get.adobe.com/flashplayer/
Close FIREFOX. Reinstall Adobe Flash. Start FIREFOX.
Now VIMEO should be working again.

-----

Here is what I did to fix VIMEO & Firefox.
First, go to C:\WINDOWS\system32\Macromed\Flash
(Or search for npswf*.dll in the C:\WINDOWS\ folder)

For myself I found -- NPSWF32_11_6_602_168.dll
I wondered if VIMEO was looking for the generic NPSWF32.dll so I renamed NPSWF32_11_6_602_168.dll to NPSWF32.dll and restarted Firefox (which had VIMEO claiming that I didn't have Flash installed). I did this once before with FIREFOX 18 claiming I had multiple versions of Adobe Flash installed, didn't fix VIMEO then though.

Deleted the C:\WINDOWS\system32\Macromed\Flash\NPSWF32.dll
I already had downloaded the offline Adobe Flash installer, so I closed FIREFOX again, reinstalled Adobe Flash, waited until it finished, restarted FIREFOX.

My assumption is that FIREFOX 19 is looking for NPSWF32.dll, not finding it.
Somehow it already has a workaround in play, but until Windows registers a NPSWF32.DLL in existence, FIREFOX doesn't really know what to do.
Doing my little routine seems to force either FIREFOX or Windows to play nice and begin working properly again for VIMEO.

My bet is that FIREFOX has some coding looking explicitly for NPSWF32.DLL either in its own DLL files or in the software code.  When Adobe began naming the Flash files to NPSWF32_11_6_602_168.DLL then something began breaking in a non-traumatic way for FIREFOX with it showing up specifically on VIMEO.

Of course it could also be a screwy bit of registry choking nonsense where the software says, "Adobe Flash DLL is there, going ahead", but something else is saying, "THE REGISTRY ENTRY IS WRONG OR MISSING!" and refusing to work.
The fix might be as simple as running a "REGSVR32 NPSWF32_11_6_602_168.DLL" in the command line or doing a bit of "REGSVR32 /u NPSWF32_11_6_602_168.DLL" then "REGSVR32 NPSWF32_11_6_602_168.DLL" with perhaps doing a "REGSVR32 /u NPSWF32.dll" and/or "REGSVR32 NPSWF32.dll" just to cover all the bases.

I am using WINDOWS XP with FIREFOX v19.0
(In reply to Gridlock from comment #26)
Thanks for the comment but this bug is for playing videos using Firefox for Android
(In reply to adrian tamas from comment #27)
> (In reply to Gridlock from comment #26)
> Thanks for the comment but this bug is for playing videos using Firefox for
> Android

Figured it might be useful information anyway given that a bunch of similar Firefox code is going to be in play even on a Linux-based system (thusly any coding oddities such as looking for a specific file that is now named different by Adobe) that a coding error of this type from one OS might afflict another OS since Adobe is altering their file naming conventions.

Take the weirdness of Apple's iTunes issues on Windows versus being mostly stable on the Macs. Coding habits that don't translate well when switch OS conventions while trying to reuse as much of the initial code base model of operation. Wouldn't be the first time that these types of coding habits struck the final compiled job to enact all manner of strange results.
Not sure why this is still open, video's play for me on Vimeo fine now with their changes. The comments above should be filed as desktop bugs as this is an Android specific filing.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Any news? Except the audio playback, embedded Vimeo videos still doesn't work on Firefox mobile.
Any news? Except the audio playback, embedded Vimeo videos still doesn't work on Firefox mobile.
aaron, why is this "Status: 	RESOLVED WORKSFORME"?!
this is still broken! actually this "resolved works for me" expression is very insulting to the enduser - it sounds like "i dont care about you USER, it works for me the developer, you are an idiot". maybe i should fill a bug to bugzilla itself.
anyway, 
when i open a vimeo link, the page loads as expected but when I tap the play button it appears to start caching/downloading but the play button transforms into pause button then back into play button (instantly). no video or audio is played, even though the stream appears to be received from vimeo! (also my network traffic app displays sustained incoming flow at maximum wifi speed during video caching - when the playback bar starts filling)
Flags: needinfo?(aaron.train)
firefox 26.0.1 on android 4.4.2 with art runtime on nexus 7 2nd gen lte model
(In reply to costinel from comment #32)
> aaron, why is this "Status: 	RESOLVED WORKSFORME"?!
> this is still broken! actually this "resolved works for me" expression is
> very insulting to the enduser - it sounds like "i dont care about you USER,
> it works for me the developer, you are an idiot".

The reason it is resolved as WORKSFORME is explained in comment 29. Considering Aaron was the one who filed this bug to begin with, I'd say he's well within his rights to close it as such. If you still have a problem with Vimeo videos not working please file a separate bug with steps to reproduce and details and we can investigate.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #34)
> (In reply to costinel from comment #32)
> > aaron, why is this "Status: 	RESOLVED WORKSFORME"?!
> > this is still broken! actually this "resolved works for me" expression is
> > very insulting to the enduser - it sounds like "i dont care about you USER,
> > it works for me the developer, you are an idiot".
> 
> The reason it is resolved as WORKSFORME is explained in comment 29.
> Considering Aaron was the one who filed this bug to begin with, I'd say he's
> well within his rights to close it as such. If you still have a problem with
> Vimeo videos not working please file a separate bug with steps to reproduce
> and details and we can investigate.

I do not feed the need to duplicate a separate bug since I'm affected by the same issue, in title naming and vimeo link. so why should I open a duplicate when you ALREADY have all information needed in this bug concerning the same exact behaviour?!
feel, typo
The way you imagine we use Bugzilla and the way we actually use Bugzilla are not the same. There is a lot of information stored in each bug about a particular investigation and resolution. If the same bug happens again years later, we do not go back and reopen the same old bug just because the title and steps to reproduce are the same. We file a new one, because we will need investigate again from scratch, as the underlying issue may be different. There are lots of other pieces of information in a bug such as bug dependencies, status flags, tracking flags, etc which are only valid for a single investigation. Doing multiple investigations in the same bug would make these flags meaningless at best, and misleading at worst.

If you want your issue to be investigated, you should file a new bug. Or you can keep ranting here and nobody will do anything about it.
Flags: needinfo?(aaron.train)
costinel - Thank you very much for your comments. I really appreciate you taking the time to communicate the issue that you are experiencing with Vimeo playback in Firefox.

As kats said, the accepted process in Mozilla's bug tracker is to open a new bug rather than reopen old bugs. On top of the reasons that kats stated, given that this bug was resolved 6 months ago, a lot may have changed in both Firefox for Android and Vimeo. While it is a good idea to reference this bug in the new filing, the comments and investigation performed by this bug may be misleading when working to diagnose the current problem. 

For your specific case, can you please share (preferably in a new bug) specific steps to reproduce the issue including a URL and any applicable screenshots so that we can attempt to recreate your environment. The information that you provided in comment 32 and comment 33 is a good start.
thanks for suggestions. i'll fill a new bug after the ddos on vimeo ends. apparently they happened to be under attack recently https://status.vimeo.com/
Product: Tech Evangelism → Web Compatibility
Component: Mobile → Site Reports
You need to log in before you can comment on or make changes to this bug.