Moodle in English: Better support for audio/video capture

Better support for audio/video capture

by Justin Hunt - Tuesday, 9 April 2013, 4:09 PM

There is another thread going on that started to get into this, but I thought it deserves its own space.

Moodle doesn't have its own audio/video capture capability. For content creation and for language classes these are pretty much necessary. The current thinking is that since no recorder really covers all the bases, it is best to rely on plugins and let people choose the one that at least covers their bases. I basically agree with this. With Java applets insecure and basically dead, Flash only covering desktops, and HTML5 recording not up to speed , the landscape is changing and its a bad time to pick winners.

However there is still a lot we can do to shore moodle up. Basically I think Moodle needs to have a central media capture API that is called on from other areas of Moodle. So when Paul Daniels wants to add a recorder to his VideoBoard mod, he should just be able to call on Moodle's video capture api. Similarly the PoodLL audio recording assignment, would also be able to call on Moodle's audio capture api, and get a recorder back that is Moodle aware. As for the recorders themselves, Moodle might provide a base range of recorders, but should allow hooks for other recorders that implement the required API's, to be registered centrally.

I believe that this is similar to the way the new Media Capture repository works. Except there everything is limited to working as part of the repository. There is no central API that might allow someone to put an audio recorder in their slideshow mod, or anywhere else. The repository system is a good fallback but it just isn't direct enough for all cases.

Using this system would allow mods to call up an audio recorder, much as they now call up an HTML area or a file upload area, without needing to know the details of the implementation of the recorder. As recorders drop off the radar (java etc) and new ones show up (HTML5..) the mods require little or no modification, and Moodle can stay on the curve. The same system could work not just for audio and video, but for drawing applications.

The need to implement recording functionality is currently an impediment to the development of new and interesting mods because of the complexity of the task. And given the changing landscape is a risky undertaking. Having a central API could remove the impediment and future proof Moodle.

Average of ratings: Useful (4)

Re: Better support for audio/video capture

by Howard Miller - Tuesday, 9 April 2013, 4:28 PM

"Moodle doesn't have its own audio/video capture capability. For content creation and for language classes these are pretty much necessary"

I'm not sure I agree with you. At least I think this statement may need justified. I don't know anything about language classes but most material creation seems to happily go on outside of Moodle using whatever tools are best suited to the task.

Average of ratings: -

Re: Better support for audio/video capture

by Justin Hunt - Wednesday, 10 April 2013, 7:42 AM

True, I suppose its more of a "necessity" for language courses and a "nice to have" for other courses. But there are enough language teachers using PoodLL(thats my thing) and Nanogong and the like to make this a discussion worth having.

Do any people have thoughts on this?

Average of ratings: -

Re: Better support for audio/video capture

by Matt Bury - Wednesday, 10 April 2013, 8:58 AM

I'm involved with projects using Moodle for English as a Foreign Language (EFL), English as a Second Language (ESL), and English for Academic Purposes (EAP).

If Moodle is integrated as part of the core curriculum, especially on completely online (i.e. not blended learning) then media capture is pretty much a necessity. Learners have to be able to submit recordings in the correct formats for teacher and peer review and general discussions about discourse, presentations, interviewing, etc. Yes, learners can record on their cell/smartphones but as so many learners have iPhones these days, it presents problems of its own (See: http://blog.matbury.com/2013/01/09/are-you-using-an-iphone-ipad-or-ipod-touch-for-you-blog-project/).

If left to "fend for themselves" learners can run into all kinds of obstacles with file formats and/or transfering files from their recording devices to Moodle. I've witnessed learners' intense disappointment when they come to the depressing realisation that after all the hard work they've put into creating a recording, they can't submit it. It's soemthing that can kill learners' engagement and enthusiasm for a course.

What Moodle needs is a simple, easy to deploy, one or two step system for capturing and submitting audio and video recordings in appropriate formats. We're not talking live streaming and media servers here, just record and submit.

Nanogong is great but the necessary JRE is becoming more of a rareity on school, college, and university computers these days, and not something that many system admins or IT support are willing to deal with.

There's a Flash based alternative that pretty much does the same things and records and uploads audio to MP3 very reliably in my experience. AFAIK, there's nothing for HTML5 and, as linked to above, iPhones and iPads don't allow uploading in the browser anyway.

I hope this helps!

Average of ratings: Useful (3)

Re: Better support for audio/video capture

by Justin Hunt - Wednesday, 10 April 2013, 10:24 AM

Well .. PoodLL does all that, detecting device and then offering mp3 recording or html5 record and upload. There is a video of html5 recording here at the bottom of this post. You can try it all out at http://demo.poodll.com

I think it is the most complete solution for Moodle out there. I am biased of course, being the PoodLL guy. But I don't want to toot the PoodLL trumpet too loud here, since we are really on the same page. Its the wild west right now with formats and recorders and platforms. It makes developing recording mods really complex, and forces teachers to get involved in technical situations they really shouldn't have to concern themselves with.

The point I am making is that Moodle doesn't have to try and resolve all of that. I think it just needs to provide an API for recording plugins, and an API for mod developers to request a recorder.

Average of ratings: Useful (3)

Re: Better support for audio/video capture

by Marcus Green - Wednesday, 10 April 2013, 2:54 PM

Justin, you may be biased, but I suspect you are also right.

It's worth contrasting what the core of Moodle does and what is required to do audio capture and playback. Core moodle depends primarily on web forms and to a slightly lesser extent Javascript. Every browser release for a decade or so has supported web forms in a standardised way, "it just works". Javascript has now become widely standardised and generally works. So you have two standards...

By contrast audio on the web has no accepted single standard. You can do it with Java on the client but it has trust problems, plenty of people don't have it installed. Flash was becoming universal but has now been massively pushed back because of Apples stance and Adobe's dropping of Flash for mobile. HTML 5 promises much and may well become the standard but it is not there yet.

So developing for this requirement is partly a gamble on the future and whatever technology you choose you can be confident that it will not have universal access for the near future.

By contrast developing functionality for PHP and web forms will run on just about anything now and for the forseeable future.

Average of ratings: Useful (3)

Re: Better support for audio/video capture

by Matt Bury - Wednesday, 10 April 2013, 8:57 PM

To underline a point, the issue with iOS devices is not that they block this or that runtime (Java or Flash) but that users can't upload files in the browser at all (See the article I linked to above).

BTW, Flash runs perfectly well on iOS and Android, and is still supported by Adobe. Flash Player for mobile and Linux has stopped at FP 11.2 which has more than enough functionality to satisfy the vast majority of oniline elearning applications. Apple Inc's objection to Flash in the browser was that it would undercut their profits from iTunes App Store. Some of the most successful games on iPhone and iPad were developed in Flash: http://gaming.adobe.com/

Average of ratings: -

Re: Better support for audio/video capture

by Marcus Green - Wednesday, 10 April 2013, 10:02 PM

Up to a point (Lord Copper). I have owned two Android phones and neither came with flash. As a geek it might have been possible to get it to work on the second phone, but most of the world are not geeks. I understand that Flash does not come as standard with iOS, which means for most of humanty, iOs does not run on iOS.

Your comment about iOS not allowing upload through flash confirms my opinion that it represents the spoon of mobile operating systems whereas I am interested in having a spoon, knife and fork.

I just read your blog post Matt, very interesting.

Average of ratings: -

Re: Better support for audio/video capture

by Matt Bury - Thursday, 11 April 2013, 2:44 PM

Hi Marcus,

The uploading issue isn't related/limited to Flash, it's all uploads via the browser. I've witnessed half a cohort of learners with their iPhones, sitting dismayed that they couldn't upload their photos, audio, or video to complete their online projects. Apparently, there's no way round it, you either need to sync the iPhones with their "paired" PCs/Macs or use some kind of app that's compatible with your LMS/CMS.

Flash isn't just a browser plugin. Basically, Apple Inc. want to push as much functionality onto its App Store as possible. If you want to do anything "fancy" you have to go via apps and, at the moment, that's where Flash is going on mobile devices instead of in the browser.

There are also non-branded smartphones that have Flash Player preinstalled, e.g. http://www.amazon.co.uk/STAR-N9770-SANDWICH-smartphone-supported/dp/B008MKGNF6/ It might become more common as users see the benefits (and of course the drawbacks) of being able to view the ubiquitous Flash content on the websites they visit.

Hi Justin,

Perhaps iOS 6 has lifted this block. It would certainly be good news for iPhone and iPad users that have it. Quick check and yep, looks like it: http://www.idownloadblog.com/2012/06/13/ios-6-safari-media-uploads/

Perhaps one day, using a mobile device won't feel like taking a time machine back to 1999.

Average of ratings: -

Re: Better support for audio/video capture

by Matt Bury - Thursday, 11 April 2013, 2:45 PM

Hi Marcus,

Hi Justin,

Perhaps one day, using a mobile device won't feel like taking a time machine back to 1999.

Average of ratings: -

Re: Better support for audio/video capture

by Justin Hunt - Wednesday, 10 April 2013, 10:26 PM

Are we talking about the same thing? Users of iOS 6 and above can upload photos and videos from their devices camera roll, directly from their browsers. They can also optionally shoot straight from their camera and upload. As in the video I posted.

Flash doesn't run perfectly well on iOS, at least not in the only browser most iUsers use, Safari. Thats partly why we are in this thread together, because flash audio and video recorders don't work in any acceptable way on iOS and mostly not on Android either.

Average of ratings: -

Re: Better support for audio/video capture

by Simon Story - Thursday, 11 April 2013, 4:16 PM

No, flash is almost gone on Android too. You can't install it on the Nexus 4 and I think on the Nexus 7 as well. I don't think it is straightforward install from the Play store on any Android >4.1.x device.

It may work perfectly, but the fact you have side-load on the developer reference devices makes the message pretty loud and clear (to me) that developers should not bother developing for it.

Adobe Air is still there.

Average of ratings: -

Re: Better support for audio/video capture

by Richard Oelmann - Thursday, 11 April 2013, 5:35 PM

As you say, you can't install it direct from the Play store, but using work-arounds on the net, I do have flash on my nexus7 with the firefox browser, although I haven't tried on my nexus4 yet.

That said I agree, Android/Google are deliberately making it hard to install in order to kill it off on their devices and most users will not bother to do this and will just say - no, Flash doesn't work

Richard

Average of ratings: -

Re: Better support for audio/video capture

by Matt Bury - Thursday, 11 April 2013, 6:27 PM

To reiterate: Flash DOES run on iOS and Android, just not in the browser. You just download and install your Flash apps on the desktop along with all your other software. Millions of users play Flash games on iOS and Android.

It's simple: you write a single code base for your app and then port (cross-compile) it for whichever platforms you want to target (WORA). For example, if you want to support advanced video features and functions (e.g. RTMP/live streaming, webcam/mic capture), develop a media player from something like the Open Source Media Framework (http://www.osmf.org/), from your single code base, compile and package the versions for the various platforms (you might need to make some adjustments for some platforms), and then upload them to Google Play, iTunes, and whichever other app stores you want to target (not all Android devices can install apps from Google Play - Some network carriers insist that you use their own app stores).

Average of ratings: -

Re: Better support for audio/video capture

by Paul Nicholls - Friday, 12 April 2013, 5:28 AM

As far as I recall (and can discern from the information that's out there), it was Adobe who pulled it from the Android market / Play store (I forget which it was called at the time) - Google had little to do with it. Adobe decided to cease development on mobile Flash Player rather than release a version for Jelly Bean, and flipped the switch to prevent new installs (claiming that "unpredictable behaviour" was likely on JB).

As for the original topic of this thread, some kind of core media capture API would be great. For quite a while now, I've been wanting to rebuild my Flash audio recording widget as an HTML interface with HTML5 and Flash backends (sorry, I'm not going to go near Java!) - but I just haven't had the time to so much as get started on it. That said, the longer it's left, the more likely that all the building blocks (GetUserMedia, Media Capture API) will be in place in enough browsers to make it really worthwhile.

-Paul

Average of ratings: Useful (1)

Re: Better support for audio/video capture

by Justin Hunt - Friday, 12 April 2013, 7:28 AM

Yes an html front end that supports both desktop/flash/java and mobile would be great As part of a media capture API.

Something like this for audio:

Record or upload

Average of ratings: Useful (1)

Re: Better support for audio/video capture

by Paul Daniels - Monday, 15 April 2013, 2:09 PM

Hello,

As others have commented, video/audio recording needs to be transparant for both the learners and teacher. Installing (after creating) an app is always an option, but whenever possible, this should be avoided to lessen the complexity of the assignment. Learners (as well as teachers) want the simplist solution (i.e. browser only) when completing an assignment.

1. Currently, using html5 users can submit images, video and audio (in iOS can submit video and the server can strip the audio) directly from the browser using a standart browser in iOS and Android.

2. As Jusin was saying (and I agree) that Moodle has room for improvement to better accomodate media capture (perhaos via a media capture API).

3. The API would support both capture and playback from a number of devices & technologies (i.e. html5 media capture/uploads, Flash capture & Java capture.

Average of ratings: Useful (1)

Re: Better support for audio/video capture

by Marcus Green - Monday, 15 April 2013, 6:51 PM

That sounds like an expensive chunk of development, that would be used by a minority and would lack compatibility for many people.

Or resources could be put into development that would be used by the majority, and be compatible with almost every browser.

I'm not saying that these technologies are not important, but that they should not be part of core Moodle. Moodle should make it easy to integrate and incorporate 3rd party developments.

Average of ratings: -

Re: Better support for audio/video capture

by Justin Hunt - Tuesday, 16 April 2013, 8:13 AM

Marcus,

You are definitely correct that Moodle core shouldn't be muddling around with the complexities of audio/video recording. And I think that has pushed the discussion into "leave it up to third party plugins."

What I am suggesting is that Moodle takes one more step to aiding plugin developers. And it is not such a big step either. Moodle doesn't need to provide recorders. It just needs to provide an API for the Moodle Form that fetches an audio recorder. And a new plugin type called "audiorecorder."

People like me(PoodLL) will write audiorecorder plugins. And maybe Paul Nichols will do one for his audio recorder, and someone do one for nanogong. Then when plugin developers want to make, say, an audio forum plugin, or a narrated slide show mod, they don't have to also write their own audio recorder. They just call the fetch audio recorder API of the Moodle form.

It would work pretty much how it does now for the file picker. Currently you do something like this:

$mform->addElement('filepicker', 'userfile', get_string('file'), null, array('maxbytes' => $maxbytes, 'accepted_types' => '*'));

But for getting an audio recorder you might call this:

$mform->addElement('audiorecorder', 'audiofile', get_string('audionarration'), null, array('maxbytes' => $maxbytes));

The audiorecorder type would deal with getting the recording into the draft files area, and possibly doing file conversions. How to deal with playback and HTML5 etc are things that would need to be decided, but those are not insurmountable problems.

Average of ratings: Useful (1)

Re: Better support for audio/video capture

by Marcus Green - Tuesday, 16 April 2013, 3:08 PM

Sounds an excellent idea, I'd vote for that.

Average of ratings: -

Re: Better support for audio/video capture

by Matt Bury - Tuesday, 16 April 2013, 9:56 PM

At this point would it be a good idea to list some examples of usage scenarios from learners', teachers', and curriculum developers' perspectives? I think it may give us a better idea of what Moodle + media capture would need to do and what it might look like.

We already have the functions of the Nanogong and Audio Recorder modules and filters.

How about quiz question type? i.e. listen/read and respond orally.
Oral forum discussions? i.e. users record their contributions to an oral discussion.
Oral glossaries? e.g. user generated talking dictionaries, narrated charts/diagrams.
more?

Basically, it should be easy to place audio and maybe even video anywhere you would normally find text.

I think it'd also make Moodle a lot more accessible for the visually impaired and less dependent on expensive proprietary assistive software like JAWS, and recordings of humans are so much easier on the ear than "robot" voices.

Who would use easy-anywhere media capture?

Second and foreign languages.
Media studies.
Marketing and public relations.
Journalism.
Prep courses for academics to appear in the media, e.g. promotion, news, consultancy, and interviews.
more?

I think the idea is to remove as many of the barriers to spontaneous, collaborative, online computer mediated learning activities as possible so recording audio to somehwere on Moodle should be as easy as typing.

Is that too ambitious for Moodle?

Average of ratings: Useful (1)

Re: Better support for audio/video capture

by Tim Hunt - Tuesday, 16 April 2013, 3:35 PM

We don't need to add a new plugin type for this. There already is one, the repository plugin type.

Indeed, PoodLL have already already made a record audio/video repository, haven't they?

We had a go at the OU, but failed for various reasons. The repository API might need a bit of optimising, but we really don't need anything fundamentally new - other than plugins.

Average of ratings: -

Re: Better support for audio/video capture

by Justin Hunt - Wednesday, 17 April 2013, 12:48 PM

Yes, Tim, you are right. PoodLL does have an audio/video recording repository. And the repository system is a good general panacea. But it just is not effective for every situation.

For example when an audio recording is required as a response to quiz question. Clicking through from the file picker to the audio recording repository and then clicking back out again, is not that great and raises various points at which a hapless student could get lost.

Another problem is that currently if an audio file is selected/recorded via the file manager/file picker components, the file when later displayed can not be played inline. It has to be downloaded or played in a popup.

The real purpose of the proposed change is to encourage the development of new mods with recording capability built in. This would free mod developers up from having to code their own recording solution and let them focus on their mod. Also given the fractious landscape for recording right now, it allows us to get on with making recording mods, without being locked into a recording solution. So when HTML5 recording truly arrives, or Java applets truly die, the mod doesn't require a a near rewrite.

Having said all that, it does depend on what these future mods would be and whether the file picker (possibly modified to allow inline playback) would suffice.

Matt already gave a list of audio recording capable mods that he felt might be considered. Here is a list off the top of my going bald head. Most of them already exist in some form(its hard to predict the future), but are tied to a single recording solution.

assignment submission type
assignment feedback type
question type
database activity field type
audio annotated slideshow
voice shadow (think "listen THEN repeat" followed by " listen AND repeat"
TinyMCE plugin (toolbar icon)
Audio messaging block

Average of ratings: -

Re: Better support for audio/video capture

by Tim Hunt - Wednesday, 17 April 2013, 3:55 PM

Right, so in the case where you know the user will be recording some media, rather than uploading an arbitrary file type, then it would be good to optimise the UI so that the recording widget is right there in the page. However, we can do that using the existing repostiory plugins (with perhaps minor tweeks).

We would need to create new formslib field type for audio and/or video, but that would just display the existing record audio/video repository UI inline in the form, rather than making user click the button to pop-up the file-picker. I guess there would be admin settings for which repository plugin to use for audio/video.

For the download thing, there is a good, security-related reason why we have to force download of files uploaded by students. The solution for this that works everywhere else is the multimedia filter, isn't it? That lets you play media files inline. Why won't that work here?

Average of ratings: -

Re: Better support for audio/video capture

by Justin Hunt - Wednesday, 17 April 2013, 4:41 PM

Hmm, that is an interesting idea. Using the existing repository plugins and displaying them inline. If that could be done it would be a neat solution. And as you were saying, it would avoid the need to create another plugin type. The flip side of that of course, is that the repository API would probably have to change and some might not think the gain justifies the disruption.

The "download vs play inline" problem turns out to be not with the file manager/picker component actually. I just went and checked. It seems that the different mods handle the display of the uploaded file differently. The assignment won't pass file submissions or file feedbacks through any filters. That is what really forces the download. The forum however does filter the text, and we get a player. I did not look at other mods.

Average of ratings: -

Re: Better support for audio/video capture

by Jamie Pratt - Saturday, 10 August 2013, 7:20 PM

Thinking through Tim's idea, streamlining the file picker UI may not be that trivial to do well.

Normally the file picker pop up would :

allow repositories to upload or do whatever in order to store files in the file repository which are for the time being associated with the draft item area id.
then the files are already on the sever and it is this draft item id that is then uploaded with the form.

I guess we could stick with a similar model if we were recording audio with a Flash or HTML5 widget inline in the page. I wonder if the submission of the form before the audio has been saved in the background by the widget might cause problems. The Flash or HTML widget would probably send the audio file to the server after recording, by which time the user would probably be about ready to press submit on whatever form they are interacting with.

We could alternatively submit the audio file along with the form instead of the draft item id. I think that would be quite a departure away from the way the other repository plug ins work.

Average of ratings: -

Re: Better support for audio/video capture

by Tim Hunt - Saturday, 10 August 2013, 8:51 PM

While this is not trivial, it is not that hard either. We (well, I think it was sam) did this in some OU activities (using this Java applet https://github.com/sammarshallou/ouaudioapplets).

For this sort of thing, you can't re-use any of the filepicker. You embed your applet wherever you want it, and get it to post to a custom script that saves the file in an appropriate place. That probably means using the File API to store it in an appropriate file area, or draft file area.

If you are thinking of creating a question type, then you need to mimic what the file manager does for attachments to essay questions. When the question is displayed, an appropriate draft file area is created, and you need to store the audio data into there as a file.

Average of ratings: -

Re: Better support for audio/video capture

by Matt Bury - Sunday, 11 August 2013, 12:43 AM

Something that seems to be becoming an issue with Moodle already is how Javascript performs on ARM chip (mobile) devices, e.g. the long discussion on "Can we stop using TinyMCE yet?"

Using Javascript to handle media capture in addition to Moodle's heavy UIs may work well on AMD and Intel (x86) CPUs which have enough power and memory to deal with them, but for the foreseeable future, it looks like ARM CPUs are likely to run into difficulties very quickly.

See: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ and a response http://www.codenameone.com/3/post/2013/07/why-mobile-web-is-slow.html

Perhaps in the not-to-distant future consumers' perceptions ARM based tablets (with add-on keyboards) and AMD/Intel based ultrabooks/laptops will converge. It's not unreasonable for people to expect something that looks like a laptop to behave like a laptop. In which case, there'll be two kinds of laptops; slow/weak (ARM) and fast/beefy* (AMD/Intel). Then, demands for using Javascript intensive UIs and web apps will put pressure on OEMs to produce personal computers that perform like we expect personal computers to perform.

*"beefy" was the actual term I heard used by a research scientist (Can't find the link) to describe the comparative performance of ARM vs. AMD/Intel (x86).

Average of ratings: -

Re: Better support for audio/video capture

by Tim Hunt - Sunday, 11 August 2013, 5:13 PM

Matt, where is anyone talking about audio-capture in JavaScript? From reading you past posts, you seem to have a pro-flash, anti-anything-else bias. What has this thread done to deserve your standard rant on the subject?

But, to explain how audio capture actually works (roughly)

You have a microphone connected to the computer. This spits out a stream of uncompressed data.
You then need to encode that into a standard data format, like MP3. This is the computationally expensive bit.
Then you have to do something with that data, e.g. save it to a file, or send it to a Moodle server. Also to control when to start and stop recording.

2. gets done by library code written in C, hopefully optimised for your particular hardware, which may have hardware accelerations for specifically that task. The code for 3. is just glue code. It does not do anything performance critical.

Using Flash (I believe) the audio library is build into the flash browser plug-in, and the glue code is written in Action Script = ECMAscript.

Using HTML5, the audio library is build into the web browser, and the glue code is written in JavaScript = ECMAscript.

So, once we have HTML5 compliant browsers, the two solutions should have similar performance.

Average of ratings: Useful (1)

Re: Better support for audio/video capture

by Matt Bury - Monday, 12 August 2013, 7:55 AM

Tim, I don't want to get involved in personal attacks; I find them unconstructive and distasteful. Let's stick to the topic and facts.

All the cross platform HTML5 implementations of media capture I've seen so far use Javascript workarounds. Do you know of any working examples that don't? Currently, whatever language you use, Javascript, Actionscript, or Java, has to manage ByteArrays of media data to manage storage, playback, and encoding. There are some great open source libraries available for transcoding captured media to various web formats and they have some impressive low-level coding to optimise it (Hats off to those developers!) The main issue so far has been browsers crashing even in reasonably powerful desktop computers because of the shortcomings of Javascript, i.e. no concurrency (multi-threading), no memory management, and no built in multimedia classes.

Actionscript and Java support concurrency, have effective memory management, and built in classes for managing multimedia.

Assuming that most browsers will eventually support native media capture (client side binaries built into the browser), we're still held back by the same issues that are holding back audio and video playback: CODEC licensing. Unless we can convince Microsoft, Apple, Google, and Mozilla to support open source CODECs or at least agree to all support the same one(s), we're still stuck with the mess of multiple CODECs.

So how will media be encoded on the client side and what will make that playable to users of other browsers?

So, the way I see it, the issue is how to develop a media capture API that resolves these issues and can be made forwardly compatible with whatever Microsoft, Apple, Google, and Mozilla have in store for us in the months and years to come.

Average of ratings: Useful (1)

Re: Better support for audio/video capture

by Justin Hunt - Monday, 12 August 2013, 4:13 PM

Actually I also think that using the repository plugins as parts of this, would be stretching things a little. Because the code to display the recorder and where the file is posted and picked up is not all that simple to just lift and put into the Moodle form. eg there is no getrecorder or getsubmittedfile function in the repository api.

But it is worth thinking about the different ways this might be accomplished. With changes in the repository api, that is an option you could put on the table.

re javascript vs arm processors and flash obsessions. Well that and Matt's previous posts, point more to the need for a new a/v capture element for the Moodle forms library than against it really.

The idea is to provide the apis for recorders and then leave the implementation up to them . Moodle just prepares the info the recorder needs and fetches back the submitted file. As the landscape changes, flash dies, javascript gets awesome, all the browsers get html5 recording etc, the forms using the av capture form element really don't need to change. Moodle devs are happy, plugins devs are happy, site admins are happy. People making recorders for the api, have a little work to do of course.

Average of ratings: -

Re: Better support for audio/video capture

by Tim Hunt - Monday, 12 August 2013, 9:01 PM

You may think it is a stretch, but at least three people have already made it work: https://moodle.org/plugins/browse.php?list=category&id=25

Average of ratings: -

Re: Better support for audio/video capture

by Justin Hunt - Monday, 12 August 2013, 9:39 PM

Well four if you count

PoodLL

which I wrote.

Trying to turn an existing repository plugin into an audio/video capture forms element, is the stretch I am talking about.

I proposed a new audio/video/image capture forms element that published a capture API. And then I proposed a new plugin type for the "recorders" that would interface with that API. That way the forms that used the av capture element would not need to worry about how the recording was implemented.

You suggested we did not need a new plugin type for the recorders, because we already had the repository plugins. The stretch is really trying to make the repository plugin do the job of the "recorder" plugin.

Average of ratings: Useful (2)

Re: Better support for audio/video capture

by Tim Hunt - Tuesday, 13 August 2013, 1:31 AM

Sorry, I should have remebered PoodLL.

audio/video/image capture form field elemnts might acutally be a good idea, but they shoudl also be usabile outside formslib. E.g. in question types. Still not sure whether this really requires a new plugin type.

Average of ratings: -

Re: Better support for audio/video capture

by Justin Hunt - Monday, 12 August 2013, 4:15 PM

I suppose it is time now that I should really summarize all this, make a proposed set of APIs and put it on the tracker.

Average of ratings: -

Re: Better support for audio/video capture

by Stuart Lamour - Tuesday, 13 August 2013, 8:12 AM

Hi Justin,

this is a long one, apologies!

We have a full on video & audio transcoding, lecture capture & personal capture system at Sussex based on the open source http://opencast.org/matterhorn/ + moodle.

Before we integrated this institutional youtube/soundcloud into our moodle the majority of our tutors thought audio and video on the interweb were indistinguishable from 'magic' or required the full services of the bbc. Fortunately, once we made it simple for them - they seem much happier with it all.

To start with lectures are recorded in rooms with the necessary metadata, auto transcoded on the matterhorn server into mobile friendly, flash versions etc and then tutors can 'claim' them in moodle through a custom moodle mod - lecture recording.

Here is a video of this workflow -

Students can watch lectures on any device, download them etc and in our 'top tips from students for tutors' research it came out as one of the highest rated things in our moodle.

The matterhorn 'engage' player page mixes flash and html - it not currently great it terms of usability, but it looks like it will be getting better http://engagedevcamp.files.wordpress.com/2013/06/theodul-pass-player-the-new-matterhorn-engage-player.pdf.

It does some great things like ocr of slides, subtitling and building chapters into videos and this seems to be getting better all the time with a major focus on accessibility (its great to use with screen readers and without a mouse).

We built lots of custom things like our own none-flash fallback but they seem to be building many of these into the next version - the community http://engagedevcamp.wordpress.com/ are a good bunch.

For personal capture we built an mvp upload to matterhorn - just a button on the wysiwyg editor in moodle. In practice this is really rather powerful.

It means that anywhere you have a wysiwyg editor in moodle, you can upload a recording and it will return the embed/iframe of your recording (with a message as to how far it is in processing) into the html - in quizzes, assignments, forums, messages, marking and giving feedback - you name it. Flip learning becomes very simple. If you have a wysiwyg editor on the page, you can add a recording.

It is just a standard html select button, with a few html5 params, but in practice this is incredibly powerful. On mobile/tablet it gives you direct access to the device camera to record - it just works

Desktop it actually lagging behind because, as you say, html isn't quite there yet. You cannot yet do it all in the browser, but it is getting there.

As you probably know there are already a plethora of real time web video chat systems https://apprtc.appspot.com/ in html5 and i built a webrtc for moodle, with flash fallback, that still has a few teething problems, but most importantly makes the rather expensively licenced ways we normally do this stuff obsolete....

...and there are some rather fun javascript libs to capture/record/download your getusermedia http://ericbidelman.tumblr.com/post/31486670538/creating-webm-video-from-getusermedia with all of the majour players pushing for http://www.w3.org/TR/mediastream-recording/ although at the time of writing my code can currently only record/capture the live video (without audio) as a download or into moodle

For the moment we allow the user to use anything they have (native mobile/tablet or desktop app) to record & upload - then take care of transcoding it into an appropriate format for anyone to watch - which is a huge educational win, especially for our language and sign language courses.

While none-opensource products like http://mediacore.com/ are out there people can always buy an offtheshelf version, but i completely agree with your sentiment/vision that this is an important part of the future for online learning - as important as uploading a pdf/doc was creating the online text in a wysiwyg editor is today - and strategically it would be advantages for moodle hq to start thinking about this now, before it passes them buy.

Did you read/watch https://www.ezuce.com/blog/1749751/the-promise-of-webrtc-for-higher-ed ?

Thanks again for kicking this off.

Cheers

Stuart Lamour, user experience developer, university of sussex (http://blogs.sussex.ac.uk/elearningteam/)

Average of ratings: Useful (3)

Re: Better support for audio/video capture

by Stuart Lamour - Tuesday, 13 August 2013, 8:46 AM

p.s. for audio - i'm good with this polyfill https://github.com/mattdiamond/Recorderjs

anyone found a good one for video synched audio yet?

Average of ratings: -

Re: Better support for audio/video capture

by Justin Hunt - Tuesday, 20 August 2013, 8:38 AM

Stuart

It took me a week to read all those resources and info you linked to. It sounds like you have a complete system.

Average of ratings: -