Closed Bug 801693 Opened 7 years ago Closed 7 years ago

Camera - video recording - need to plumb video recorder error-handling

Categories

(Firefox OS Graveyard :: General, defect)

All
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed)

RESOLVED FIXED
blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- fixed

People

(Reporter: mikeh, Assigned: mikeh)

References

Details

Attachments

(1 file, 2 obsolete files)

This is likely related to the work required for bug 795090, but filing it separately and explicitly here.

The hook is to pass a suitable Listener-derived object into setListener().
blocking-basecamp: --- → ?
blocking-basecamp: ? → +
Assignee: nobody → mhabicher
Status: NEW → ASSIGNED
Whiteboard: [LOE:S]
:dale, how's this for an error handler?  Any thoughts on what kind of errors you want to get or even how specific they are?

It seems that in some cases, recovery is just restarting the preview, but I'm still trying to come up with a way of reliably triggering errors.
Attachment #676447 - Flags: feedback?(dale)
We will likely want to have 'time remaining' notifications, as well as when the recording is force stopped due to out of space. I cant think of many other expected errors.

Just in terms of nitting the api I would expect these to be an eventListener which would conform to the usual eventlistener semantics (addEventListener / remove etc), but that isnt a big deal for me.
Attachment #676447 - Flags: feedback?(dale) → feedback+
(In reply to Dale Harvey (:daleharvey) from comment #3)
> We will likely want to have 'time remaining' notifications, as well as when
> the recording is force stopped due to out of space. I cant think of many
> other expected errors.

Time remaining notifications?

Other errors: this may happen if the uSD card fails for some reason, or the recorder runs out of memory, or who knows what.

> Just in terms of nitting the api I would expect these to be an eventListener
> which would conform to the usual eventlistener semantics (addEventListener /
> remove etc), but that isnt a big deal for me.

Agreed.  I'm still learning how to do that, and will update all of the onX event handlers.
try-server push: https://tbpl.mozilla.org/?tree=Try&rev=881cf3083dbb

jst, do you have time for one more review?

dale, the messages this change will kick out to you include:
- FileSizeLimitReached and VideoLengthLimitReached
- TrackCompleted (two of these will accompany the above messages, or any time the recorder is stopped: one for the audio track, one for the video)
- MediaRecorderFailed, MediaServerFailed, and TrackFailed

I think they're pretty self-describing; when you receive one, the preview will freeze--just call stopRecording() and the preview will resume.
Attachment #676446 - Attachment is obsolete: true
Attachment #677517 - Flags: review?(jst)
Attachment #677517 - Flags: feedback?(dale)
Comment on attachment 677517 [details] [diff] [review]
Add support for onRecorderStateChange

Looks good!
Attachment #677517 - Flags: review?(jst) → review+
Attachment #676447 - Attachment is obsolete: true
Whiteboard: [LOE:S] → needs-checkin-aurora
https://hg.mozilla.org/mozilla-central/rev/b9835e1e6be8
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Attachment #677517 - Flags: feedback?(dale) → feedback+
You need to log in before you can comment on or make changes to this bug.