[Loop][Optimization] Load local video when calling or receiving a call even if it's not answered yet

RESOLVED FIXED

Status

Firefox OS
Gaia::Loop
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: borjasalguero, Assigned: borjasalguero)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

60 bytes, text/x-github-pull-request
On parental leave
: review+
vicky
: ui-review+
Details | Review | Splinter Review
(Assignee)

Description

3 years ago
We want to show to the user the local video Stream even if the call is not answered, trying to avoid user to be frustrated with no feedback in the UI.
(Assignee)

Updated

3 years ago
Assignee: nobody → borja.bugzilla
(Assignee)

Comment 1

3 years ago
Created attachment 8469215 [details] [review]
Pull Request
Attachment #8469215 - Flags: ui-review?(vpg)
Attachment #8469215 - Flags: review?(ferjmoreno)

Comment 2

3 years ago
Comment on attachment 8469215 [details] [review]
Pull Request

Thanks for the patch Borja.

I was wondering if we could try a different approach.

I believe we decided not to start any media stream until the callee party accepted the call to avoid unnecessary battery drain and network usage. But I agree that given that we are taking too long to connect both peers it might be worth to start the media stream as soon as possible.

Instead of using a fake local video, could we just start publishing the video of the caller as soon as the call is triggered? That way the caller will be able to see his own video stream very soon and we will save a few seconds on the call set up.

On the callee side we shouldn't publish the stream until the user accepts the call for obvious reasons. But alos I can't see how showing the local video in the callee side could improve the UX. In fact, IMHO it might even be scary for the user to see her own stream before accepting the call. She doesn't really know that we are not publishing it yet.

Also I believe that given the current absence of a proper echo cancellation feature we shouldn't publish the audio stream until both parties are connected.
Attachment #8469215 - Flags: review?(ferjmoreno)
(Assignee)

Comment 3

3 years ago
Comment on attachment 8469215 [details] [review]
Pull Request

Updated with Fernando's suggestions. Now we are publishing our stream asap, trying to reduce the time to connect with the other peer.
Attachment #8469215 - Flags: review?(ferjmoreno)
Attachment #8469215 - Flags: ui-review?(vpg) → ui-review+

Updated

3 years ago
Attachment #8469215 - Flags: review?(ferjmoreno) → review+
(Assignee)

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.