Issues in RTSP playback - no images on vlc

Topics: Question
Feb 9, 2015 at 8:59 AM
Hi, we are trying to implement an rtsp streaming server for some ip cameras.
your project is very nice and useful, but there's an issue that i could solve myself looking through the forum or anywhere else.

we are trying to collect some ip camera rtsp streams and serve it through MMA server (as an rtsp proxy), we have some issues during the PLAY state of the rtsp conversation.

For some streams it works (original rtsp streams can be viewed with VLC flawlessly),
but randomly (or we couldn't find why) some streams originated by MMA server cannot be seen by VLC nor any other player/client with errors - freezing or no images at all.
The server and also rtsp dialog seems to be ok, also analyzed with Wireshark gives us no visible protocol errors (we suppose wireshark should detect errors as it does with other protocols).

We presume maybe it's an Encoding/decoding error? (maybe related to h264 enc?)
how can we know? the original sources streams are ok though, so we can't figure out what's happening that stops the server.

Here's what server log reports:

Request=> DESCRIBE rtsp://192.168.*****/live/protech4 RTSP/1.0
Accept: application/sdp
CSeq: 2
User-Agent: Lavf56.4.103

Session=> 06a3845f-645a-49f2-8b2e-a3948f93aff2

Response=> RTSP/1.0 200 OK
Content-Encoding: utf-8
CSeq: 2
Content-Type: application/sdp
Content-Base: rtsp://192.168.*****/live/4056e666-7090-4729-87a1-5f7db7532fae/
Content-Length: 382
Server: ASTI Media Server RTSP/1.0
Date: Wed, 04 Feb 2015 13:16:51 GMT

v=0
o=ASTI-Media-Server 15599512824060701542 15599512824060701543 IN IP4 192.168.*****
s=ASTI Streaming Session
e=NONE
c=IN IP4 192.168.*****
a=sendonly
t=0 0
m=video 0 RTP/AVP 96
b=AS:70
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e01f;packetization-mode=1;sprop-parameter-sets=Z0LgH9oBQBbE,aM4wpIA=
a=control:/live/4056e666-7090-4729-87a1-5f7db7532fae/video

Session=> 06a3845f-645a-49f2-8b2e-a3948f93aff2

Request=> SETUP rtsp://192.168.*****/live/4056e666-7090-4729-87a1-5f7db7532fae//live/4056e666-7090-4729-87a1-5f7db7532fae/video RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=13596-13597
CSeq: 3
User-Agent: Lavf56.4.103

Session=> 06a3845f-645a-49f2-8b2e-a3948f93aff2

Response=> RTSP/1.0 200 OK
Content-Encoding: utf-8
CSeq: 3
Transport: RTP/AVP;source=192.168.*****;unicast;client_port=13596-13597;server_port=30000-30001;ssrc=D35420BA
Session: -682150766;timeout=30
Server: ASTI Media Server RTSP/1.0
Date: Wed, 04 Feb 2015 13:16:51 GMT

Session=> 06a3845f-645a-49f2-8b2e-a3948f93aff2

Request=> PLAY rtsp://192.168.*****/live/4056e666-7090-4729-87a1-5f7db7532fae/ RTSP/1.0
Range: npt=0.000-
CSeq: 4
User-Agent: Lavf56.4.103
Session: -682150766

Session=> 06a3845f-645a-49f2-8b2e-a3948f93aff2

Response=> RTSP/1.0 200 OK
Content-Encoding: utf-8
CSeq: 4
Session: -682150766;timeout=30
Range: npt=now-
RTP-Info: url=rtsp://192.168.""/live/4056e666-7090-4729-87a1-5f7db7532fae/video;seq=0;rtptime=0;ssrc=D35420BA, url=rtsp://192.168.""/live/4056e666-7090-4729-87a1-5f7db7532fae/video;seq=0;rtptime=0;ssrc=D35420BA, url=rtsp://192.168."*****"/live/4056e666-7090-4729-87a1-5f7db7532fae/video;seq=0;rtptime=0;ssrc=D35420BA
Server: ASTI Media Server RTSP/1.0

Date: Wed, 04 Feb 2015 13:16:51 GMT

the mostly different things we've noticed is that in OK streams (that you can see in vlc with no problems), those parameters are different from zero: seq and rtptime , wheras here they are seq=0;rtptime=0; and also in other not working streams we've found.


hope this can help,
thanks a lot for your time and your wonderful project

hope it's ok i have created a new disussion thread, otherwise please tell me where i should post this

Thanks,

Giacomo
Coordinator
Feb 9, 2015 at 2:41 PM
Thanks for the report.

If you have a stream I can test against I wish check it out.

The other thing you can do in post a filtered wireshark capture so I can analyze it.

Thanks for the kind words and I hope to hear back soon.
Marked as answer by juliusfriedman on 2/9/2015 at 7:41 AM
Feb 9, 2015 at 3:57 PM
Here's a wireshark capture with our camera (can't provide you the stream but it's an ordinary h264 ip camera, on vlc works fine with no tweaks).
I provide you another faulted stream, which is one of the .mov streams (h264) provided with your code in the tests section.

http://we.tl/wCg7kkR5Po (wireshark cap files insed .zip)

and here's one stream we used.
rtsp://quicktime.uvm.edu:1554/waw/wdi05hs2b.mov

the first time i connect with VLC i get everything fine on RTSP side in wireshark, but then vlc times out giving a goodbye message in rtsp.
the second time and other times i connect i can see in the log the parameters seq = 0, rtptime = 0.

The fault doesn't seem to depend on any particular stream, but somehow on the decoding maybe?


Thanks for your help,
Giacomo
Feb 9, 2015 at 4:23 PM
Here's another scenario we have:
We set up VLC as a streaming server using the GUI, connecting to an h264 movie clip source.

Then we check the rtsp stream with your client example in tests: RtspInspector program,
using wireshark and the log output to have some clues:


Here's 3 wireshark captures, and descriptions below:
Trace rtsp-vlc-OK -> client vlc connects to server and outputs the stream.

Trace rtsp-vlc-malformed_Packet -> WinRtspInspector tries to connect to vlc-server but raises
                                                    => exception in RtspClient.SendDescribe 
                                                          (HResult -2147467261)

Trace rtsp-vlc-malformed_Packet_StepByStep -> WinRtspInspector tries to connect to vlc-server, while step-debugging in the DESCRIBE rtsp state,
                                                             between request and response
                                                    => no exceptions raised, the sdp message is "malformed" but still the rtsp conversation can go as far as SETUP, 
but then "freezes" and nothing new happens.

Thanks again,
Giacomo
Coordinator
Feb 9, 2015 at 4:31 PM
I will check the logs and see.

It may be relevant to the change I made for determining if rtcp is enabled during the setup.

I can't allocate time today but tomorrow or the next day I will try to verify.

In short im aware of an ambiguous issue in which the ssrc can be decimal and read as hex.

I.e. '11223344'

I will address this and any other issue I find when reviewing the capture and ask you test again.

Thanks for bringing this up and definitely keep me updated!
Marked as answer by juliusfriedman on 2/9/2015 at 9:31 AM
Coordinator
Feb 9, 2015 at 9:09 PM
Edited Feb 9, 2015 at 9:10 PM
I also probably shouldn't send 0 there as it just may not be known yet. I should use a different check there also.

I will keep you updated.

Thanks.
Feb 10, 2015 at 4:44 PM
we've also tryed another test, uncommenting your code in test.program (test experimental h264 encoding),
is it still experimental? i'm trying to see on h264 topic for some clues in forum.

there's ARGB exception raising. thanks again for your help.

here's a screenshot in vs2013!!(Image)
i've had problems with emgucv accessing rtsp streams in x64 windows machine, (32bits working fine though)
so now i'm trying with using directly your client to grab rtp frame and then decode to bitmap.
Seen some interesting discussions on forum. any advices?

thanks


Giacomo
Coordinator
Feb 10, 2015 at 11:55 PM
Try the latest release.

I have addressed where the server wouldl be sending 0 values in the RtpInfo header.

I have also changed RtspClient to not send the 'ssrc' by default which should have been why the client wouldn't get past the SETUP where it wasn't before.

The ARGB exception is because there are only functions in the utility class for the ARGB format, I have to add converters for the other pixel formats to be supported.

ABGRA2YUV420Managed is also very slow because it's not using the lookup table.

Decoding isn't that much more difficult if the frame is an IDR as it will have no reliance on previous frames but also may not contain a whole frame so only part of the data may be visible.

There are notes in the class and the process is exactly the reverse of how the encoding is performed.

If you need anything else let me know!
Marked as answer by juliusfriedman on 2/10/2015 at 4:55 PM
Feb 11, 2015 at 2:40 PM
We tried the latest release (server running, and vlc as client), but seems quite buggy. no streams can be playbacked without errors now, not even pics over tcp, nor bandit (it freezes in vlc after a few secs).
Also we get in test log: No context for channel ... and also No context for packet.. messages. Those messages are displayed continuously, over and over.
are those ok?

inspecting with wireshark we can see connection drops and a tcp error/warning (tcp reset = set, bit).

could you try with your samples videos (Alpha and bandit are ok).

Here are pictures of our tests.



thanks a lot for your support,
Giacomo
Coordinator
Feb 11, 2015 at 2:49 PM
Edited Feb 11, 2015 at 2:58 PM
If no streams can be played back then how can alpha and bandit work?

What about omega and gamma?

Vlc freezing after a few seconds under tcp is sometimes related to how rtsp is parsed, you will notice vlc still receives data in the information window.

I will check out your pictures as soon as possible.

If you could post the exact contents of the log I could elaborate further.

I would also like to see a wireshark capture from the same session as when the logs were generated if possible.

Thanks
Marked as answer by juliusfriedman on 2/11/2015 at 7:50 AM
Feb 11, 2015 at 3:57 PM
Sorry, i may have been not clear. Alpha and Bandit are not working, i meant if you could do test on just those two sources. i'm uploading captures on we-transfer and more log info. Hope this can help to sort it out,
thanks again for the great effort you're putting in this very nice project.

Link to download the pictures and captures

hope we can sort this out,
and thank you again

Giacomo
Coordinator
Feb 11, 2015 at 11:55 PM
This should be all fixed.

Let me know if you have any other issues.

Thanks!
Marked as answer by juliusfriedman on 2/11/2015 at 4:55 PM
Feb 12, 2015 at 9:03 AM
Thank you so much again!
The streaming is now working again.

How do you advise to set up the server (and particularly rtsp h264 sources) for live streaming purposes?
(there should be no delay and lost packet should not be retransmitted)

now i tryed like simply this:
server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("giacomo", "rtsp://<IP of ip-camera streaming h264>"));
Now the streams are good and the overall is much better, though we have increasing delays during runtime in Vlc.
How does server deal with packet loss?
does it retransmit them? i think the best option would be just to throw them away as otherwise it increases the delay gap,
and also is RTP over UDP transport the standard? - in wireshark i see a TCP packets alternating among RTP packets,
wheras during a "standard" rtp connection, tcp packets are very less frequent.

