RTP socket.ReceiveBufferSize for udp

Topics: Question
Mar 22, 2015 at 5:27 PM
Using my hikvision ds-2cd2432f-iw camera I'm getting dropped frames evidenced by logging RTP sequence numbers and by poor video quality.

In my previous thread https://net7mma.codeplex.com/discussions/588376
with Foscam FI 9831W, version 111198 solved my dropped frames issues by ensuring that the buffer size specified in the RTSPClient constructor was correctly set in the RTP sockets' ReceiveBufferSize property.

For the hivison cam I'm finding that the ReceiveBufferSize is at the default 8192 bytes despite setting it to 128K in the constructor.

I suspect that this may be a result of the hikvision cam defining video only (no audio) in the SDP. In other words there may be a bug in the library that surfaces when audio isn't specified.
The reason for this suspicion is that the Foscam SDP defines video and audio and does not have the problem. In addition, I tried TrendNet TV-IP672W (video and audio) and its buffers were being set correctly too.

https://www.cubbyusercontent.com/pl/MMA111198_DebugReceiveBuff/_f8ae4bbf9c244f6bbf6939f25dc7aa39
Coordinator
Mar 22, 2015 at 6:02 PM
Edited Mar 22, 2015 at 6:25 PM
I doubt it has to do with Audio or Video only but it probably has to do with the SessionDescription, can you post that?

You can verify this by forcing only Audio or Video on either one of the other streams with the option on the RtspClient OnlyMediaType.

The Send and Receive interval are defined from that currently and most other options of the TransportContext.

I see no reason that the ReceiveBufferSize isn't set, if you put a break point at the same location you put in your other thread you should be able to verify right after that call

'Media.Common.ISocketReferenceExtensions.SetReceiveBufferSize(((Media.Common.ISocketReference)m_RtpClient), m_Buffer.Count);'

Which I am looking at changing to:

'Media.Common.ISocketReferenceExtensions.SetReceiveBufferSize(((Media.Common.ISocketReference)created), m_Buffer.Count);'

There are also a few other changes I would like to eventually iron out and implement but they require some small API changes which I am just determining the extent of which to implement in pieces such that I can allow for other paradigms such as Rtsp over Http to be completely supported.

It's quite easy to determine where and how and why just about anything is done, the sockets are only created if necessary for Rtsp during the Connect operation of the RtspClient.

If you are using Tcp (which I don't think you are) then this is the same socket for Rtp, unless there is a different source returned in the setup response during the SendSetup call of the RtspClient.

If you are using Udp which I think you are then new sockets are created in the SendSetup call of the RtspClient call each time, where they are also configured.

Beyond that there should be no mystery, you can easily work around this and set them after the Playing event with RtspClient.Client.GetTransportContexts and then doing whatever you want with each context, or if you just want the sockets associated with a certain context just Media.Common.ISocketReferenceExtensions.GetReferencedSockets combined with the GetTransportContexts call to check or set any sockets and their options :)

It would be nice to know why in your case it's not working, if you can step through as you did previously it would probably help because I don't seem to understand how camera model is changing the ReceiveBufferSize in your local code :)

Are you enabling the AllowAlternateTransport option? Is this possibly a new connection which you are confusing with the original connection?
Marked as answer by juliusfriedman on 3/22/2015 at 11:02 AM
Coordinator
Mar 22, 2015 at 6:16 PM
I think what you are seeing is Udp re-ordering and getting confused because you are using the packet events, you will see the packet's come with different order than intended sometimes.

If you also monitor the FrameChanged events you can make a check on those sequence numbers and the packets contained to also double check that your not losing track.

I make a test similar to this in the UnitTests in which I track both packets and frame events.

None the less the re-ordering will also typically cause the RtpClient to fire the FrameChanged event, this just allows for adjusted operation if required by receivers.

Typically the FrameChanged event will fire two or three more times after such, once again for the CurrentFrame and then again for the LastFrame and then again for the CurrentFrame.

In the first case the IsComplete will be false and then in the second it may be true.

Hopefully that is clear and we agree the RecieveBufferSize is set. I am not sure how it's not, if you can produce a code sample which re-produces it not being set I would then be able to attempt to fix it :)

Thanks for your time.
Marked as answer by juliusfriedman on 3/22/2015 at 11:16 AM
Mar 22, 2015 at 8:32 PM
Thanks for your attention to my post.

I couldn't find "OnlyMediaType" in your code. Is there an alternative way to exclude audio? That would be a good experiment I think.

