DataChannel-only libwebrtc, without video / audio

[keroserene]

In our use case, only PeerConnection DataChannels are required. RTP media stream stuff is not.

It would be great to build a version of libwebrtc without all the video/audio functionality & codecs, etc. included. This would drastically reduce the size of the archive.

This would require something like:

• [ ] Branch the webrtc source, replace wherever the video/audio MediaStreams are specified in relation to PeerConnection with "fake" providers, and remove all the included codecs.
• [ ] Custom build rule where video / audio dependencies can be safely omitted.

Although...

• [ ] Having the "full" libwebrtc is useful for people who want the full WebRTC available in Go. It would then be nice to provide a build flag to switch between these archives in go-webrtc. This is lower priority for what I need to do at the moment. But if you, dear reader, desire this, please let me know below.

[arlolra]

This would drastically reduce the size of the archive.

Probably a hard requirement for distributing with Tor Browser.

[infinity0]

Have you also tried building against libjingle_peerconnection_so.so? This would more likely to be in the future to be standardised as an actual system shared library. (But this doesn't include the test/fake*.h headers that you're including.)

[keroserene]

Have you also tried building against libjingle_peerconnection_so.so?

Yes - though at least when I tried in October, this resulted in a bunch of undefined references (The current working libwebrtc_magic.a is about 28M, while the libjingle_peerconnection_so.so is only 9.5M) but that's probably because I didn't concat correctly. Have you had success with it?

Looking at peerconnection_client.ninja and libjingle_peerconnection_so.ninja though, it appears they have essentially the same dependencies:

    obj/webrtc/system_wrappers/libfield_trial_default.a $
    obj/talk/libjingle_peerconnection.a obj/webrtc/base/librtc_base.a $
    obj/webrtc/libwebrtc_common.a obj/webrtc/base/librtc_base_approved.a $
    obj/chromium/src/third_party/jsoncpp/libjsoncpp.a $
    obj/chromium/src/third_party/boringssl/libboringssl.a $
    obj/talk/libjingle_media.a obj/webrtc/modules/libvideo_render_module.a $
    obj/webrtc/modules/libwebrtc_utility.a $
    obj/webrtc/modules/libaudio_coding_module.a obj/webrtc/modules/libcng.a $
    obj/webrtc/common_audio/libcommon_audio.a $
    obj/webrtc/system_wrappers/libsystem_wrappers.a $
    obj/chromium/src/third_party/openmax_dl/dl/libopenmax_dl.a $
    obj/webrtc/common_audio/libcommon_audio_sse2.a $
    obj/webrtc/modules/libaudio_encoder_interface.a $
    obj/webrtc/modules/libg711.a obj/webrtc/modules/libpcm16b.a $
    obj/webrtc/modules/libwebrtc_opus.a $
    obj/chromium/src/third_party/opus/libopus.a $
    obj/webrtc/modules/libg722.a obj/webrtc/modules/libisac.a $
    obj/webrtc/modules/libaudio_decoder_interface.a $
    obj/webrtc/modules/libisac_common.a obj/webrtc/modules/libilbc.a $
    obj/webrtc/modules/libred.a obj/webrtc/librtc_event_log.a $
    obj/webrtc/librtc_event_log_proto.a $
    obj/chromium/src/third_party/protobuf/libprotobuf_lite.a $
    obj/webrtc/modules/libneteq.a obj/webrtc/modules/librent_a_codec.a $
    obj/webrtc/modules/libmedia_file.a $
    obj/webrtc/common_video/libcommon_video.a libyuv.a $
    obj/chromium/src/third_party/libjpeg_turbo/libjpeg_turbo.a $
    obj/webrtc/libwebrtc.a obj/webrtc/voice_engine/libvoice_engine.a $
    obj/webrtc/modules/libaudio_conference_mixer.a $
    obj/webrtc/modules/libaudio_processing.a $
    obj/webrtc/modules/libaudioproc_debug_proto.a $
    obj/webrtc/modules/libaudio_processing_sse2.a $
    obj/webrtc/modules/libaudio_device.a $
    obj/webrtc/modules/libbitrate_controller.a $
    obj/webrtc/modules/libpaced_sender.a obj/webrtc/modules/librtp_rtcp.a $
    obj/webrtc/modules/libremote_bitrate_estimator.a $
    obj/webrtc/modules/libvideo_capture_module.a $
    obj/webrtc/modules/libvideo_processing.a $
    obj/webrtc/modules/libvideo_processing_sse2.a $
    obj/webrtc/modules/libwebrtc_video_coding.a $
    obj/webrtc/modules/libwebrtc_h264.a obj/webrtc/modules/libwebrtc_i420.a $
    obj/webrtc/modules/video_coding/utility/libvideo_coding_utility.a $
    obj/webrtc/modules/video_coding/codecs/vp8/libwebrtc_vp8.a $
    obj/chromium/src/third_party/libvpx_new/libvpx_new.a $
    obj/chromium/src/third_party/libvpx_new/libvpx_intrinsics_mmx.a $
    obj/chromium/src/third_party/libvpx_new/libvpx_intrinsics_sse2.a $
    obj/chromium/src/third_party/libvpx_new/libvpx_intrinsics_ssse3.a $
    obj/chromium/src/third_party/libvpx_new/libvpx_intrinsics_sse4_1.a $
    obj/chromium/src/third_party/libvpx_new/libvpx_intrinsics_avx.a $
    obj/chromium/src/third_party/libvpx_new/libvpx_intrinsics_avx2.a $
    obj/webrtc/modules/video_coding/codecs/vp9/libwebrtc_vp9.a $
    obj/webrtc/sound/librtc_sound.a $
    obj/webrtc/system_wrappers/libmetrics_default.a $
    obj/webrtc/libjingle/xmllite/librtc_xmllite.a $
    obj/webrtc/libjingle/xmpp/librtc_xmpp.a obj/webrtc/p2p/librtc_p2p.a $
    obj/chromium/src/third_party/usrsctp/libusrsctplib.a $
    obj/webrtc/modules/libvideo_capture_module_internal_impl.a $
    obj/webrtc/modules/libvideo_render_module_internal_impl.a $
    obj/talk/libjingle_p2p.a obj/chromium/src/third_party/libsrtp/libsrtp.a $