from wireshark (while playing rtsp stream):
2989    19.030270000    serverIP    clientIP    RTP 1518    PT=DynamicRTP-Type-96, SSRC=0x54A88E4, Seq=41856, Time=400680419
2990    19.031254000    clientIP    serverIP    TCP 60  1779→554 [ACK] Seq=838 Ack=121187 Win=66560 Len=0
2991    19.031411000    serverIP    clientIP    RTP 1518    PT=DynamicRTP-Type-96, SSRC=0x54A88E4, Seq=41857, Time=400680419
2992    19.032402000    clientIP    serverIP    TCP 60  1779→554 [ACK] Seq=838 Ack=122651 Win=66560 Len=0
2993    19.032532000    serverIP    clientIP    RTP 1518    PT=DynamicRTP-Type-96, SSRC=0x54A88E4, Seq=41858, Time=400680419
2994    19.033484000    clientIP    serverIP    TCP 60  1779→554 [ACK] Seq=838 Ack=124115 Win=66560 Len=0
Example: TCP packet - length 60 - Transmission Control Protocol, Src Port: 1779 (1779), Dst Port: 554 (554), Seq: 838, Ack: 121187, Len: 0
What is their purpose?

Could you try test your streams with vlc web plugin also?
You can find a working test page in <VideoLan installation folder>/VLC/sdk/Activex/test.html

