Using WebRTC lib

[Iskren Chernev]

It looks like the main webrtc repo (http://webrtc.googlecode.com/svn/trunk) contains code for audio/video encoding/decoding/capture and also RTP/RTCP packet creation/parsing.

However the PeerConnection part of WebRTC, including an ICE implementation, DTLS (TLS over UDP) sockets, SDP and the JSEP implementation are not inside. The PeerConnection branch (http://webrtc.googlecode.com/svn/trunk/peerconnection) contains that code, but at the expense of including several huge libraries (libjingle, some gtalk libraries etc), containing code that isn't part of WebRTC.

For that reason mozilla use their own libraries to implement ICE, DTLS etc, to get a PeerConnection.

Is there a plan to include PeerConnection and its dependencies inside WebRTC without huge external (somewhat unneeded) dependencies and when?
Do you plan of providing any documentation on how to actually use the WebRTC library on its own (not in a browser context)?

[PhistucK]

As far as I know, LibJingle is indeed a hard dependency of WebRTC. You could create your own stack, I guess, but it does not work without a stack.

☆PhistucK

--
 
 
 

[Ivan Vučica]

Just my two cents...

Since some of these libraries do a large portion of work (and native part of WebRTC is, indeed, just a wrapper that came as a blessing to anyone who wanted to do custom signaling directly with libjingle) -- I'm not sure what you'd accomplish by ripping out the very things that make WebRTC tick.

Dependencies could perhaps be reduced, but by ripping out libjingle, you'd probably get nothing but a dead shell -- almost certainly not PeerConnection.

Other implementations may indeed implement the components that WebRTC project reuses from libjingle et al, but why would Google's team reinvent the wheel by repeatedly writing code their own teams have already written?

[Iskren Chernev]

On Fri, Nov 2, 2012 at 12:58 PM, Ivan Vučica <ivu...@gmail.com> wrote:
> Other implementations may indeed implement the components that WebRTC
> project reuses from libjingle et al, but why would Google's team reinvent
> the wheel by repeatedly writing code their own teams have already written?

I agree with the code-reuse standpoint. I certainly do not advocate
for a rewrite of the code, but maybe for extracting a subset of
libjingle (and others) in a standalone library to be used in both
libjingle and webrtc. Otherwise it seems to me like linking to
chromium just to get bookmarks support. I know computation is cheap
nowadays, but if this library is to be used on mobile the size issue
is more relevant. I'm not sure if the linker can strip all the
bytecode that is not used, and actually what percentage of the code is
not used.

I just started this thread to get a better understanding of the
directions of the project, because at first sight, the webrtc trunk
contains well organized, freshly written code with sane dependencies,
and then the PeerConnection branch includes a huge bunch of stuff from
which a very small portion is actually utilized (I may be wrong on
this one). There is webrtc stuff as a third party dependency of
itself, as a portion of libjingle and talk... To me it just looks like
a quick, durty hack to get it working ASAP, so that is why I asked for
clarification :)

Regards,
Iskren