967733 - vid.ly (Air Mozilla) serves mp4 video, instead of webm, to Firefox 30 (Nightly)

Status: VERIFIED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Josh Aas]

https://air.mozilla.org/gecko-cycle-collector-intro/

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

WFM on Windows 8.1 in today's nightly. Weird, as that video is a WebM, so the decoding code paths should be the same on both OS's.

Comment 2

[Josh Aas]

Should have noted that I was testing on OS X 10.9 (MacBook Air).

Comment 3

[Josh Aas]

I think Gavin said he was able to repro this morning, not sure which OS he was on.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

I'm also on OS 10.9.

Comment 5

[Chris Peterson [:cpeterson]]

This is a vid.ly UA detection problem. Air Mozilla serves webm video from vid.ly to Aurora, Beta, and Release, but it tries to serve mp4 video to Nightly. If I change Nightly's UA string to mimic Firefox 25, then Air Mozilla serves webm as expected.

Nightly has see the same problem on Vid.ly's home page: http://m.vid.ly/

HTTP "Content-Type" of "video/mp4" is not supported. Load of media resource https://vid.ly/3q8j1d?content=video&format=mp4 failed.

Comment 6

[Chris Peterson [:cpeterson]]

Vid.ly assumes that any UA with a version number beginning with the digit 3 can play mp4 video:

• Firefox/3.0   -> mp4
• Firefox/29.0  -> webm
• Firefox/30.0  -> mp4
• Firefox/39.0  -> mp4
• Firefox/40.0  -> webm
• Firefox/300.0 -> mp4

Comment 8

[Mike Taylor [:miketaylr]]

See http://s.vid.ly/vid.ly/8bcbb16-stable/js/html5.js?link=5u4h3e&new=1&autoplay=false&width=311&height=175:

In setPlayer:

if(ua.indexOf('Firefox/3') !=-1){
  type = "mp4";
  format = "mp4";
}

(thx to @vladikoff for pointing that out to me)

Comment 9

[Axel Hecht]

Cringe. I guess the right feature test should be

videoElement.canPlayType('video/mp4')

At least that return "" on mac nightly, which means it can't play this.

I hope we return "maybe" or "probably" on windows, and linux with codecs installed or so.

Comment 10

[Robert Kaiser]

(In reply to Mike Taylor [:miketaylr] from comment #8)
> if(ua.indexOf('Firefox/3') !=-1){

Ouch.

FAIL.

Comment 11

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Axel Hecht from comment #9)
> Cringe. I guess the right feature test should be
> 
> videoElement.canPlayType('video/mp4')
 
Yes.

> At least that return "" on mac nightly, which means it can't play this.

Yes. We haven't shipped MP4/H.264/AAC support on MacOSX yet.

> I hope we return "maybe" or "probably" on windows, and linux with codecs
> installed or so.

We do.

Comment 12

[Richard A Milewski[:richard]]

I can file a ticket with Vid.ly's engineering team.  What's the proper way to decide what to serve Firefox, Firefox for Android, and Firefox on FirefoxOS?

If we're going to pester them to change it, then it would be good if they got it right the first time.

Comment 13

[Robert Kaiser]

I *think* we always prefer open formats, but also, AFAIK, the <video> tag has a way to specify multiple sources with fallbacks so I guess that would be preferred. Otherwise, I think actual feature detection instead of UA detection is preferred in JS, though I don't know the code for codec detection.
That said, I wonder where that "Firefox/3" detection comes from, I think we didn't even ship <video> support with Firefox 3.x, did we?

Comment 15

[Richard A Milewski[:richard]]

Have an open ticket (#11942) with Vid.ly support that references this bug.

Comment 16

[Richard A Milewski[:richard]]

Vid.ly support escalating this issue to engineering.

Comment 17

[Richard A Milewski[:richard]]

Vid.ly reports that they have pushed a fix.  Firefox 30 should now be getting WebM.

Comment 18

[Raniere Silva]

Already test with some of newer videos and it work as expected.

Comment 19

[Chris Peterson [:cpeterson]]

Verified fixed with Nightly 31.