vlc web is working fine on ip cameras with direct rtsp streams (with nearly no time lag),
but gives some problems or very high latency with your server (even more than standard vlc).



Thanks again,
hope this is useful to everybody


Giacomo
Coordinator
Feb 12, 2015 at 2:53 PM
Edited Feb 12, 2015 at 3:13 PM
gparmigiani wrote:
Thank you so much again!
The streaming is now working again.

How do you advise to set up the server (and particularly rtsp h264 sources) for live streaming purposes?
(there should be no delay and lost packet should not be retransmitted)

now i tryed like simply this:
server.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource("giacomo", "rtsp://<IP of ip-camera streaming h264>"));
Now the streams are good and the overall is much better, though we have increasing delays during runtime in Vlc.
How much delay and what mechanisms do you use to calc delay?

The server design doesn't introduce delay beyond the initial rtt of the packets received.

What type of network connection do you have and how many streams do you plan on supporting?
How does server deal with packet loss?
does it retransmit them? i think the best option would be just to throw them away as otherwise it increases the delay gap,
No it doesn't retransmit rtp by default however using the avpf profile for feedback you could if you wanted to.
The server shouldn't throw away anything though it should send it if it was received from the source.

Each client needs to deal with this depending on its own connection.

The clients session logic already discards packets which are out of sequence on the source connection or where a large gap occurs.

If you want those packets you would have to add logic to not skip them, as the source is already further along and this method reduces any gap even further.

Thats how it needs to work, especially if retransmit is required.

What gap are you referring to?
and also is RTP over UDP transport the standard? - in wireshark i see a TCP packets alternating among RTP packets,
The standard? Yes rfc3550 specified udp as the default Protocol.

udp functionality is the same as tcp overall especially in an independent connection, what exactly is the question?

Alternating how?
wheras during a "standard" rtp connection, tcp packets are very less frequent.
?.... that usually depends on many things beside just the protocol.

What do you mean standard?
from wireshark (while playing rtsp stream):
2989    19.030270000    serverIP    clientIP    RTP 1518    PT=DynamicRTP-Type-96, SSRC=0x54A88E4, Seq=41856, Time=400680419
2990    19.031254000    clientIP    serverIP    TCP 60  1779→554 [ACK] Seq=838 Ack=121187 Win=66560 Len=0
2991    19.031411000    serverIP    clientIP    RTP 1518    PT=DynamicRTP-Type-96, SSRC=0x54A88E4, Seq=41857, Time=400680419
2992    19.032402000    clientIP    serverIP    TCP 60  1779→554 [ACK] Seq=838 Ack=122651 Win=66560 Len=0
2993    19.032532000    serverIP    clientIP    RTP 1518    PT=DynamicRTP-Type-96, SSRC=0x54A88E4, Seq=41858, Time=400680419
2994    19.033484000    clientIP    serverIP    TCP 60  1779→554 [ACK] Seq=838 Ack=124115 Win=66560 Len=0
Example: TCP packet - length 60 - Transmission Control Protocol, Src Port: 1779 (1779), Dst Port: 554 (554), Seq: 838, Ack: 121187, Len: 0
What is their purpose?
What is the purpose of what?

I assume you mean the Len 0?

The server uses 0 length sends to refresh the tcp stacks state of the connection.

It resets the receive window and stops unnecessary retransmit where one cannot change the retransmit timeout at the socket level.

Basically tells the receiver to hold on sending if they are and ensures that the connection is still active for read or write.

Here is a good answer explaining the concept.

https://ask.wireshark.org/questions/11863/why-do-tcp-clients-send-packets-with-no-data

The server isn't doing anything unusual at all Especially since it only does it in response to a 0 byte receive or incomplete reception.

What do you think is wrong with that?
you try test your streams with vlc web plugin also?
You can find a working test page in <VideoLan installation folder>/VLC/sdk/Activex/test.html

vlc web is working fine on ip cameras with direct rtsp streams (with nearly no time lag),
but gives some problems or very high latency with your server (even more than standard vlc).
My server is not the issue, try buffering settings in vlc or try another player e.g. QuickTime or mplayer.

Vlc has its own issues, the same with ffmpeg.

What exactly are you trying to solve?
Thanks again,
hope this is useful to everybody


Giacomo
Marked as answer by juliusfriedman on 2/12/2015 at 7:53 AM
Feb 12, 2015 at 3:56 PM
Thank you, you are right, the server is working properly also with vlc plugin now,
i tested and the issue was transmitting with "reliable transport" can cause issues to vlc.
thank you very much for your patience

have a nice weekend,

giacomo
Marked as answer by juliusfriedman on 2/12/2015 at 12:16 PM
Coordinator
Feb 12, 2015 at 7:14 PM
Edited Feb 12, 2015 at 7:16 PM
Can you elaborate on what issue you are specifically talking about. (Either with a link to the source or an outline of the issue your experiencing with VLC)

Without trying to overload you I will give you the compressed version of the response I wanted to try and give to explain what I think the issue is but to be honest I need some more information to make sure I am talking about the same thing.

My server used to send responses with a 'Server' header which had the text 'RTSP/X.Y' where X and Y were the major and minor versions, (Google also did this for a while ...)

It was obviously determined that most libraries which receive RTSP over TCP (interleaved) are not doing it correctly and they changed their header to be more compatible even though they don't support interleaved TCP externally.

Apple's QuickTime also had other related issues but I digress.

The issue wasn't with 'RTSP' appearing in the header (at least not for my library) but with the handling of '$'

I submitted a report to libav's devel list because of how they handle data with '$' and a patch was made but im not sure who applied it as of yet, also VLC and MPlayer seem to use Live 555 by default.

The issue can be found here:

https://lists.libav.org/pipermail/libav-devel/2015-January/066305.html

In short you might want to try to 'ffplay' or a different utility because Live 555 itself is .... .... .... [intentionally left blank]

Take a look at these claims it makes:

http://www.live555.com/liveMedia/faq.html#packet-loss
It's important to understand that because a LIVE555 Streaming Media application runs as a single thread (never writing to, or reading from, sockets concurrently), if packet loss occurs, then it must be happening either (i) on the network, or (ii) in the operating system of the sender or receiver. There's nothing in our code that can be 'losing' packets.
Meanwhile, some user created a patch which SOMEHOW was accepted without really being correct.

http://stackoverflow.com/questions/18525980/rtsp-client-sending-delimited-data-before-session-has-been-completely-set-up?rq=1

E.g. if the packet is malformed or malicious then the code added will cause Live555 to go into an infinite loop and skip packets because it doesn't verify anything including that the data belongs to the Rtp Frame it thinks it does...

I tried contacting Ross a few times but he's not really cooperative, he seems to think that I need support and wants me to pay for finding bugs in his library; which it seems that he has enough help (paid, unpaid or otherwise) so I did my part there.

That's not the only issue with Live555 the (library or the server), It also has Teardown issues which are apparent with the default server implementation because of how the standard RFC2326 was interpreted by whoever wrote that implementation and as a result its not really correct especially when aggregate control of single track of a multi-track media is being played.

In short though the reason why WE all have to deal with this is not the fault of Live555, it all stems from 'GStreamer', who decided it was important to send a RTP or RTCP packet before the response to 'PLAY' (which by the way is a repeat of dumb issues which were present in SIP and there are actually options in some IP Phones which say 'Allow First RTP Packet before response' and sometimes cite a RFC..)

They advertise it as a feature because their software was already written like that and they didn't want to revise it to be correct because that would interfere with whoever was already using it....

THE IETF messed up by defining such a stupid framing character '$' (why to be cute I guess).

That character was invalid to the mask specified in the RFC and also doesn't allow any state information to be conveyed e.g.

The framing character should have used the first bit to indicate it was the framing character and the next bits should have been used to indicate if the packet was a continuation or new packet, this would have allowed for re-transmission to be handled much better since the underlying protocol TCP itself is subject to the same bit stream errors.

None the less, RTSP 2.0 keeps this mechanism (which I am trying to change) but the IETF is discussing how it would work with existing implementations.

I argue it can be subverted by making the Application Layer Framing 6 bytes (or 5) and using the old header after the first two 'new bytes'

e.g.

[(XX)YY]$CZZ

Where XX and YY are two new octets which can be used to indicate a lot of information about the underlying packet AND be backwards compatible with the older implementations.

Anyway that is another topic.

As it stands now Axis and some other cameras (pretty much everyone who uses GStreamer) exhibits that issue unless they code around it, my library handles this if the SETUP response indicates the state of the RTP Context (With the Transport header) and thus it can receive the packet (even if the packet is invalid or malformed) without missing any data. (Also due to how I handle interleaved processing)

No other library I am aware of does this in such a way.

VLC will freeze, ffplay used to freeze, QuickTime would freeze and I can't remember if Real One also had issues with the response but I think it didn't freeze in the version I tried.

Anyway in short, even great little utilities like

http://bisqwit.iki.fi/source/ms-rtsp-dump/

Don't work correctly when TCP Re-transmissions occur (especially if '$' is present)

As far as I know I have one of the only correct Rtsp implementations (correct by logic not necessarily be design) and as a result more lesser known clients player as Blackberry or Nokia can actually play from my server where they will NOT play from others.

I am going to be working on the design more to make it 'more correct' but that isn't really an issue at the current time unless you want to use RTSP with MPEG Transport Streams.

Hopefully I didn't confuse you more.

If you have any further questions or need any further clarification please let me know!

And thank you for testing!
Marked as answer by juliusfriedman on 2/12/2015 at 12:16 PM
Feb 13, 2015 at 11:29 AM
Edited Feb 13, 2015 at 12:37 PM
Hey thank you so much with this response.
Actually is very useful and explains why we get issues with VLC and some axis cameras.
But i just wanted to show you another thing we've noticed. how does the server deal with audio-video streams?
meaning data packets shouldn't be sent over different ports, one __for each track __(audio track and video track)?
in the DESCRIBE request the server exposes how many "tracks" he has,
and then in the SETUP request should'n we open 2 ports for (say) track1 (video) and another couple for track 2 (audio) ?


i just noticed that (for example : ) vlc sends them on distinct ports.
shouldn't the client open 2 different channels for audio and video?

otherwise how can the client determine which packet belongs to audio and which to video?

