Still not stable

Topics: Bug Archive
Dec 23, 2015 at 2:45 PM
Edited Dec 23, 2015 at 2:45 PM
after longtime i come back and test your rtsp server, it is better but still not stable. the cpu usage rise to ~ 90%. seem there is a bug when rtsp server trying to connect/reconnect to rtsp source.
there are some live rtsp streams from HIkvision ip camera, if you want to test:

server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("Hikvision1", "rtsp://demo:demo12345@118.69.78.228:2102/Streaming/Channels/101?transportmode=unicast&profile=Profile_1", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));

server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("Hikvision2", "rtsp://demo:demo12345@118.69.78.228:2902/Streaming/Channels/101?transportmode=unicast&profile=Profile_1", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));

server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("Hikvision3", "rtsp://demo:demo12345@118.69.78.228:3202/Streaming/Channels/101?transportmode=unicast&profile=Profile_1", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));

server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("Hikvision4", "rtsp://demo:demo12345@118.69.78.228:2232/Streaming/Channels/101?transportmode=unicast&profile=Profile_1", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));

server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("Hikvision5", "rtsp://demo:demo12345@118.69.78.228:5222/Streaming/Channels/101?transportmode=unicast&profile=Profile_1", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));
Coordinator
Dec 23, 2015 at 3:58 PM
Hey, glad to have you back.

Thanks again for bringing this up, I have a limited amount of sources to test against and also haven't done much testing recently because of that.

I will surely check into these sources and do some profiling to determine the cause of the high load.

Christmas is in the next few days so if I don't get right back to this thread then don't think I forgot about you.

Thanks again for your interest in the project.
Marked as answer by juliusfriedman on 12/23/2015 at 8:58 AM
Coordinator
Dec 23, 2015 at 4:43 PM
Can you please ensure your using the latest source and if possible try to describe when the CPU rises and falls?

I have just tried to replicate the High CPU but I was really unable to see any major CPU usage, even with repeated connecting and disconnecting.

I was able to view with VLC and QuickTime without any issues and I was able to run the load test without any issues.

I am going to let it run for a few hours and do profiling but I wanted to see if you could offer any potential input to narrow down the high usage.

Thanks again!
Marked as answer by juliusfriedman on 12/23/2015 at 9:43 AM
Coordinator
Dec 23, 2015 at 5:09 PM
It seems those cameras are going up and down also, please ensure their connection is stable.

It seems to me that the connection may be dying and that causes the streams to stop and then start again which is the source of the high load.

What I can say is that right now is pretty much what I indicated when I first tried this, which is that when the source is up and running there is very low CPU usage even with multiple clients connecting and disconnecting.

I really would like to help you narrow it down, especially if it's a problem in the server.

Let me know what you think and thanks again for your interest!

Sincerely,
Julius
Marked as answer by juliusfriedman on 12/23/2015 at 10:09 AM
Dec 24, 2015 at 1:53 PM
Coordinator
Dec 24, 2015 at 4:03 PM
Edited Dec 24, 2015 at 4:32 PM
I definitely believe you, I just think there may be another culprit for instance the bandwidth of the camera.

For instance:

"rtsp://admin:admin@118.70.125.33:24454/h264.sdp?res=full" I am not even to really open and play that stream in VLC, QuickTime or Mplayer at least not for very long periods of time.

I have a 100MBPS connection so I should be able to easily consume that stream and play it back also however it seems the bandwidth of the connection of the device is either over utilized by the existing streams being consumed from it.

I also have similar problems with "rtsp://hptvn:hptvn@hptvn-com.dyndns.org:9821/videoMain", it plays for a minute or so and then stops also.

The same with "rtsp://admin:admin@118.70.125.33:24454/h264.sdp?res=full" also and "rtsp://admin:pass@118.70.125.33:9554/rtsph2641080p" and "rtsp://admin:admin@118.70.125.33:15554/channel1" Seems like that entire 118.70.125.33 host exhibits that behavior.

"rtsp://root:root@118.70.125.33:15754/cam0_0" Seems to work fine for me right now.

I am running some tests using that as a baseline and I don't see usage anywhere over 5% even while consuming multiple copies of that same stream.

I was also able to do some load testing and it seems I am handling over 1000 connections with just over 50% CPU even when rapidly connecting and disconnecting as a client.

I am going to see if I can find another camera in that list which seems to have a good connection and profile again with that but I suggest you try the Wowza stream @ "rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov" to get a good indication of how it's working and we will be able to see after that if you still have high usage etc.

The other thing I noticed was a problem with Authentication where the process would get into a StackOverflow, that was probably the cause of the High CPU.

I just made a commit to fix that.

Give this and the new code a once over and let me know what you think and have a Merry Christmas also!
Marked as answer by juliusfriedman on 12/24/2015 at 9:32 AM
Dec 25, 2015 at 12:41 AM
Edited Dec 25, 2015 at 12:42 AM
Coordinator
Dec 28, 2015 at 5:37 PM
I am having a much easier time pulling the streams now, however I am not really able to replicate the high CPU usage.

One thing I can see from the video is that your still always attached to the project while it's running, try detaching the debugger from the process after starting the server so it interferes less with the operation of the test. This is especially needed because send and receive buffering is disabled on TCP connections by default.

I also notice that if stream loses it's connection there is still a lot of wasted CPU until the socket can reconnect, I will work on some additional improvements this week for that issue as well as some general code cleanup so keep your eyes out.

I just wanted to make sure if there was anything in particular I could pay special attention to or that I wasn't already aware of.
Marked as answer by juliusfriedman on 12/28/2015 at 10:37 AM
Coordinator
Dec 31, 2015 at 6:37 PM
I am still having a problem with a few of those streams but in general the first 4 seem to work much better.

I have made a new commit with a small server testing form, if you can please give that a shot and let me know if your still experiencing the high usage I would appreciate it.

I plan on adding more updates soon after the new year.

Thanks again for your interest and have a Happy New Year!
Marked as answer by juliusfriedman on 12/31/2015 at 11:37 AM
Coordinator
Jan 5, 2016 at 9:05 PM
Edited Jan 22, 2016 at 4:14 PM
Hey,

I narrowed down the streams which were having problems to really only 1 particular stream.

"rtsp://admin:pass@118.70.125.33:9554/rtsph2641080p" I didn't have much time to look into it yet but I wanted to let you know that I will be looking at it this week or next week.

