Can anybody give me a link to a working example of playing background live-streaming audio in Window Phone 7 (or 7.1)? I saw a lot of examples (in microsoft.com too) and noone of them works correctly for playing a background live-streaming audio.
FYI, here's an url of live-streaming audio http://radiozetmp3-02.eurozet.pl:8400/
Background audio is not supported on 7.0, only 7.1 (and above).
If you want to play streaming audio in a format/codec which is not natively supported by the phone you must do it with an AudioStreamingAgent. If it is a supported codec, you can use an AudioPlayerAgent (see sample here).
Using an AudioStreamingAgent is a nontrivial task and requires a deep understanding of the codec you need to play so you can convert it to something the phone understands. I know of one person who did this, for a H.264 stream, and it took a long time and much hair pulling to get it working. And before anyone asks: No, they are not able to share code from that project.
If you really must go down this route, the ManagedMediaHelpers (previously here) are a good place to start, but yes, they don't cover all codecs and this is, potentially, very complicated and not something well documented on the web.
Related
We have an iOS app that we are currently rebuilding for Android. The app relies on being able to scrub video with frame accuracy. We have 3D animations that are rendered out as single frames; we build subsets of frames into lots of small (1-2 second) videos; and the app provides the ability to scrub those videos and see each individual frame.
The MP4 videos we initially created work fine on iOS. When we tried to get them working on Android (using the MediaPlayer class), we entered a world of pain! What we need to do is find a video format that will play and allow frame-accurate scrubbing across all Android devices, using MediaPlayer.seekTo(). Initially we are targetting Android 3.0 and above, but we probably want to stretch back to 2.3.3 after our initial release. Here's what I've discovered so far:
(A) Android claims that H264 "baseline profile" should be supported everywhere: (URL). However, within that, there are dozens of other settings that may or may not be supported. Is there a more fine-grained list anywhere? Currently we are converting to H264 within an MP4 container.
(B) I haven't yet seen an Android device that will accurately scrub H264 files without inserting keyframes ("intra frames"). iOS will happily take H264 files without keyframes and provide accurate scrubbing. It seems that, to allow accurate scrubbing, we need to insert a keyframe for every frame of the video (the relevant ffmpeg setting is "-g 1"). This significantly increases the file size.
(C) However, inserting a keyframe for every frame results in a video that will not play at all on the Samsung Galaxy Note 3 (Snapdragon chipset I believe). Reducing the keyframes to every second frame or above seems to work (ffmpeg setting "-g 2").
To summarise:
MediaPlayer.seekTo() seems very dependent on the video format, and varies across devices. Is this the intention? Is there a base level of behaviour that seekTo() is supposed to provide, regardless of format?
What video format that will allow frame-accurate scrubbing (using MediaPlayer.seekTo()) across all Android devices (at least for 3.0 and above?)
The MediaPlayer isn't likely to give you what you want anytime in the near future. The underlying native players are still relatively immature in some respects, not to mention H.264 in particular has lost favor at Google (and other places) because of patent issues.
You may want to look into using ffmpeg itself on Android. See here for some help with that. Using ffmpeg on Android isn't uncommon, so there's plenty of info on how to do it floating around.
Making the video all i-frames seems a terrible waste. I would avoid that at all costs if I were you.
3gp works fine for me. However, the video seems to restart a couple of frames before.
This question arises out of a combination of this being my first time working with video and unfamiliarity with Macs. Basically I'm finding it difficult to figure out how to play a video (within a QWidget, or otherwise) using any standard format, e.g. avi, mpeg, mov, etc. In particular,
QMovie::supportedFormats() gives me only .gif and .mng, but I need to use standard formats. Is there a way to increase the number of supported formats?
Phonon requires the presence of a 'backend' which the user has to implement himself. I looked to see if I could somehow do this with Quicktime, but I couldn't get the application to launch--and anyway I didn't really see how to do that. Also, Phonon looks pretty heavyweight, I'd like to avoid it if I could.
While there are plenty of avi (et al.) players floating around on the web, I think it's probably unlikely I'd be able to use them--I need to start, stop, and change the playback speed of videos programmatically i.e. through my C++ program.
I'm not sure why this should be so hard--working with images in Qt is a snap by comparison. So: What's a good way to play videos from within a C++/Qt program?
Stop what you are doing right now: Phonon is the past, Qt Mobility is the future.
After you download, compile and install Qt Mobility, check the examples: videowidget and videographicsitem, located at: qt-mobility-opensource-src-1.2.0/examples/
They pretty much answer all your questions.
Can any one tell me how to stream video using mac osX , i need to write an application in mac os for video conferencing please let me know any prerequisites for making this application and what shud i learn for this .
Thanks in advance .
Do you need to do streaming or two-way videoconferencing? The latter is orders of magnitude harder than the former. If you just need streaming (one server, many clients), then QuickTime Broadcaster will do what you want.
Some time ago I used libcurl to stream a video from youtube, libavcodec (from ffmpeg) to decode and parse the data into frames and finally SDL to display it on my Mac OS X.
If you are looking for ffmpeg/SDL code examples, you must check this out:
http://dranger.com/ffmpeg/tutorial02.html
Based on your comment to Josh Wolf, you might want to consider developing an Adobe AIR application (inherently flash, but via whichever OSes you choose), as it already has built-in components for capturing and streaming video.
There's a great alternative for using this kind of service: tinychat.com
You can create a private room there and tell the password only for the people you need to talk to. The best reason for using tinychat.com is that you don't need to install anything.. It does works very well and quickly, and suports 9 broadcasts at the same time, with webcam, audio and/or text chat.
I am using Windows Media Format SDK to capture the desktop in real time and save it in a WMV file (actually this is an oversimplification of my project, but this is the relevant part). For encoding, I am using the Windows Media Video 9 Screen codec because it is very efficient for screen captures and because it is available to practically everybody without the need to install anything, as the codec is included with Windows Media Player 9 runtime (included in Windows XP SP1).
I am making BITMAP screen shots using the GDI functions and feed those BITMAPs to the encoder. As you can guess, taking screen shots with GDI is slow, and I don't get the screen cursor, which I have to add manually to the BITMAPs. The BITMAPs I get initially are DDBs, and I need to convert those to DIBs for the encoder to understand (RGB input), and this takes more time.
Firing a profiler shows that about 50% of the time is spent in WMVCORE.DLL, the encoder. This is to be expected, of course as the encoding is CPU intensive.
The thing is, there is something called Windows Media Encoder that comes with a SDK, and can do screen capture using the desired codec in a simpler, and more CPU friendly way.
The WME is based on WMF. It's a higher lever library and also has .NET bindings. I can't use it in my project because this brings unwanted dependencies that I have to avoid.
I am asking about the method WME uses for feeding sample data to the WMV encoder. The encoding takes place with WME exactly like it takes place with my application that uses WMF. WME is more efficient than my application because it has a much more efficient way of feeding video data to the encoder. It doesn't rely on slow GDI functions and DDB->DIB conversions.
How is it done?
The source to CamStudio, a GPL'd screencasting app that's been around for years (commercially and then open-srcd later) might be useful?
http://sourceforge.net/project/showfiles.php?group_id=131922
I'd suggest looking at the guts of VNC clients too, though they're probably very simplistic (I think just grabbing screenshots then jpg'ing the tiles that have changed since the last capture).
You might want to consider not using WMV9 as the encoder for on-the-fly encoding if it is too cpu-heavy? Maybe use an older, less efficient compressor (like MS RLE) as used by HyperCam and then compress to WMV afterwards? MS RLE has been a default install since at least Win2000 I believe:
http://wiki.multimedia.cx/index.php?title=Microsoft_RLE
CamStudio's Lossless codec is GPL (same link as above), that offers pretty good compression (though you'd need to bundle the dll in your installer) and could be used on the fly, it works well with high compression on all modern systems.
It's been ages since I've done any Win32 coding, but AFAIK, WMF as a format is basically a list of GDI commands and their parameters which would explain why it is much more efficient to encode...
You'd probably need to hook into the top level GDI context (just as Remote Desktop does, I guess) and capture the GDI commands as they are called. I seem to remember there being some way of creating a WMF output GDI context which means you may be able to just delegate calls to it in some way.
I'm guessing here, but you may be able to find example code for the above in the TightVNC/QuickVNC for Windows projects as they would have to do something like that to capture changes on screen in an efficient way.
Have you checked out the BB FlashBack library?
I am on a similar hunt, and I have just started evaluating the BB FlashBack library.
I am not sure about the external dependencies or install footprint. It appears to have a proprietary codec that has to be installed, but the installation of the codec can be handled by the exposed BB FlashBack API.
Beware, there are licensing restrictions (Runtime setting of license keys, ...)
I can send you the CHM from the SDK via e-mail if you want to evaluate the API before committing to a licensed download.
Things I am in the midst of evaluating:
Proper captures of WPF views
mouse cursor tracking
Size of stored movie
How to display stored movie without proprietary codec (i.e. SWF export)
--Batgar
I'm making an application where I will:
Record from the microphone and do some realtime processing on the input
Play an MP3 file (a regular song), but manipulating the output in realtime
Every now and then I'll need to play additional sounds over this song too, but I guess I can do that by simply adding the buffers.
In short, I need to have circular buffers for both recording and playing, and I need to be "feeding" the output buffer every 20 ms or so with the new data that is just about to be played.
I've been looking at DirectSound, and it doesn't seem to help a lot. The reading and writing to the output buffers seem very similar to Win32, the only place where it seems it'd help is in playing the "additional sounds" over the main song.
Should I use DirectSound, or should I go straight to raw Windows APIs?
Is DirectSound going to do anything for me?
Thanks in Advance!
The Directsound API's give you better realtime control. They are also the supported way to use sound in Windows. I was under the impression that the win32 api's were depracated, but I could be wrong on this.
This question is close to yours
https://stackoverflow.com/questions/314522/what-is-the-best-c-sound-api-for-windows
also
Is DirectSound the best audio abstraction layer for Windows?
last but not least, this is what microsoft has to say http://msdn.microsoft.com/en-us/library/dd370784(VS.85).aspx
Neither? :)
The story is that DirectSound is the replacement for waveOut, but DirectSound joined DirectInput as deprecated APIs in Vista and is replaced with WASAPI. DirectSound and waveOut are implemented on top of the User-Space WASAPI in Vista. On XP, waveOut and DirectSound feed to the same kernel level Mixer API.
To consolidate all of these interfaces take a look at something like OpenAL, it's a well supported audio standard along the same lines as OpenGL.
It sounds like you're going to be quite sensitive to latency. It might pay to look at ASIO
I found Harmony Central - Audio Programming. Also read w:DirectSound.
Windows Vista features a completely
re-written audio stack based on the
Universal Audio Architecture. Because
of the architectural changes in the
redesigned audio stack, a direct path
from DirectSound to the audio drivers
does not exist.
Because of Xbox 360 and Microsoft
Windows integration, Microsoft is
actively pushing developers to migrate
new applications to equivalent Xbox
audio APIs such as XAudio and XACT.
OpenAL looks promising.