This is the part assigning the port in RtspClient class if i'm correct. (also i tryed openPort = 0, but gives me socket exceptions).
else if (string.Compare(mediaDescription.MediaProtocol, RtpClient.RtpAvpProfileIdentifier, true) == 0) // We need to find an open Udp Port
                    {
                        //Revise
                        //Is probably Ip, set to Udp
                        m_RtpProtocol = ProtocolType.Udp;

                        //Could send 0 to have server pick port?                        
                        int openPort = Utility.FindOpenPort(ProtocolType.Udp, 10000, true); //Should allow this to be given or set as a property MinimumUdpPort, MaximumUdpPort

                        rtpTemp = Utility.ReservePort(SocketType.Dgram, ProtocolType.Udp, ((IPEndPoint)m_RtspSocket.LocalEndPoint).Address, clientRtpPort = openPort);
                        
                        if(needsRtcp) rtcpTemp = Utility.ReservePort(SocketType.Dgram, ProtocolType.Udp, ((IPEndPoint)m_RtspSocket.LocalEndPoint).Address, (clientRtcpPort = openPort + 1));

                        if (openPort == -1) Common.ExceptionExtensions.RaiseTaggedException(this, "Could not find open Udp Port");
                        //else if (MaximumUdp.HasValue && openPort > MaximumUdp)
                        //{
                        //    Common.ExceptionExtensions.CreateAndRaiseException(this, "Found Udp Port > MaximumUdp. Found: " + openPort);
                        //}    

                        //WMS Server will complain if there is a RTCP port and no RTCP is allowed.

                        setup.SetHeader(RtspHeaders.Transport, RtspHeaders.TransportHeader(RtpClient.RtpAvpProfileIdentifier + "/UDP", localSsrc != 0 ? localSsrc : (int?)null, null, openPort, (needsRtcp ? (int?)(openPort + 1) : null), null, null, true, false, null, false, 0, 0, RtspMethod.PLAY.ToString()));
                    }
                    else throw new NotSupportedException("The required Transport is not yet supported.");
Also, knowing it's not correct but for making it work, would be nice to have a parameter to be able to handle "non conform" RTSP servers, meaning servers which do not reply correctly to the SETUP request (as vlc does if you use vlc for streaming in rtsp other sources).

MinimumUdpPort, MaximumUdpPort may come in handy in this case? i see they're not implemented actually.

Thank you again!

[EDIT]------------------------------
i've just noticed that the rtspClient opens 2 connections when the server behaves correctly, so this is just another case of server not behaving "right", as in the SETUP response doesn't retransmit client ports. Every time this happens, your client doesn't manage to connect to server apparently.

but i also notice most server don't behave right. so should the library be more "flexible" for real implementations?

when what descrived above happens server rises those two esceptions, which are handled by your code and not rethrown (just written in stdout):
A first chance exception of type 'System.InvalidOperationException' occurred in Media.Rtsp.dll
A first chance exception of type 'System.InvalidOperationException' occurred in Media.Rtsp.dll
We have verified that when using a compliant server (which retransmits the client ports in the SETUP response), the rtsp dialogue goes on fine.


Thanks
Coordinator
Feb 13, 2015 at 12:05 PM
Edited Feb 13, 2015 at 12:33 PM
Just to be clear there is no issue with receiving the packets in my library as the logic I have allows for it.

The link you cited was interesting but invalid, I will explain.

If the ip of the client changes a new setup is required anyway And the server handles this already.

E. G. You technically could take anyone's session for which you know the session Id and setup or teardown their existing session.

And what do you mean different ports?

No its not required to use different ports.

One reason is because you could multiplex rtp and rtcp on the same port.

I use the payload type first and then the ssrc to obtain a context.

Minimum and maximum are useful but your os and firewall really control this anyway.

its usefulness is limited but I will enable that feature if you show me a use case. And how you would recover from the exception both when the range is full and when the range is empty.

E.g. What exception do you want and how should the client handle enforcement of this.

One thing I should add though is the ability to detect mixing of rtp and rtcp from the media description to determine if rtcp is needed also. This would allow the mixing to be requested by the client even if the sdp didn't specify it.

No problem at all and please do let me know if anything comes up.
Marked as answer by juliusfriedman on 2/13/2015 at 5:05 AM
Feb 13, 2015 at 1:46 PM
Thank you.
Yes adding more useful details on those exception would help,
as describing how and why the server can't add that particular rtsp source.

Maybe the server after this warning could automatically disconnect from the sources?
(because the server does connect to them but actually is unable to stream from them),
or otherwise try to modify source parameters to get a working stream and then evenctually disconnect after a timeout?
how can we ensure the server "adds" these external "unperfect" rtsp sources (ex VLC server as source, which do not retransmit the client_ports in the SETUP response) correctly?

the RtspClient we are using is just "wrapped" inside the server method
VLC rtsp stream --> server.TryAddMedia(New RtspSource("sourcename", <VLC rtsp stream>, sourcetype[optional]))
is there a way to make the server "guess" the sourceType from the DESCRIBE response? (maybe it already does)

Also i have some errors now when using the method server.Stop(), (which i hadn't on previous releases) have you tryed?
here's my code handling a "stop" button (it's in VB.net):
Private Sub btnStop_Click(sender As Object, e As EventArgs) Handles btnStop.Click
        For Each m As IMedia In server.MediaStreams
            If m.State = SourceMedia.StreamState.Started AndAlso server.IsRunning Then m.Stop()
        Next
        server.Stop()
        While (server.IsRunning)
            Thread.Sleep(100) <-- FREEZES HERE (never gets server.IsRunning=false after server.Stop()?)
        End While
        MessageBox.Show("Server stopped.")
    End Sub
Thanks again for everything

Giacomo
Coordinator
Feb 13, 2015 at 1:54 PM
If you can show me a Wireshark capture or a quick copy paste to highlight what you mean I would appreciate it.

As far as I know there is no issue with VLC as a source for the RtspServer or client. I would need the above to help you.

E.g. just show me the SETUP request I send and what you think I should send.

Also show me what VLC sends on its own to the same source if possible so I can compare.


About the IsRunning, I have a line which needs to be changed there but I will fix that in the next release.

Let me know about the SETUP so I can resolve that also.