Did you look at the link I provided? It clearly shows the ReceiveBufferSize at 8K in the Hikvision case and at 128K for Foscam case. (stopped at breakpoint in RTPClient.ReceiveData).

I also tried this:
rtspClient.StartPlaying();
rtspClient.Client.GetContextByPayloadType(96).RtpSocket.ReceiveBufferSize = 128 * 1024;
That fixed the image quality problem, but for some reason the video stops after a minute or so.

Here is the RTSP connection conversation including the SessionDescription:

OPTIONS rtsp://admin:xxxxx@192.168.0.148:554/cam1/mpeg4 RTSP/1.0
CSeq: 1
Authorization: Digest username="admin", realm="", nonce="37FFFFFA", uri="rtsp://admin:xxxxx@192.168.0.148:554/cam1/mpeg4", response="bc78ceeea6d4e7058514d7426bbcd379"

RTSP/1.0 200 OK
CSeq: 1
Public: OPTIONS, DESCRIBE, PLAY, PAUSE, SETUP, TEARDOWN, SET_PARAMETER, GET_PARAMETER
Date: Sat, Mar 21 2015 21:30:36 GMT

DESCRIBE rtsp://admin:xxxxx@192.168.0.148:554/cam1/mpeg4 RTSP/1.0
Accept: application/sdp
CSeq: 2
Authorization: Digest username="admin", realm="", nonce="7271CAF7", uri="rtsp://admin:xxxxx@192.168.0.148:554/cam1/mpeg4", response="f548a2865b41b72e4e26309e6988e52f"

RTSP/1.0 200 OK
CSeq: 2
Content-Type: application/sdp
Content-Base: rtsp://admin:xxxxx@192.168.0.148:554/cam1/mpeg4/ Content-Length: 584

v=0
o=- 1426973436296103 1426973436296103 IN IP4 192.168.0.148
s=Media Presentation
e=NONE
b=AS:5050
t=0 0
a=control:rtsp://admin:xxxxx@192.168.0.148:554/cam1/mpeg4/ m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:5000
a=recvonly
a=control:rtsp://admin:xxxxx@192.168.0.148:554/cam1/mpeg4/trackID=1 a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=420029; packetization-mode=1; sprop-parameter-sets=Z00AKZpmA8ARPyzUBAQFAAADA+gAAJxABA==,aO48gA==
a=Media_header:MEDIAINFO=494D4B48010100000400010000000000000000000000000000000000000000000000000000000000;
a=appversion:1.0
SETUP rtsp://admin:xxxxx@192.168.0.148/cam1/mpeg4/trackID=1 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=10000-10001;mode="PLAY"
CSeq: 3
Authorization: Digest username="admin", realm="", nonce="3FDFC3DB", uri="rtsp://admin:xxxxx@192.168.0.148/cam1/mpeg4/trackID=1", response="2e67471b299f194fb00ae19aeb12e4d7"

RTSP/1.0 200 OK
CSeq: 3
Session: 274510417;timeout=60
Transport: RTP/AVP/UDP;unicast;client_port=10000-10001;mode="PLAY";server_port=8230-8231;ssrc=7290e29c;mode="play"
Date: Sat, Mar 21 2015 21:30:36 GMT

PLAY rtsp://192.168.0.148:554/cam1/mpeg4 RTSP/1.0
Range: npt=now-
CSeq: 4
Authorization: Digest username="admin", realm="", nonce="1DEB7C7F", uri="rtsp://192.168.0.148:554/cam1/mpeg4", response="e59a3f086b9737b5f549e2f6bf02c23f"
Session: 274510417

RTSP/1.0 200 OK
CSeq: 4
Session: 274510417
RTP-Info: url=rtsp://192.168.0.148:554/cam1/mpeg4/trackID=1;seq=45633;rtptime=1261796546
Date: Sat, Mar 21 2015 21:30:36 GMT

GET_PARAMETER rtsp://admin:xxxxx@192.168.0.148:554/cam1/mpeg4 RTSP/1.0
CSeq: 5
Authorization: Digest username="admin", realm="", nonce="7DFE7D1A", uri="rtsp://admin:xxxxx@192.168.0.148:554/cam1/mpeg4", response="996eb00170cba72d7f9d5b69daff870d"
Session: 274510417

RTSP/1.0 200 OK
CSeq: 5
Date: Sat, Mar 21 2015 21:31:06 GMT
Coordinator
Mar 22, 2015 at 8:50 PM
Edited Mar 22, 2015 at 8:55 PM
Yes I did see the images but it doesn't help me get to understand how they came to have the values they have :)

