WebRTC Native c++ demo

[T Man]

I was trying to build the webrtc native c++ demo examples described in http://www.webrtc.org/reference/getting-started

I was able to get the Peerconection_client and the Peerconnection_server working, I have some basic questions about the implementation.

I assumed that the peerconnection_server was only the signalling channel between the two peer instances but after I got two peers video streaming to each other, i saw that the video/audio UDP traffic was passing via the peerconnection_server.

I dont understand why the implementation of the native demo is not the same as the browser, where we have the clients communicate directly to each other P2P after using the signalling channel to exchange SDPs, I wanted to be able to get a native implementation communicate with a browser based HTML5 version, but looks like the Native demo code is not organized to make this implementation easy to do.

I'd like to have your opnions if you think i've misunderstood something with regards to the native demo?????

[V]

I'm doing something very similar with the native to web browser.  It seems everyone is more focused on the browser to browser and the native doesn't get much support yet.  I'm not complain as I need both to work if we end up using webrtc...maybe we need a native only forum as I'm sure others exist like us too.  In response, I've only been working with the codebase for a couple weeks and can tell you where you might want to look.  In the conductor class, you can compile with debug(or optimizations off) on the peer client and look at the messages/JSEP (or is it still ROAP for the native?  I didn't validate or even look at the code if its still ROAP or JSEP).  At one time I thought it was at least telling each other to send the video p2p.  I did see a string message that can go round trip with the server, but not video (but I was not looking for video to be wrong as I would have expected what you expected to see as well).

[Philipp Hancke]

It is quite easy to emulate the signalling protocol peerconnection_client speaks to the peerconnection_server in a browser-based client and thereby demonstrate interoperability. The protocol is basically using two GET for signing in and out (/sign_in and /sign_out), another one for polling (/wait) and a POST for sending a message to another client (/message).
server_test.html in libjingle/source/talk/examples/peerconnection/server already implements it and you might only have to add a getusermedia, peerconnection and video stuff.

[T Man]

@philipp : thanks for the suggestion, beats me as to why the example does not have the peerconnection and video stuff!!

[T Man]

I have tried to process the offer sent by the native client implementation, but was not able to get to to create an Answer successfully, Hasn't anyone done this already??

On Tuesday, 20 November 2012 09:40:59 UTC+1, Philipp Hancke wrote:

[T Man]

Well, i found the error, the pc.setRemoteDescription() expects a JSON object and I was passing a JSON string :D Annoying, anyway, i'll keep silent unless I get the whole thing working.

[T Man]

http://dl.dropbox.com/u/14722731/appstract/jsep_native/server_test.html

I have tried to modify the html page to communicate with the native client, in the above link, i'm just not sure  how to get the html and native clients to ICE each other.

On Tuesday, 20 November 2012 09:40:59 UTC+1, Philipp Hancke wrote:

[Ket]

I've complained about something similar long ago but it seems no one listens.

[T Man]

Thats sad, I've noticed that that native code uses the same STUN server too, 

STUN stun.l.google.com:19302

and I do get a stream URL, its just that, nothing plays, could someone please tell me how to get this to work? i.e. browser to native. 

[Harald Alvestrand]

I don't think the stun.l.google.com server is RFC compliant.
Use your own servers, or the servers used by the apprtc.appspot.com demo.

We won't be doing support on connecting to the non-compliant servers.

> --
>
>
>

[Antony Meyn]

the servers used by the apprtc.appspot.com demo is

var pc_config = {"iceServers": [{"url": "stun:stun.l.google.com:19302"}]};

I have tried using the following modified html code to talk to the latest native peerconnection_client via the peerconnection_server.

>>> http://dl.dropbox.com/u/14722731/appstract/jsep_native/server_test.html

--

[Antony Meyn]

I got this to work :) Finally

--
Regards,

Antony Meyn

{ Backend Developer } @ Appstract

+45 71891398

[V]

Nice! I was on vacation...otherwise i would have worked with you as i need to do the same thing. If you are willing to give a summary or even the code changes, i would be thankful!

[Antony Meyn]

I've attached the modifications for a one way stream i.e. from the native to the html, I'm now trying to understand how huge the native code is actually. I was planning to rewrite it, to get a better understanding of everything thats been done so far.

[V]

Thank you!  I did a quick test to see if it worked which it didn't work here.  I have yet to look over the code.  I did notice an exception which I think is only about the send message button which has nothing to do with the video.  I was at Version 25.0.1337.0 canary but am updating now to Version 25.0.1338.0 canary just in case.    I should have a chance to look things over the changes later today.

[Antony Meyn]

