I want to establish a p2p video chat using WebRTC.
This is meant for a "doctor-patient" 1-on-1 video chat.
The video conference should start at a certain date/time.
However, both parties should be able to already join the room, but not see each other. They should be able to adjust their camera in private.
How could this be achieved?
I'm absolutely not sure which way to go here.
Could I perhaps switch from local stream to p2p stream at that certain start date / time of the appointment?
Thank you.
Related
https://docs.agora.io/en/Interactive%20Broadcast/start_live_ios?platform=iOS
I've followed above tutorial to implement interactive live video streaming. I've one broadcaster and multiple audience. Only broadcaster can broadcast and audience can only view broadcaster.
Broadcaster can't hear his own audio. Is there a way to enable audio on broadcaster side so that he can hear his own audio?
I've used code from above tutorial and set role to .broadcaster on broadcaster side and on audience side it is set to .audience.
Broadcaster
func setClientRole() {
// Set the client role as "host"
agoraKit?.setClientRole(.broadcaster)
}
Audience
func setClientRole() {
// Set the client role as "audience"
agoraKit?.setClientRole(.audience)
}
Generally with Video Streaming services the local user can not hear their own audio by design (look at YouTube Live, FB/Insta Live, etc). Otherwise it would cause echo or could possibly mute the audio if the echo cancelation. It is also very disorienting to a user to hear themselves so I would recommend against this.
In an effort to still answer your question and if it's imperative to your project to have that mic audio, I would recommend that you force the user to use headphones to avoid echo issues. This way you can use a custom audio source (full guide), where you initialize the mic and can send the audio to the headphones as well as pass it to the Agora SDK.
Since the implementation end of this could vary greatly depending on your project, I'll explain the basic concept.
With Agora you can enable the custom audio source using:
self.agoraKit.enableExternalAudioSource(withSampleRate: sampleRate, channelsPerFrame: channel)
When you join the channel you would initialize the mic yourself, and maintain that buffer. Then pass the custom audio to the
self.agoraKit.pushExternalAudioFrame(buffer, System.currentTimeMillis());
For more details I'd recommend taking a look at Agora's API Examples Project. You can use some of the Audio Controllers to see how the audio is handled.
Context: we're building a HIPAA-compliant video chat, and evaluating Twilio as a potential supplier for video streams. Part of the requirement is that we need to make a recording on each video -and this needs to be stored encrypted in a HIPAA-compliant storage.
Having set up Twilio's excelent quickstart example, I've started a server, and were able to connect with two clients to it, with videos. However, looking around Twilio's room configuration, the server-side recording appears to refer to Twilio-based storage, which is not HIPAA-compliant.
Question: In what ways can we configure the started Node server to save a local copy of all streams participating in a room?
Thank you!
Twilio developer evangelist here.
When you set up a group room based video chat using Twilio Video all participants in the chat make WebRTC connections to a Twilio server in order to transmit and receive data via the room. When you turn on recording, the video that passes through the server is then written to disk. As far as I'm aware, this is not HIPAA compliant.
We do have a page on building HIPAA compliant video applications with Twilio Video but the advice is to use peer to peer rooms so that the only media that potentially goes through Twilio (via the TURN relay) is encrypted and can't be read or saved by Twilio.
You can't record the video on the Node server from the quickstart, because that's not used to stream the media at all. It only exists to generate an access token.
You could build a server that also joined the peer to peer room of the chat and saved the video that way. I have no experience in building WebRTC server applications though, so I can't help guide you with that. It's certainly not a case of just configuring the server differently.
Your other option would be to record the video in the client and somehow transfer that to your server. That might be unwieldy though for long chats that would cause extra work on the client and result in a potentially large video file to send to the server.
I'm building a streaming iOS app in Swift. Looking at the docs https://www.twilio.com/docs/api/video I understand that you can create live video chat rooms on the fly.
My use case is a bit different:
User A access a room, hit 'record' and start streaming a video of himself to Twilio storage. Creates a thumbnail in the UI. User B enters the same room and click the video thumbnail - that video should be streamed down to User B.
If user A is talking (Streaming up) and user B is in the room at the same time, it should be possible to 'Go live', which would start a live video chat room that other users can join too.
Main question: Does Twilio Programmable Video allow streaming up and down using their storage?
Secondary question: Would you say Twilio Programmable Video is the right choice for this use case or would you recommend another service?
Twilio developer evangelist here.
I'll answer this the other way around that you asked if that's ok.
If User A is currently streaming to a room and recording it (having created the room in group mode with RecordParticipantsOnConnect set to true) and another user wants to join the room, then they can. They just need an access token that gives them access to the room. They will then be able to join the room and chat and be recorded too.
Once a recording is complete, you will receive a webhook to the statusCallback URL that was set for the room. The callback for the recording will have the recording-complete and will include a MediaURL for the recording as well as the Uri and Sid for the recording resource.
You can use the media URL or the recording resource to get the binary data, which for videos will be in .mkv format. If you want to stream this video to your users, you may want to download the video and convert to a playable format. Or upload it to a streaming service.
Let me know if that helps at all.
I want to create a basic app that allow users to simply start to broadcast a video through their phone camera (front and back) just by pressing a button.
Does the YouTube live stream API allow me to handle the video streaming process?
If so, is YouTube Live Stream API totally free of charges and will never ask me to pay something if I reach a certain amount of usage?
Creating a Live Event and Live broadcast is language and hardware agnostic, just use YouTube's Live Streaming HTTP API. Read through the Core Concepts and Life of a Broadcast guides.
Your flow might look something like this:
Authenticate the user.
Set up and schedule your Live Broadcast object.
Start your video encoder and create a Live Stream Object.
Bind your Live Stream to your Live Broadcast.
Test to verify your video is going through.
Set your Live Broadcast to Live.
At the conclusion of your event, set your Live Broadcast to Ended.
Note that setting up your encoder is on you. Asking "How do I create an RTMP or DASH video encoder for [hardware or software]" is too broad of a question for Stack Overflow.
The YouTube API is free to use within a specific quota. If you hit that quota limit, there are ways to request additional quota from Google (potentially for a fee).
I answered a similar question about integrating with YouTube's Live Streaming API on iOS here: YouTube live on iOS?
I am new to Live streaming of a data. I have been exploring in a web about how to live stream a Video. Actually I am an iOS developer and I want to develop an App that streams video.
I am clear about the fundamentals of live video streaming. I came to know that I will be need a Streaming Media Server which will feed the stream to the viewer. I also came to know that viewer has to have a player which decodes the data and synchronize the audio/video stream.
Now, Wowza is a kind of Streaming Media Server which is recommended. But, I have following questions..
(1) Why Media Server? Why we can't have our own Media server? What actually Media Server do that makes its role necessary ?
(2) In my App, I will have to integrate a library for encoding and feed to a streaming server like Wowza. But, how it would be fed to the streaming server ?
(3) How will my server communicate with a streaming server like Wowza ?
(4) How Wowza will feed the stream to the receiving side i.e. the user having an iPhone and needs to see a live stream.
(5) What should be at the receiving side. What will decode the stream and will play the stream to AVPlayer ?
Guys, I need to develop a streaming App with better quality. So, better I first understand the flow of data and then start.
It would be great if someone gives a graphical representation of the data flow.
Thanks a lot in Advance !!!
Let me quickly add my understanding to your questions:
1a. Why Media Server? ..
You could write your own software for distributing the stream data to all the players as well. But in that case you would need to implement various transport protocols and you would end up implementing a fairly big piece of software, your home grown media server.
1b. What actually Media Server do to make its role necessary?
A way to see the role of the media server is to either receive the live stream from a stream source and handle the distribution of this stream to probably many-many other players. This usually involves taking the data out from the source transport protocol and repackage it into one or more other container format or transport protocol that the clients favour. Optionally the Media Server can change the way the video or the audio is encoded (transcoding), or produce different resolution and quality streams and provide the players with the list of available qualities in the form of a manifest file (e.g. m3u8 or smil file) so they can do so called adaptive streaming.
An other typical use-case of Media Servers is serving non-live video files to players from disk, as well as recording live streams, and so on. If you look at the feature list of popular media servers, you'll see that they are really doing many things, so practically this is something you probably want to get out of the box and not implement your own.
In my App, I will have to integrate a library for encoding and feed to a streaming server like Wowza. But, how it would be fed to the
streaming server?
You need to encode the video and audio with a particular codec (such as H.264 for video and AAC for audio), then you need to choose a suitable container format to put these streams into (e.g. MPEG-TS) and then choose a transport protocol to push the stream to the server (e.g. RTMP). Best if you google for tutorials to see how this looks like in code.
How will my server communicate with a streaming server like Wowza?
The contract is basically the transport protocol, one example is using RTMP protocol to connect to Wowza and publish the stream to it. These protocols cover all the technical details.
How Wowza will feed to the stream to the receiving side i.e. the user having an iPhone and needs to see a live stream.
The player software will initiate the communication with Wowza. This is again protocol dependent but in case you are using HLS, the player will use the HTTP protocol to find out the URL of the consequtive video chunks that it will progressively download and display to the user.
What should be at the receiving side. What will decode the stream and will play the stream to AVPlayer ?
It's not clear whether your app under development is the broadcaster side or the player side. But generally on the player side you need to find a library that is able to pull the stream from the media server with the protocol/transport/codec you are using. I am not familiar with this part in iOS, I only have experience with players embedded in websites.
I am not going to draw this, but imagine 3 boxes connected with arrows and that's the data flow. From encoder to streaming server and finally to player. That's it I guess.. :-)