Please also take a look at the latest code and ensure that you are only having problems with that one stream and if not let me know so I can see what else I need to look at.

Sincerely,
Julius
Marked as answer by juliusfriedman on 1/5/2016 at 2:05 PM
Coordinator
Jan 22, 2016 at 4:16 PM
Hello,

I posted an updated version which I have been using and I wanted to get your feedback.

A lot of those test cameras still seem to have bandwidth issues, I was wondering if you could change the password and message me with the IP and credentials so I can be sure that no uncecessary bandwidth is being taken up by other means.

It will be a lot easier for me to test that way and hopefully make some updates!

Thanks again for your interest in the library!
Marked as answer by juliusfriedman on 1/22/2016 at 9:16 AM
Jan 23, 2016 at 3:24 AM
Hi,

I send private message to you.
Please check.

Best Regards,
Le Hong Thai
Coordinator
Mar 11, 2016 at 4:45 PM
I have had some time to address a few issues, unfortunately I don't still think that this is the best the library can be it should be stable.

I have verified with most but not all of the cameras in the private message.

Let me know if your still having issues.

Sorry for any inconvenience.

If you could elaborate on your goals or uses for the library it would also help me learn where certain features could be added or improved.

Thanks again for your help and interest and I'm waiting to hear back!
Marked as answer by juliusfriedman on 3/11/2016 at 9:45 AM
Coordinator
May 13, 2016 at 7:46 PM
The latest version has been uploaded, it will handle more clients and higher resolution streams.

I have not had a chance to do much bench-marking yet but preliminary results indicate that the performance increase is over 15% with only 5 - 10% more memory utilization.

I will wait for your feedback.

Thank you again for your interest!
Marked as answer by juliusfriedman on 5/13/2016 at 12:46 PM
May 16, 2016 at 3:31 PM
Thank for your update.
Tomorow I will try latest version with some cameras and you know result.

Best Regards,
Le Hong Thai
Coordinator
May 16, 2016 at 6:45 PM
Edited May 16, 2016 at 6:46 PM
No problem at all sir, one is glad to be of service.

Please let me know what you find.

Performance is improved, if you want to enable ThreadEvents on each RtpClient watch out for bugs but it should be even faster than with ThreadEvents = false (which is the default)

Also TCP may have some issues while I work around the problem of frame headers during the next two versions or so, don't forget to try IListSockets = true if you experience an issue.

Sincerely,
Julius
Marked as answer by juliusfriedman on 5/16/2016 at 11:45 AM
Coordinator
May 16, 2016 at 9:39 PM
Kindly also see release set 112051, please let me know what you find both using ThreadEvents, IListSockets on and off.

Thanks again!
Marked as answer by juliusfriedman on 5/16/2016 at 2:39 PM
Coordinator
May 18, 2016 at 4:37 PM
Edited May 18, 2016 at 6:47 PM
I have made more changes @ 112059 & 112060, Let me know how things are going!
Marked as answer by juliusfriedman on 5/18/2016 at 9:37 AM
Coordinator
May 18, 2016 at 11:00 PM
112062 is stable for now.

Please let me know what you find!
Marked as answer by juliusfriedman on 5/18/2016 at 4:00 PM
Coordinator
May 24, 2016 at 2:10 PM
112072 just released, please let me know if I am going in the right direction for your needs!
Marked as answer by juliusfriedman on 5/24/2016 at 7:10 AM
Coordinator
May 24, 2016 at 5:49 PM
112073 is very good, the only thing I see I need to work on is the usage after a client disconnects in the RtspServer (and possibly is not going to re-connect) as it higher than I like.

The other things are the new events and a few changes to how events propagate to sources so that re-ordering can be avoided.

I will also try to work more on the ClientSession and RtspSession to support multiple servers and also to share the logic in the RtspClient with the RtspServer soon.

Any other feedback you have would be extremely useful.
Marked as answer by juliusfriedman on 5/24/2016 at 10:49 AM
Coordinator
May 28, 2016 at 2:27 PM
Wondering if I can assume that things are stable now...

If you have some camera you want to share your have my email.

I am moving this to archive for now.

Please leave new feedback if possible.
Marked as answer by juliusfriedman on 5/28/2016 at 7:28 AM
Jun 2, 2016 at 3:43 PM
Dear Sir,

Seem latest version has problem, the server always restart fault streams and cpu usage increase to 100%.
May be connection timeout to short ?
Here is some stream iam using to test:
server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("EverFocus1", "rtsp://user1:11111111@76.79.115.83:559/cgi-bin/rtspStreamOvf/1", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));
            server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("Hikvision1", "rtsp://demo:abcd1234@118.70.181.233:2121/Streaming/Channels/102", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));
            server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("Hikvision2", "rtsp://demo:abcd1234@118.70.181.233:2221/Streaming/Channels/102", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));
            server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("Hikvision3", "rtsp://demo:abcd1234@118.70.181.233:2033/Streaming/Channels/102", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));
            server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("Hikvision4", "rtsp://demo:abcd1234@118.70.181.233:6027/Streaming/Channels/102", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));
            server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("Hikvision5", "rtsp://demo:abcd1234@118.70.181.233:2833/Streaming/Channels/102", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));
            server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("Hikvision6", "rtsp://demo:abcd1234@118.70.181.233:2043/Streaming/Channels/102", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));
            server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("Hikvision7", "rtsp://demo:abcd1234@118.70.181.233:2415/Streaming/Channels/102", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));
            server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("Hikvision8", "rtsp://demo:abcd1234@118.70.181.233:2943/Streaming/Channels/102", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));
            server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("Hikvision9", "rtsp://demo:abcd1234@118.70.181.233:2813/Streaming/Channels/102", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));
            server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("Hikvision10", "rtsp://demo:abcd1234@118.70.181.233:7175/Streaming/Channels/102", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));
            server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("benco1", "rtsp://118.70.125.33/user=admin&password=admin12345&channel=1&stream=0.sdp?real_stream", Media.Rtsp.RtspClient.ClientProtocolType.Tcp));
Best Regards,
Le Hong Thai
Marked as answer by juliusfriedman on 6/2/2016 at 8:52 AM
Coordinator
Jun 2, 2016 at 3:51 PM
Thank you for getting back to me.

I will be checking into this later today and tommorow.

Please ensure that some of the streams are working and that there is sufficient bandwidth for testing.

I appreciate your continued testing.