The current FakeContraint* requirements will probably disappear in the near future, so that should be okay. However, the process of eliminating all the audio/video codecs, voice_engine, etc. could be very involved.

[infinity0]

Alright I just managed to get this to work. You need to set CXXFLAGS=-fvisibility=default when running the gyp_webrtc configure script, then build libjingle_peerconnection_so. Obvious, right(?) This also increases the size of the .so to 14MB unstripped, 11MB stripped. Then to run the chat demo you need to set LD_LIBRARY_PATH=lib, or install the .so into /usr/lib or one of its friends. (The fake*.h headers you're using, can be used without building the unittest objects - they are header-only includes.)

Taking a step back, the libjingle_peerconnection_so was designed for JNI, and without my CXXFLAGS hack, it only makes the JNI webrtc functions visible externally, which is why you were getting undefined reference errors. This appears to be gyp's default setting, and I'm not sure if the webrtc authors consciously chose this. It works out well for them because libjingle_peerconnection is not really stable. Even so, it may be worth adding a tweaked target like libjingle_peerconnection_private.so without the JNI stuff, for developers like us that don't mind the bleeding edge.

One awkward thing is that we set -fvisibility when building the .o files, so we wouldn't be able to simultaneously create two .so files that each have different visibilities for their symbols.

(edited to correct the CXXFLAGS hack)

[keroserene]

That's awesome. Thanks so much for figuring this out! This CXXFLAGS tweak definitely seems easy enough to include in the build script, and preparing a custom gyp or ninja file and then copying it over to the webrtc checkout also seems automate-able. I can get started on this soon -- unless you're planning a pull request? :)

[infinity0]

Hey, yes I was planning to eventually submit a pull request, but have some issues to think through first. I'll write these up over the next few days. As far as I understand "best practises" to be, at least on GNU/Linux the (or one) ideal situation would be that:

1. webrtc upstream commits to a stable API for libjingle_peerconnection.so which would be the shared-library form of libjingle_peerconnection.a (currently built as a thin archive) but with only certain symbols exported. (then we wouldn't need the CXXFLAGS hack.)
2. what is currently libjingle_peerconnection_so.so is renamed to libjingle_peerconnection_jni.so and it can link against (1)
3. go-webrtc also links against (1).
4. any other libraries such as the objc also link against (1). Having everything link against (1) would also help to ensure uniformity of APIs across languages - since only certain symbols would be exported and used by everyone.

But getting there from the current situation will involve some thinking, so I'd like to do that first before committing a "quick fix" too hastily. I hear some of the webRTC people will be at FOSDEM this weekend so I'll try to talk to them about this also.

[infinity0]

See also https://bugs.chromium.org/p/webrtc/issues/detail?id=5627

[arlolra]

See https://trac.torproject.org/projects/tor/ticket/19569

[keroserene]

Awesome! :+1: