I am actually working on a server-client multimedia player. This player can be a server to stream a MP3 file (or wma, wav, ogg, flac ...) over the network to another player (client).
I worked first on a basic network communication (client-server), that send and receive bits. But I have a problem : the audio encoding. I need a tool to encode the audio data to be able to send a little part of it through the network and let the client play it before the next part is coming.
I saw a few tools on internet such as BASS library, Live555 ... I used to work with PortAudio for student's projects but I hate it.
So basically, I need a tool to encode audio data (server side), (I can send it over lan), and decode data to play it (client-side).
Do you guys have some ideas about how to do it ? Which tool could be useful for me in that case?
PS : I am trying to use Qt library for the network interface (it is efficient, and it works on windows, linux, mac) ... Is there any audio streaming tool included in the Qt library ?
You can try FFMPEG. It can convert almost anything to anything (so it claims) and it is a widely used open source library.
We use it in our application mainly for decoding video/audio streams.
Related
I would like to write a gstreamer pipeline that mixes the audio from two sources. I then want to be able to select an audio source from an app on my computer, i.e. Discord, such that the mixed audio will play as if it was coming from my mic.
It seems simple enough to get the mixing right, but it seems like I need to use something like Virtual Audio Cable to achieve the second part. Is there a way to do this entirely in gstreamer or with something more lightweight than installing Virtual Audio Cable?
There is no [yet] Windows API to create virtual audio endpoint, so that applications could interact with it similarly to real device. Consequently, there is no GStreamer wrapper over this non-existent API either.
Doing it without VAC would require that you still install an audio driver where you would provide your own endpoint for Windows to use and expose to applications.
The project I'm currently working on, requires an addition to the already existing VoIP capabilities. The core for speech processing is in C, the remainder is in C++ with Qt - the audio is handled via portaudio. The connection between users is currently established via UDP, which I think has to be changed for the planned video connection. Developing platform is Windows on VS2012 - however, the system is cross-platform.
In a nutshell, what I want to do is: Grab the video signal from a webcam, synchronize audio coming from C core and video from webcam and use a library and codecs for (de-)coding/muxing the signals on the respective sides and sending via RTP. The system should be capable of multicast transmission.
I did some research for possible libraries and stumbled upon ffmpeg and libVLC. For the codec I thought about using x264. And if I'm correct, ffmpeg and libVLC should both be capable of what I'm looking for?
However I'm not sure which one to pick, and from their documentations I really can't extract, which library is the better fit. Has anybody had similar problems and can help me out - I'm quite a newbie, when it comes to video processing and encoding.
Extra question: Do you have any hints or approaches on syncing the video and audio signals?
If anyone is interested, this is what I ended up doing:
I am using the WebM container format, VP8 with Vorbis currently (but going to change to VP9 with Opus soon if out of beta), handled by ffmpeg/libav libraries for encoding/decoding/muxing etc. and SDL for displaying and threading. ffmpeg/libav was cross-compiled on Unix with LGPL support to keep our project closed source.
I'm currently specing out projects for my graphics class and I am thinking of writing an application that displays a visualizer for midi data. What I would like to do is sniff midi data as it passes through the system. I do not want to hijack a driver, only watch the data go by (that is, I want the MIDI data to later be accessible by a DAW). I am not familiar with programatically accessing midi in windows. The closest I could find to what I want seems to be midi spy. However I would prefer to write the app in c/c++.
I was looking at MIDI Stream API, but I can't tell if I'll be able to sniff devices that weren't opened by the library. I was also looking at SDL Mixer and QT Midi. I'm just trying to get some personal pros and cons to the options that I've presented or ones that I haven't found.
Unfortunately, there is no way to actually sniff MIDI streams under Windows. All you can do is place your application between the two MIDI devices.
Unless you are putting software between physical in/out ports, you will need to set up a virtual MIDI loopback driver that directs the MIDI stream data from an input to an output. Fortunately, there are a few off-the-shelf solutions already. The easiest method is to require your users to set up a virtual MIDI port and configure it on their own. LoopBe1 and MIDI Yoke are free.
Another method is to use a virtual MIDI driver that goes directly to your application. Tobias Erichsen has created a very easy-to-use driver for this very purpose. I don't believe he has released it yet, but if you shoot him an e-mail, he might get back to you. See this question: DDK "Hello World"
I'm using c++ and poco libraries. I'm trying to implement a video streaming httpserver.
Initially i used Poco::StreamCopier.
But client failed to stream.
Instead client is downloading the video.
How can i make the server to send a streamresponse so that client can stream the video in browser instead of downloading?
While not within POCO, you could use ffmpeg. It has streaming servers for a number of video protocols and is written in C (which you could write POCO-like adapters for).
http://ffmpeg.org/ffmpeg.html#rtp
http://ffmpeg.org/ffmpeg.html#toc-Protocols
http://git.videolan.org/?p=ffmpeg.git;a=tree
And it has a pretty liberal license:
http://ffmpeg.org/legal.html
You need to research which video encoding and container that is right for streaming -- not all video files can stream
Without using something to decode the video at the other end but simply over HTTP, you can use The mime encoding "content-type:multipart/x-mixed-replace; boundary=..." and send a series of jpeg images.
This is actually called M-JPEG over HTTP. See: http://en.wikipedia.org/wiki/Motion_JPEG
The browser will replace each image as it receives it which makes it look like it's video. It's probably the easiest way to stream video to a browser and many IP webcameras support this natively.
However, it's not bandwidth friendly by any means since it has to send a whole jpeg file for each frame. So if you're going to be using this over the internet it'll work but will use more bandwidth than other method.
However, It is naively supported in most browsers now and it sounds like that is what you're after.
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.