Sincerely,
Julius
Coordinator
Jun 6, 2016 at 4:38 PM
Edited Jun 6, 2016 at 4:40 PM
Dear sir,

It seems that I cannot replicate your cited issues at all with one exception:

'benco1' appears to have either a mis-configuration with MSS or otherwise.

When I connect to the camera It indicates it's MSS is 1398 but then it sends packets which are LARGER than the MSS e.g. 1412.

Frame 2398: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0
Internet Protocol Version 4, Src: 192.168.1.151, Dst: 118.70.125.33
Transmission Control Protocol, Src Port: 11504 (11504), Dst Port: 554 (554), Seq: 0, Len: 0
Source Port: 11504
Destination Port: 554
<Source or Destination Port: 11504>
<Source or Destination Port: 554>
[Stream index: 30]
[TCP Segment Len: 0]
Sequence number: 0    (relative sequence number)
Acknowledgment number: 0
Header Length: 32 bytes
Flags: 0x002 (SYN)
Window size value: 8192
[Calculated window size: 8192]
Checksum: 0xb5cd [validation disabled]
Urgent pointer: 0
Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted
__ Maximum segment size: 1460 bytes__
    No-Operation (NOP)
    Window scale: 2 (multiply by 4)
    No-Operation (NOP)
    No-Operation (NOP)
__ TCP SACK Permitted Option: True__

Your camera responds with the following

Frame 2399: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0
Internet Protocol Version 4, Src: 118.70.125.33, Dst: 192.168.1.151
Transmission Control Protocol, Src Port: 554 (554), Dst Port: 11504 (11504), Seq: 0, Ack: 1, Len: 0
Source Port: 554
Destination Port: 11504
<Source or Destination Port: 554>
<Source or Destination Port: 11504>
[Stream index: 30]
[TCP Segment Len: 0]
Sequence number: 0    (relative sequence number)
Acknowledgment number: 1    (relative ack number)
Header Length: 32 bytes
Flags: 0x012 (SYN, ACK)
Window size value: 14600
[Calculated window size: 14600]
Checksum: 0x21aa [validation disabled]
Urgent pointer: 0
Options: (12 bytes), Maximum segment size, No-Operation (NOP), No-Operation (NOP), SACK permitted, No-Operation (NOP), Window scale
__ Maximum segment size: 1398 bytes__
    No-Operation (NOP)
    No-Operation (NOP)
__ TCP SACK Permitted Option: True__
    No-Operation (NOP)
    Window scale: 1 (multiply by 2)
[SEQ/ACK analysis]
This causes the stack on the opposite side to have to ACK additional segments under TCP.

RTSP specifies that TCP UserTimeout should be used to prevent such duplicate acknowledgements.

My RtspClient under windows uses the Selective Acknowledge permitted to compensate for this (SACK) which your camera indicates it can support.

Unfortunately your camera has a BUG where it does not respect it's own MSS as can be seen in some frames:

