Basic-Video-Call
Basic-Video-Call copied to clipboard
Please update the samples with v2.90 sdk
Can we please have the samples update with the latest sdk.
the merge from dev/2.9.0 to master is on-going. you may now take a look at branch dev/2.9.0 first, in case you find sth wrong while compiling demo with latest sdk
Sure. I was trying to see how you would have implemented onRemoteVideoStateChanged().
The default state is REMOTE_VIDEO_STATE_STOPPED(0) & reason is REMOTE_VIDEO_STATE_REASON_REMOTE_MUTED(5). These are called even before REMOTE_VIDEO_STATE_STARTING(1) when a user joins a call.
If you use REMOTE_VIDEO_STATE_STOPPED(0) and REMOTE_VIDEO_STATE_REASON_REMOTE_MUTED(5) to ascertain if a user is muted then the very first message that comes is that the user has muted their cam. Then REMOTE_VIDEO_STATE_STARTING(1) is called and user joins and video is shown.
This behaviour doesn't seem to be right to me.
i did a quick test and the state code changed from 0 to 1..2..3, how did you managed to get state 5? Which api did you call?
Reason 5 and not State. State starts with 0. In my experience when a user joins, it starts with state REMOTE_VIDEO_STATE_STOPPED(0) and reason REMOTE_VIDEO_STATE_REASON_REMOTE_MUTED(5) which is the same one used for checking if a user is muted.
What I was saying was that the very first state is 0 and reason 5 which is also used to ascertain if the video is muted. So right before the very first video frame comes the user is notified that the video has been muted and then it calls REMOTE_VIDEO_STATE_STARTING(1) which is where I would start airing the video.
thanks for the feedback, you are right - this sounds unreasonable. I will talk to SDK team directly and push them to fix this by next release.
Great to hear that. Please feel free to close the ticket whenever you deem appropriate.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.