Thanks!
Marked as answer by juliusfriedman on 2/13/2015 at 6:54 AM
Feb 13, 2015 at 2:43 PM
Ok here are two captures of VLC and MMA both trying to connect to WOWZA MOBILE BUNNY and to VLC_server (vlc as a streaming rtsp source)

Wireshark Captures Here

ANOTHER ISSUE:
i have to report this exception also when using two istances of MMA on two separate machines for testing (before we were using VLC as server on one machine, and MMA on the other).
A first chance exception of type 'Media.Common.TaggedException`1' occurred in Media.Common.dll
my setup is the one described here:

one MMA server (one machine1) collects 1 rtsp source from ip camera and starts with a series of new published streams as rtsp::/machine1IP/live/cam1, 2.., 10.
(those streams serves as virtual rtsp camera streams for another listening machine, described hereafter).

a second MMA istance is running on another machine (machine2), collecting one or more published rtsp streams from MMA server on machine 1,
and adding them as its own sources. --> at this point the system raises the above exception, and the MMA on machine 2 freezes.

the last step would be to open VLC and check the published rtsp streams from machine2.
Coordinator
Feb 13, 2015 at 3:03 PM
Edited Feb 13, 2015 at 3:04 PM
What exactly are you trying to show me in the issues?

It seems in the MMA to VLCServer capture that your server is running slow.

It didn't respond over UDP in a timely fashion and TCP SETUP was attempted.

The time it waits in given by half the session timeout - the connection time - the maximum receive interval (or 1 millisecond)

So your waiting around 30 seconds if the session timeout is 60....

Why the client sends a TEARDOWN sooner than that is a bug...

Could you put a break on

if (AllowAlternateTransport) m_ProtocolSwitchTimer = new System.Threading.Timer(new TimerCallback(SwitchProtocols), null, halfSessionTimeWithConnection.Subtract(m_RtpClient.GetTransportContexts().Max(tc => tc.ReceiveInterval)), Utility.InfiniteTimeSpan);

And check what the value would be?

Also check what the MediaEndTime of each m_RtpClient.GetTransportContexts() is.

It should be equal to Utility.InfiniteTimeSpan in this case (for the VLC example).

Also where do you get that exception, I need a stack trace to make it better :) Just the fact it happened tells me nothing, I can make any class have just about any exception I want, its the stack trace that counts...

You have to provide some code so I can understand what your attempting to do...

Why do you need a 2nd server?

It Freezes? I guess you mean after the exception...

Also post the stack trace, I need to see how any why so I can address it.

I just checked Big Buck Bunny and everything is fine? What issue are you trying to show me there? The same with MMA to Wowza.. I don't have that issue and I can't replicate it.

Make sure your using the latest code.

I will make another release shortly if required to make sure we are on the same page.

Also first chance exceptions are not really bad, the server probably froze because the debugger was in ring and never released control back to the caller.

I need a stack trace to debug that any further, I am almost 100% sure it was NOT related to anything with using the server from another server.

I am seeing that the client sends a teardown but I am not sure why, e.g. you could have had the process blocked or something else... I need to find out why the teardown was occuring.

You can put a break point on the method itself and check the call stack which will tell you where it came from.

let me know so I can address your issues if possible.
Marked as answer by juliusfriedman on 2/13/2015 at 8:03 AM
Coordinator
Feb 13, 2015 at 4:34 PM
Edited Feb 13, 2015 at 4:34 PM
In short,
Looking at the logs you sent and trying to also understand your post I think you might have an issue with the VLC Server not sending media in a timely fashion.

I cam to this conclusion by looking at the captures.

In the capture vlc_to_vlcServer you can see VLC does exactly the same thing as my client, (which is send a TEARDOWN) although it happens slightly longer then with my client.

My client responds to this by trying to SETUP an Alternate Transport.

VLC it seems doesn't and you can stop my client from doing that with the AllowAlternateTrasnport property.

The other thing I notice is that VLC is not sending the correct profile indication in the Transport header.

You can verify this in the 'vlc_to_wowza' capture and compare it to 'MMA_to_wowza'

'RTP/AVP/UDP' is what I use

And that is the RTSP Transport Profile for UDP RTP indication (datum) specified @ http://www.ietf.org/rfc/rfc2326.txt

Not 'RTP/AVP'.

Although it is technically the same things in certain (most) cases and is used in Media Descriptions even when the Transport of the stream being setup MAY be Interleaved, Muxed or use an otherwise specified Transport such as 'Independent TCP'.

Anyway, the reason why your not seeing any packets is because my client attempted to SETUP UDP Transport again.

VLC Gets the packets because it did setup the TCP transport.

Why the RtspClient tried to setup UDP transport again I am not sure.

I cannot replicate this.

If you can create a unit test to prove this out I will address it, you can use the same source "Wowza / Big Buck Bunny" and then in the test I should be able to see how you configured the client which caused it to setup UDP twice.

If you need the RtspClient to think it's not receiving packets you can call ResetState in the test on each TransportContext of the RtspClient's.Client property. (RtpClient)

Then when SwitchProtocols is called the 'contextsWithoutFlow' will be forced to populate.

I have tried my best and I cannot replicate this.

I will be making another release today at some point which will support rtcp-mux better, you can check back later today to see if that helps you.

Keep me updated on anything else!

Sincerely,
Julius
Marked as answer by juliusfriedman on 2/13/2015 at 12:07 PM
Coordinator
Feb 13, 2015 at 7:07 PM
I released 110942.

If you can please let me know what your issues are now I can try to help you.

Please try to be concise as possible.

Thanks!
Marked as answer by juliusfriedman on 2/13/2015 at 12:07 PM
Coordinator
Feb 14, 2015 at 3:58 AM
I released 110949.

I tried to handle the Minimum and Maximum Ports but you didn't get back to me..