Frame 2578: 1452 bytes on wire (11616 bits), 1452 bytes captured (11616 bits) on interface 0
Internet Protocol Version 4, Src: 118.70.125.33, Dst: 192.168.1.151
Transmission Control Protocol, Src Port: 554 (554), Dst Port: 11504 (11504), Seq: 133902, Ack: 815, Len: 1398
Source Port: 554
Destination Port: 11504
<Source or Destination Port: 554>
<Source or Destination Port: 11504>
[Stream index: 30]
[TCP Segment Len: 1398]
Sequence number: 133902    (relative sequence number)
[Next sequence number: 135300    (relative sequence number)]
Acknowledgment number: 815    (relative ack number)
Header Length: 20 bytes
Flags: 0x010 (ACK)
Window size value: 7300
[Calculated window size: 14600]
[Window size scaling factor: 2]
Checksum: 0xa706 [validation disabled]
Urgent pointer: 0
[SEQ/ACK analysis]
TCP segment data (70 bytes)
[2 Reassembled TCP Segments (1412 bytes): #2577(1342), #2578(70)]
RTSP Interleaved Frame, Channel: 0x00, 1408 bytes
Real-Time Transport Protocol
__ Data (1328 bytes)__

This causes a 'Continuation' to be seen in Wireshark as it attempts to manually re-assemble the segments which are received.

My client also deals with this appropriately as it should by reading all required data in the frame if the entire segment is transmitted and received, if not the data is skipped appropriately also.

The only thing which causes this camera not to work via the RtspServer is that this camera uses SSRC 0 which is illegal in RTP, it indicates that the ID is unknown and unassigned.

If you run the RtspClient UnitTest against that stream you will be able to verify this.

The RFC is here RTP RFC, I can't find the explicit text which says that the SSRC cannot be 0 but if you look in the source code I have it cited somewhere and I use the 0 value to indicate discovery.

This can be changed although I am not sure it should be as there is no reason for the camera to not pick a unique ID..

'TransportContext.InDisconvery => get { return RemoteSynchronizationSourceIdentifier == 0 && ValidRtpPacketsReceived < MinimumSequentialValidRtpPackets; }'

I will run a few tests and scour the RFC to verify but in the mean time... can you direct me to the manufactures website for that camera so I can being a dialog with them to fix this?

As it stands now I cannot even watch the camera in VLC as it has much worse packet handling than my implementation, UDP succeeds but the external IP is routed so VLC falls back to using TCP which then causes VLC to error:
MultiFramedRTPSource error: Hit limit when reading incoming packet over TCP. Inc
rease "MAX_PACKET_SIZE"
MultiFramedRTPSource error: Hit limit when reading incoming packet over TCP. Inc
rease "MAX_PACKET_SIZE"
Sending request: TEARDOWN rtsp://118.70.125.33/user=admin&password=admin12345&ch
annel=1&stream=0.sdp/ RTSP/1.0
CSeq: 6
User-Agent: LibVLC/2.1.5 (LIVE555 Streaming Media v2014.05.27)
Session: 72874550
Please verify this and let me know how you would like to proceed!

Otherwise it seems cpu usage is good (below 10% for mostly all of the run time) and memory usage also, all cameras were being streamed without any issues and the server never used over 80MB of memory with up to 10 simulated viewers on each stream and 1 real viewer.

Let me know if you cannot confirm or have further questions!

Sincerely,
Julius
Marked as answer by juliusfriedman on 6/6/2016 at 9:38 AM
Jun 7, 2016 at 4:23 AM
Dear Sir,

That camera come from many brand name in China.
If you need check some camera settings, this is link to camera: http://118.70.125.33:19000/
I've test this camera with Onvif Device Manager (https://sourceforge.net/projects/onvifdm/) and VLC, it's work fine.
Onvif port of camera is 8899, in ODM, you add follow url: http://118.70.125.33:8899/onvif/device_service

Best Regards,
Le Hong Thai
Coordinator
Jun 7, 2016 at 11:35 AM
If you allow the SSRC 0 my RtspClient works also and the camera can be relayed to others via the RtspServer.

You may have better luck from VLC because your closer to the device e.g. in the same network or right next to the camera so the fragmentation doesn't effect you as much but the issue still remains...

Are you watching via UDP or TCP? The tests indicate TCP. Under UDP it would be better probably but VLC will drop packets from this camera on occasion and not be able to recover. The same with ODM as it uses ffmpeg.

The camera cannot send data segments which exceed the MSS without expecting fragmentation and this is not allowed in Rtsp without setting BlockSize appropriately which the camera does not.
12.7 Blocksize RFC RTSP
This request header field is sent from the client to the media server
asking the server for a particular media packet size. This packet
size does not include lower-layer headers such as IP, UDP, or RTP.
The server is free to use a blocksize which is lower than the one
requested. The server MAY truncate this packet size to the closest
multiple of the minimum, media-specific block size, or override it
with the media-specific size if necessary. The block size MUST be a
positive decimal number, measured in octets. The server only returns
an error (416) if the value is syntactically invalid.

If you look in the latest sources you can see how I allow from remote parties with the ID 0 by using the code which is commented for the InDiscovery property, please take this into consideration if you proxy this stream as the SSRC will be repeated as 0.

If I still cannot find good cause to keep the 0 value for discovery other than as indicated in my notes I will make the change in the code and remove the association with 0 as a Discovery mechanism for single party Rtp session and reserve that for use within Conference.

I tried to login to the camera to take a look but it said invalid password.

Take a look in there and see what the MTU and MSS settings are and adjust to values which are appropriate.

Let me know if you have further issues or if you can't get that camera to work with the rtsp server after making the change.

Also if you have some way I can replicate the high usage issue so that I can debug it.

Thank you again!
Marked as answer by juliusfriedman on 6/7/2016 at 4:36 AM
Coordinator
Jun 14, 2016 at 8:41 PM
I believe I have fixed the high usage issues.

If you can confirm and let me know I would appreciate it.

All other streams (besides benco) seem accessible and working as expected.

Please let me know if you find otherwise and thank you again for your testing and feedback!
Marked as answer by juliusfriedman on 6/14/2016 at 1:41 PM
Coordinator
Jun 16, 2016 at 7:48 PM
Edited Jun 16, 2016 at 7:48 PM
I am confident the RtspServer is now stable and the high usage is all but fixed in certain cases.

If you would please do some testing and let me know what you think I would appreciate it.

The most prevalent issue seems to be clients who disconnect but the Teardown is either not received completely or at all; In such cases their RtpClient becomes inactive and takes up to the 'RtspClientInactivityTimeout' to be disposed.

I really need to revise 'RtspServer.DisconnectAndRemoveInactiveSessions' as well as 'ClientSession.ReleaseUnusedResources' to make them more efficient.

I will be working on that in next few releases.

Any bugs you find or exceptions which are out of the ordinary please let me know!

Thank you again for your continued assistance and interest!
Marked as answer by juliusfriedman on 6/16/2016 at 12:48 PM
Coordinator
Jun 16, 2016 at 8:41 PM
112158 has minor revisions which seem to improve that performance further, it's not perfect yet but its quite close.

If you can also verify that 112158 is better than 112157 etc I would appreciate that...

I am going for 10k clients eventually and then 100k clients should be as far as anyone needs to go.

Thanks again for your help!
Marked as answer by juliusfriedman on 6/16/2016 at 1:42 PM
Jun 21, 2016 at 4:52 PM
Dear Sir,

Current version (112162) is more better.

Now I dont see high CPU usage problem. May be the key of problem is low speed internet connection and in real application, some cameras can be down and server always trying co reconnect.
Do you think the stream from server to client is not smooth as original source ?
(I am testing with 2 LILIN cameras in local network, but there is delay (3 seconds) and not smooth)
Thera are some other camera source for testing:

DAHUA IP CAMERA/DVR/NVR:
rtsp://admin:admin@118.70.125.33:53554/cam/realmonitor?channel=1&subtype=1 channel from 1-16, subtype=0 for Mainstream (HD, 2 Mbps), subtype=1 for Substream (VGA)

Benco1 can access again on other port:
rtsp://118.70.125.33:19054/user=admin&password=admin12345&channel=1&stream=0.sdp?real_stream
Benco2:
rtsp://118.70.125.33:19154/user=admin&password=admin12345&channel=1&stream=0.sdp?real_stream
Benco3:
rtsp://118.70.125.33:5854/user=admin&password=&channel=1&stream=0.sdp?real_stream
If internet connection is low, you can set "stream=1" for connection to sub stream instead of mainstream

Best Regards,
Le Hong Thai
Coordinator
Jun 22, 2016 at 8:29 PM
May be the key of problem is low speed internet connection and in real application, some cameras can be down and server always trying co reconnect.

Yes, this is a good point however I think I handled this by adding another state 'StartRequestedandStopRequestedwhich will signal that the streams should not be started again until they are inStartedorStopped. Please let me know if you see otherwise.

I will add these cameras in the next day or two and let you know how they work.

Thank you again for the cameras / resources and I will get back to you probably next week after I collect additional feedback and perform additional testing with these cameras.

My environment for development and testing has at least 100 MBPS dedicated to the operation of the server consuming streams for testing so I should be able to support quite a few streams depending on the resolution and frame-rate.

I have another few virtual machines setup on a virtual network which is how I do most of the testing so I don't overload the physical interface during those times.

I have no problem running and consuming all of the streams list in the
TestRtspServer` from my location at the same exact time and then watching them once they come out of the RtspServer from either the virtual network or the physical network, mind you I can accomplish this while also serving the MJPEG streams which use considerably more CPU and bandwidth than any of the actual streams probably do (except at maximum resolution and quality).

Are you testing via UDP or TCP and using Ethernet or Wifi?

Are you watching the streams from the same machine as you are consuming them?

What player are you using?

Do you have network buffering turned on in your player?

My research and testing seems to reveal only smaller potential issues with Rtsp and Wifi and only under TCP due to coverage when moving around which has nothing to do with the application layer logic and can be worked around in all but the most severe cases simply by not re-transmitting data to clients over TCP as I already configure in the library.

What are the exact issues you are experiencing at this time? Possibly a video of the delay and some graphics from the performance logging of the server or some other type of information would be useful to help me narrow down exactly what your issues are.

In my testing my RtspServer provides the same experience as the camera would directly and in mostly every case can substitute for the the camera directly by emulating the responses required for certain integration which would otherwise be impossible without software modifications to the camera directly;

The other benefit is that a RtspServer will likely have higher bandwidth and more resources than the cameras them-self, this means you can support more viewers on a camera which is configured to exactly only support 1 viewer each on 2 separate streams at a specific resolution and it's accompanying rendition.

Another benefit is that you will be able record streams and play them back or trans-code and play back if required.

There are a myriad of other possible benefits depending on what you compare the library to or what you are trying to achieve.

If you can please possibly shed some light on your current issues, how you are using the library and what you think of it in comparison to other solutions it would be very helpful to me!

Sincerely,
Julius
Coordinator
Jun 24, 2016 at 8:07 PM
I have another update I will be posting hopefully today.

That Duhua gives pretty good quality and all 12 channels can be consumed at the same time, what model is that?

I have found no issue with any of the streams you allow access to except the 'Benco' cameras.

Those Benco cameras are either not configured correctly or their firmware has a bug where the MSS / MTU is exceeded, this causes a lot of stress on the network because of re-transmissions under TCP and I can't even get a UDP stream routed to me from that camera.

This may be bandwidth related but I am not 100% sure yet and I didn't invest much time into testing and diagnosis.

I notice less of an issue if I don't pull from the Benco devices at all, but once I start pulling from any of the Benco devices it seems to bring down other streams I am pulling e.g. Duhua or Hikvision

Thus I am pretty sure if there is a bandwidth issue it's not on this side of the connection.

In my latest version of the code I turn on certain options which may make a difference for Tcp so we can test that and we can go from there.

Take a look when I update the code and please also let me know how your using the library / what you compare it against so that I can review further.

Thank you!

-Julius
Marked as answer by juliusfriedman on 6/24/2016 at 1:07 PM
Coordinator
Jun 25, 2016 at 2:59 PM
I took some time today to verify the network on my side.

It seems there is no connection problem on my side @ all.

I can verify that your connection is dying at roughly 50 - 75 mbps.

I verify this by spinning up a single RtspClient.Tcp1 @ on 'rtsp://118.70.125.33:19154/user=admin&password=admin12345&channel=1&stream=0.sdp?real_stream'

Then I wait for it to start playing.

I verify with Wireshark and then I perform some internet speed test @ www.speedtest.net

I start another RtspClient.Tcp2 @ rtsp://118.70.125.33:5854/user=admin&password=admin12345&channel=1&stream=0.sdp?real_stream

RtspClient.Tcp1 is still connected. I still can browse the internet and perform another speed test.

RtspClient.Tcp1 died randomly.

I can repeat this with any combination of the Benco cameras and it seems to occur right around 50 - 75 mbps.

Let me know if you can provide more bandwidth or I can lower the resolution for testing.

Thanks again for your assistance and resources!
Marked as answer by juliusfriedman on 6/25/2016 at 8:00 AM
Jun 26, 2016 at 3:19 AM
Edited Jun 26, 2016 at 3:22 AM
Dear Sir,

Dahua rtsp source is HD-CVI DVR. All Dahua models come with same protocol, so i think your it shall works fine for all Dahua devices, include: DVR, NVR and IP camera.
In case of you still want to test with Dahua IP camera, you can use source:
substream: 704x576, 25 fps, 1Mbps: rtsp://admin:admin12345@118.70.125.33:23154/cam/realmonitor?channel=1&subtype=1 mainstream: 1920x1080, 25 fps, 2Mbps: rtsp://admin:admin12345@118.70.125.33:23154/cam/realmonitor?channel=1&subtype=0 In local network, i have 3 Benco ip cameras:
Camera1, 1920x1080, 25 fps, 2Mbps: rtsp://118.70.125.33:5854/user=admin&password=&channel=1&stream=0.sdp?real_stream
Camera1, 704x576, 25 fps, 768 Kbps: rtsp://118.70.125.33:5854/user=admin&password=&channel=1&stream=1.sdp?real_stream

Camera2, 1280x720, 15 fps, 2Mbps: rtsp://118.70.125.33:19054/user=admin&password=admin12345&channel=1&stream=0.sdp?real_stream
Camera2, 704x576, 15 fps, 1 Mbps: rtsp://118.70.125.33:19054/user=admin&password=admin12345&channel=1&stream=1.sdp?real_stream

Camera3, 1280x720, 15 fps, 2Mbps: rtsp://118.70.125.33:19154/user=admin&password=admin12345&channel=1&stream=0.sdp?real_stream
Camera3, 704x576, 15 fps, 1 Mbps: rtsp://118.70.125.33:19154/user=admin&password=admin12345&channel=1&stream=1.sdp?real_stream

if you want to config parametter of this camera, please using Http Port is 19000 and ONVIF port is 8899 (ussing Onvif Device Manager)

I have two internet connections and router config with load balance session base, total bandwith download is 101 Mbps and upload is 90 mbps (test by speedtest)

Best Regards,
Le Hong Thai
Coordinator
Jun 27, 2016 at 12:46 AM
I don't need access to the Http Interface at this time, I would like to do some more testing with higher resolution streams on the other devices to see if there is some other issue.

Perhaps the issue is with a Switch the Benco devices are hooked up to? Possibly something in the router configuration from the LAN where the Benco is to where the LAN where the router is?

I will let you know what I find later in the week but if you only have 100 MBPS available it seems that is right where the issue is, probably in the bandwidth throttling is enabled in some aspect.

It seems like you have good comprehension of the environment and bandwidth requirements, please review these two good questions on Super User to ensure you do have the sufficient bandwidth requirements for me to consume the HD resolution on all of those streams.

http://superuser.com/questions/434532/what-data-transfer-rates-are-needed-or-streaming-hd-1080p-or-720p-video-or-stan

http://superuser.com/questions/413982/how-much-bandwith-is-required-to-stream-1080p

I think I will have to either reduce the resolution of the streams I am consuming to allow for the available bandwidth you have available but before I do so I will need to explore the potential of seeing if I can utilize a single RtspClient to proxy more than one stream at a time and thus increase the overall available bandwidth from a single connection to reduce the stress on your network.

I will attempt this by creating a few examples which perform multiple 'DESCRIBE' and 'SETUP' and PLAY requests from a single RtspClient and adapt any major changes required at the RtspSession level to accommodate; the result should be that a single connection can get slightly more data in and out from a network than multiple connections at the expense of slightly more latency.

Please keep in mind though since the Benco devices share the same SSRC this may not be a viable solution in such a case unless the RtspServer manually assigns their outgoing streams a new SSRC (which I can allow for via an option on RtpSource very easily) which will also cost slightly more memory and cpu.

Bandwidth is the single most valuable asset to a streaming solution as I am sure you know; without sufficient bandwidth no matter how many tricks or how much compression you add your still going to be unhappy with the result if you don't have a big enough pipe to allow the data to flow where it needs and how it needs.

Consider this; If I consume all of those streams and use 80 MBPS of the connection then how will anyone else consume any streams from your network? You will only have 10 or 20 MBPS available for up stream data flows.

Let me know what I can expect to be able to stream and I will test accordingly, I have about 100 MBPS but up to 120 MBPS I can dedicate solely for the purpose of testing the RtspServer while still being able to maintain network connectivity for everything else I need to do.

Thanks for the model information about the Dahua I will see if I can get one of those to play around with and I appreciate being able to test with it for the time being.

If you could also please also let me know how you intend to use the library and what you have also tried as an alternative and how this library compares as it will be very helpful to me.

Finally please let me know any issues you still experience with the library at this time so that I can look into them further.

Sincerely,
Julius
Marked as answer by juliusfriedman on 6/26/2016 at 5:46 PM
Coordinator
Jul 6, 2016 at 4:11 AM
Edited Jul 6, 2016 at 6:07 PM
Sir,

I would REALLY REALLY like to know more about the camera @ 'rtsp://118.70.125.33:19154/user=admin&password=admin12345&channel=1&stream=0.sdp?real_stream'

It is one of the most intriguing implementations of stream layering I have ever seen... Either that or it has a bug in the firmware...

Is the source code for the firmware available for this camera?

Also how do you like the latest sources, if you experience issues with the Benco cameras let me know and I will make an option for the SSRC to be allowed so it can be more easily streamed from the RtspServer.

I believe though this camera attempts to use tricks and holes in the Rtp and Rtsp protocol to enable the viewer to receive an alternate version of the stream when it detects the application buffer is too small or the bandwidth is too low.

This allows the viewer to switch streams depending on the bandwidth but is not compatible with all decoders and can possible overflow or underflow for good or bad....

My implementation is compatible with the RFC and you can usually get a decent quality video and transmission speed but VLC can't really render the textures accurately because the NAL data is incomplete in the primary stream and VLC will not associate it with the actual stream due to the identity or 'ssrc' not being the same.

As I can't get a UDP stream it's harder to really analyze as TCP segments appear to be lost which is why I get the bad quality.

This steams from the MSS issue which is a configuration on the firmware of the camera either related to the Rtp packet size generated by the camera encoder or a setting on the OS of the camera which was not configured with respect to the Rtp packet size generated by the encoder.

Let me know what you think and I hope to hear from you soon!

Image

Keep in mind... That picture is from my library recording the stream as VLC plays it back, VLC cannot even playback the stream for me without my library in the Transport layer... It just gets stuck and eventually stops or crashes.

I have located another bug or two in my depacketization process....

I will definitely fix it but the issue seems to be more or less 'Network' related, there MUST be a middle box or MANE which is either transforming this data or you have a bad switch / etc on that particular camera IMHO...

Please let me know what you think about the camera in question

rtsp://118.70.125.33:19154/user=admin&password=admin12345&channel=1&stream=0.sdp?real_stream

Thank you again for your resources and testing!
Marked as answer by juliusfriedman on 7/5/2016 at 9:11 PM
Jul 7, 2016 at 2:46 PM
Edited Jul 7, 2016 at 2:48 PM
Dear Sir,

Camera @'rtsp://118.70.125.33:19154/user=admin&password=admin12345&channel=1&stream=0.sdp?real_stream' come from NVT manufacturer from China and i dont have any source code or firmware of this camera.
I don't have plae using this type of camera again, so now you can forget them.
About your new version:
Seem RTSP client is very good, i can save H264 video stream from camera to .h264 file and playback by VLC (previous version save .h264 file with distortion image as your picture) but RTSP server is not. The CPU usage raise to high value and video stream (in local network) always restart.
Sorry about i can not debug your code, i am only testing and report.
This is some stream from other branch camera:
Brickcom:
rtsp://admin:admin12345@118.70.125.33:15554/channel1
rtsp://admin:admin12345@118.70.125.33:15554/channel1
LILIN:
rtsp://admin:pass@118.70.125.33:9654/rtsph2641080p
rtsp://admin:pass@118.70.125.33:9654/rtsph264480p
Coordinator
Jul 7, 2016 at 4:01 PM
Edited Jul 7, 2016 at 4:24 PM
For server function you want to use the older version probably, When I merged in the changes for the latest version some issues were still present.

I don't expect you to debug but I do appreciate the feedback and I will fix and make a stable release soon enough.

Please keep that camera around though so I we can test against some of the nuances it exhibits with the RTSP and TCP protocols especially. I find it an extremely useful as a test resource due to the way the stream comes through.

Thank you for the additional test cameras.

I also have questions about the cameras @ "rtsp://admin:11111111@118.70.125.33:7801/Streaming/channels/301" It appears this camera has in band sps and pps, the camera also frequently sends out of order and duplicate TCP packets.

I am not sure if this is network related or cameras configuration related similar to the above camera, it's less interesting in the types of traffic I see but it still leaves me with some questions....

Image

Eventually this clears up but then it starts again..

Image

The video is not really watchable in VLC unless you adjust the playback speed.

This is probably also due to bandwidth and camera configuration but I just want to have your opinion also...

The data which comes out of band seems to be pt '112' with an Extension which is always valid but I can't really seem to make out what the data in the Extension is easily..

I assumed this was SPS and PPS or possibly some type of extension data to the stream but perhaps you can clarify or ask the manufacturer, here is an except:
Start:@ 159797938 (2)/(96) 00-02-80-00-23-FF-45-6C-E0-F1-F0-50-4D-1D-BD-B5-56-DA-89-53-D4-96-BE-B9-6F-26-10-20-B8-58-50-28-56-74-5E-E9-E3-7E-D6-D0-B0-E5-4E-92-5A-C5-65-36-06-9B-74-10-AB-A3-1A-7A-9A-5E-CC-FD-5A-C5-65-36-06-9B-74-10-AB-A3-1A-7A-9A-5E-CC-FD-C8-82-91-17-0A-32-0F-D7-07-AF-CB-98-43-A5-A1-A6
Start:@ 159797938 (5)/(52) 00-03-00-00-23-FF-45-6C-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159805138 (5)/(52) 00-03-00-00-23-FF-45-6D-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159812340 (5)/(52) 00-03-00-00-23-FF-45-6E-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159819540 (5)/(52) 00-03-00-00-23-FF-45-6F-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159830342 (5)/(52) 00-03-00-00-23-FF-45-70-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159837542 (5)/(52) 00-03-00-00-23-FF-45-71-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159844744 (5)/(52) 00-03-00-00-23-FF-45-72-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159851944 (5)/(52) 00-03-00-00-23-FF-45-73-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159859144 (5)/(52) 00-03-00-00-23-FF-45-74-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159866346 (5)/(52) 00-03-00-00-23-FF-45-75-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159873546 (5)/(52) 00-03-00-00-23-FF-45-76-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159880748 (5)/(52) 00-03-00-00-23-FF-45-77-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159887948 (1)/(52) 40-0E-48-4B-01-00-10-73-DB-5B-20-00-00-FF-FF-FF-45-0A-1B-91-00-23-45-78-FF-FF-FF-FF-41-12-48-4B-00-01-02-03-04-05-06-07-08-09-0A-0B-0C-0D-0E-0F
Start:@ 159887948 (2)/(20) 42-0E-00-00-60-00-02-C0-02-40-0A-00-FF-00-3A-99
Start:@ 159887948 (2)/(96) 00-02-80-00-23-FF-45-78-E0-F1-F0-50-A8-55-90-61-CD-1C-DB-82-7E-77-17-A0-7C-96-CF-93-40-18-C5-F1-A4-73-CA-4E-D2-8A-91-AE-57-6D-DB-D6-B3-0F-AF-58-B0-DF-7B-73-41-88-D0-CE-36-8C-31-70-B3-0F-AF-58-B0-DF-7B-73-41-88-D0-CE-36-8C-31-70-AB-21-47-8F-B3-E5-AC-1D-F7-E0-CA-CD-17-A5-75-ED
Start:@ 159887948 (5)/(52) 00-03-00-00-23-FF-45-78-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159895148 (5)/(52) 00-03-00-00-23-FF-45-79-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159902350 (5)/(52) 00-03-00-00-23-FF-45-7A-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159909550 (5)/(52) 00-03-00-00-23-FF-45-7B-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159920352 (5)/(52) 00-03-00-00-23-FF-45-7C-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159927552 (5)/(52) 00-03-00-00-23-FF-45-7D-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159934754 (5)/(52) 00-03-00-00-23-FF-45-7E-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159941954 (5)/(52) 00-03-00-00-23-FF-45-7F-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159949156 (5)/(52) 00-03-00-00-23-FF-45-80-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159956356 (5)/(52) 00-03-00-00-23-FF-45-81-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159963556 (5)/(52) 00-03-00-00-23-FF-45-82-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159970758 (5)/(52) 00-03-00-00-23-FF-45-83-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159977958 (1)/(52) 40-0E-48-4B-01-00-10-73-DB-5B-60-00-00-FF-FF-FF-45-0A-1B-91-00-23-45-84-FF-FF-FF-FF-41-12-48-4B-00-01-02-03-04-05-06-07-08-09-0A-0B-0C-0D-0E-0F
Start:@ 159977958 (2)/(20) 42-0E-00-00-60-00-02-C0-02-40-0A-00-FF-00-3A-99
Start:@ 159977958 (2)/(96) 00-02-80-00-23-FF-45-84-E0-F1-F0-50-C5-10-9E-A9-E2-7B-D1-25-C6-62-30-62-D6-69-AD-EF-CD-8F-52-0D-49-02-E0-83-A3-5E-B0-8A-7A-8B-DD-D4-EB-9E-49-86-D6-C9-CA-15-E7-84-56-A9-16-73-2F-AD-EB-9E-49-86-D6-C9-CA-15-E7-84-56-A9-16-73-2F-AD-34-32-12-0E-9C-CA-08-53-B5-6C-C8-56-D2-AB-54-3B
Start:@ 159977958 (5)/(52) 00-03-00-00-23-FF-45-84-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159985160 (5)/(52) 00-03-00-00-23-FF-45-85-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159992360 (5)/(52) 00-03-00-00-23-FF-45-86-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 159999562 (5)/(52) 00-03-00-00-23-FF-45-87-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 160010362 (5)/(52) 00-03-00-00-23-FF-45-88-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 160017564 (5)/(52) 00-03-00-00-23-FF-45-89-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 160024764 (5)/(52) 00-03-00-00-23-FF-45-8A-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
Start:@ 160031964 (5)/(52) 00-03-00-00-23-FF-45-8B-FF-FF-02-00-02-00-01-11-80-00-01-BE-34-FF-9C-BE-34-BF-9D-44-21-80-00-05-A2-8F-9F-1A-C1-26-FD-D1-E9-78-F0-61-D3-94-B1-CA
The format is given from the expression:

"Start:@ " + packet.Timestamp +" (" + ext.Flags + ")/(" + ext.Size + ") " + System.BitConverter.ToString(data) + Environment.NewLine

The payload type is always '112'...

I also see frequently see SILENCE packets, e.g. type 13 so I believe this retransmission issue has something to do with the Audio source bandwidth but I am not 100% sure.

Also I was just curious what type of device is pictured and what is it doing? It appears to me some type of detector or camera.. I was just curious what it was :)

I experience similar things with the camera @ rtsp://admin:11111111@118.70.125.33:7801/Streaming/channels/201

Sometimes, if I just keep the data according to timestamp and put it in with the video by 'AllowMultiplePayloadTypes' I can get pretty good video as can be seen here: h264 sample



I am just really curious if this is the proper way to 'depacketize' this stream and if there is any documentation from the manufacture on this mode of Rtp packetization...

Thanks again for your feedback and testing!
Marked as answer by juliusfriedman on 7/7/2016 at 9:01 AM
Coordinator
Jul 8, 2016 at 1:00 AM
I think I got it...

Image

Image

....

I will make the update to the code hopefully tommorow.

Btw Lillin and Brickcom seem A OK, no issues @ all.

Sincerely, Thank you again for your resources and testing!
Marked as answer by juliusfriedman on 7/7/2016 at 6:00 PM
Coordinator
Jul 11, 2016 at 8:32 PM
I am making a lot of improvements I am currently testing and profiling, if I am testing too much or disturbing your bandwidth just send me an email and I will take a rest..

Thank you again for your patience and resources!
Marked as answer by juliusfriedman on 7/11/2016 at 1:32 PM
Coordinator
Jul 15, 2016 at 9:01 PM
Still testing, thank you for your patience!

Good news is that the improvements are will worth the wait.

If there was any other feedback you had or could provide now would be a good time.

Thank you again for your patience and resources.

P.s. The myriad of reasons you don't want a SSRC == 0 can be plentiful regardless of that the RFC says.

I have allowed for it in my recent builds and I am further testing it to ensure corner cases previously noted are no longer problematic...

E.g. Payload Type = 0 and SSRC == 0 is bad combination for multiple reasons, this is only worsen when Timestamp wraps.

Some links cannot have 9 consecutive 1's or 0's, other links have other such restructions which are usually handled with 'stuffing' or escaping.

Although this link layer semantic has nothing to do with RTP or RTSP it is good to keep in mind.

A reason directly related to RTP or RTSP would be it can create interesting parsing scenarios, such as when the length is 0, the channel is 0 etc (channel may not even be used under independent TCP) or otherwise.

The value 0 is also End Of String.

Anyway, it seems to not matter in most cases BUT I wanted you to have the information JIC.

Hopefully next week ...

明天会更好
Marked as answer by juliusfriedman on 7/15/2016 at 2:01 PM
Coordinator
Nov 29, 2016 at 8:14 PM
Hello Sir, I will have some time in the coming weeks and I would like to ensure compatibility and stability during the next releases.

If you would be so kind as to provide a list of cameras their respective RTSP URI, their manufacturer and models I will test UDP, TCP and HTTP and organize the UnitTests to take advantage of the list of sources so that multiple tests can be performed using a single list of test sources.

I would also like to work on file muxing and demuxing as well as other transport protocols such as HTTP and SIP.

Let me know when you have compiled the list and if I get a chance to compile it first I will update the list and you can correct it.

Thank you again for your time and resources.

Sincerely,
Julius
Marked as answer by juliusfriedman on 11/29/2016 at 1:14 PM
Nov 30, 2016 at 3:02 AM
Dear Sir,

Here is some cameras:
Sony: (all cameras model from Sony has same RTSP API), max ~ 5 connections
user/pass: admin/admin
Main Stream 1280x720, 30fps, VBR, max bitrate 2 Mbps: rtsp://118.70.125.33:6854/video1
SubStream 640x480, 30fps, VBR, max bitrate 512 Kbps: rtsp://118.70.125.33:6854/video2
Avigilon: (all cameras model from Avigilon has same RTSP API), max ~ 5 connections
user/pass: admin/admin
Main Stream 2592x1944, 12fps, VBR, max bitrate 12 Mbps: rtsp://118.70.125.33:21154/defaultPrimary?streamType=u
SubStream 352x288, 12fps, VBR, max bitrate 512 Kbps: rtsp://118.70.125.33:21154/defaultSecondary?streamType=u
LILIN: (all cameras model from LILIN has same RTSP API), max ~ 5 connections
user/pass: admin/admin12345
(with audio)
Main Stream 1920x1080, 25fps, VBR, max bitrate 4 Mbps: rtsp://118.70.125.33:55554/rtsph2641080p
SubStream 720x480, 25fps, VBR, max bitrate 512 Kbps: rtsp://118.70.125.33:55554/rtsph264480p
NVT (some manufacturer from China, all cameras has same RTSP API), max ~ 10 connections
user/pass: admin/admin12345
Main Stream 1280x720, 15fps, VBR, max bitrate 2 Mbps: rtsp://118.70.125.33:19154/user=admin&password=admin12345&channel=1&stream=0.sdp?real_stream
SubStream 352x288, 15fps, VBR, max bitrate 256 Kbps: rtsp://118.70.125.33:19154/user=admin&password=admin12345&channel=1&stream=1.sdp?real_stream
user/pass: admin/(empty)
Main Stream 1280x720, 15fps, VBR, max bitrate 2 Mbps: rtsp://118.70.125.33:5854/user=admin&password=&channel=1&stream=0.sdp?real_stream
SubStream 352x288, 15fps, VBR, max bitrate 256 Kbps: rtsp://118.70.125.33:5854/user=admin&password=&channel=1&stream=1.sdp?real_stream
DAHUA (all cameras model from DAHUA has same RTSP API ), max ~ 10 connections
user/pass: admin/admin12345
Main Stream 2048x1536, 20fps, VBR, max bitrate 6 Mbps: rtsp://118.70.125.33:23154/cam/realmonitor?channel=1&subtype=0
SubStream 352x288, 20fps, VBR, max bitrate 256 Kbps: rtsp://118.70.125.33:23154/cam/realmonitor?channel=1&subtype=1
DAHUA DVR/NVR, max 128 connections
user/pass: admin/admin
Main Stream 1920x1080, 12fps, VBR, max bitrate 2 Mbps: rtsp://118.70.125.33:53554/cam/realmonitor?channel=1&subtype=0
SubStream 352x288, 12fps, VBR, max bitrate 256 Kbps: rtsp://118.70.125.33:53554/cam/realmonitor?channel=1&subtype=1

All rtsp url work fine with VLC
If you need more cameras (HIKVISION - China, DMAX - Korea, FLIR - DVTEL, Panasonic, Arecont Vision...), i will install and send rtsp url to you

Best Regards,
Le Hong Thai
Nov 30, 2016 at 3:40 AM
Dear Sir,

I am trying to build a rtsp server, using your sample source code with only 1 camera in local network.
the video streaming from RTSP server is delay and lag. Please watch screen recording video here:
https://drive.google.com/file/d/0B58kkH1zYKgacUJSRjVFSExCMnM/view?usp=sharing

I was tried with some media streaming engine as wowza streaming engine on windows, Ureal media server, it's work fine.

Best Regards,
Le Hong Thai