Closed Bug 939798 Opened 11 years ago Closed 7 years ago

Tutorial video uses H.264 with no fallback, and no sensible error message is given

Categories

(Webmaker Graveyard :: Popcorn Maker, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: gerv, Unassigned)

References

()

Details

Attachments

(1 file)

I just used the tutorial video in a class:
https://popcorn.webmaker.org/templates/basic/?savedDataUrl=tutorial.json

I then got all the kids to load it on their Ubuntu LiveUSB systems to remix it... and found that the video didn't load :-( This is because it's an MP4, with no WebM fallback, and the systems don't have Flash or a MP4 decoder that works with <video>.

But there was no error saying "we can't play this video", so they were all wondering why they couldn't hear anything when they pressed Play. This was a pretty hair-tearing experience as a teacher, and a pretty frustrating experience as a student.

We should have better errors, and we shouldn't publish official Webmaker content without free format fallbacks.

Bug 902514 could be related.

Gerv
:thecount - it looks like the tutorial.json file does have a fallback in it's sources; I guess adding jwplayer means that we don't use fallback anymore?
Assignee: nobody → scott
jbuck: as in, we've decided to fall back to Flash, and then fail, rather than fall back to open formats? That really would suck, if it were true...

Gerv
bug 936107 removed fallbacks.

We can simply revert that patch.

We can make fallbacks still work if previous projects have it, but not allow new ones to use it.

We can update tutorial.json to use webm over mp4.
These are the options I see right now. Not sure which one is best.
Oh, I thought of another option.

We can display a warning if flash is not installed.
Flags: needinfo?(schranz.m)
Flags: needinfo?(brett)
I'd like us to consider reverting the patch.

"Tech shapes culture. Defaults shape values." At the moment, if you have an entirely free software system (which is what I gave these kids), Popcorn videos don't play. That doesn't seem to be shaping our culture in a good direction. While we can't do automatic transcoding or anything like that, we can at least give authors the _option_ (and even a UI hint, like we used to have) to do the right thing and make their presentations work everywhere.

So I think we should restore the "fallback" UI in the authoring tool.

Then, when doing playback, we should use sources in the following order:

1) WebM in <video>, if format available and browser support available

2) H.264 in <video>, if format available and browser support available

3) H.264 in JWPlayer, if format available and Flash available

4) Error message, suggesting that users upgrade to the latest version of their browser. If their browser is Firefox or Chromium, the Popcorn presentation is H.264-only, and they are on a platform which does not yet support H.264 in <video> in the release channel, only then should we tell them that they should install Flash Player. Otherwise, we should never tell them this.

Gerv
I'm going to say we keep the UI removed. It was a feature that was never used for us because it is a pain point for the majority of the people our application is targeted at. The simple fact is HTML5 video is a pain for people to use as it's not convenient.

However, I am very open to still keeping relic supporting code that will follow the sort of code path specified above:

Main Source -> Fallbacks -> JWPlayer -> Fail
Flags: needinfo?(schranz.m)
The fallback UI is not so bad. I say it's the lesser of the evils.
(In reply to Matthew Schranz [:mjschranz] from comment #7)
> I'm going to say we keep the UI removed. It was a feature that was never
> used for us because it is a pain point for the majority of the people our
> application is targeted at. The simple fact is HTML5 video is a pain for
> people to use as it's not convenient.

I'm not following your logic there. 

When you say "HTML5 video is a pain for people to use", what do you mean by "HTML5 video"? Do you mean "video on the web"? Or "the <video> tag"? Or WebM? Or something else?

What people want is one video file which works everywhere. But it's just not possible today to create such a video file. So by only having one URL slot, you are forcing creators to decide which group of users to leave in the lurch.

Video on the web today is more of a pain than it could be because of the format wars. Mozilla has spent a lot of time and effort (and even some market share) trying to make open video (Theora first, then WebM) a first class citizen on the web. We didn't win this round, but we hope to win the next one. But in the mean time, we should at least _allow_ people using our tools to provide an open video option, even if they are basically required to provide H.264 as well.

Gerv
I think the pain he is talking about is expecting users to deal with multiple video formats so their project works on multiple platforms.

While I agree it is a pain, we had it in a place where it wasn't so bad, because it was opt in. Users only had to deal with it if they understood it. Otherwise flash would be the fallback.

We tried removing it, and there was a complaint about it almost immediately. This tells me removing it was a mistake and badly executed. We should of put something in the mailing list before we did it.

The good that comes of this is we now know we need to have a warning if flash isn't installed, regardless of the outcome of this ticket.

Throwing another need info of Matt because this isn't resolved.
Flags: needinfo?(schranz.m)
(In reply to Scott [:thecount] Downe from comment #10)
> I think the pain he is talking about is expecting users to deal with
> multiple video formats so their project works on multiple platforms.

I agree this is a pain. However, dealing with the pain by only allowing the user to specify a single video format simply moves the pain to some subset of the users instead of the author. 
 
> The good that comes of this is we now know we need to have a warning if
> flash isn't installed, regardless of the outcome of this ticket.

I think that warning should encourage browser upgrades (where it makes sense), rather than encouraging the installation of Flash. 

We, as Mozilla, need to follow our principles and be consistent with our public positions, both in the app features we provide and in what we ask users to do.

Gerv
I filed the flash warning here bug 940400
(In reply to Gervase Markham [:gerv] from comment #9)
> Video on the web today is more of a pain than it could be because of the
> format wars. Mozilla has spent a lot of time and effort (and even some
> market share) trying to make open video (Theora first, then WebM) a first
> class citizen on the web. We didn't win this round, but we hope to win the
> next one. But in the mean time, we should at least _allow_ people using our
> tools to provide an open video option, even if they are basically required
> to provide H.264 as well.

Right, I get why it is and understand that :) We decided to try and remove it for the simple reason it wasn't used much and obviously this was the incorrect choice. We can easily implement it back in.

Removing it did expose two things. Our flash detection isn't up to snuff and once we implemented the JWPlayer fallback we weren't using those fallback resources at all.
Assignee: scott → schranz.m
Status: NEW → ASSIGNED
Flags: needinfo?(schranz.m)
This patch is simply reverting to the old UI.
Attachment #8337889 - Flags: review?(scott)
Attachment #8337889 - Flags: review?(scott) → review+
There should also be a tutorial.webm file - try it with same path just using webm.
Flags: needinfo?(brett)
Assignee: schranz.m → nobody
Status: ASSIGNED → NEW
Popcorn Maker is no longer under active development.

https://learning.mozilla.org/blog/product-update-for-appmaker-and-popcorn-maker
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: