Closed Bug 1154699 Opened 9 years ago Closed 3 years ago

Hosting MDN videos on Air Mozilla?

Categories

(Webtools Graveyard :: Air Mozilla, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: sheppy, Assigned: richard)

Details

We're finally starting to gather ourselves to get started posting
videos -- we've got a couple already produced and more on the way. We're trying to sort out where to put them and I have a few questions for so I can hopefully get things up and running soon. A couple of people in the community have had questions related to whether we should be posting our videos on Air Mozilla or on YouTube, and I'd like to share those with you and see what you can tell me.

1. What options do we have to correlate a video with its context? Many
of the videos we are going to produce will directly tie into articles
on MDN. We would want to be sure that this relationship can be
reflected by linking to the article in a clear and visible way
(ideally with an attractive button or widget of some sort). Is this
feasible? I believe it is, but would like to be certain.

2. It's been a while since the channel was created and your previous
email on this thread. I'm curious what advances have taken place in
features and function on Air Mozilla since then. Are there docs about
how to upload to and administrate content on Air Mozilla?

3. What is the cost to Mozilla here? YouTube doesn't cost us anything
to use, so some people in the community suggest that if we can save
the organization money by hosting video on YouTube, that might be
something we should do.

4. How is performance these days? We know that live streams can often
be hicuppy during our meetings, so community has voiced serious
worries about whether Air Mozilla is up to the job of hosting a lot of
screencasts and the like. I personally suspect they're overreacting
but promised to pass on the question. Would love some details on
performance and how things are set up to ensure reliability and speed.

5. Are there any special issues involved with using it embedded? I see
that the embed button gives you an iframe. Is there a reason we can't
just use a <video> element directly? Are there any potential pitfalls
we might run into using the iframe to show the video in-site on MDN?

6. How are videos submitted and approved (and managed), and what
permissions model is available? Can we have a primary administrator
then other people with the ability to upload videos, some also with
the ability to approve them or whatever workflow is required to make
them "live" on site? We will probably have a few people who will need
the ability to upload videos.

7. What is the process for adding subtitles or redubbing the audio for
localization purposes? We would love to allow community to do this
with minimal hassle required.

8. Does Air Mozilla offer any other special features we might not know
about, such as triggering events or otherwise triggering events when
certain times are reached? This would be amazing for things like
automatically displaying relevant code snippets or the like as they're
discussed, and that kind of thing.

We certainly don't need all of these things in order for Air Mozilla
to make sense for us, but would like to be fully informed.
Component: Other → Air Mozilla
Product: Air Mozilla → Webtools
Version: unspecified → Trunk
(In reply to Eric Shepherd [:sheppy] from comment #0)  

> We're finally starting to gather ourselves to get started posting
> videos -- we've got a couple already produced and more on the way. We're
> trying to sort out where to put them and I have a few questions for so I can
> hopefully get things up and running soon. A couple of people in the
> community have had questions related to whether we should be posting our
> videos on Air Mozilla or on YouTube, and I'd like to share those with you
> and see what you can tell me.
> 
> 1. What options do we have to correlate a video with its context? Many
> of the videos we are going to produce will directly tie into articles
> on MDN. We would want to be sure that this relationship can be
> reflected by linking to the article in a clear and visible way
> (ideally with an attractive button or widget of some sort). Is this
> feasible? I believe it is, but would like to be certain.


Tell us what you want, and we'll build it :)

* We can make a dedicated "template" for pages with MDN videos. 
* We can have custom extra widgets to appear on events tagged as MDN videos. For example, Mozilla HR runs special recruitment messages on certain pages. E.g https://air.mozilla.org/engineering-meeting-20140805/ (scroll down to see "A message from Mozilla Careers")

We have put a lot of effort into building a flexible platform on which we can do a lot of customization quickly and easily.



> 
> 2. It's been a while since the channel was created and your previous
> email on this thread. I'm curious what advances have taken place in
> features and function on Air Mozilla since then. Are there docs about
> how to upload to and administrate content on Air Mozilla?

There's an upload wizard that walks you through the upload process.  We're rolling out a new one this quarter, but even the current one is easy to use:   

Click on REQUEST in the AirMo Navbar at the top of the page, then Select the Prerecorded Video radio button, and you'll be prompted to upload your file and answer a few questions to collect the metadata.    We can create a special instance of the (new) uploader with metadata questions tailored for MDN.

We're also working on a tool for making "screencast" videos in the browser, and hope to have that in place by Q3. It should be especially useful for MDN.

If you need some MDN specific instructions, we can create a static page (or pages) on AirMo.   We'd be delighted to work with your team to optimize an instruction set for MDN users.



> 
> 3. What is the cost to Mozilla here? YouTube doesn't cost us anything
> to use, so some people in the community suggest that if we can save
> the organization money by hosting video on YouTube, that might be
> something we should do.

Cost is minimal.  We've been doubling the number of videos added each year for the past three years.  Last year we added 783.  So unless you expect to do thousands of hours of video you won't impact total costs much.  

"Free" services aren't always cheaper. You have to consider total costs for the entire organization.

Having all Mozilla videos in a single searchable repository will make it easier for others to find and reuse or remix existing videos quickly.  The time savings can actually reduce costs over having video spread over multiple sites.  

In addition, the AirMo solution to the points you raise in part 6 below will save your team many hours over attempting to do administration in an ad-hoc manner. If you factor that in, I suspect this project can be a net savings to Mozilla.


> 
> 4. How is performance these days? We know that live streams can often
> be hicuppy during our meetings, so community has voiced serious
> worries about whether Air Mozilla is up to the job of hosting a lot of
> screencasts and the like. I personally suspect they're overreacting
> but promised to pass on the question. Would love some details on
> performance and how things are set up to ensure reliability and speed.
> 

Have any of your community members experienced stalling issues when watching
archived AirMo events?   Live streaming is a considerably more complex problem than
streaming a pre-recorded video.  We are making good progress on improving the live stream
reliability and moving to HLS and MPEG-DASH this year will help with that as well.

But archived streams have been extremely reliable.  If anyone is experiencing issues with archived streams PLEASE ask them to file a bug.  The pre-recorded videos have been so reliable that we have very little real data to work with to improve performance.    (Bugs reporting issues with live streams are always welcome too, but we have more data to work with there).

We can bore you to tears with details on video streaming performance and the things that get in the way of flawless streams, but that's much better done over a beer.  (...or six.   The first few rounds are on us!)



> 5. Are there any special issues involved with using it embedded? I see
> that the embed button gives you an iframe. Is there a reason we can't
> just use a <video> element directly? Are there any potential pitfalls
> we might run into using the iframe to show the video in-site on MDN?

Yes this is possible. Sort of. 
Instead of an <iframe> you can use Vid.ly's solution of embedding an HTML5 player. 

If you know the video's "tag" (e.g. "7u9u1i") all you need to embed it is:
<script type="text/javascript" src="//vid.ly/7u9u1i/embed"></script>

We know the tag of every video and can extend the current "Embed" instructions we have to offer this too.   The advantage here is that you get access to the Javascript API.

The downside to using just a simple <video> tag is that for users on expensive wireless connections you wind up sending them a much higher resolution version of the video than they can display.  They wind up paying their wireless carrier outrageous per-megabit rates for bits their browser just throws away.  We actually have each video transcoded into 10 different formats that get matched to the device and available bandwidth of the user.  This problem is particularly severe for users on older (2G/3G) connections or with spotty wireless connectivity.  


> 
> 6. How are videos submitted and approved (and managed), and what
> permissions model is available? Can we have a primary administrator
> then other people with the ability to upload videos, some also with
> the ability to approve them or whatever workflow is required to make
> them "live" on site? We will probably have a few people who will need
> the ability to upload videos.

Not a problem.  We have a very flexible permissions system and we can create multiple groups with different sets of permissions.  It sounds like what you're asking for is very similar to the process we now use for P/R clearance of public events.  Event requests get submitted, they get reviewed by end-user-services to ensure they can staff the event (control room operations), then P/R reviews them so they don't get surprised by stories in the press that mozilla is doing something we aren't, then they wind up on the Air Mozilla calendar.   It's all done on a web-based management system.   

We can set up a similar flow for your submitters, editors and approvers.  We can support any number of uploaders.  For general AirMo content, we currently have 4,315 authorized uploaders (you are one right now).   But we can make MDN videos a special case and restrict who can upload to that channel.   We can give MDN administrators the ability to grant and revoke permissions for other users. The infrastructure is in place for a custom multi-layer approvals process.


> 
> 7. What is the process for adding subtitles or redubbing the audio for
> localization purposes? We would love to allow community to do this
> with minimal hassle required.

We have an unfinished prototype for adding overlays on top of videos. Basically little snippets of HTML (including hyperlinks) that appear at configurable locations between two timestamps. 
Our primary goal is for our crowd/active audience to help put up names (a la TV news) of the person talking and putting actual links over mentioned links/URLs in the videos. 

Yes, we have the capability to enter transcriptions from video to English. It's only in prototype state but technically it should be possible. We'd use the Amara platform for this. It also allows for a great/easy way to localize that English to other languages.  The blocker for subtitling most AirMo video has been the availability of an English transcript.  I suspect that won't be the a problem for most MDN videos.



> 
> 8. Does Air Mozilla offer any other special features we might not know
> about, such as triggering events or otherwise triggering events when
> certain times are reached? This would be amazing for things like
> automatically displaying relevant code snippets or the like as they're
> discussed, and that kind of thing.

Yes! Almost. We are playing (archived) videos now in HTML5 and there's a Javascript API you can hook up to. We're currently using this for the little "tear out" icon (seen below the lower right-hand corner) that opens the video in a new window and it's using the Javascript API to know what moment in time to resume at. 

This API is not accessible "to the content" but we could make some customizations dedicated to your video descriptions or something that ties into that API. For example, we could allow for special hidden markers in the description text that gets highlighted. 

However, when playing embedded videos on another site with an <iframe>, you don't have the javascript API access.  (Note: See answer in question 5 about using Vid.ly's HTML5 player instead of an iframe.)


We have limited Popcorn integration as well, and MDN use cases sound like a reason to expand that.

> 
> We certainly don't need all of these things in order for Air Mozilla
> to make sense for us, but would like to be fully informed.


We're excited about this project.  We should probably schedule a Vidyo call to lay out the next steps.
Assignee: nobody → richard
Priority: -- → P1
(In reply to Richard A Milewski[:richard] from comment #1)
> (In reply to Eric Shepherd [:sheppy] from comment #0)  

> Tell us what you want, and we'll build it :)
> 
> * We can make a dedicated "template" for pages with MDN videos. 
> * We can have custom extra widgets to appear on events tagged as MDN videos.
> For example, Mozilla HR runs special recruitment messages on certain pages.
> E.g https://air.mozilla.org/engineering-meeting-20140805/ (scroll down to
> see "A message from Mozilla Careers")

One of our major use cases is to have video that demonstrates something that goes along with an article describing things, including the sample code that's being discussed. We'd love to be able to correlate timestamps in the video to given snippets of code, so the viewer can click a button to link straight to the appropriate piece of code or paragraph in the article.

That's somewhat beyond your examples, and could be considered a longer-term goal -- but if it's not remotely possible, let us know, because that's an important data point. :)

The uploader and its customization sound fantastic, and you're right that the screencast functionality sounds awesome. That's something we've wanted for a long time, in fact.

> > 3. What is the cost to Mozilla here? YouTube doesn't cost us anything
> > to use, so some people in the community suggest that if we can save
> > the organization money by hosting video on YouTube, that might be
> > something we should do.
> 
> Cost is minimal.  We've been doubling the number of videos added each year
> for the past three years.  Last year we added 783.  So unless you expect to
> do thousands of hours of video you won't impact total costs much.

I didn't expect it to be a serious problem, but wanted to ask out of thoroughness. Does the number of views have an appreciable impact, though? I don't expect the number of videos to be unreasonable, but it's possible they could get a lot of views.

> Having all Mozilla videos in a single searchable repository will make it
> easier for others to find and reuse or remix existing videos quickly.  The
> time savings can actually reduce costs over having video spread over
> multiple sites.

Agreed; this is one of the reasons our preferred choice would be to use AirMo for these videos if there aren't any blockers.

> But archived streams have been extremely reliable.  If anyone is
> experiencing issues with archived streams PLEASE ask them to file a bug. 
> The pre-recorded videos have been so reliable that we have very little real
> data to work with to improve performance.    (Bugs reporting issues with
> live streams are always welcome too, but we have more data to work with
> there).

This is what I expected to hear on this. I'm not aware of any known issues with the prerecorded material, but, like I said, I was asking to be sure we cover all our bases.

> The downside to using just a simple <video> tag is that for users on
> expensive wireless connections you wind up sending them a much higher
> resolution version of the video than they can display.

Hm. I wonder if we can come up with a way to deal with that. Coming up with a way to embed that works well is one of the must-have features, since we need to present videos inline with other content.


> We can set up a similar flow for your submitters, editors and approvers.  We
> can support any number of uploaders.  For general AirMo content, we
> currently have 4,315 authorized uploaders (you are one right now).   But we
> can make MDN videos a special case and restrict who can upload to that
> channel.   We can give MDN administrators the ability to grant and revoke
> permissions for other users. The infrastructure is in place for a custom
> multi-layer approvals process.

Sounds fabulous.

> Yes, we have the capability to enter transcriptions from video to English.
> It's only in prototype state but technically it should be possible. We'd use
> the Amara platform for this. It also allows for a great/easy way to localize
> that English to other languages.  The blocker for subtitling most AirMo
> video has been the availability of an English transcript.  I suspect that
> won't be the a problem for most MDN videos.

Yes, these would be all or almost all scripted presentations, so it should be no problem.

> > 8. Does Air Mozilla offer any other special features we might not know
> > about, such as triggering events or otherwise triggering events when
> > certain times are reached? This would be amazing for things like
> > automatically displaying relevant code snippets or the like as they're
> > discussed, and that kind of thing.
> 
> Yes! Almost. We are playing (archived) videos now in HTML5 and there's a
> Javascript API you can hook up to. We're currently using this for the little
> "tear out" icon (seen below the lower right-hand corner) that opens the
> video in a new window and it's using the Javascript API to know what moment
> in time to resume at. 
> 
> This API is not accessible "to the content" but we could make some
> customizations dedicated to your video descriptions or something that ties
> into that API. For example, we could allow for special hidden markers in the
> description text that gets highlighted. 
> 
> However, when playing embedded videos on another site with an <iframe>, you
> don't have the javascript API access.  (Note: See answer in question 5 about
> using Vid.ly's HTML5 player instead of an iframe.)

Sounds promising. This would definitely be something we'd love to explore over time, and I'm pleased to hear there's possibility there!

> We're excited about this project.  We should probably schedule a Vidyo call
> to lay out the next steps.

Probably, yes. I need to talk to some folks on the MDN team to see if there's anything else they want me to pre-flight here, and find out who all wants to be part of the conversation.

Thanks for all your answers!
We have begun drafting up our requirements doc for the video project on MDN. We want to be sure our ducks are in a row and know where the pond is before we get started.

For anyone that wants to follow along, that document is here: https://wiki.mozilla.org/MDN/Projects/Development/Videos
:richard - The requirements document at https://wiki.mozilla.org/MDN/Projects/Development/Videos is now finished. What do you think? How far off are we from being able to do these things?
Flags: needinfo?(richard)
:sheppy - I read it last week.  I'll re-read the final version and post a list of what we can and can't do here, as well as estimates of how likely we are to be able to fill any gaps.

Thanks!
Flags: needinfo?(richard)
Here's what I thing we can and can't do.  Caveats and comments **[marked]** to make them easy to spot.


MUST HAVES ************************

 Yes   Ability to host large pre-recorded videos in a performant way.
 Yes   Ability to embed the videos in articles on the MDN wiki.
 Yes   Broad support for a variety of devices and bandwidth levels.
 Yes   Low cost to Mozilla financially.  
       **[Especially when measured as TCO]**

 Yes   Ability to attach a detailed description text to each video.
 Yes   IRC backchannel link to #mdn    
       **[Not absolutely certain what you had in mind but we can put an irc URL and Mibbit or a similar IRC client on each MDN AirMo page]**

SHOULD HAVES *************************


 Yes   A permissions model that allows us to grant upload/approve/moderation privileges to non-staff users
       **[ ...and you can use curated groups in mozillians.org to create heirarchies of groups of users ]**

 Yes   Support for adding sub-titles for various locales as well as the original language of the video.
       **[ Not implemented today but on our roadmap.  Estimate 1 week development time Using Amara (Universal Subtitles)  -- We also have a path to multiple soundtracks in different languages if you have folks to want to overdub) ]**

 Yes   Ability to correlate videos with context; that is, if viewing the video off of MDN, there should be a way to provide at least one link back to the article that covers the topic at hand. 
       **[ Also support for multiple links if a single video illustrates more than one topic ]**

 Yes   Easy, convenient video uploading process.  
        **[ Also coming soon, an easy way to make screencast style videos right in the browser]**
    
 Yes   Ability to load a new video with the play position set to a given offset into the video.
       **[ Requires 1 day development time. ]**
    
 Yes   Videos should show up on search engines.
 
 Yes   Statistics tracking including visit counts, play counts, follows/subscriptions, etc.

