@dentangle @librecast after playing with @gstreamer and #RaptorQ I was also wondering, if there were some #NetworkCoding algorithms that could do something like this: For some fixed data X, have n different multicasted streams, with each next one having a twice as high bitrate. The app/library joins the next #multicast stream with double as much bitrate until the path is saturated.
Is it something along that line you're looking for?
It's a new release of lcrq!
lcrq now makes use of a CPU dispatcher to detect the available SIMD instruction sets at runtime, ensuring that the code runs as fast as possible on the target machine.
Thanks to @nlnet and #NGIAssure for funding this work.
lcrq (Librecast's RFC 6330 RaptorQ library) was one of the more fun projects I've worked on. I do love a bit of matrix maths.
Perhaps I should put together an explainer talk on #RaptorQ #FEC and the #Librecast LCRQ library.
I wonder if anyone would be interested in that?
And are there any Covid-safe conferences in Europe to submit it to?
Yaiy, found some detailed #RFC|s which seem to describe how to handle #FEC and how to associate them to their primary stream. Was looking for this for #RaptorQ / #SDP / #SAP / #multicast / #Freifunk. Lot's of reading to catch up with - too tired to do this today though, will have to do that later :D.
https://datatracker.ietf.org/doc/html/rfc8872
https://datatracker.ietf.org/doc/html/rfc5109
https://datatracker.ietf.org/doc/html/rfc8843
https://datatracker.ietf.org/doc/html/rfc5888
https://www.rfc-editor.org/rfc/rfc2198.html#section-5
https://www.rfc-editor.org/rfc/rfc6354.html#section-5
https://datatracker.ietf.org/doc/html/rfc6330
I could figure out most of the #RaptorQ parameters from the #gstreamer docs and looking at what they do in #Wireshark.
For the "mtu" setting in raptorqenc does anyone have an idea if a larger value helps in any way? Or can I just set it as low as what works/fits with #Opus at the "constrained VBR" setting (for me about 400)?
And what should I set the symbol-size in raptorqenc to for Opus audio? #multicast
The #gstreamer #RaptorQ implementation (in #Rust!) for Forward Error Correction (#FEC) is awesome! Played a bit with it yesterday. With less than double extra overhead it worked well for an #Opus audio stream at 25% packetloss rate!
Which will be very handy for streaming with the new #batman_adv #multicast packet type at #Freifunk.
So what do these API's do?
sync API:
The beginning of our IPv6 Multicast data syncing support.
It uses #RaptorQ and symmetric Key encryption.
mdex API:
Lets you build a multicast index of files and blobs using BLAKE3 hashed addressing. Then those mdexes can be passed to the sync API to share the data over multicast
mtree:
Building #merkletrees with BLAKE3 hashing. BLAKE3 itself is a merkle tree. 
Merkle tree's all the way down! 
smolq:
A small queue API
It's a new release of lcrq!
Our #RaptorQ library that provides forwards error correction to librecast.
V0.1.1 contains a few minor bug fixes as well as arc4random_uniform() support to rq_random_esi().
More details here.
https://git.sr.ht/~librecast/lcrq/commit/0450d0ddc67b8946a435949238cd4a7390994ffe
