I'm looking for advice on how to generate videos in C. The main issues I'll be dealing with are
Must be open source, would prefer BSD type license but GPL is acceptable
Must be reasonably well documented (I'm looking at you FFMPEG)
Must be able to generate a non-compressed video
Must be able to draw each frame
Should be able to set the frame rate (though of course I can just make n identical frames)
My toolkit is the GNU development system on UNIX like systems (Linux, OS X, Cygwin, ...)
Having said that, I'm picky about these requirements because if I don't have them I know I can pretty easily generate the individual frames with libgd and use ffmpeg commands to output a video. The point is that I'd rather be able to draw them and generate the video entirely in my C code. Even better would be to be able to provide the library in my own source (BSD license) so that my users don't need to worry about getting things installed on their particular platform.
I'm not set on a video codec other than the availability of non-compressed video (I'm visualizing changes in simulated rotational spectroscopy as rotational parameters or other variables like temperature change). Advice on a particular codec welcome.
Related
I'm encoding images as video using FFmpeg using custom C code rather than linux commands because I am developing the code for an embedded system.
I am currently following through the first dranger tutorial and the code provided in the following question.
How to encode a video from several images generated in a C++ program without writing the separate frame images to disk?
I have found some "less abstract" code in the following github location.
https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/encode_video.c
And I plan to use it as well.
My end goal is simply to save video on an embedded system using embedded C source code, and I am coming up the curve too slowly. So in summary my question is, Does it seem like I am following the correct path here? I know that my system does not come with hardware for video codec conversion, which means I need to do it with software, but I am unsure if FFmpeg is even a feasible option for embedded work because I am yet to compile.
The biggest red flag for me thus far is that FFmpeg uses dynamic memory allocation. I am unfamiliar with how to assess the amount of dynamic memory that it uses. This is very important information to me, and if anyone is familiar with the amount of memory used or how to assess it before compiling, I would greatly appreciate the input.
After further research, it seems to me that encoding video is often a hardware intensive task that can use multiple processors and mega-gigbyte sizes of RAM. In order to avoid this I am performing a minimal amount of compression by utilizing the AVI format.
I have found that FFmpeg can't readily be utilized for raw-metal embedded systems because the initial "make" of the library sets up configuration settings specific to the computer compiling, which conflicts with the need to cross compile. I can see that there are cross compilation flags available, but I have not found any documentation describing how to use them. Either way I want to avoid big heaps and multi-threading, so I moved on.
I decided to look for more basic source code elsewhere. mikekohn.net/file_formats/libkohn_avi.php Is a great resource for very basic encoding without any complicated library dependencies or multi-threading. I am yet to implement, so no guarantees, but best of luck. This is actually one of the only understandable encoding source codes that I have found for image to video applications, other than https://www.jonolick.com/home/mpeg-video-writer. However, Jon Olick's source code uses lossy encoding and a minimum framerate (inherent to MPEG), both of which I am trying to avoid.
Way way back in the day Itried to learn C from a game programming book. If I recall correctly, one of the first things your game "engine" would do would be to switch display modes to render. This involved a bit of asm to switch to a 640x480 display mode (mode 13 maybe?) so you could draw directly to the screen. Something like that.
My question is, what is the modern equivalent of this? I'm interested in writing a command line program that does something similar; drops into some kind of raster mode for me to draw to, but, I do not assume that my program would be running under some kind of window manager like kde, unity,Aqua etc.
Would this be something that OpenGL could provide (or does OpenGL assume a window manager too). My proposed program isn't a game, but would ideally start with a basic clear screen that I can draw primitives (2d lines, circles rects etc)
Cheers!
Modern operating systems don't give programmers as convenient access to low-level graphics routines as they used to. Partially, this is due to the advent of the GPU, which makes utilizing the graphics hardware a much more significant challenge than if you only had a CPU. The other reason is as window managers have gotten more and more complex, the graphical sandbox each operating system gives a programmer is more constrained.
That being said, OpenGL is definitely worth looking at. Its cross-platform, versatile, and automatically utilizes any hardware available (including the graphics card). OpenGL itself doesn't directly provide access to a windowing context, but you can easily create that with the OpenGL utility library (GLUT). OpenGL is however very low-level, you'll have to deal with frame buffers and flushing and bit masks and all sorts of low-level nonsense that can make OpenGL development a nightmare if you haven't done it before.
If I were starting a project, I would probably want a more robust graphics environment that provides drawing functions and windowing out of the box. Both SDL and SFML provide low-level graphics APIs that will be a little more friendly to start with. They are both implemented on top of OpenGL so you can use any of the OpenGL features when you want to, but you don't have to worry about some of the more tedious details.
As a side note, C might not be the best language to get started with graphics programming these days. If you want a really simple graphics environment that is becoming more relevant every day, you might want to check out what the web has to provide. JavaScript and the HTML5Canvas provide a very simple interface for drawing primitives, images, etc.
I'm looking for a simple-ish library for outputting audio. I'd like it to meet these criteria:
Licensed under LPGL/zlib/MIT or something similar – i'm going to use it in an indie commercial application and i don't have the money for a license.
Written in C, but C++ is fine.
Cross-platform (Windows, Linux, maybe OSX)
Able to read from some sort of audio file (i'd prefer WAV or OGG but i will gladly use less popular formats if need be) in memory (i've seen the use of a memfile struct and user-defined I/O callbacks). I need the file to be in memory because i put all my resources into a .zip archive, and i use another library to load those archived files into memory.
Supports playing multiple sounds at the same time, having a max of 8 or so is ok.
I'd really like to either have the source code or a static library (MinGW/GCC lib???.a), but if nothing else is available i will use a shared library.
I must have come accross two dozen different audio libraries in my search, all of which haven't quite met these criteria...
I would recommend PortAudio + libsndfile. Very popular combo, meets your requirements. Used by many other software applications including audacity.
Some of the candidates that immediately spring to my mind are:
SDL (there is a tutorial that demonstrates how to play a .wav format sound)
libav
ffmpeg
libao
OpenAL Soft
Jack Audio
You may have already looked at these and eliminated them, though. Can you give some more detail about the libraries that you have eliminated from consideration and why? This will help narrow down our recommendations.
You might want to look into SDL and SDL_mixer. Here is a good tutorial.
I've used SDL_mixer and it makes it easy to play background sounds or music and play multiple simultaneous sounds without having a need to write your own sound sample mixer.
I ended up using PortAudio (very low-level, flexible license) and wrote a mixer myself. See this topic i made on the C++ forums for some other people's tips on writing a custom mixer. It's not hard at all, really; i'm surprised that there are so many mixer libraries out there. For a breakdown of the WAV format (ready-to-stream raw audio data with a 44-byte header) see this.
I was wondering if its possible to use a sound card , and produce various notes from it using assembly level or C programming language .
See this SO answer Streaming Data to Sound Card Using C on Windows
which points you towards http://www.portaudio.com/
PortAudio is a free, cross-platform, open-source, audio I/O library. It lets you write simple audio programs in 'C' or C++ that will compile and run on many platforms including Windows, Macintosh OS X, and Unix (OSS/ALSA). It is intended to promote the exchange of audio software between developers on different platforms. Many applications use PortAudio for Audio I/O.
PortAudio provides a very simple API for recording and/or playing sound using a simple callback function or a blocking read/write interface. Example programs are included that play sine waves, process audio input (guitar fuzz), record and playback audio, list available audio devices, etc.
Yes, it is possible. Implementation of that will greatly depend on the system you will be coding for.
You're generally will have a choice to work with DAC (digital to analog converter) output, or, possible, accessing MIDI.
I'm no expert in sound generation, but... Of course it's possible. Something is needed to make calls to the sound card at some point in any application that uses audio, after all.
However, in almost all cases it's better to make calls to an API, and let the existing sound card driver of the system do all the busywork. Much more portable (...to an extent, at least), and much easier.
http://www.linux.com/archive/feature/113775 might have some good info. For Windows Vista/7, you can check out http://msdn.microsoft.com/en-us/library/dd370784%28v=vs.85%29.aspx.
Oh, and in many cases you'd be better off using an existing software library that can produce the notes rather than trying to generate the waveforms yourself. (See Fredrik's answer.)
I'm working on an audio application, written in C. I need to provide live audio playback under Windows. I need to decide which audio API to use. I'm planning to use the basic waveOut API, but I wanted to check to see what the community here recommends.
I want code that will Just Work on any recent version of Windows, with no need to install libraries; and I want minimal latency.
I don't need or want any "effects", I just need to faithfully play whatever wave samples the application generates.
My understanding is that most of the professional audio applications on Windows use ASIO, which gives excellent low latency, but I don't want ASIO because I want my code to Just Work and most people don't have ASIO pre-installed on their computers. (At a later date I may go back and also add ASIO as an option, but I'm going for the most general solution first.)
Is there anything out there that would be better than waveOut for my purposes, or is that the best choice?
It depends on what you are trying to do. The basic waveOut audio API is better for streaming audio. It lets you queue up several buffers and have them automatically played in succession. But if audio is playing and you want to change it, or add something to it, that's relatively hard.
DirectX audio is better for event based audio. You can have several things playing at the same time without having to do the mixing yourself. You can add or remove little pieces of audio easily - like playing a sound when the user pulls the trigger on their gun. But streaming (i.e. playing 1 buffer after another) is harder.
waveOut is designed to facilitate playing audio that is constant, like a .mp3 file. DirectX is designed for audio that is intermittent, like feedback in a game.
ASIO is like the worst of waveOut and DirectX in terms of difficulty of programming, and it's not that stable. Applications typically can't share the audio device. However, it gives you the lowest latency access to that audio hardware. ASIO also gives you a way to synchronize playback on multiple devices.
If you don't need to be able to change what is going to be played right before it is played, and you don't need to synchronize multiple devices, then you don't need ASIO.
in addition to the options mentioned by John Knoeller, there is WASAPI which allows for much lower latencies than WaveOut, but unfortunately is only available from Windows Vista onwards.
At the time I asked this question, I wrote streaming code using the waveOut and waveIn APIs. Since then, I have discovered a useful library:
PortAudio
http://www.portaudio.com/
PortAudio is free software with a commercial-friendly license. If you write your code to call PortAudio it should be able to work with waveOut devices but also with ASIO devices under Windows; it can be then recompiled for Linux and should work with ALSA devices; and it can then be recompiled for the Mac and should work with CoreAudio devices. I haven't tested the Mac part but my project is working great with Windows and Linux.
Having written a DirectSound streaming application myself, I certainly recommend it for low-latency and ease of use. Also, it enables you to set a higher quality format for playback on legacy editions of Windows.