Closed Bug 489802 Opened 15 years ago Closed 15 years ago

Investigate/build PoC for OS FLV player

Categories

(support.mozilla.org :: General, defect)

Product:
support.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: laura, Assigned: ecooper)

References

Details

(Whiteboard: sumo_only) 

Investigate whether we can just use the open source (php) FLV player used in Podpress to play .flv files.

(refer to https://wiki.mozilla.org/Support/ScreencastsPRD)
Blocks: 489803
Depends on: 489801
While it's a requirement by Wordpress for plugins hosted by them to be GPL compatible, it's not abundantly clear where the podpress flv player comes from.

My suggestion would be to utilize something like a customized OS Flv (http://www.osflv.com/) or something from (http://flv-player.net), which are all easily customizable, Creative Commons/MPL players.

Aesthetically speaking, if we want something similar in appearance like podpress, <http://flv-player.net/players/normal/generator/> customizing that would be easiest.

If we want to have our own player, OS Flv includes the fla of the player and we can modify that.
Why is flv a requirement? Aren't we creating extra work by trying to support that for Firefox 3 when it will be EOLed within a year?

Also a bit more importantly, where was all this discussed? I don't see anything in the meeting notes and there's definitely nothing in the newsgroup.
So, this issue (in a slightly different form) came up yesterday in terms of morgamic asking about what webdev can do to promote the open web technologies, and really showcase the things we're implementing in Gecko, etc.  We're going to make a major push behind <video> as a key component of the Open Web, and it feels like we should not put any cycles into supporting FLV/SWF, since those formats are incompatible with our goals as an organization.

Yes, we have existing content in proprietary formats, but it seems _far_ easier to just roll transcoding support into the upload process than to manage files in multiple formats and fallbacks between native and plugin content.  I'd be totally happy to find machine time to convert all of the existing FLV/SWF content to Theora.  Of course, the link in the PRD is dead, so I don't know how many there are, but one Mac Pro should make mincemeat of the conversion in short order.

I recognize that this will limit the audience of screencasts to Firefox 3.5 users, but I think it becomes another touchpoint to encourage upgrades, and will be a great showcase for a very important technology.
The main reason for supporting Flash screencasts is to help users who are trying to install Firefox or for whom Firefox is not working.  For screencasts in these articles to be useful, Flash versions would be needed.

No mainstream screencast software exports to OGG format - all screencasts users have submitted so far have been in FLV or SWF Flash formats.  Hence, until users can create OGG-format screencasts with mainstream software, we will need to somehow accept SWF and FLV contributions.  Advanced contributors can then perform the conversion to Theora, which is extremely easy using software such as VLC.

The development time required to detect whether the running browser is capable of Theora/<video> should be minimal.  If the browser is not capable of <video>, Flash is installed, and a flash file was given in the {SCREENCAST()} plugin syntax, then the flash version would be shown.  A FLV player is needed for flv files, while swf files (eg. from screencast.com) are embedded directly.  If no Flash file is present, or if the current browser doesn't have Flash, the user would be informed that they first need to upgrade to Firefox 3.5 or higher.
(In reply to comment #4)
> The main reason for supporting Flash screencasts is to help users who are
> trying to install Firefox or for whom Firefox is not working.  For screencasts
> in these articles to be useful, Flash versions would be needed.

I don't really think screencasts are useful for troubleshooting.  I have a strong feeling that they are a waste of time.  And, honestly, if our installer isn't good enough without a screencast, file bugs.  Screencasts that explain how to install Firefox mean we've failed in a design sense, IMO.

> No mainstream screencast software exports to OGG format - all screencasts users
> have submitted so far have been in FLV or SWF Flash formats.  Hence, until
> users can create OGG-format screencasts with mainstream software, we will need
> to somehow accept SWF and FLV contributions.  Advanced contributors can then
> perform the conversion to Theora, which is extremely easy using software such
> as VLC.

We can make the uploader automatically transcode FLV to Theora, and ask users to use the highest-quality output format they can get.  Transcoding non-HD video is pretty fast on good hardware.  I'd rather throw a server at transcoding 24/7 than be forced to support Flash due to lack of specific tooling support.  Tech adoption is a bit of chicken and egg, of course, and if we can't lead by example, who are we expecting to do that?  I'd rather we enable Theora than take the easy way out.

> The development time required to detect whether the running browser is capable
> of Theora/<video> should be minimal.  If the browser is not capable of <video>,
> Flash is installed, and a flash file was given in the {SCREENCAST()} plugin
> syntax, then the flash version would be shown.  A FLV player is needed for flv
> files, while swf files (eg. from screencast.com) are embedded directly.  If no
> Flash file is present, or if the current browser doesn't have Flash, the user
> would be informed that they first need to upgrade to Firefox 3.5 or higher.

Complexity sucks, especially if it can be eliminated.  This means needing to maintain two copies of every screencast, which is unnecessary, and test each format of the screencast.  More importantly, of course, it ignores the goal of promoting and using Open Web technologies over proprietary tech.  I think we shouldn't use Flash because there's no compelling need, and because there's now a viable alternative.

I really don't think you're considering this from a Mozilla project perspective.  We shouldn't be building new capabilities out to use Flash video while we're preparing to make a push against the use of proprietary file formats for video and audio.  It just doesn't make sense to me.
Few thoughts:
- Saying screencasts are not useful for support?  Waste of time?  That's a bit much to generalize it on just installer support, and in general you're just wrong about that.

- Yes, want to use the open web but we have Firefox 3 users to support for about a year, so not sure why you are flipping out about Flash if we're supporting release versions of Firefox without open video support.

- We should research transcoding and figure out how to offer <video> for 3.5 by the time it is released for general availability -- and even then only show it for UAs that support it to ensure a positive user experience.  And no, support videos for Fx 3 are not a waste of time.

- Mike, it'd be helpful if someone pointed the SUMO team to documentation and guide them on how to use <video> for when 3.5 is released?  So far I've only seen comments on how easy it is to use with no real help -- and that's not how to get people excited about a new technology.  Some of these comments are so absolute and drive-by in nature it's pretty alarming.  Really not the way people on the same team should be speaking.
The mission of SUMO is to help as many users as possible.  That includes people who don't have browser support for <video> yet.

This has been discussed in SUMOdev meetings since the middle of Q1.  You will see it in the minutes with links to the PRD.(The link to the PRD is not broken for me - perhaps try it again?)

If you had read the PRD you would see that it reads in part:
"If an ogg/theora version of a screencast exists and the browser supports the video tag, the ogg/theora file would be used. Otherwise, it would fall back to an object tag with the .swf file, or the built-in video player with the .flv file. "

In other words, we are planning <video> as the deafult where supported and flv where it is not.

All of our community submissions thus far are in non-theora formats.  Contrary to what you suggest, transcoding on upload is pretty expensive.  In the timeframe to deliver the Q2 goal of providing screencast support for SUMO, we don't have IT budget or bandwidth to study feasibility.  We would be happy to look at this later on.

In summary, the entire team worked through this and came to an agreement about the best way to support our users.  We plan to offer both formats side by side to support user choice.  I'm sorry you think screencasts are a waste of time, but that is not an opinion that is shared by the SUMO team.

If having a say in these decisions is important to you, please feel free to contribute to the SUMOdev team.  Our meetings are open to all, and are documented here:
https://wiki.mozilla.org/Support/SUMOdev_Meeting_Notepad
I think the link Mike was referring to was <http://videos.mozilla.org/screencastcontest/>, which is linked in the PRD under "File types".
(In reply to comment #7)

I don't want to pile on here, but I do want to address one particular point from my point of view.

First let me say I know how much work webdev does for SUMO, and I understand how frustrating it can be when someone comes in after everything has been decided and wants to do things differently.

> If having a say in these decisions is important to you, please feel free to
> contribute to the SUMOdev team.  Our meetings are open to all, and are
> documented here:
> https://wiki.mozilla.org/Support/SUMOdev_Meeting_Notepad

this is great, if it were the impression being given out. A while ago I raised the issue of encouraging people to join these meetings and was told flat out that we didn't really want that as these meetings were just for webdev to sort out who's going to fix what bug.

The minutes aren't posted in any of SUMOs communication channels, nor has there been a formal invite encouraging people to attend.

While I haven't been calling in for Monday's SUMO meetings lately I do read the minutes and try to follow up on any issues that stand out to me.  Screencasts weren't mentioned in those minutes since the screencast contest. This bug was the first I saw of this and is the first anyone could have seen unless they were already watching the SUMOdev meeting notes or calling in to the meetings.
I don't recall telling you that, and I don't know who did.  I run these meetings.  I am also the only person from the webdev team who attends them.  Everybody else is from the SUMO team.

They are usually a technical/implentation discussion, so we don't really want 100 people attending.  You could consider my previous comment on this bug a formal invite if you would like.  We mostly work through buglists so the agenda/minutes are very short.

The SUMO 2009 roadmap, posted in the SUMO blog, links to the Screencast PRD, so it's been public since the start of the year when we began working on it. David has also invited comment on the roadmap and associated work in the weekly project meetings.

I'm going to ask you to take this to email.  Bugzilla is not a place to make random attacks on the work process for SUMO.
I'd be very happy if we all moved discussion to the SUMO newsgroup, however I don't think bugzilla is the place to villainize each others' viewpoints either. This may not have been the best place to bring these issues up, but that doesn't mean they're not valid or relevant.
I just want to say that if I offended or upset other people who I haven't talked to already, I am truly sorry.  I clearly felt like this is the wrong approach in the long term, but I also now realize how far along the project is, and I'm entirely happy to see us work to deprecate Flash over the next while, as long as we're all on the same page with long term goals.

Again, sorry for pulling the seagull act, I'm really really happy with 95% of what you guys are doing (and too silent about that) but I'm sure it's like all I do is criticize.  I'm trying to fix that, but everyone (and I mean everyone) should feel free to call BS on me, for real.
(In reply to comment #5)
> I don't really think screencasts are useful for troubleshooting.
> I have a strong feeling that they are a waste of time.
>
> More importantly, of course, it ignores the goal of
> promoting and using Open Web technologies over proprietary
> tech.  I think we shouldn't use Flash because there's no
> compelling need, and because there's now a viable alternative.
>
> I really don't think you're considering this from a Mozilla
> project perspective.

Just for the record, for everyone reading this bug: the primary goal of the SUMO project is user retention -- to solve people's problems with Firefox so they can continue to use it. This includes people who may have to resort to IE to access the support information, and who may have to start Firefox in Safe Mode or locate the profile folder for the first time.

With our goal in mind, SUMO is not a suitable channel for us to promote exclusive use of open technologies if that means we will degrade our users' support experience. While we will certainly push the use of open video by defaulting to it and enabling our community to upload an .ogg file in addition to Flash, we will not design our customer support in a way that locks the people that need it the most out.

John Lilly summarizes well this balance between organization mission and doing things that matter to real people today in his talk about Poetry & Pragmatics (http://john.jubjubs.net/2009/05/01/poetry-pragmatics-mozilla-all-hands-2009/).

(In reply to comment #9)
> Also a bit more importantly, where was all this discussed? I don't see anything
> in the meeting notes and there's definitely nothing in the newsgroup.

As I am sure you are aware, it is next to impossible to discuss every detail of every feature or decision in public; that is why we have PRDs. This particular decision to fall back to (and require) Flash was easy to make given our primary project goal.

Anyone who wants to get involved and share ideas and feedback is welcome to do so in our regular communication channels. Our roadmap and PRDs are public for a reason.
(In reply to comment #14)

I'd like to reply to this post but I'm going to do so in mozilla.support.planning for anyone else who wants to follow me there.

As for the point of openness and discussion I already made a newsgroup post yesterday, http://groups.google.com/group/mozilla.support.planning/browse_thread/thread/9576810a83379302# I'd love to see some replies there.
(In reply to comment #14)
> With our goal in mind, SUMO is not a suitable channel for us to promote
> exclusive use of open technologies if that means we will degrade our users'
> support experience. While we will certainly push the use of open video by
> defaulting to it and enabling our community to upload an .ogg file in addition
> to Flash, we will not design our customer support in a way that locks the
> people that need it the most out.

This all sounds well and good, except that:

a) I don't think that only using <video> locks the people that need it the most out.
b) I don't think it will degrade the user experience.

My argument is that it will do neither, so arguing that we won't do that is pretty much a straw man.

> John Lilly summarizes well this balance between organization mission and doing
> things that matter to real people today in his talk about Poetry & Pragmatics
> (http://john.jubjubs.net/2009/05/01/poetry-pragmatics-mozilla-all-hands-2009/).

I don't think you have the right balance, based on the PRD.  I really don't, and if you do, I don't think we took the same things out of that talk.
Resolving this since it was hijacked while I was lost in the woods.

We'll be using a solution detailed in comment 1 for the flash component of the screencast goal.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Verified FIXED -- we're live with SUMO 1.1 as of tonight, which includes supports for FLV, SWF, and OGG-based screencasts.
Status: RESOLVED → VERIFIED
Whiteboard: sumo_only
You need to log in before you can comment on or make changes to this bug.