What is WebRTC currently missing?

ashley
ashley Dailynista
edited August 2022 in Discussion ๐Ÿ’ฌ

Are there any features that you wish WebRTC had?

For example, features that exist in other specs, or are coming in future iterations but not here yet? If so, what are they?

Tagged:
ยซ1

Comments

  • rory
    rory Dailynista

    uniform browser support ๐Ÿ˜…

  • ashley
    ashley Dailynista

    Haha @rory! Okay, not asking for miracles here...

  • chad
    chad Dailynista

    This may not meet the exact specifications of the question, but hopefully it's in the right ballpark :) I wish there was an easier way to do file transfers through WebRTC. I've seen plenty of example code that essentially shows how to do your own chunking on both ends, and so on... but I wish it was easier to just say "send this file, or blob of data, or whatever". Like a MediaStreamTrack, but, I guess a FileStream?

  • jameshush
    jameshush Dailynista

    An actual definition. Right now WebRTC is just... "video stuff" :)

  • Vincent
    Vincent Dailynista

    A proper (and embeddable) alternative implementation that isn't owned/maintained by Google.

  • aconchillo
    aconchillo Dailynista

    @Vincent If only webrtc GStreamer's implementation was the default standard... It's very clean and well written: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/tree/main/subprojects/gst-examples/webrtc

  • vr000m
    vr000m Dailynista
    edited July 2022

    WebRTC is a high level abstraction, I wish it were more low-level. The current API and architecture forces the new features that people think about to be a much bigger lift than it ought to be.

    For example, building a new codec, does not only require you to build a new codec, but also figure out how this would be set in the APIs, negotiated on the wire, packetised on the wire, etc. Which means you need to have a lot of muscle power to make new features.

    Another example, want to change noise suppression or any in-pipeline improvements, either cannot be done or done inefficiently (at the cost of CPU cycles).

    My main ask has been for a lower api, i.e., allows the web developer to build the pipeline in javascript. Developers will build abstractions and perhaps if we are able to get this dream realised in v2, we would be able to build WebRTC v1 APIs atop those v2 APIs.

    @aconchillo's example of gstreamer and building the pipeline is a good one:

    gst-launch-1.0 videotestsrc is-live=true ! videoconvert ! queue leaky=2 max-size-buffers=5 ! nvv4l2vp8enc maxperf-enable=1 ! rtpvp8pay ! webrtcwrapperbin ip_port_discovery_sendrecv ! rtpvp8depay ! decodebin ! autovideosink
    

    It would be conceivable with v2 and webassembly that developers would override parts of the existing pipeline with their own code, which would give us creativity at two levels -- optimised pipelines and optimised algorithms for specific use-cases.

  • vr000m
    vr000m Dailynista

    @chad there was a fair amount of debate on FileStream, TimedText, eventually building DataChannels as the underlying API and protocol, the assumption was that it would allow web developers to build the higher level abstraction.

    Alas, most abstractions intertwine these with their flavour of signalling protocol, which meant that they were more prescriptive than they needed to be...

  • ashley
    ashley Dailynista

    @jameshush That's interesting, I'd like to understand your perspective a bit more. It feels pretty well-defined to me. What do you think the gaps are?

  • chad
    chad Dailynista

    @vr000m It's funny you mentioned "intertwining with signaling protocol"; that was one of the weirdest things for me to understand as I was getting into all this stuff. It's like the spec defines specific ways to do so many things, but then just kind of hand waves about "oh yeah, you probably need to do something something signaling too" :)