Well I hope you modified the IP address of the signalling server, cause I hard coded it within the Javascript, works for me on regular chrome Version 23.0.1271.91 m 

[Vincent Autieri II]

I didn't change any code other than to use jquery-1.8.3.js, so I'll need to track down the area in code to fix it(as I only have an idea where you might be talking about).  I've only been going native to native as I too didn't realize the browser part of this was never properly written until you found this out.  As for the native code, I'm using my own video capture and found that if you want to have  video larger than 640x480 you have to modify the defaults within WebRTC itself... just an FYI as it took me a while to figure this out, as it doesn't matter what resolution your video capture is at. I've read where the webrtc group is still working on a way for a client to have the ability to request the resolution it wants (which I'm anxiously waiting for as I need such).   I'm also getting an extremely lossy looking picture on the client side, which I have yet to figure out why as I have great bandwidth, and my H264 implimentation(not webrtc) works perfectly...so I dont think its an issue with VP8...  It might be due to the fact my CPU usage is already high before even starting the encoding as I see some code that can change the quality of the video based in a few things.

On Thu, Nov 29, 2012 at 11:40 AM, Antony Meyn <ant...@appstract.dk> wrote:

Well I hope you modified the IP address of the signalling server, cause I hard coded it within the Javascript, works for me on regular chrome Version 23.0.1271.91 m 

--
 
 
 

[Antony Meyn]

Search for the function connect(), its the 2nd line within that function. So are you saying, you have done a complete homemade native implementation of WebRTC?? Is it in C++ as well? 

[Vincent Autieri II]

No, I didn't make my own native implementation of WebRTC.  I cannot go through the Directshow or the Media Foundation(MF is what they are currently adding) for my video capture device.  I'm refering to is the fact I made my own external video capture source and have the native app (in conductor.cpp) use my capture source instead of what it gets from the device manager (the device manager holds all the Directshow and probably soon the Media Foundation capture devices for a MS windows system).

 

BTW, I've leaned alot of the guts by looking at a few other native interfaces.  If you search for a webrtc IE plugin, that will get you some more code to learn from.  I also found other native code that uses nicelib...but I cannot remember what the project was.  It was probably located on github.  I can see if I can find it again if you are interested.

 

All in all, I started to focus on the guts of WebRTC to determine if we want to adopt it, trying to prove out with the video quality, bandwidth, and latency are comparable to an H264 implementation we have.  Currently the webrtc sdk has high latency and not so great video quality in comparison to our H264 implementation, but I think what I'm seeing is all fixable as I would be surprised if this VP8/RTP config will not work for us.  I still struggle with the guts of webrtc/libjingle mix, but as time goes on I see how its not so bad, just a ton of noise and a large learning curve.

 

As for the negotiation/connections, you have done a great deal more work than I have...  I've made a few bad assumptions how their native example was working to connect up the video streams, as my main assumption was that the server was a broker that would end up enabling the native client and browser to connect its video and data streams directly.. (or native to native),

 

