4 comments on “Finding the Warts in WebAssembly+WebRTC

      • Thanks for the reply, I have some more questions 🙂

        1A) Can you explain why are you considering a 64KB limit for SCTP message?

        1B) Given the mentioned limit, why are you fragmenting in 16KB chunks?

        2) How hard would it be to test with an unreliable and unordered SCTP connection?

        3) Digging in the js code: can you clarify the meaning of

        vpxconfig_.packetSize = 16;

        in vpxconfig_ of main.js ?

        • 1) didn’t want to check the adapter-provided max-message-size and vaguely remembered 64k as the value. Using 16k is a bit silly indeed!
          2) On localhost that would be silly since the chance of loosing a packet is very, very low. As the framedrop experiment in the libvpx sample shows you’ll need a buffer to both reorder and recover lost packets, basically redoing the whole NACK/PLI mechanism. This would be an interesting hack but I’d say its better to start from Surma’s encoder — you can modify the source and add a requestKeyFrame() method. You already know how to submit posts here 🙂
          3) One would have to have access to the source for that and sadly that wasn’t part of the wart branch.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.