i am trying to set up a few ip cameras for a client.
yet i am having trouble getting the stream from the camera to the webpage then for it to play through a player. i have tried different players such as WMP, VLC(cant get it to work). i am now trying to use jplayer which would be great if i could get it to work on this one as works for phones or so it says.
what i have done so far is to go into my router(thomson TG585 v8) and set up port forwarding.
i have set up port 554 on TCP/UDP which in the camera settings is the RTSP port.
i have set my camera to a static ip and am using no-ip for the ddns.
rtsp://thepolishedknob.servebeer.com/h264/1/media.amp
this is the url i am trying to use but i cannot get the stream on to the player i know the stream works outside my LAN as connected to it through VLC last night.
if anyone can help me it would be greatly appreciated as been working on this for over a week and been going nowhere.
so if you have noticed i have missed anything out or done something wrong please let me know.
There is no universal way to do the embedding. Typically solution is one of the following:
As IP cameras comes with web interface, they already provide some way to present video off the web page. Often, this is an ActiveX control based solution with respective browser limitations. You can check HTML and duplicate the code, and it can also be mentioned in the vendor's documentation.
As you discovered the stream is RTSP, and hopefully valid RTSP without tricks, there might be a third party solution "player" to present the stream off the webpage.
You might want to re-encode the stream into another format (VLC or another aplication), such as M-JPEG which is more browser friendly. You'll find a lot of discussions for this, e.g. http://forum.videolan.org/viewtopic.php?f=16&t=57715
Related
What I'm doing
Basically I'm writing simple a Q&A site with an option to create links to specific positions in media files. As of now the app is intended to be used in LAN environment only.
I have put a video in appRoot/public folder and created a view using
html5 video tag.
It works and even seeking is available. Wow...
What I don't understand
I'm clueless as to the tech behind and its limitations.
It just worked, so I don't even know a key word to hit google with.
What I know
With the way I'm doing:
No encryption
No way to prevent users to save video files
No automatic trans-coding available
The real question
What is the name of the tech behind.
How well can rails handle streaming and seeking requests with the way I did as compared to using dedicated video streaming servers or gems.
As long as your underlying web server understands how to handle the MIME types for video, and responds correctly to byte range requests - as it seems to be - that's all you need. The underlying mechanics of streaming video with HTML5 is that the browser asks for a chunk of content as a range of bytes from the source (enough to keep the buffer full) and the server delivers it.
You might want to look at using ffmpeg to optimize your videos so that the metadata is in the right place in the file to start streaming quicker.
You've correctly pointed out the limitations of the solution in your environment. The other thing to be aware of is capacity - if the videos are long and a lot of people are accessing them concurrently then without caching (in a LAN via a caching proxy or on the internet via a CDN service) your server capacity may be stretched
I am using a proprietary RTSP server (I don't have access to the source code) running on a Linaro based embedded system. I am connecting to the device using WiFi and use VLC player to watch the stream. Every often, VLC player's window resizes to different sizes.
Is this a normal behavior in RTSP stream (resizing the video)?
-If yes, what is causing this change? Is it my WiFi bandwidth?
-If not, what are the suggested steps to find the root cause of this problem.
Thank you
Ahmad
Is this a normal behavior in RTSP stream (resizing the video)?
Yes, the RTSP DESCRIBE Request should give info about the resolution. (See this discussion)
-If yes, what is causing this change? Is it my WiFi bandwidth?
Most probably not. However I guess more info would be needed on your bandwidth and network setup.
-If not, what are the suggested steps to find the root cause of this problem.
Option 1: Try to disable (uncheck) VLC's preference to resize the interface to native video size, and see what happens.
Also see the following post over at superuser discussing about automatic resizing options
Option 2: Enable VLC's verbose mode (console log) and see what errors or messages come up. This often helps, and points into new directions to look for solutions.
Option 3: It could be a problem with how information is encoded in the stream concerning the resolution. You would need to get in touch with the vendor of your RTSP server software in order to dig deeper.
Open the VLC player press (Ctrl + P) or go to
Tools -> Prefrences -> Interface (look for below options)
Integrated video in interface [Check]
Resize interface to video size [UnCheck]
Must close and open again the VLC player
Interested in the question m3u8-play video streams on chromecast device. Studying the docks as I understand it does not necessarily write Custom Receiver, ready enough to use Default Receiver or Styled Media Receiver. But some servers with HLS videos have the problem with CORS.
What are the options to solve this problem to play any m3u8-streams (from any server)?
Use CORS-proxy or something else?
You cannot get around the CORS requirement so your options are limited; the proxy approach seems to be your only option. Note that your options are the same regardless of using a custom receiver or a default/styled; even if you write a custom receiver, you will run into the very same CORS requirement.
I have tried to use LiVu and Broadcast Me, but it does not work smoothly with what I am trying to do. I need to live stream audio/video from the iPhone to our servers (while saving locally).
I have tried to implement a RTSP UDP stream but it is proving to be more of a challenge than we initially thought.
RTSP/UDP is preferred, but whatever gets the stream to the servers in a timely fashion will work.
Any advice or framework suggestions would really help. Have already looked at iOS-RTMP-Library but its too expensive for us to use at this point.
I don’t know about your budget, but you might check ANGL lib which worked fine for us on RTMP.
I am trying find a way to transcode an rtsp stream to HTTP (iOS) so that I can view a rtsp stream on a ipad. The video is embedded in our SaaS web view, and launching a third party player is not a possibility.
I found sirannon which according to the documentation can do this no prob.
However I am puzzled on how to actually execute.
Our rtsp stream is as such rtsp:\xxx.xxx.xxx.xxx:554\ch0_unicast_firststream
there is no .sdp file or anything. And vlc can play it fine.
But if i open a browser and attempt to open http://localhost:8080/RTSP-proxy/192.168.33.216/ch0_unicast_firststream
or
http://localhost:8080/RTSP-proxy/192.168.33.216:554/ch0_unicast_firststream
it gives me this error
[1516250] Warning: core.HTTP-server: Handling RuntimeError: Could not
guess container type for
URL(/RTSP-proxy/192.168.33.216/ch0_unicast_firststream)
(core.HTTP-server.session-42)
So far I haven't found any goo dexamples using sirannon. I am also open to using VLC, but again, do not know if or how to do a rtsp to http conversion with VLC.
With wowza we are able preemptively start the root stream ahead of the http stream request.
With a delay of about 3 seconds, the client is able to connect nicely. Then we monitor the client list to see if it is empty, if so, we kill the stream.
I've been digging into this for personal use and have gotten the same error. After some digging (notably in src/Communicator/HTTP/HTTPSession.cpp), I've made some progress.
While it's not explicitly in the documentation, it seems that you have to add the container type to the app type in the proxy, just as if you were streaming a file. As such:
http://localhost:8080/RTSP-proxy#[CONTAINER_TYPE]/192.168.33.216:554/ch0_unicast_firststream