A small code example would be helpful because on the RtspClient unit test when inputting a buffer size I do not have that issue regardless of the source I use the ReceiveBufferSize is set to what I provide so long as the value is in the appropriate range.

StartPlaying on the RtspClient accepts a MediaType to play instead of playing all types, please do try this as you like and let me know your results if possible in a reproducible test either against once of the test sources or against the RtspServer if you run into any issues.

The SessionDescription you posted doesn't seem to indicate any specific send or receive interval only a Application Specific interval so that shouldn't be making any difference here.

I am glad the ReceiveBufferSize can be set but I am unsure why it is not being set for you, if you put a break point in the same place you did in your previous tests you will see that it should be and if it's not I am unsure why it's not. Stepping through would indicate that to you.

"the video stops after a minute or so." isn't clear to me what you mean or what you are experiencing.

Where are your image quality issues are occurring and where is the video being displayed and how are you getting it to be displayed? E.g. ere you saving the packets to a file and then playing them back somewhere?

Again a small reproduce-able example would help me help you :)
Marked as answer by juliusfriedman on 3/22/2015 at 1:50 PM
Mar 23, 2015 at 12:12 AM
Ok, here's a way to reproduce it.

Run your TestRtspClient and enter 131072 for buffer size at the command prompt.

Here's what I got (Hope this helps):

RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:131072
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
Client Playing for :00:01:22.4197142
Remaining Time in media:00:29:23.9132858
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Receiving Data
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Data Received
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:131072
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Receiving Data
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Data Received
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:131072
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Receiving Data
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Data Received
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:131072
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Receiving Data
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Data Received
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:131072
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:131072
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Receiving Data
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Data Received
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:131072
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Receiving Data
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Data Received
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
Client Playing for :00:01:24.4198286
Remaining Time in media:00:29:21.9131714
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:131072
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Receiving Data
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Data Received
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6971 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:131072
RtpClient: ReceiveData: RemoteSocket:132.198.101.167:6970 socket.ReceiveBufferSize:8192
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Receiving Data
Media.Rtsp.RtspClient-71850b6f-46e0-4d16-9504-c5ef1dfaaadf@MonitorProtocol: Data Received
Coordinator
Mar 23, 2015 at 1:17 AM
Edited Mar 23, 2015 at 1:59 AM
1) That output isn't consistent with what is output from the method by default, did you change the code? If so can you include a code sample of what changed so I can try to replicate.

2) I tried to follow your steps but cannot reproduce any such error, partly because the output is different and otherwise I can only assume because there is something different.

I am in the middle of quite a few other changes and if I can't replicate an issue with the code as is from the repository you will have to wait for another release and see if we both can replicate the issue at that point.

Sorry for the inconvenience.

If you can find another way to replicate the issue let me know.

Additionally to verify the logic you can just add another case to the program:

'
    case ConsoleKey.W:
                                    {
                                        foreach (var tc in client.Client.GetTransportContexts())
                                        {
                                            if(tc.RtpSocket != null) Console.WriteLine("RtpReceiveBufferSize" + tc.RtpSocket.ReceiveBufferSize);
                                            if(tc.RtcpSocket != null) Console.WriteLine("RtcpReceiveBufferSize" + tc.RtcpSocket.ReceiveBufferSize);
                                        }

                                        break;
                                    }
'

I am changing the topic from Bug to question for now.
Marked as answer by juliusfriedman on 3/22/2015 at 6:52 PM
Mar 23, 2015 at 3:37 AM
No problem. I can wait for the next release.
I commented out the first three statements in Program.Main, and added Console.WriteLine in RtpClient.ReceiveData.
        [MTAThread]
        public static void Main(string[] args)
        {
            //Run the main tests
            //foreach (Action test in LogicTests) RunTest(test);

            //Console.WriteLine("Logic Tests Complete! Press Q to Exit or any other key to perform the live tests.");

            //if (Console.ReadKey(true).Key == ConsoleKey.Q) return;

            RunTest(RtspClientTests);

            RunTest(RtspInspector);

            RunTest(TestServer);
        }
