858163 - Firefox flicks does not work with HTML5 in Firefox / Mozilla promoting non-free/patented formats (H.264 and/or Flash)

Status: RESOLVED FIXED

(Websites :: Firefox Flicks, defect)

Description

[Hubert Figuiere [:hub]]

Firefox flicks does not work with HTML5 in Firefox. I get a message that I need patent encumbered video code to view the flicks. This send the wrong message in our fight for open video on the web.

(at least it does not tell me to install Safari on Linux like it used to with the video hosting)

Comment 1

[Hubert Figuiere [:hub]]

Attachment: screenshot

What I see in my browser, just for illustration purpose.

Comment 2

[Hubert Figuiere [:hub]]

That's right I use Firefox and I get told to switch browser to view a Firefox sponsored competition entry.

Comment 3

[Hubert Figuiere [:hub]]

"Mozilla sponsored competition" I meant.

Comment 4

[Osmose [:osmose, :mkelly]]

Not that this is a solution, but does it work in Nightly on Linux? Skimming bug 794282 makes me think that it _might_ have support for using GStreamer for H.264 on certain platforms.

Comment 5

[Ralph Giles (:rillian)]

This is because the videos are hosted on Vimeo. Their player supports HTML5 video with fallback to flash, but they don't support WebM, only mp4.

I'm also amused by the Creative Commons tag when there's no download link.

It's unfortunate that we aren't showing more leadership for the open web in this initiative.

Comment 6

[Ralph Giles (:rillian)]

