View Single Post
Old 18th July 2016, 14:59   #6  |  Link
juliusfriedman
Registered User
 
Join Date: Oct 2014
Location: U.S.A.
Posts: 6
For whatever it is worth I do appreciate your response.

A wise individual once told me: `There is no such thing as a bad question` but a wiser individual once told me `Ask whatever you want, The worst that can happen is that you will get NO response` and someone wiser than said `Questions lead to more questions.`;

What I will say in response here will be brief but I will expand the notion of these concepts further through the documentation provided in my project.

What does this library do?

It provides an object oriented application programming interface which exposes the concepts and entities which are required to interface with other such programs or hardware for the purpose required.

More succinctly, it provides packet implementations for Rtp, Rtcp and Rtsp (as well as Http) and further consolidates them and unifies them under an interface which allows a myriad of diverse inter-interactions which would otherwise be impossible to achieve.

Where is the working example

Is there not a `UnitTest` solution? Is that `solution` not sufficient to demonstrate how the included classes and the server are intended to work?

There is an example of using the RtspClient, RtpClient, RtspServer and all other included classes, some examples are more functional than others.

Who is not the target user base?

Portable Executable could just as well provide the `ease of use` in which the `ffmpeg / aconv` application provide, i.e. `net7-mma -rtsp` etc.

Why would people want this

Why wouldn't they?

Without even taking a shot at any other library here I can outline quite a few things here which are probably not handled correct by your existing `Tools` regardless of who made them.

Specifically I saw in other tools the following common attributes:

Rtsp / Http Message Parsing is not accurate with respect to the request for comments.

Interleaved Binary Data is not handled appropriately

Rtp and Rtcp data is not verified before it is delivered to the display stack which is a MAJOR security concern considering most implementations also utilize Any Port (0) to perform reception when their configuration allows for such.

In short,

Data which is sent and received by most existing tools is done so in a highly unpredictable and mostly incorrect way (with respect to various particulate matter)

Finally,

My libraries are built in .Net which all but eliminates the requirement of providing binaries which are built and linked to other software which is specific to the architecture where it is being deployed, it thus decreases the amount of time you would have to take to update such deployments and it would also implicitly make such systems more secure and efficient.

Thank you again for your time and response.
juliusfriedman is offline   Reply With Quote