We already have a functionality of Video uploading in our webapplication[built using python with Django framework]. Now we are in the process of building a livestream site where people are able to use their webcam to record the live event and it's live streamed to different participants at the sametime.
I am wondering if somebody has any idea of how to go about building a functionality like this or any pointers that would be really helpful.
I sort of looked into this same question a while ago. The dominant solution seems to be Adobes Flash Media Server. It is closed source of course and quite pricey. There are companies who run it as a service, lowering the cost of entry. And there are open source contenders, the main one being Red5, which of course also relies on flash being available on the client side.
In the future we'll probably see viable HTML5 alternatives but if you're doing something right now my feeling is that the flash route is the simplest solution and has the largest install base.
I did a video vlc record with python and it was quite simple. VLC have a stream recorder and as I know you could launch a vlc stream with a simple python code who manage the video ans the stream. I think all you need is to manage the sources and then, doing a small script who takes care about the vlc stream.
VLC stream will be launch on a different port, so I think you've to search a good server.
see vlc docs :
https://wiki.videolan.org/Documentation:Streaming_HowTo/Command_Line_Examples/
Enjoy :)
Check VLC or Flumotion...
Probably Photolab as well..
The latter one doesn't support audio...
Gee
Related
I'm looking into coding a very simple LAN based home monitoring system using python 2.7 on Windows. I have a number of computers around the house each with a usb webcam attached. The cameras have built in microphones. I'm looking for the best way to capture and stream the audio and video over the network, then recieve and view/listen to it. I'm guessing I'd have to use PyAudio to get the audio from the microphone and CV2 to get the video, past that, I'm not sure how I'd stream that data to another computer, recieve it and then view/listen to it.
Not realy a question here, but still I guess I have a solution for you
(but there a millions of ways to solve this.)
My way is ROS (Robot Operating System), which is basically a TCP/IP Service Wrapper. Anyway you can simple broadcast and receive streams via your network.
ROS can be implemented in C++ or Python.
ROS usually applies OpenCV as CV-library, so it should suite your wishes.
Straight forward examples for video are (i.e.) here:
mjpeg_server
web_video_server
Audio streaming is introduced here:
audio_common (there might be solutions via PyAudio. Not sure if other solutions might come more easy and still suitable.)
I downloaded some flash games some time ago to play offline at school if I find myself with no work to do and have a spare. The only problem is that they always attempt to save/load from the application data, and I don't believe the files are created at all, let alone loaded next time I would play it again.
Instead of decompiling each one and finding/changing the save and load location I thought about the Windows API, hooks in particular. Perhaps it may be possible to monitor system requests to create such a file, or open it if it's trying to load, and then tell it to look elsewhere (i.e. my flash drive)?
I don't know if the idea is actually plausible or not, but any solutions, or a solid "It's impossible" would be great.
I hope some of these help:
WinAPIOverride32 is an advanced api monitoring software.
Deviare API
Deconstructing the Poker Client, Part 1
In my application we will present the video stream from a traffic camera to a client viewer. (And eventually several client viewers.) The client should have the ability to watch the live video or rewind the video and watch earlier footage including video that occurred prior to connecting with the video stream. We intend to use wxWidgets to view the video and within that we will probably use the wxMediaCtrl.
Now, from the above statements some of you might be thinking "Hey, he doesn't know what he's talking about." And you would be correct! I'm new to these concepts and I confused by the surplus of information. Are the statements above reasonable? Can anyone recommend a basic server/client architecture for this? We will definitely be using C++ wxWidgets for the GUI, but perhaps wxMediaCtrl is not what I want... should I be directly using something like the ffmpeg libraries?
Our current method seems less than optimal. The server extracts a bitmap from each video frame and then waits for the single client to send a "next frame" message, at which point the server sends the bitmap. Effectively we've recreated our own awkward, non-standard, inefficient, and low-functionality video streaming protocol and viewer. There has to be something better!
You should check out this C++ RTMP Server: http://www.rtmpd.com/. I quickly downloaded, compiled and successfully tested it without any real problems (on Ubuntu Maverick). The documentation is pretty good if a little all over the place. I suspect that once you have a streaming media server capable of supporting the typical protocols (which rtmpd seems to do), then writing a client should fall into place naturally, especially if you're using wxWidgets as the interface api. Of course, it's easy to write that here, from the comfort of my living room, it'll be a different story when you're knee deep in code :)
you can modify your software such that:
The server connect, server grabs an image, passes it to ffmpeg establishing stream, then copy the encoded data from ffmpeg stream and send to client via network, if the connection drops, close the ffmpeg stream.
Maybe you can use the following to your own advantage:
http://www.kirsle.net/blog.html?u=kirsle&id=63
There is a player called VLC. It has a library for c++ and you can use it to embed the player in your GUI application. It supports a very wide range of protocols. So you should leave connecting, retrieving and playing jobs to VLC and take care of the starting and stopping jobs only. It would be easy and probably a better solution than doing it yourself.
For media playing facility, both music and audio, you can a look on GStream. And talking about the server, I think Twisted (A network library in Python) should be good option. The famous live video social website justin.tv is based on Twisted. Here you can read the story from here. Also, I built a group of server for streaming audio on Twisted, too. They can serve thousands of listener on line in same time.
I wanted to get some ideas one how some of you would approach this problem.
I've got a robot, that is running linux and uses a webcam (with a v4l2 driver) as one of its sensors. I've written a control panel with gtkmm. Both the server and client are written in C++. The server is the robot, client is the "control panel". The image analysis is happening on the robot, and I'd like to stream back the video from the camera to the control panel for two reasons:
A) for fun
B) to overlay image analysis results
So my question is, what are some good ways to stream video from the webcam to the control panel as well as giving priority to the robot code to process it? I'm not interested it writing my own video compression scheme and putting it through the existing networking port, a new network port (dedicated to video data) would be best I think. The second part of the problem is how do I display video in gtkmm? The video data arrives asynchronously and I don't have control over main() in gtkmm so I think that would be tricky.
I'm open to using things like vlc, gstreamer or any other general compression libraries I don't know about.
thanks!
EDIT:
The robot has a 1GHz processor, running a desktop like version of linux, but no X11.
Gstreamer solves nearly all of this for you, with very little effort, and also integrates nicely with the Glib event system. GStreamer includes V4L source plugins, gtk+ output widgets, various filters to resize / encode / decode the video, and best of all, network sink and sources to move the data between machines.
For prototype, you can use the 'gst-launch' tool to assemble video pipelines and test them, then it's fairly simply to create pipelines programatically in your code. Search for 'GStreamer network streaming' to see examples of people doing this with webcams and the like.
I'm not sure about the actual technologies used, but this can end up being a huge synchronization ***** if you want to avoid dropped frames. I was streaming a video to a file and network at the same time. What I eventually ended up doing was using a big circular buffer with three pointers: one write and two read. There were three control threads (and some additional encoding threads): one writing to the buffer which would pause if it reached a point in the buffer not read by both of the others, and two reader threads that would read from the buffer and write to the file/network (and pause if they got ahead of the producer). Since everything was written and read as frames, sync overhead could be kept to a minimum.
My producer was a transcoder (from another file source), but in your case, you may want the camera to produce whole frames in whatever format it normally does and only do the transcoding (with something like ffmpeg) for the server, while the robot processes the image.
Your problem is a bit more complex, though, since the robot needs real-time feedback so can't pause and wait for the streaming server to catch up. So you might want to get frames to the control system as fast as possible and buffer some up in a circular buffer separately for streaming to the "control panel". Certain codecs handle dropped frames better than others, so if the network gets behind you can start overwriting frames at the end of the buffer (taking care they're not being read).
When you say 'a new video port' and then start talking about vlc/gstreaming i'm finding it hard to work out what you want. Obviously these software packages will assist in streaming and compressing via a number of protocols but clearly you'll need a 'network port' not a 'video port' to send the stream.
If what you really mean is sending display output via wireless video/tv feed that's another matter, however you'll need advice from hardware experts rather than software experts on that.
Moving on. I've done plenty of streaming over MMS/UDP protocols and vlc handles it very well (as server and client). However it's designed for desktops and may not be as lightweight as you want. Something like gstreamer, mencoder or ffmpeg on the over hand is going to be better I think. What kind of CPU does the robot have? You'll need a bit of grunt if you're planning real-time compression.
On the client side I think you'll find a number of widgets to handle video in GTK. I would look into that before worrying about interface details.
I have an application that grabs video from multiple webcams, does some image processing, and displays the result on the screen. I'd like to be able to stream the video output on to the web - preferably to some kind of distribution service rather than connecting to clients directly myself.
So my questions are:
Do such streaming distribution services exist? I'm thinking of something like ShoutCAST relays, but for video. I'm aware of ustream.tv, but I think they just take a direct webcam connection rather than allow you to send any stream.
If so, is there a standard protocol for doing this?
If so, is there a free library implementation of this protocol for Win32?
Ideally I'd just like to throw a frame of video in DIB format at a SendToServer(bitmap) function, and have it compress, send, and distribute it for me ;)
Take a look at video LAN client (or VLC for short) as a means for streaming video.
As for distribution sites, I don't know how well it works with ustream.tv and similar new services.
ustream.tv works by using Adobe Flash's support for reading input from a webcam. To fake it out, you need a fake webcam driver. Looking on the ustream.tv site, they point to an application called WebCamMax that allows effects and splicing in video. It works by creating a pseudo-webcam that mixes video from one or more cameras along with other sources. Since that app can do it, your own code could do that too, although you'll probably need to write a Windows driver to get it all working correctly.