I love the ideas behind SRT and SLDP.
I still need to understand the technologies and how to use them as technologies, not as a ready made app that does everything for me. I need to define my requirements and build accordingly.
I am not sure if there are plans to have Nimble Streamer provide a developer API for configuration and authentication, separate from WMSPanel. Otherwise, if WMSPanel implements the authentication scheme using the callback scheme described in the Access Control doc (i linked to from the SRT library github issue) and provides a user registration widget in the same way Stripe provides a payment widget (can be integrated into other apps) then Haivision becomes a platform provider not a technology vendor. In that case, I would be using the SRT library, which wouldn&#39;t exist without Haivision and your efforts, but in that case I&#39;d lose SLDP since I don&#39;t think SLDP is an open standard.
I&#39;m wondering if I should go down that route and maybe use ffplay and build a native app for my clients to use to play SRT directly, and use SRT library to implement the server, with authentication.
Can you please provide me with your advise and perspective on this?
Thanks for asking good questions.
- Haivision will not become the sole platform provider with SRT from my perspective and based on public information they provide. The main sources of success of SRT story are the open-source permissive license, a great market placement and a great support for SRT development community. SRT will be popular as long as they go this way. If you're afraid that they will get SRT to themselves and stop working with the community, then I would say that RIST will replace SRT immediately. I know SRT people and they are very smart guys not to do that. There are competitors who are ready to replace them. I don't see such risk even long-term. Don't consider this as an advice, that's just my own "IMHO".
- SLDP was intended to replace RTMP when we realized that RTMP playback will stop working shortly. We didn't have any long assumptions about this beast and we didn't want to support it for too long initially. We just wanted to provide people with some options to work in browsers. But people liked it and forced us to add mobile support too. And so we did. We were not sure why SLDP is in use in the world where webRTC exists, but now I realize its place and why people like it.
As you see there is no any huge idea or great plan to make it a widespread technology. Softvelum has always been a small software vendor with very limited development/marketing(almost absent)/support resources so we cannot afford to provide good protocol documentation, examples, reference implementation etc. I believe that if some big software house acquires the company they will be able to handle all of that. But Softvelum itself cannot afford that and hence will do what we actually can afford, that is - provide software for our clients.
- Speaking of access control for SRT. We're working right now on the feature to provide our clients the ability to create separate JSON file for each SRT input and support different SRT publish policies based on that file. You will be able to use Publish control (https://blog.wmspanel.com/2015/12/rtsp-publish-control-setup.html) feature in conjunction with SRT passphrase and that JSON file.
This feature will be part of an Addenda (https://wmspanel.com/nimble/addenda) subscription.
- Long story short: SLDP is neither a game changer nor webRTC competitor but just an interesting solution especially for managed networks. If you believe in it, then encourage a good software house to grab our team and do good things with SLDP, like haivision did with SRT. I was part of that and understand I cannot do the same.
- Softvelum will support SLDP and provide our clients with protocol support like before, since it's a popular soluton. But if you need something open and ready to support it on your own or paying for that from your pocket, please make this decision yourself.
and required to achieve the purposes illustrated in the
If you want to know more or withdraw your consent to all or some of the cookies, please
refer to the