internal protected virtual int ReceiveData(Socket socket, ref EndPoint remote, out SocketError error, bool expectRtp = true, bool expectRtcp = true, MemorySegment buffer = null)
        {
            //Nothing bad happened yet.
            error = SocketError.SocketError;

            //Ensure the socket can poll
            if (IsDisposed || m_StopRequested || socket == null || m_Buffer.IsDisposed || remote == null)
            {
                return 0;
            }
            Console.WriteLine("RtpClient: ReceiveData: RemoteSocket:" + remote.ToString() + "   socket.ReceiveBufferSize:" + socket.ReceiveBufferSize);

            bool tcp = socket.ProtocolType == ProtocolType.Tcp;

            if (buffer == null) buffer = m_Buffer;

            //Cache the offset at the time of the call
            int offset = buffer.Offset, received = 0;
            .......
            .......
      }
Coordinator
Mar 23, 2015 at 3:52 PM
Hmm, Weird.

I am not really sure how we can have such different results. I am running .Net 4.5.2 which I assume you are also.

Obviously something changed in the code I am using vs what you are using, it's probably related to work I was doing though and not your fault as that's the only thing that makes sense.

I will see about getting a release out today to try to try and help you but it seems like you were able to work around the issue anyway, if not let me know and I will see if I can try to patch together something which I am certain does not have this issue and I will release it but please remember that since I can't replicate it anyway I am kind of shooting in the dark.
Marked as answer by juliusfriedman on 3/23/2015 at 8:52 AM
Coordinator
Mar 23, 2015 at 11:44 PM
Edited Mar 23, 2015 at 11:44 PM
111202 is verified to not have this bug although I couldn't replicate it anyway :).

I have also verified that all streams are working as expected while being re-streamed.

Please let me know if you find anything different of if your issue is not resolved.
Marked as answer by juliusfriedman on 3/23/2015 at 4:44 PM
Mar 24, 2015 at 12:54 AM
I was away from my office today.
I'll try 111202 this evening.
If we can't figure it out then maybe we're living in alternate universes :--)

Right, it's not holding my project up at this point so we have plenty of time.
Coordinator
Mar 24, 2015 at 1:22 AM
Heh, as soon as your able to confirm or deny exactly what universe your in let me know and I will double check mine, by that time we may shifted alternated planes again :P

In any case I am confident you shouldn't have any such issue with the latest code as I have verified all unit tests and performed some re-streaming tests to ensure I was on the same page.

If you do it would be fairly surprising to myself but interesting to troubleshoot especially from an alternate universe :)

Take care!
Marked as answer by juliusfriedman on 3/23/2015 at 6:22 PM
Mar 24, 2015 at 4:40 AM
Good news. With 111202 no more dropped RTP packets with either V or AV. Solid video on my iOS client for both cases.
Coordinator
Mar 24, 2015 at 5:02 AM
Well yes I suppose but I was hoping to get some [more] inter-universal debugging experience :P

In all honesty and seriousness the code is slightly messy right now, I only have two eyes and it's hard to keep the methods updated while I am in the middle of working on Unit Tests, API changes and additions / reductions to the classes.

As you may or may not notice I am in the process of revamping quite a few things, any feedback you have on the API could be extremely helpful in my next iterations.

Please see the Issue Tracker for further information on specifics of what I plan on changing but the changes will be for the better I believe, and while they may add a middle layer of complexity it will be for the best in the end.

Feedback on classes in the Concepts solution is also taken, especially on the classes which are needed first such as the MediaConnection class and SocketConfiguration but not limited to by any means.

Binary could also use feedback to determine what people understand and don't as well as on method naming and conventions used.

Any UnitTests you can contribute, weather they are successful right now or not will help me determine how people are using the classes and other API's and what they expect to occur when they call certain things.

The more the better especially if they are in VB or other .Net language, I have plans for at least VB tests but I am thinking about DLR examples as well and just maybe F#.

Other areas which need enhancements are the RtspInspector and ContainerInspector, if you use WPF let me know, I need to have separate WPF and WinForms examples and I just haven't got around to re-making RtspInspector in WPF.

It may seem like work for nothing but the main purpose will be so that when my API is re-factored the UnitTests will also then be re-factored along with them.

Glad I was able to solve the issues you were experiencing and I hope that you can continue to at least test the new releases if nothing else.

Thanks!
Marked as answer by juliusfriedman on 3/25/2015 at 1:29 PM
Mar 24, 2015 at 5:59 PM
It's certainly tempting to jump in and participate in the areas you mention, but reality at this time is that I can only continue at my current level. I am considering using the Rtsp Server which would pull me back in as questions arise. Meanwhile, I'm focused on the RTSPClient and still have at least one more issue which I will post later today.

Keep up the good work! It's a pleasure working with you.