I have a wowza server receiving RMTP video and sending RTMP video, this works flawless.
Now I need to add ssl suport, so I configured the streamlock and is working well receiving RTMPS from ffmpeg as encoder and sending RTMPS to users with flowplayer.
But I need to make it works with VidiU Encoder, and this device do not support RTMPS protocol, it only works sending video using RTMP.
Then I tried to send RTMP video (using VidiU) to the sever (with streamlock enabled) to send RTMPS video to users, but it don't work for me, I don't know which configuration is needed in wowza to do this. any hints?
I solved.
On the menu: Wowza> Server >Virtual Host Setup for Streamlock configuration I have 2 host ports:
I added a third Host Port with the following configuration:
Type: streaming
IP: *
Port: 1934
SSL/StreamLock Enabled: false
Yes I used port 1934 instead of 1935 because this is used for the RTMPS protocol.
This way on the encoder side, the RTMP address must go to the 1934 port (rtmp://[server_ip]:1934/streamapp/ ).
With this configuration, the incoming stream is an RTMP stream to the port 1934 and the outcoming stream will be an RTMPS stream.
Now my configuration looks like this:
Related
I've developed an app which sends RTP packets to a local ip client. So the client has to listen on the specified port (rtp://:#portnumber, on VLC) to play the streamed data. Right now i'm going to develop the code needed to create the SDP file needed to start streaming.
My doubt is, how to send this file to the client? At the beginning of the RTP stream?
Really n00b at this point. Any help will be useful.
Thanks
VLC specifically supports RTSP, HTTP, SAP protocols for establishing session and communication. And of course the local file system (file://)
so basically you can call vlc in some manner like this (I cannot test it but should be like this):
vlc file://path/to/sdp-file
or
vlc rtsp://server-path:port/sdpfile.sdp
and so on
Aside from storing the SDP file in the local system, perhaps HTTP would be easiest if you have up and running http server on your server machine.
I would like to develop a very tiny and small RTSP client to get the video stream from network cameras. Does anybody know where can I find a simple explanation of the protocol and some good examples?
Best regards,
You connect to the camera via RTSP protocol to query its capabilities, identify streams and prepare/start transmission.
RFC 2326 - Real Time Streaming Protocol (RTSP)
As a part of initialization and handshaking, you will discover available streams.
RFC 4566 - SDP Session Description Protocol
Then you will set up RTP session(s) to receive data, over UDP or sharing the same TCP connection.
RFC 3550 - RTP A Transport Protocol for Real-Time Applications
RFC 4571 - Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Trans
To decode media streams you will convert the payload into pure data you need for further processing. With IP cameras your primary interest is perhaps MPEG-4 AVC (H.264):
RFC 3984 - RTP Payload Format for H.264 Video
RFC 6184 - RTP Payload Format for H.264 Video
This looks like some (introductory) reading.
Try GStreammer library. It is modular, wery flexible library, which can be used for streamming (both client and server). Just check the docs and pick right plugins.
GStreammer could be used in two ways: as a commandline tool or as a library in your project, depending on your requirements.
I've compiled with VS the live555 source code, and it works just fine if I try to stream locally a file
e.g.
Command Line:
live555.exe myfile.mp3
VLC Connection String
rtsp://169.254.1.231:8554/myfile.mp3
but if I try to stream it over the internet, VLC communicates with live555, but live555 won't send data to him
Command Line
live555.exe myfile.mp3
VLC Connection String
rtsp://80.223.43.123:8554/myfile.mp3
I've already forwarded the 8554 port (both tcp/udp) and tried to disable my firewall but this doesn't solve.
How is that?
To troubleshoot:
Are you streaming RTP over RTSP: have you checked the "Use RTP over RTSP (TCP)" option in VLC? You can check this in VLC under the preferences: input/codecs->Demuxers->RTP/RTSP. You can try to see if this solves the problem in which case it could be that UDP is blocked.
You speak of forwarding. Do you mean port forwarding from one machine to the RTSP server? if so-> if you are not doing RTP over RTSP, then you would also need to forward the ports for the media which is not the same as the RTSP port (554 or 8554). These ports are exchanged during the RTSP SETUP. If you do RTP over RTSP the media is interleaved over 554 or 8554 and you don't have to worry about this.
Also, another good debugging tool is the live555 openRTSP application. You can run it from the command line and specify "-t" for RTP over RTSP, which is basically what the VLC option does. You can specify "-T" for HTTP tunneling, etc and it allows you to write captured media packets to file, etc.
If the client wants to watch a stream that is on my RTSP server, it first tries to setup a stream through the UDP protocol. How can I tell it that my server only supports RTP/AVP/TCP and that it should switch transports?
I want to terminate the UDP support on my server, but all the clients first try to SETUP the session over UDP, and later they do so over TCP... and I want to switch them to TCP as soon as possible in RTSP protocol.
How can I do that?
As far as I know, there is no control at server side for transport type preference. Server should be made generic it should support RTP over UDP, RTP over TCP, RTP over RTSP and RTP over RTSP over HTTP(S). And its clients choice which transport to choose. Transport field is first sent in SETUP request
1) UDP
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057
2) TCP
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 1
Transport: RTP/AVP/TCP;unicast;client_port=3056-3057
3) RTP over RTSP and RTP over RTSP over HTTP(S)
S->C: RTSP/1.0 200 OK
CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;interleaved=0-1
As we can see "Transport type" request is sent by client side.
If you want to support TCP only server you can send "400 Bad Request" or "461 Unsupported transport" in response to SETUP request as suggested by you or another way is to send 200 OK but do not transmit any RTP packets. Client will timeout and get to know that it is behind proxy and it will send SETUP request again with RTP/AVP/TCP parameter (Not an ideal case).
To expand on the answer for android,
For Android clients, they will always attempt to establish a UDP connection first.
For both OpenCore and StageFright I can confirm that if I return "461 Unsupported Transport" from my server in response to the first SETUP request for UDP transfer, both of these clients will then IMMEDIATELY attempt to establish a TCP based connection over the RTSP port.
All other responses are detailed here: http://www.ietf.org/rfc/rfc2326.txt
OK one way is to send "400 Bad Request" as the response to the client's SETUP request... and it automatically switches to TCP protocol. This is for RealOne and QuickTime.
But I am not sure that it will work on all other players since this is a hack.
Any other ideas? =|
If you used ffmpeg, you can force switch rtsp transport layer protocol.
av_dict_set(&format_opts, "rtsp_transport", "tcp", 0);
err = avformat_open_input(&ic, is->filename, is->iformat, &format_opts);
What client connects to your server? Some clients can be triggered through the URI method in the URL. For example, you could specify rtspt://myhost/path.sdp.
If you have control over client/servers you could use the Require header on clients and Unsupported on servers to indicate that UDP isn't supported; but most clients I've seen don't use this.
You can try to pass "transport" header in a response to Describe request, and state there that your server only supports RTP/AVP/TCP transport, and the client should know that UDP is unsupported.
I am writing a RTSP client in Android. I am able to receive the Responses for all the requests
i.e.,
DESCRIBE it sends back the 200 OK
SETUP with transport: RTP/AVP:unicast:client_port=4568:4569 got the 200 OK Message back
Sent PLAY, and got the OK Message
After that how to get the audio and video frames?
I have searched on blogs, but all say to listen at client_port but I am not receiving any packets.
Please let me know am I doing correctly.
You may or may not know this, but Android has built in support for RTSP using the VideoView.
http://developer.android.com/reference/android/widget/VideoView.html
This may cut down on your development time...or it may be totally useless if you're trying to roll your own RTSP stack.
RTSP is only used to start the streaming. It gives you an SDP description of the real streams. You have to manage an RTCP connection and a RTP connection per channel (audio / video). The ports to use are the "client_port" ones.
It is pretty complex to code a RTSP/RTCP/RTP stack from scratch. You can have a look at the live555 library that implement such a stack in c++.
Put a sniffer on the network, you should see UDP packet with destination port 4568 targeted at your IP address.
With a decent sniffer, you will be able to see the rtsp dialog. Maybe you are missing something in the answers
You should also check the content of the SETUP response, to see if the port you requested were accepted.
Things to check :
Listening in UDP.
Firewall rules.
Range of the play request : Don't specify any to be sure the server will be playing something.
If you are behind a router or firewall, you probably won't receive anything, because your router / firewall don't know what to do with incoming UDP packets
Try first with a local Darwin Streaming server installed within your LAN.that way Firewall wont matter.Streaming will work.
If you want to try from external server then:
1) Check the client_ports mentioned in the SERVER response,some servers suggest different ports from the one requested.you have to use the ports suggested by server.
2) If the ports are correct, then you can send 64byte empty packets from each of the UDP ports to the server(called "door openers").
3) If the above two don't fix it, check the server side logs.The server might be closing the UDP ports.