As the title suggests, I'd like to re-stream an existing live stream (h264) to multiple clients over RTSP, from an IP camera. What is the best way to go about this? I have tried to do this using VLC, though so far, it hasn't worked.
Method:
- Media->Stream->Network
- Added ip camera stream url (rtsp://ip-address/xxxxx)
- next
- new destination -> RTSP (display locally)
- add - set port 8181 - set path /stream
- next
- disable transcoding
Have I made an obvious mistake here?
Thanks!
Try using RTP or UDP and I would suggest to to try this via command line. Also, since you want to reach multiple clients, a multicast could prove useful.
I don't know which platform you are using. Here is a working command running on a Mac environment. You should be able to port this command to other platforms easily.
vlc -vvv $YOUR_INPUT_VIDEO_RTSP_URL --sout='#transcode{vcodec=h264,vb=768,fps=25.0,width=1920,height=1080,scale=1,acodec=aac,ab=128,samplerate=32000}:standard{access=udp,mux=ts,dst=239.0.0.1}'
To view the stream you need to access the multicast address such as in:
vlc -vvv udp://#239.0.0.1
There are plenty of tutorials out there. Take a look at this post explaining a bigger toolchain, however, it includes restreaming an RTSP IP camera stream. Also, read up on the Streaming How to guide over at VLC's wiki.
Hope this gets you going.
Related
I'm trying to figure out the communication between an iOS app, and an online server. To my knowledge, a REST service is used.
With a tricky setup with two macs, an ethernet hub and an iPhone, I manage to capture the traffic between the device and the server.
So far so good. However, when I fire up the app, a trace is shown in Wireshark (also very good), but all that is listed is in TCP protocol, where I am expecting HTTP protocol.
Now, I'm running out of knowledge.
Does this mean, that there is no HTTP communication going on at all, or am I seeing raw TCP packages that need to be assembled into HTTP? If the latter, how do I approach that, and will I ever see readable xml?
Thanks for your insights!
Actually, this question became obsolete, since I found exactly what I wanted to do here:
http://nickfishman.com/post/50557873036/reverse-engineering-native-apps-by-intercepting-network
Since I'm not happy with the functionality of an iPhone App that operates my Actioncam, I would like to write an app that improves on that functionality.
In order to do that, by lack of proper documentation, I need to reverse engineer the communication between the App and the Device.
What I know, is that the Device only responds on ports 21, 554 and 15740.
I managed to create a setup including an iPhone, the Device and two Macs, and traffic analyzing software called Charles (but likely I could also use Wireshark), that shows me all HTTP(S) traffic.
This is where my knowledge ends. What I hoped to see, was that Charles would report something like
rtsp://[my device ip, which is known to me]:554/[unknown to me path]
Potentially it would even involve a login and password in that URL.
Could any of you give me a hint on how to proceed? Aforementioned software seems to be limited to HTTP traffic.
What excatly do you want to reverse engineer? The video feed or control logic? From what you mentioned it seems that 21 could be used for FTP, 554 for RTSP and 15740 for some custom TCP protocol. If you have no idea about the format of the data that is sent over to the port 15740 it will be quite hard to reverse engineer (except if it is some kind of plain text ascii protocol).
For the video feed - I'd suggest setting up Wireshark to monitor the port 554 and then you should be able to see the url of the video location from the DESCRIBE command.
I'm currently playing around with WebRTC on Chrome behind a company firewall, using Google's demo app at: https://apprtc.appspot.com. Is there any sure-fire way to determine whether the connection being made to another app user outside my company firewall is via UDP or streaming TCP through Google's STUN/TURN server? chrome://webrtc-internals provides a lot of stats, but nothing obvious to me. Or is there an API call I can make during the session to determine the transport type? Thanks
=========== UPDATE ==============
FYI, this provides more information - press 'i' when using the demo app will show if using a TURN server (but not if using tcp/udp).
Wireshark will work fine for that. On Firefox, you can go to about:webrtc, click on the peerconnection, and see which candidates from ICE were selected (and if they're TCP or UDP, etc).
[edit - added]
Programmatically, you can look at the type of candidates using statistics reports, such as in this example and this PR and using the type property. You may have to parse the SDP to get the priority from the Candidates in Firefox. (thanks to Fippo for pointing this out).
Is it possible to recreate the media file from the captured wireshark logs. Is there any doc which explains how this needs to be done.
I am doing RTSP based streaming from my darwin test server. So I want to compare the Quality of the original and the streamed file.
I'm not familar with Darwin Streaming Servers but generally RTSP is only for establishing the RTP stream. The direction of RTP packets is normally in one direction (ignoring the ACK-packages for TCP).
For comparing the files I would use a tool suggested by all other users.
But to answer your question for wireshark:
filter you stream for the destination ip by using 'ip.addr eq '
look for your RTP or UDP packages from the RTSP-server
in case you see UDP-packages: right click on the package->'Decode As' and choose 'RTP' in Transport tab
choose from context menu 'follow UDP stream'
now you have the whole RTP-stream without RTP headers.
But keep in mind that in H.264 you have packetization which gives you extra bytes in the displayed stream. You cannot compare this with the original file!!
Look here in chapter 5.4. for further description.
Better use the tools mentioned by the others!
I don't think it is possible the way you hope, as RTSP is a sort of conversation between a client and a server (or servers). To recreate the RTSP session you would have to recreate all of this two-way traffic - it is not really comparable to opening a file in a video player.
I think you will find it easier to use VLC to stream the rtsp:// link and save it to a file. The stream will be transcoded while saving, so if you need a "true" comparison to the original file, you will want to use a lossless video codec for transcoding, and the output file could be very large.
Using Ostinato, You should be able to replay the file and capture using VLC.
Hi I'm trying using vlc to broadcast UDP stream within a LAN, Making it like a TV channel.
I used command line to launch VLC which then vlc is ok to run =
cvlc --repeat filename.avi --sout '#standard{access=udp,mux=ts,dst=239.255.12.42:8001}
problem is it works on some network, and I have problem receiving it on a network without router!
Question: what is some magical about the address "239.255.x.x" ? what network hardware is require for UDP broadcast besides switches and cables? Does wireless can accept UDP broadcast?
Thanks for your answers!
The 239.255.x.x addresses are part of the multicast address space, ranging from 224.0.0.0 to 239.255.255.255 (and there are some specific-use areas in there).
You've correctly noted that it doesn't work without a router. This is because the basic IP stack still wants to know how to route those addresses to determine which interface to send them on. You can either add a static route for multicast (that address or all multicast addresses), or put in a default gateway.
Read about using command line options here.
More specific answer:
standard (alias std)
Sends a stream.
Options:
access: how to send: file, udp, rtp, http.
mux: which muxer (ie, which format) will be used. It can be one of avi (for AVI format) ogg (for OGG format) ps (for MPEG2-PS format) ts (for MPEG2-TS format).
url: if you use the file access, it will be the location where to store the stream; if you use another access, it will be the unicast or multicast IP address where you want to stream.
sap: if you use the udp or rtp accesses, use this option to announce your stream, using SAP/SDP.
name! This option contains the name under which you want to announce the program.
slp: like sap, but use the SLP protocol. You need to have libslp on your system.
sap_ipv: if you use the sap option, use this option to specify if you want to send the SAP announces in IPv4 or IPv6. The value of this option is 4 or 6.