What I have learned though you is that I need to sit down and figure out how the connections really get hooked up.  I say this as I've not been able to get the code you sent to have the video I'm sending show up in the browser.  I'm assuming the only modified code is the html code sent.  I'll tell you what I did, but if you are getting tired of holding my hand on your changes I understand, as I probably just need to sit back and learn the javascript/html code and how to get the remote video in the browser myself.  I do have javascript programmers I can probably let figure this out too...(I'm more of a low level developer/c++ and rarely go into javascript)

 

second line down of connect()...

server = document.getElementById("server").value.toLowerCase();

 

I set server = to the IP address (as a string) of the native app, which doing so throws an error Cross origin requests are only supported for HTTP..   And.... as probably expected, if I dont set this I get an error: Failed to create PeerConnection with 11, exception: NOT_SUPPORTED_ERR: DOM Exception 9

 

My guess is  11 is probably suppose to be the IP address of the client.

 

 

This is the complete error what i get if I set server = to the native client IP address.  Seeing its trying to do something with the file system tells me I must be doing something very wrong as I've only set the ip address.

 

XMLHttpRequest cannot load file:///C:/Users/test/Desktop/New%20folder/192.168.1.27/sign_in?my_name. Cross origin requests are only supported for HTTP.

On Thu, Nov 29, 2012 at 12:52 PM, Antony Meyn <ant...@appstract.dk> wrote:

Search for the function connect(), its the 2nd line within that function. So are you saying, you have done a complete homemade native implementation of WebRTC?? Is it in C++ as well? 

--
 
 
 

[Antony Meyn]

All you have to do is host the html file on a web server, you could use dropbox's public directory in case you dont want to waste time setting up a web server your self.

[Antony Meyn]

and its not 

server = IP_address

its

server = http://ipAddress:port

[Antony Meyn]

https://dl.dropbox.com/u/14722731/appstract/jsep_native/4VincentAutieri.html

This should work fine, just fire it up within Chrome.

[Vincent Autieri II]

finally..thank you!

--
 
 
 

[Vincent Autieri II]

Thanks Antony.  Just so you are aware about some possible upcoming changes..  Your example works fine on the released version of Chrome, but has issue with the latest Canary.  I did not look if Canary is broken or if they just moved more to the standard APIs. 

 

pc.createAnswer(

function(sessionDescription) {  fails in Canary...

But your example does work on the current released version of Chrome.

 

Thanks again,

Vincent

On Fri, Nov 30, 2012 at 5:23 AM, Antony Meyn <ant...@appstract.dk> wrote:

https://dl.dropbox.com/u/14722731/appstract/jsep_native/4VincentAutieri.html

This should work fine, just fire it up within Chrome.

--
 
 
 

[Vincent Autieri II]

Doing more testing today in regards to the communication/connection native to browser.   I'm using the latest released chrome.  If I run the browser locally with the peer server, everything works fine.  However, if I try to have the  browser on the remote machine connecting to the peer server/native peer client on the other, I get this error on the offer.

 

Failed to create PeerConnection with 46, exception: NOT_SUPPORTED_ERR: DOM Exception 9

 

the area:

var pc_config = { "iceServers": [{ "url": "stun:stun.l.google.com:19302" }] };

pc = new webkitRTCPeerConnection(pc_config); <<-- this line will cause the exception.

I also tried passing null into webkitRTCPeerConnection and get the same error.

 

Any ideas?

 

Note... I do this test to detect if its chrome, and I do see this print.

 if (navigator.webkitGetUserMedia) {
    console.log("Chrome detected");

 

 

 

 

On Fri, Nov 30, 2012 at 5:23 AM, Antony Meyn <ant...@appstract.dk> wrote:

https://dl.dropbox.com/u/14722731/appstract/jsep_native/4VincentAutieri.html

This should work fine, just fire it up within Chrome.

--
 
 
 

[Antony Meyn]

Hi, im on my mobile @ the moment, but Im guessing the stun doesn't work for complex network topologies, try having them on the same network level, else you might have to run it via a TURN server, the example I hosted for you, works for nodes on the same ip range.

--
 
 
 

[Vincent Autieri II]

Looks like its an issue with the released Chrome as I finally have things working in Canary.  You just need to update your constraints type to work in Canary.  I did validate if you use this new constraints type things still work in the released Chrome.

 

var mediaConstraints = {
    'mandatory': {
        'OfferToReceiveAudio': true,
        'OfferToReceiveVideo': true
    }
}

 

I must say, is a rather challenge to figure out all the changes between the released Chrome to Canary that need to take place with the webrtc interface within Chrome.  They probably have a page somewhere that documents the changes.. I just need to look a little harder.

 

Cheers,

Vincent

--
 
 
 

[Hans Anderson]

hey, guys, so very glad to connect with folks working on the native api.  I am extremely grateful for any and all help you can provide. Am I correct in understanding that:

1. the native peerconnection_server.exe example in libjingle does NOT conduct video transfer peer2peer for connected clients? What is the crux of the issue, if this is true?
2. I am trying to get virtual directshow devices to work. currently, the native api just grabs the first device with an "usb" in the devicePath. It's turning out to be surprisingly difficult. Any thoughts off the top of your heads?
3. does the native example support more than one to one connections? (ie. does it support 2 clients viewing a 3rd client feed?)
4. it seems from what you guys say, above, that goog app engine python server demo will serve the peerconnection_clients.exe's we compile from the native api?
5. I am also doing an evaluation of webrtc versus a more direct method minus the network traversal stuff. What do you recommend for the best matchup to compare for zero-latency against webrtc native?

Thanks a ton,

H

[Vincent Autieri II]

1. Answer: The spec is followed from what I can tell.  You should be able to take his html example above and have a browser and the peerclient communicate properly.
2. Answer: You will need to recompile the peer client, as if you look over the code, it gets the video/device manager and takes the first directshow device.

 

As for #3, I have not worked with such so hopefully someone else can answer.

As for  #4, you are at the mercy of directshow, and when I did some testing it seemed webrtc itself has a bit of latency as well.

[medusade]

I've done a lot of building and testing with modified versions of the native peerconnection_client. Here are some things I've learned relating to some of your points/questions.

1. jingle is designed to create peer-to-peer connections not peer-to-server-to-peer connections. The sample server is used to decide what two peers want to connect, and it is designed as a simple non secure http server. The two peers then use UDP via WebRTC library to send each other video data.

2. In the older rev 11xx's of the code base there was a call to "SetVideoCapture()" that set the device the library would use. 

3. The server does, but the client does not.

4. I think the native demo is using simple connection protocol for testing that is different than the one used by the browser clients.

medusade

[abul walid]

Hi Folks,

I have plugged android webrtc video demo with mjsip and it works fine for android to android audio/video calls.

Now I want to get it to work with chrome peerconnection client as well.

I saw this post and find some hope. How will I be able to communicate between webrtc android demo app and the chrome client for audio and video.

Thanks

On Monday, November 19, 2012 10:30:29 PM UTC+5:30, T Man wrote:

I was trying to build the webrtc native c++ demo examples described in http://www.webrtc.org/reference/getting-started

I was able to get the Peerconection_client and the Peerconnection_server working, I have some basic questions about the implementation.

I assumed that the peerconnection_server was only the signalling channel between the two peer instances but after I got two peers video streaming to each other, i saw that the video/audio UDP traffic was passing via the peerconnection_server.

I dont understand why the implementation of the native demo is not the same as the browser, where we have the clients communicate directly to each other P2P after using the signalling channel to exchange SDPs, I wanted to be able to get a native implementation communicate with a browser based HTML5 version, but looks like the Native demo code is not organized to make this implementation easy to do.

I'd like to have your opnions if you think i've misunderstood something with regards to the native demo?????

[Punyabrata Ray]

Please refer to this thread. /Ray

--
 
 
 

[Aleks Clark]

Does anyone know what sort of signalling channel the native client is using? It almost looks like a long http poll or something, from the source. Initially the path is pretty straightforward, GET /sign_in?, and you get a list of peers....unsure how the communications go from there

On Sunday, February 10, 2013 10:27:47 AM UTC-8, Aleks Clark wrote:

You guys are awesome, I've been looking to do this for the past 3 days. Currently working on one-way browser -> native streaming, will post when done. Eventually I want to transcode and broadcast from the native client.

[Kam Low]

This thread is a little old and has some good info, but no real solution.

I modified the peerconnection_client slightly and posted a solution over at http://sourcey.com/webrtc-native-to-browser-video-streaming-example/

[Jori Liesenborgs]

Thanks to Kam's code I was able to create a very simple Qt test application which streams the contents of a Qt widget to a browser. The code and some screencasts can be found here: http://research.edm.uhasselt.be/~jori/page/index.php?n=Misc.QtWebRTC

[Sam Dutton]

This is very cool. 

Particularly like that for the demo you manually cut and paste SDP to avoid signaling complexity/magic.

Would love to see 'camera video' from the Qt app as well as 'widget-casting' :).

[Danny Chami]

Hi Kam,

I am new to webrtc, and keen to develop a native C++ based app on ubuntu, and would love to leverage the work that you had done.. but been doing loads of research and still hitting a brick wall in getting webrtc compiled on ubuntu. I followed the instructions here  http://www.webrtc.org/reference/getting-started with no luck.. not able to get webrtc built on ubuntu.. done a bit of research, and I see instructions for building for android on ubuntu but no native build instructions. Do you have any pointers on,  how to build webrtc for Ubuntu, (make or ninja) and second how to build based off of that?

thanks,
Danny

[Kam Low]

Where exactly are you getting stuck ie. what build errors are you getting?

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/Pdas21qohck/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Danny Chami]

Hi Kam,

sorry for the delay, been travelling.. I followed the steps below:

1. gclient config https://webrtc.googlecode.com/svn/trunk

2. add "target_os = ['android', 'unix'] to .gclient

3. gclient sync

4. cd trunk

5. source ./build/android/envsetup.sh
6. gclient runhooks

7. export GYP_GENERATORS=make


following that I tried make, make peerconnection_server, peerconnection_client, all with no luck.. no target found and no make file found.. I would greatly appreciate if you have any instructions you can share on how to compile the peerconnection_client & server.

thanks,
Danny

[Alexandre GOUAILLARD]

Hi guys,

last year we toyed with peerconnection_{client|server} and we eventually coded a client desktop for appRTC based on it, to have the capacity to interoperate with the web, iOS, and android version as well. It uses Qt for the GUI instead of gtk also.

We released the code for free under APACHE 2.0 last sunday, and fixed the last major bug outstanding this morning.

https://github.com/TemasysCommunications/appRTCDesk

Hoping this will help the community by providing a missing piece to the appRTC landscape..

Regards,

Alex.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[Amit Nishry]

Hi Alex,

Thanks for the code release, this is very helpful !

Amit

• 
  

[Alexandre GOUAILLARD]

no problem,

Thanks francois, he is the one who coded that piece.

cheers.

alex.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Yu Bin Ang]

Hi Alex

Thanks you for releasing appRTCDesk. Currently I am have a slight issue with building the code. Following the instruction on the site, I was given the following error when running ninja -C out/Debug appRTCdesk. The error given was , ninja: error: unknown target 'appRTCdesk'.As I am not very familiar with ninja, I am stuck trying to figure out what is  causing this issue. Will you be able to assist with this? 

Thanks you so much

Yu Bin 

[Alexandre GOUAILLARD]

hi YBA,

This code has been in need of love for some time.

I m trying to resurrect it this week, i ll keep this thread updated.

Alex.

[Yu Bin Ang]

Hi Alex

Thanks a lot, will keep a look out for the update! If its not too much trouble, I have one more question with regards to the audio source implementation.

 I have been studying the code for AppRTCClient, i understand that within the Conductor.cpp, the AddLocalStream() method is used to added the video and audio stream to their respective track track. 

Within the method, _peer_connection_factory->CreateAudioSource(NULL) is called while calling the consturctor audio_track(). How is the audio source selected if NULL is being given? 

To be more specific, how do I select the audio source to be streamed over webrtc?

Thanks in advance

Yu Bin

[Alexandre GOUAILLARD]

hi YBA,

Since you're singapore local, why don t you stop by 80 amoy street #02-02 and ask all the questions you want to the team ? There was a meetup at JFDI Last week as well.

For the desktop client, it will take several weeks, I'm upgrading the library build first.

Alex.

[San Martino]

Hi,

if the remote peer disconnects/shuts down without signalling (i.e. the user abruptly closes the browser forever), how does the application detect this event? how/where is this situation supposed to be handled in the code?

[Alexandre GOUAILLARD]

hi san martino,

you already asked this question in two different threads. Highjacking a new thread with the same question will not help your case ....

Alex.

[San Martino]

Hi,

my question was really related to the appRTCClient application on github this time. I have been reading the code of all the available examples and I think the result is always the same. appRTCClient does not seem to be an exception as is basically derived from the peer_connection_client example. There seems to be no code handling  the case where the remote peer closes the connection without signalling. According to the API the onIceStateChange on the observer should be called after some seconds. But this does not happen in practice. Another would be to rely on getStats, but no examples ever used this approach and native API is rather obscure about it.

So let me retorically ask another thing, as I think I am helping you after all. Have you ever tested appRTCClient to see what happens if the remote peer stops to send data because of a possible unnotified disconnection?

[Kaiduan Xie]

You should listen to the IceConnectionState.

http://code.google.com/p/webrtc/source/browse/trunk/talk/app/webrtc/peerconnectioninterface.h#373

Override this function in your application.

virtual void OnIceConnectionChange(

PeerConnectionInterface::IceConnectionState new_state) {}

/Kaiduan

[Alexandre GOUAILLARD]

Hi,

my question was really related to the appRTCClient application on github this time.

Then ask it in your own thread.

 

I have been reading the code of all the available examples and I think the result is always the same.

wrong.

 

appRTCClient does not seem to be an exception as is basically derived from the peer_connection_client example.

wrong again. peer connection_client is derived from old code in lib jingle. apprtc was created from scratch for webrtc and interop. the base for signaling and hosting is very different (GAE's channel API, GAE app).

 

There seems to be no code handling  the case where the remote peer closes the connection without signalling. According to the API the onIceStateChange on the observer should be called after some seconds. But this does not happen in practice. Another would be to rely on getStats, but no examples ever used this approach and native API is rather obscure about it.

So let me retorically ask another thing, as I think I am helping you after all.

still wrong, you're not helping.

 

Have you ever tested appRTCClient to see what happens if the remote peer stops to send data because of a possible unnotified disconnection?

This thread is about appRTCDesk, not "apprtcclient". The google project name is apprtc, the binary name is apprtc, the mobile project name is apprtcDemo, only one class of the android code is named apprtcclient.

[Hussein Vastani]

Hey Alex
Are you planning to update the appRTCDesk repo to work with the webrtc codebase (https://chromium.googlesource.com/external/webrtc/) that has been migrated to git?
I noticed that the base folder is no longer in talk and has been moved to webrtc so any references to talk/base in appRTC will need to be updated

Thanks
Hussein Vastani