Please get back to me so I can understand your use case and additionally any existing issues which need to be addressed.

Thanks!
Marked as answer by juliusfriedman on 2/13/2015 at 8:58 PM
Feb 17, 2015 at 7:13 AM
Hello! sorry but i was away from my computer this weekend,
we will surely let you know and have feedback within tomorrow.
Thanks!

Giacomo
Coordinator
Feb 17, 2015 at 7:21 AM
https://net7mma.codeplex.com/SourceControl/latest

Make sure you have the latest version and check into the comments and issues before reporting!

Thanks!
Marked as answer by juliusfriedman on 2/17/2015 at 12:21 AM
Feb 17, 2015 at 12:37 PM
i tryed this test (added this within your main in unitTest program).
could you help me out on how to make this work?
here i used wowza bunny but anything is fine if i can get it working.

Thanks

        /// <summary>
        /// Tests the Media.RtspServer by creating a server, loading/exposing various streams from one source (ex. here 3 streams), 
        /// and connecting another MMA server to restream again. server1 acts as a fake "source", while server2 acts as the end server.
        /// purpose: arbitrary rtspSource (src1) --> server1 (many copies of src1) --> server2 (one restream for each copy to the "public")--> Clients (Vlc, FFMPEG, MMA, or others)
        /// </summary>
        static void TestMMA_server_client()
        {
            //"fake" source restreamer server at port 8554
            using (Media.Rtsp.RtspServer server1 = new Media.Rtsp.RtspServer(System.Net.IPAddress.Any, 8554)
            {
                //new Media.Rtsp.Server.RtspServerDebuggingLogger() 
                Logger = new Media.Rtsp.Server.RtspServerConsoleLogger()
            })
            {

                //let's add some sources to the media server (call it cam1, cam2, cam3, etc...)
                for (int i = 0; i < 3; i++ )
                {
                    server1.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource(String.Format("cam{0}",i+1), "rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov"));
                }

                //Start the "fake" Sources streamer (server1)
                server1.Start();

                //Wait for the server to start.
                while (!server1.IsRunning) System.Threading.Thread.Sleep(0);
                Console.WriteLine("server1 (sources) started");

                    //Setup a Media.RtspServer on port 554 - end server.
                    using (Media.Rtsp.RtspServer server2 = new Media.Rtsp.RtspServer(System.Net.IPAddress.Any, 554)
                    {
                        //new Media.Rtsp.Server.RtspServerDebuggingLogger() 
                        Logger = new Media.Rtsp.Server.RtspServerConsoleLogger()
                    })
                    {

                        //let's add sources for server2 (streamed from server1) (call it out1, out2, out3, etc...)
                        for (int i = 0; i < 3; i++)
                        {
                            server2.TryAddMedia(new Media.Rtsp.Server.MediaTypes.RtspSource(String.Format("out{0}", i + 1), String.Format("rtsp://127.0.0.1:8554/live/cam{0}",i+1)));
                        }

                        //Start the "fake" Sources streamer (server1)
                        server2.Start();

                        //Wait for the server to start.
                        while (!server2.IsRunning) System.Threading.Thread.Sleep(0);

                        Console.WriteLine("server2 (end) started");

                        //If you add more streams they will be started once the server is started

                        Console.WriteLine("Listening on: " + server2.LocalEndPoint);

                        Console.WriteLine("Waiting for input...");
                        Console.WriteLine("Press 'Q' to exit");

                        //While Running.... press Q to exit
                        while (true)
                        {
                            ConsoleKeyInfo keyInfo = Console.ReadKey(true);
                            if (keyInfo.Key == ConsoleKey.Q) break;
                        }

                        server2.DisableHttpTransport();
                        server1.DisableHttpTransport();
                        
                         server2.DisableUnreliableTransport();
                        server1.DisableUnreliableTransport();
                       
                        Console.WriteLine("Server Streamed : " + server1.TotalStreamedBytes);

                        Console.WriteLine("Rtsp Sent : " + server1.TotalRtspBytesSent);

                        Console.WriteLine("Rtsp Recieved : " + server1.TotalRtspBytesRecieved);

                        Console.WriteLine("Stopping Server");

                        server2.Stop();
                        server1.Stop();
                        

                        Console.WriteLine("Server Stopped");
                
                }

            }
        }
Coordinator
Feb 17, 2015 at 4:36 PM
Edited Feb 17, 2015 at 4:38 PM
I don't agree with this particular design concept especially in the same process as there is no point.

You can do the same thing using just the RtspSource if you needed.

None the less I will help you, what is the issue your having exactly so I can try to replicate and resolve it?

E.g when I run your test what are the expectations and actual results?

Let me know and I'll resolve any issues with my library possible.

I also don't completely support http tunnels yet so you're code there is very relevant in that case, please ensure that your outlining what your doing so I can respond intelligently.

Thanks
Marked as answer by juliusfriedman on 2/17/2015 at 9:36 AM
Feb 18, 2015 at 4:28 PM
the purpose is to emulate two machines, just within one, and to have avaiable N sources to do a stress-test of the server, thus also to test server-client dialogues.
you could use two machines and re-stream MMA content from another MMA istance i guess, but i think it's inconvenient (we tried that also).
We also tryied to create N similar RtspSources from the same original source, with the same connection-url and different name of course,
but this approach has it's limits and showed inconvenience.
Also we must be able to check that a client from another machine would be enabled to restream that rtsp source over again.

If you have other ideas please let me know,

thank you so much.

Giacomo
Coordinator
Feb 19, 2015 at 1:15 AM
We have come quite a long way from your initial question.

You started out asking about encoding and decoding errors and I tried to explain the issues with the Rtsp parser in the other libraries specifically live and libav/ffmpeg.

You then had questions about the streaming working from the server but didn't indicate what your issues were exactly or what you wanted me to do about it, instead you were asking for explanations about TCP segments.

