Project Description

I run openSUSE TW and FF with i7-5600U Intel CPU. Calls with ~4 (video) participants work but my CPU load is approaching number of cores. In slightly bigger calls (>=6 participants) the CPU load was insufficient and audio packets were being dropped. I'd like learn more about webrtc video streams in order to reduce the client's CPU work or make it more adaptive when running with limited resources.

Goal for this Hackweek

  • Prepare a testbench for stressing a client (likely bunch of extrinsic VMs with v4l2loopback).
  • Learn about webrtc and browser API wrt video.
  • Profile CPU work -- where the time is spent.
  • (Reduction: reap any low-hanging fruits discovered in the profile.)
  • (Adaptibility: figure out to how to recognize tight-CPU situations in the client and ensure audio QoS.)

Resources

Looking for hackers with the skills:

webrtc jitsi video codecs gpu

This project is part of:

Hack Week 20

Activity

  • 4 months ago: pvorel liked this project.
  • 4 months ago: toe liked this project.
  • 4 months ago: fos liked this project.
  • 4 months ago: dgedon liked this project.
  • 4 months ago: dfaggioli liked this project.
  • 5 months ago: mkoutny started this project.
  • 5 months ago: mkoutny added keyword "webrtc" to this project.
  • 5 months ago: mkoutny added keyword "jitsi" to this project.
  • 5 months ago: mkoutny added keyword "video" to this project.
  • 5 months ago: mkoutny added keyword "codecs" to this project.
  • All Activity

    Comments

    • mkoutny
      4 months ago by mkoutny | Reply

      • I used built-in support in FF with media.navigator.streams.fake + Selenium to realize test callers
      • Quite an exhaustive blog on webrtc, the codec benchmarking in browser (alas worked in Chromium only, not FF)
        • webrtc abstracts away many fine-tunings from the JS code, the parts that allow some tuning aren't standardized and each browser implements it differently
      • FF has built-in JS profiler (measures real-time, not CPU time), I used perf for cpu time debugging
        • (surprisingly), remarkable amount of CPU work is spent in (local) audio processing -- might be possible to reduce (in FF codebase), that's where I stopped
        • video (decoding) didn't seem to be an issue in my measurements but it may be caused by synthetic video streams that didn't stress the decoder
      • I didn't got down to the adaptibility issue
      • code and private notes

    • mkoutny
      4 months ago by mkoutny | Reply

      I've continued analyzing the excessive audio cpu consumption and filed a FF bug (TL;DR it's tackled in upstream libwebrtc but FF "vendors" a stale version.)

      Ad the audio QoS, the audio threads apparently run with SCHED_RR (therefore my attempts to reproduce tight CPU situations with cpu controller won't be realistic (only SCHED_NORMAL are throttled)). However, it seems the crackling noise isn't directly caused by low cpu bandwidth but: a) scheduling latency dispersion, b) receive threads (no RT priority) lagging behind.

    Similar Projects

    WebRTC individual track recorder by avicenzi

    [comment]: # (Please use the project descriptio...


    WebRTC individual track recorder by avicenzi

    [comment]: # (Please use the project descriptio...


    Jitsi for Hackweek by rsimai

    Primarily to support Hackweek, but also to gain...


    Jitsi for Hackweek by rsimai

    Primarily to support Hackweek, but also to gain...


    Learn DaVinci Resolve by psimons

    [comment]: # (Please use the project descriptio...


    WebRTC individual track recorder by avicenzi

    [comment]: # (Please use the project descriptio...