876018 - [refapps][rtcamera] Determine possible fallback for platforms without WebRTC

Status: RESOLVED FIXED

(Developer Ecosystem :: App Center, defect)

Description

[Fred Wenzel [:wenzel]]

On current FirefoxOS and other platforms without getUserMedia, let's figure out if rtcamera can still do something useful. A possibility would be firing a web activity (or a file upload dialog) for a photo, or even a video, and apply our filters to it before returning a gif file, just as if we worked on a video stream.

If this seems necessary for a good v1, I am fine delaying bug 876015 until we added this. Otherwise, proceed deploying v1 without this fallback.

Comment 1

[Soledad Penades [:sole] [:spenades]]

Things we should do:

- improve WebRTC/getUserMedia detection. Currently in some platforms the error callback doesn't even get fired. So we should add some sort of timeout to it, if it hasn't happened just assume there's no getUserMedia possible

- Introduce the 'static' mode where we can choose existing images instead of using the live stream from the camera. We could add a menu with options - to start with the option would be selecting an existing image. If, on loading the app, we deem that getUserMedia is not present, then we change immediately to that mode and allow the user to select an image. Or maybe we could show a warning saying "hey, your platform doesn't support this, we changed to static, tap here for more info or tap here to continue".

I presume picking a video could work as well: it just a matter of changing the video source. Instead of being the live stream, it would then be a local video. The only issue I can think of is (guess!) codecs; I'd have to experiment to see which sort of videos are offered to the browser when the file picker dialog is opened, and what sort of support is available.

Once an item is selected, we could keep swiping to change current filter, just like right now.

- It would also be nice to introduce some sort of "camera roll" using indexeddb. This would store processed pictures/videos in the "camera roll" instead of forcing a download, which sometimes "breaks" things in Firefox for Android, and would also allow us to demonstrate the use of this API for Firefox OS. Plus it would make unnecessary the use of external viewers as I have to use on Android to see what I have downloaded. It would all be self contained in the same app.

Once in the roll, you could view the images and select whether to download it or publish it to imgur or something using yet another API :-)

- I understand that even the basic-est of FFOS phones have WebGL support, but we should add some detection/error handling for that too, even if it's just quite basic.
Currently the code just happily assumes WebGL is present!

I think this could do for covering/making more robust or complete the app for non gUM capable platforms.

Comment 2

[Soledad Penades [:sole] [:spenades]]

Closing as the fallback is determined --Fred, please reopen if you find we need to determine something else!