You need to indicate what your problems are exactly and as succinctly as possible otherwise I am afraid I will not be able to help further.

When you say something doesn't work I need to understand EXACTLY how you have the 'architecture' setup otherwise I will not really be able to answer your questions completely.

I am not an engrish professor but I will give you an example of how I would ask:

'Dear sir, I am using your 'wonderful' library to attempt to achieve communication under the following provisions:

(Camera Source RTSP/IP/TCP -> Gateway1 -> Internet -> Gateway2 -> Router->(Destination Protocol) -> Lan -> RTSP/IP/X ->Server)

Gateway/Modem 1 MSS = A, MTU = B,
Camera MSS = X, MTU = Y.
Gateway/Modem 2 MSS = C, MTU = D,
Server MSS = W, MTU = Z.

The issue I face is as follows:

1) When I use the following code:

[The issue would be explained here]

Due to the fact language, terminology often result in miscommunication:

a) I have the following traffic generated (attachment with filtered Wireshark data from the specific end points in question)

b) I also have the following logs generated (attachment with complete log entries from the server)

If you would be so kind to review both attachments a), and b) when time permits and assist me to determine where my problem lies with the issue given in 1) is I would appreciate it.

This issue is not very critical however if you plan on taking more than a few days to respond please just let me know you have received my email and it did not find it's way to your spam folder.

Sincerely,
[--Name--]
'


Now that we have that out the way.

You still never told me what your issues was with VLC?

You keep giving me partial information saying that you tried to setup VLC as a server and had issues but you didn't say with what library or where the issue was or what the issue was. (why you need VLC and my SERVER together is another question but if you were comparing performance or stress testing... understood)

I understand people might not be as attached to this library as I am especially when reporting features so I can understand you went away for a few days and you didn't get back to me but then how am I supposed to know if your issues is resolved or not?

You then gave me some additional information, a 'unit 'test' and you asked me how to make it work.

You didn't tell me what you were trying to do or how you were trying to achieve it.

Your code is incomplete (to me) as it doesn't show how or why you were calling certain methods, only that you copied and pasted my code in my 'Tests' solution into another place and had certain 'expectations' that were not met but you didn't tell me what they were or how to fulfill them.

You also go on to say you tried this and you tried that but it didn't work, well why didn't it work?

What's inconvenient about what, using a single url I am confused because your reply is TERRIBLY worded.

N Similar RtspSources... from the same original source... Are you kidding me? Why you need more then ONE stream is BEYOND MY CAPACITY TO UNDERSTAND.

The server takes a single stream and then if you want a child stream, make a child, that doesn't need a separate physical connection to the original source.

Did you read my article on Rtsp and Rtp?

http://www.codeproject.com/Articles/507218/Managed-Media-Aggregation-using-Rtsp-and-Rtp

Let me get this straight, you are testing... is that is a clever guise for taking the testing code and then using it for another purpose?

Don't I already have a SubTestLoad and TestServer?

I don't charge anything for my library, lots of people use it and sell it and I don't care, I actually even take bug reports and fix them for free.

Here is a great example

http://www.camera-sdk.com/p_273-acknowledgements-onvif.html

None the less, what I am trying to say is I will help you too but I need the proper information otherwise I cannot help you to achieve anything.

My server works with any server I know of, the same for the client. It works with itself also.

The unit testing application I have setup only are that, unit tests.

None of the code in the project shows any type of 'Application' level class aspects what-so-ever, but then again I can imagine that your the kind of develop who just uses a TcpClient without making a wrapper class for your application logic e.g.

MyTcpClient : TcpClient{} or MyTcpClient{TcpClient m_TcpClient}

You don't have to I suppose but again I am not your manager or your supervisor, I am just trying to help you achieve whatever it is your are trying to do and also determine how I can actually help you.

Here is one possible configuration on how you can setup your architecture:

Camera Network <-> Router <-> Switch <-> (Camera A, Camera B, Camera C)
| Isolation/VLAN |^<->Serial Bridge <-> (Camera D, Camera E, Camera F)
+---------------------+
^ <-> Gateway |
-----------------------+
|Internet |
-----------------------+
WAN -> Gateway -> LAN
------------------------+
| ServerA | ServerB |
+----------------------+

Server A is the Dedicated Streaming Server.

It takes ONLY the resources of the streams from the 'Camera Network' and provides them ONLY to another point.

Server B is the next and ONLY point for media obtained from Server A

Server B can consume the streams from Server A but not from the Camera Network

You can then do whatever you want from Server B without interrupting server A, including but not limited to running decoders against the streams from 'Server A'.

You can expand on this further by having a Server C, D E and F which then take appropriate roles in the network for (but not limited to)

1) Routing
2) Encoding
3) Decoding
4) Thumbnail / Recording

Etc, so on and so forth until your heart, network and client are content.

Let me make this clear, this my last response in this topic and I will ignore future requests if you do not comply both with the format of the questions and the conciseness required.

It is not my job to try to understand you or even help you for that matter, I am doing it just because I have that much confidence in both my ability and my solutions and am rewarded in the help and support I provide.

In the future, please do not make questions and post pictures which don't do anything but confuse others and try to lower the quality of the environment of the library.

The devil is always in the details.

I would ask that before you proceed that you either delete or edit you previous questions to reformulate them so I can understand them.

I would also ask that you answer my questions so that I can help you as you expect otherwise there is no further point in communicating.

Sincerely,
Julius
Marked as answer by gparmigiani on 2/19/2015 at 4:40 AM
Coordinator
Mar 9, 2015 at 2:39 AM
Hello, I have not heard from you in some time.

I will assume that whatever issues you were having have since been resolved.

Please advise if you require further assistance or not so I can remove this thread.

Sincerely,
Julius
Marked as answer by juliusfriedman on 3/8/2015 at 7:39 PM