Rtsp bridge

Topics: Question
Jul 25, 2016 at 12:30 PM

I have an IP camera which stream i can view with VLC using this url: rtsp://<camera IP>/PSIA/Streaming/channels/0

I'm using the net7mma library in a WPF application with the following code, to re-stream the rtsp source, but it doesn't work.
RtspServer server = new RtspServer();
//Create a stream which will be exposed under the name Uri rtsp://localhost/live/VN-H257
Media.Rtsp.Server.MediaTypes.RtspSource source =
                new Media.Rtsp.Server.MediaTypes.RtspSource("VN-H257", new Uri("rtsp://<cameraIP>/PSIA/Streaming/channels/0"));

//source.SourceCredential = new System.Net.NetworkCredential(<user>, <pass>);
//source.RtspClient.Credential = new System.Net.NetworkCredential(<user>, <pass>);
I've tried with the credentials, but its the credentials to enter the camera configuration through the browser. I don't know if credentials are needed, since VLC does not ask for any when connecting to the camera rtsp stream.
Otherwise, what would be the right way to add credentials for the camera rtsp stream? (I don't want to restrict access to my application rtsp re-stream for the moment)

When connecting from the same computer, VLC says it can't connect to the url, but when using vlc in a different computer in the same network and connecting to rtsp://<application computer ip>/live/VN-H257, VLC starts playing but the screen is black with vlc logo, and timer keeps counting as if it where playing normally.

I'd appreciate if someone could find something wrong in my code.

Thank you.
Jul 25, 2016 at 12:55 PM
Edited Jul 25, 2016 at 12:55 PM
If you don't add credentials to the stream then you wouldn't require credentials to consume it using a player.

The Client Credentials are used to consume the stream (e.g. what is required by the camera) and play no vital role in viewing.

The Source Credentials are used to restrict access through the RtspServer (if provided); and have no effect on the client.

You 2nd issue seems network related; Post a Wireshark log from the server and client pc and I will take a look and see if I can narrow anything down for you.

P.s. Please also indicate the version you using from source control.

Marked as answer by juliusfriedman on 7/25/2016 at 5:55 AM
Jul 25, 2016 at 3:25 PM
Server app

Client (VLC)

I added net7mma through nuget last friday, so it must be the last version. It shows: net7mma 0.111192.1

Thank you
Jul 25, 2016 at 3:37 PM
That version is actually fairly old but should be stable...

Can you post; the SDP.

If you could post the Wireshark capture it will be more helpful; one from the pc where it works as well as the other (and the server).

Any log output from the server would also be helpful.
Marked as answer by juliusfriedman on 7/25/2016 at 8:37 AM
Jul 25, 2016 at 3:46 PM
Edited Jul 25, 2016 at 3:47 PM

How do I get the latest version? I added it to Visual studio using nuget:
Install-Package net7mma
The logs are from the computer running the application that uses net7mma to create the server, and the computer that tries to connect to the rtsp stream created by the application.

The original source is an IP camera connected to the network, I can't run wireshark there.

Thank you
Jul 25, 2016 at 4:07 PM
Edited Jul 25, 2016 at 4:13 PM
The server receives:

seq = 2143 ts = 511200

Client received the same thing @ 2206 [from 43 in the server capture]

It seems there is a another SETUP and PLAY request.

This usually occurs when the client does not receive anything (usually due to some other underlying cause such as routing issues on the network or os / application level etc)

It seems you may have had the server @ a break point?

I say this because the first few hundred packets from the server to client (as can be seen in the client capture) seem like they are missing from the client capture.

Further I then see the second set of RTSP requests and responses @ 2171.

Then finally the packets start to appear in the client capture...

I would also check the logs of VLC (if thats the player your using) to see what the messages indicate.

You can also check in Codec Information.

It appears from the network capture reveals that data is received on the client just as it is subsequently received from the server and sent to the client.

The latency between the end points appears to be less than 100 microseconds.

where 0.001869 - 0.001039 is how I determined that; the figures come from the times of arrival of the source vs the client and then the difference of such;

The latest source code is available @ https://net7mma.codeplex.com/SourceControl/latest

I was not the original creator of the NuGet package;[ I imagine ] It was kindly provided by another developer who uses this library such that other users would not have to compile the code; I am unsure how it is compiled to be quite honest as I have never installed or utilized it.

In the future I may find time [or the other project members may such time] to update the NuGet package and provide binary versions of the library which are built for specific environments should the need arise;

Let me know how I can be of further assistance.
Marked as answer by juliusfriedman on 7/25/2016 at 9:07 AM
Jul 25, 2016 at 4:31 PM
Thank you for your help, I will look into those things and try to get more information on the problem.