MIDI RTP (RFC 6295)

[jwetzell]

There is a MIDI payload type for RTP (RFC 6295). I'm still making my way through the layout of this library and might be able to give an implementation of this a go.

[JoTurk]

Hi @jwetzell

This library is intended for webrtc we usually support payload formats and extensions that are supported by usual browser webrtc implementations. But we plan to change this by the next major release, since RTCRTPTransport is likely to become a thing in browsers, and we can use this library in experiments as RTP over Quic or over SCTP.

But we plan to refactor this library first and standardize interfaces more, and a map for payloaders and depacketizers.

[jwetzell]

I'm seeing that trend amongst many of Pion's libraries. Hopefully it can become general RTP library that isn't coupled to a specific use-case.

[Sean-Der]

Thanks for the feedback @jwetzell, what’s the trend?

• Staying WebRTC specific?
• being in ‘refactor mode’?

Would love to make Pion as easy/exciting as possible to contribute too :)

[JoTurk]

Also we can't support this rfc before #69 is resolved by changing the payloaders interface so they have direct access to the rtp header, because this
Payload format has use for the m bit, it's a good rfc to base the new design agains if we want to make this library not webrtc specific.
Currently the vvc and hevc payloaders are missing some optional features because of this too.

[JoTurk]

@Sean-Der I think @jwetzell is talking about the trend of making pion libraries general use, they joined to help with stuff with mdns that aren't related to webrtc, context pion/mdns#253 we currently don't have any libraries on refactor mode other than dtls (for 1.3, and currently we have a release branch and a main branch), there are planned refactors for ice and rtp, but the work didn't start yet and we still merge PRs to both of them.

I want your thought on making Pion libraries not webrtc-centeric there is some disagreements example pion/sdp#217 (comment) I'm 50/50 on this and I would love your take to use it as a reference and for future decisions, thank you.

[jwetzell]

Yes @Sean-Der, @JoTurk is correct. I completely understand that the role of a lot of these ancillary libraries is/was to support the main WebRTC "goal", but people aren't always exposed to them through that context (pion/mdns is a top result when searching "golang mDNS").

That is a funny PR to point to because I've followed the bluenviron stuff since the rtsp-simple-server days and they have countless commits adding in to support "non-standard" implementations. Maybe the thing there is though to let consumers of the library build the non-standard stuff on top of the standard-compliant library but 🤷‍♂️. I did kind of like the suggestion for a strict mode or maybe some sort of dial on how RFC enforcing things are.

Hats off to the whole Pion community its a lot of tech to implement!!