COULD HAVES **********************


Soon   Support for re-dubbing the vocals into alternate languages.
        **[MP4 certainly supports multiple sound tracks.  Not certain about WebM but probably.  This is not
       currently on the roadmap because we've not had requests for it.  But if you need it we'll implement it!]** 

Yes    An API for retrieving information about videos (title, available localizations, available sizes and bandwidth levels, duration, etc.).

Maybe  Ability to trigger an action when given points in the video are reached; for instance, it would be great to be able to show specific snippets of code (or a slide from a presentation) when the speaker reaches the corresponding part of their talk.
      **[This is the Popcorn integration we've always wanted to do, but we've not yet has a customer for it!]**
    
Not Yet  A built-in suite of tools for editing videos, adding titles and images, and so forth.
      **[ But high on our want list. We have an intern starting on exactly this project next Monday ]**
    

Maybe   Mozilla Popcorn integration (related to the previous point) would be cool.  **[See above]**
    
Yes    Optional parameter in URL to set play position at load time.  **[Part of Should Have #5]**


WON'T HAVES *********************


YES     API to allow script to change the current play position.  **[Part of Should Have #5]**
    
Yes     Commenting on videos. **[With optional moderation]**
There's a lot of great in that and we're reviewing. One thing that's come up: we have heard that Popcorn Maker (and possibly also Popcorn.js, but we aren't sure) have been EOL'ed. Is this something that impacts the Air Mozilla video edit/remix/whatever capability your intern is working on?

We'd like to know more about what technologies are involved there and if there are any risks associated with underlying tech going away.
Flags: needinfo?(richard)
I've also heard that they are EOL'ing Popcorn Maker.  I doubt that will have a large effect on Popcorn.js.
We have an intern working on an in-the-browser video editor for AirMo that leverages a bunch of code from Popcorn Maker so the parts of it that are important will live on even after the demise of Popcorn Maker itself.  ...and we'll have institutional memory of how it all fits together if we need other bits in the future. 

We should establish what we need to meet your requirements so we can ensure we have a solid understand of how those work under the hood.

If you and your team can spare a couple of hours in Whistler, I think we should try to schedule a meeting there where we can shape a plan so you can make the go/no-go decision with as much solid info as possible.
Flags: needinfo?(richard) → needinfo?(eshepherd)
Yes, I agree; a meeting would be fantastic. If we don't manage to pull it off in Whistler (these work weeks can be chaotic and even planned and scheduled meetings are prone to disappearing -- been there a few times), we will do it right after on Vidyo.

I've put this meeting on the list of things we hope to manage to do in Whistler, and will keep pushing for it to get a slot on our schedule. Can you let me know what your availability looks like?
Flags: needinfo?(eshepherd)
Following up on our meeting in Whistler, I think we can move forward here. What's the next step? Do we need to come up with a more formal project plan? File bugs regarding features we will need added?
(In reply to Eric Shepherd [:sheppy] from comment #10)
> Following up on our meeting in Whistler, I think we can move forward here.
> What's the next step? Do we need to come up with a more formal project plan?
> File bugs regarding features we will need added?

Although it occurs to me I'd better confirm with my manager before making any big steps here... I'm on that now.
Although I'm more than intrigued to start working on this from our end, I actually don't think there's a whole lot to do. We'll stick around to help with the integration and writing possible additional API endpoints and whatnot but I suspect most of the work lies with you writing plugins and stuff.
(In reply to Peter Bengtsson [:peterbe] from comment #12)
> Although I'm more than intrigued to start working on this from our end, I
> actually don't think there's a whole lot to do. We'll stick around to help
> with the integration and writing possible additional API endpoints and
> whatnot but I suspect most of the work lies with you writing plugins and
> stuff.

There are several "coming soon" replies on the requirements list we shared a while back. What I need to find out is what kind of timetable we would be looking at to get those done so that they're available.

I'm going to work on a document laying out in finer detail what we plan to/hope to do.  The more we know about possibly getting time on your end to build those features out, the sooner (and more smoothly) I think we can make this happen.
In addition to the question about the "coming soon" functionality as mentioned in comment #13, I also need to know more about what's involved in integration work that we would need to do. You mention "plugins" and "writing possible additional API endpoints" but I'm not sure what these plugins are plugging into or what API you mean exactly. Clarification appreciated. :)
Flags: needinfo?(peterbe)
There are two things we might build into airmozilla to support you. Many more maybe, but these were mentioned when we chatted:

1. An API endpoint that returns meta data about events based on a URL (or something). Someone writing a MDN article might paste in the URL (e.g. "https://air.mozilla.org/dxr-2-0-part-1-dog-pony-show/") and from that what we really need is stuff like {"webm_url": "https://d3fenhwk93s16g.cloudfront.net/k6v9a9/webm.webm?t=1436201330559ab17238253", "webm_hd_url": "https://d3fenhwk93s16g.cloudfront.net/k6v9a9/hd_webm.webm?t=1436201360559ab1901bf6c"}.

2. A link to the upload page with some stuff automatically filled in. E.g. Instead of telling people to go to `https://air.mozilla.org/new/upload` you tell then to go to `https://air.mozilla.org/new/upload?mdn=12345` and we then extract the title, tags, description etc. from your API using `ID=12345` so that when the user has uploaded the file, the form is already prefilled with the good default title, description, channel, tags, etc.
Flags: needinfo?(peterbe)
(In reply to Peter Bengtsson [:peterbe] from comment #15)
> There are two things we might build into airmozilla to support you. Many
> more maybe, but these were mentioned when we chatted:

Good deal. There are a few others though, which I'll split into short-term and long-term needs:

Short term:

>  Yes   Ability to load a new video with the play position set to a given offset into the video.
>        **[ Requires 1 day development time. ]**

This is necessary to allow articles to point at specific parts of a longer tutorial.

>  Yes   IRC backchannel link to #mdn    
>        **[Not absolutely certain what you had in mind but we can put an irc URL and Mibbit or a similar IRC client on each MDN AirMo page]**

What we would want here is a standard place on each video page which would include a link to #mdn on IRC (perhaps both irc://irc.mozilla.org/mdn and a Mibbit link). A place for chat links that's the same on every MDN video page.

> Yes    An API for retrieving information about videos (title, available localizations, available sizes and bandwidth levels, duration, etc.).

So the ability already exists to use JavaScript to ask for the duration of a video, for example? It would be nice to be able to show users how much time they need to set aside to watch each video, for example.

Long term:

>  Yes   Support for adding sub-titles for various locales as well as the original language of the video.
>        **[ Not implemented today but on our roadmap.  Estimate 1 week development time Using Amara (Universal Subtitles)  -- We also have a path to multiple soundtracks in different languages if you have folks to want to overdub) ]**

Our international community would love to have this (both for text and audio).

> Maybe  Ability to trigger an action when given points in the video are reached; for instance, it would be great to be able to show specific snippets of code (or a slide from a presentation) when the speaker reaches the corresponding part of their talk.
>       **[This is the Popcorn integration we've always wanted to do, but we've not yet has a customer for it!]**

This would let us do some fantastic integration between documentation and tutorial videos. We would definitely be a customer for this functionality.

I am excited to move forward with this project and am beginning work on a more formal project proposal document, which I'll share once I have a draft ready. Hopefully the questions above will help me do a better job of it.

Platform deprecated.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.