(In reply to Michael Kelly [:mkelly] from comment #4)
> Not that this is a solution, but does it work in Nightly on Linux? Skimming
> bug 794282 makes me think that it _might_ have support for using GStreamer
> for H.264 on certain platforms.

Not yet. Regardless, enabling gstreamer in nightly just delegates the problem to the underlying platform. Most Linux distributions don't include mp4 playback support for the same reason we don't ship a decoder.

Comment 7

[Ben (:bensternthal)]

OK a couple issues going on in this bug.

Ralph: I'll create a sep bug for the CC item you mentioned above. It's not related to the HTML5 topic that started the bug.. but still important.

With regards to the HTML5 video issue, I have spoken to a few other folks about this (although I can't seem to find the bug). In summary (and this is my read on things), the decision to go with vimeo took into account a bunch of factors. This included being able to legally host the contest, affordability, privacy, an API that fit our needs and a lot more.

If we could find a host that did that and supported html5 video in the manner described above, I'd be all for using it.

Honestly I am hopeful that our relationship with vimeo puts pressure on them to add this support. 

Hope that helps explain things.

Comment 8

[Hubert Figuiere [:hub]]

> Honestly I am hopeful that our relationship with vimeo puts pressure on them
> to add this support. 

This come from the hosting site that previously told to install Safari to get a browser that support HTML5.

I doubt this will make change their mind.

In the end, each time Mozilla work on pushing open standard the reasoning above come to tell people that it is pointless. How do you want to explain a third party to support WebM for their HTML5 video when we can't even do it ourselves one way or the other.

That's how we lose credibility. Really.

Comment 9

[Osmose [:osmose, :mkelly]]

(In reply to Ben (:bensternthal) from comment #7)
> Honestly I am hopeful that our relationship with vimeo puts pressure on them
> to add this support. 

As far as I know we haven't actually put any pressure on them. I think it's a good idea to reach out and talk to them, if for nothing else then to find out what their justification for not supporting WebM is.

In the past they've mentioned that they were working on supporting it: https://vimeo.com/forums/topic:25295

But more recently they've stated that they're not working on it: https://vimeo.com/forums/topic:67641

I would very much like to hear what their response is as well. Otherwise we'll just keep going on hope and hearsay, and won't be able to make informed decisions on whether to use Vimeo for the contest next year.

Comment 10

[Hubert Figuiere [:hub]]

> I would very much like to hear what their response is as well. Otherwise
> we'll just keep going on hope and hearsay, and won't be able to make
> informed decisions on whether to use Vimeo for the contest next year.

I will answer simply to that one. If they don't support WebM you shouldn't use them. This is valid for just any provider.

And I forecast that now we have made the decision to support H264 (in a painful way) they might even use that as an argument for not supporting WebM.

Comment 11

[alainez]

+ Kristin Baird and Greg Jost as they were the team lead in signing Vimeo.

Comment 12

[Hubert Figuiere [:hub]]

> But more recently they've stated that they're not working on it:
> https://vimeo.com/forums/topic:67641


And they are still claiming Firefox doesn't support HTML5. That says a lot. Cognitive dissonance much?

Comment 14

[Hubert Figuiere [:hub]]

Vimeo latest comment:

https://twitter.com/VimeoStaff/status/381096323635621892

"You need Flash in order to watch our videos on Firefox unfortunately. Our HTML5 player only works in Chrome + Safari currently."

Reopening. This is absolutely unacceptable.

Comment 15

[Reuben Morais [:reuben]]

(In reply to Ben (:bensternthal) from comment #7)
> If we could find a host that did that and supported html5 video in the
> manner described above, I'd be all for using it.

What happened to Vid.ly? We use them for Air Mozilla, and I thought we even required participants to use it for Flicks.

http://firefoxflicks.tumblr.com/post/21442099700/meet-firefox-flicks-partner-vid-ly

Comment 16

[tobi]

Re: Comment 14 of Hubert

Thanks for posting this issue Hubert.

Flicks 2013 is over and currently no one is working on it as far as I know. What I suggest as take-away from this bug is that the Firefox Flicks team, if there is another round in 2014, should really try to get this issue resolved by talking to Fx product / Vimeo product people as early as possible. Maybe even right now, because this can take a while.

As far as I know, Firefox desktop does support H.264 natively, so if we're lucky it's just a minor issue on Vimeos' side. They already fixed something for us to support their HTML5 video player on Fx for Android (and FxOS), so I can see this happen :)

Best,
Tobi

Comment 17

[Hubert Figuiere [:hub]]

> As far as I know, Firefox desktop does support H.264 natively, 

Except on MacOS. (tl;dr: MacOS does not seem to provide sufficient API access to perform video playback properly)

> so if we're lucky it's just a minor issue on Vimeos' side.

How about you pick a partner to fits our values instead? That part of the problem. Vimeo NEVER shared our values. They assumed that the only browser that supported HTML% was Safari for the longest time. They never considered WebM important and never liked web freedom.

If it was a minor issue, it would just be fixed, but I suspect that also Vimeo is mono platform: it is a Mac shop - hence their hatred for open web. See above comment about out lack of H.264 support on Mac.

Comment 18

[Kevin Brosnan [Ex-Mozilla]]

Firefox Desktop has inconstant support for h264.

* Firefox running on Windows Vista/XP does not support h264 < This is a lot of our user base!
* Firefox running on OS X does not support h264
* Firefox Linux mostly does not support h264
** Firefox 26+ running on Linux only supports h264 if gstreamer-ugly is installed and an about:config pref is changed
* Firefox running on Windows 7/8 does support h264

Comment 19

[Osmose [:osmose, :mkelly]]

(In reply to Reuben Morais [:reuben] from comment #15)
> (In reply to Ben (:bensternthal) from comment #7)
> > If we could find a host that did that and supported html5 video in the
> > manner described above, I'd be all for using it.
> 
> What happened to Vid.ly? We use them for Air Mozilla, and I thought we even
> required participants to use it for Flicks.
> 
> http://firefoxflicks.tumblr.com/post/21442099700/meet-firefox-flicks-partner-
> vid-ly

Vid.ly's API requires you to host the video somewhere. Two years ago we went with Vid.ly and forced users to upload videos on Dropbox or some other spot because the available dev time + my lack of expertise made that the best option to release the site on time.

This past year, we were considering Vid.ly and having users upload videos to our own server, but decided to go with Vimeo because (from the dev perspective) they had extra features in their API that I thought we'd be able to use, like a built-in voting system and video search capabilities. However, after that call was made, I found their API wasn't as suitable as I thought, and had to reimplement those on the Flicks side anyway. Ugh.

(That's just from my dev perspective, there were plenty of other factors, some of which are mentioned in comment 7).

If I'm on this project again (if it happens again), and *IF* we have enough dev time to switch video provider for the third contest in a row, I'd probably recommend going back to Vid.ly and having users upload their videos to Flicks. It'd be a little bit easier since we can pull back the Vid.ly code from before, and can refine it a bit (It's been almost two years, but I seem to remember some flakyness in their API that we had to deal with).

Comment 16 is correct, though; the contest is over for this year, and there's no paid contributors on this project anymore. Unless another contributor comes along and feels really strongly about this, there probably won't be any movement until the next Flicks contest starts up, if there is one.

Comment 20

[u597032]

Is this Bug still relevant or can it be closed?

Comment 21

[Hubert Figuiere [:hub]]

The original website lasted for less time than this issue was kept open, as today the URL redirect to the main mozilla landing page.

As of today it would probably work as a side effect of all the amazing work done on video support in the browser, as even vimeo works, but we can not test.

Comment 22

[Hubert Figuiere [:hub]]

I didn't mean to mark as "FIXED", but it seems that bugzilla took it as such.