FLVmeta 1.1.0 released
After a few years of short intense development phases, between long pauses of semi-inactivity, here it is, FLVmeta 1.1.0.
This release is a beta version, some real-world testing will be needed to ensure no bugs remain. However, I am pretty confident this version can be used in a production environment, because it is currently used in such a way on a daily basis where I work.
Here is a summary of the most interesting features:
- In-place updating: in addition to writing new files with inserted metadata, FLVmeta can now also update an existing FLV file, in order to simplify workflows where several encoding steps take place.
- Exhaustive dumps: flvdump has been removed, as its functionality has been integrated and expanded into the main flvmeta executable.
FLVmeta can now dump the onMetadata tag, the whole file, or any chosen metadata tag. A few interesting output formats are available. In addition to the old “debug” format, XML, JSON and YAML are now supported, allowing integration most software.
- File checking: FLVmeta can perform a large range of verifications on a FLV file, from the most begnin issues to fatal errors rendering the file impossible to play. A textual report will be printed, optionally as XML to allow further processing.
- File fixing: currently experimental, this is an option that will attempt to fix invalid FLV files when updating them.
- User documentation: there is a man page now, that explains in detail how every command and option works.
I have successfully implemented support for the CMake build system in addition to autotools, initially in order to facilitate Windows builds, and now as the primary build system.
I intend to get rid of autotools, for a few reasons. First, CMake exists on even more platforms that the autotools. Furthermore it is much easier to support than autoconf to implement non-trivial features. And finally, I now feel that the number of users used to the “./configure && make && make install” way of installing software on Unix derivatives is decreasing due to the availability of binary package installation systems, such as Aptitude or RPM. FLVmeta can already be found as a binary package on a number of platforms, including Debian and derivatives such as Ubuntu, or FreeBSD, NetBSD.
I also discovered a great documentation management tool named Pandoc. I needed a tool to author or maintain FLVmeta’s man page, because avoiding editing raw NRoff files seemed obvious.
At first I tried the Ronn tool, but I had trouble obtaining satisfying results, and its Markdown-derivated dialect was too far from the standard everyone seems to be used to.
Using Pandoc gives me a great level of control over the output formats, and is easy to use and integrate into my build chain. This is especially true when using CMake, as the man page can even be automatically compiled from Visual Studio, assuming the tool has been installed on your Windows box, and can be found via the PATH environment variable.
All in all, I am satisfied by the experience of developing open-source software, and I am happy to have created a tool that is useful to at least a handful of people. I know that the number of downloads is probably not a very representative figure, but there have been thousands of downloads since its first release in 2007 (approximatively 10889 as of 2012-05-13).
There have been some bug reports and patches that have been proposed (and accepted), and some people are willing to help me maintain the program, for example by providing Debian packaging.
I have learned a lot about video formats in general, FLV, AVC (H.264), and proper development in C which I had never really used in its pure form before, since some IT schools in France think it is a great idea to teach an hybrid form of C and C++ as first coding experience for many students.
So, until now, FLVmeta has indeed been developed in pure C. I first chose this language in order to achieve the greatest possible performance, especially because I needed to replace FLVtool2, which did not fit my needs (back then, I needed to update FLV files hundreds of megabytes large). I was not disappointed by the result I could obtain, very fast execution, and great control over the amount of memory used by the program. However, I am feeling kind of frustrated by the shortcomings of the languages, the more features I add.
The pure algorithmic parts of the code are fine as they are, it is mainly about handling structures and making choices depending on the contents of the files, lots of ifs and control structures.
What bothers me is the fact that when I need to use a non-trivial data structure (lists, maps…) there is no readily-available standard solutions, and I need to reinvent the wheel and write a container adapted to my needs, for example as seen in the amf.c file.
So I am pondering switching to C++. Many parts of the code will not be modified, however I’ll be able to make some parts more modular, especially AMF parsing, or the FLV reader/writer.
Do not expect heavy development soon, I first need to make sure the current iteration is stable enough.
The current todolist for FLVmeta has a few items:
- metadata insertion via XML command files: This feature would greatly benefit from a switch to C++, since I’ll need a robust XML parser and the ability to store the described commands as in-memory structures, which might be a little it complex.
- batch file processing: for the moment, FLVmeta can only handle one file for each invocation. The ability to work on a set of files would be a neat improvement, since a lot of video editing workflows that I have met involve working on a lot of files.
- FLV encryption support: I am not sure this recently added feature is widely implemented, but I need at least to detect whether a file is encrypted or not, since it must certainly have an impact on its playability on a variety of systems.
- improving command line processing: simply put, FLVmeta is a program that is invoked to run a specific command. However, right now, a command is specified using a command line switch, such as -C / –check. The more options I add, the more limited choices I have to find available letters for options. So basically, I want flvmeta to use the pattern of programs such as Git, where the program is just a driver for sub-commands specified right after the program name.
For example, I want to have flvmeta update –no-last-second file.flv and for example install a script such as flvmeta-update that automatically invokes the update command.
This would allow me to offer better online contextual help, like flvmeta help update, invocation that would print detailed help only for the update command.
Now that FLVmeta 1.1 has been formally released, I am going to shift my focus to other kinds of projects. I am currently learning how to program with QT, and I am certainly going to make some interesting cross-platform applications with it.
One project that would probably be nice to develop is flvmeta-gui, as the name indicates, a GUI for flvmeta. I need to conceptualize the interface of such a program, but it would certainly appeal to people allergic to the CLI, and I know a few of them, even though I disapprove their way of doing things :).
I will finish this (again) big post by promising I am going to try to post more at Zenhaven.org. I love writing, I love writing about software development, and I hope some people will enjoy reading me and react by writing (non-spam) comments !
The few next posts will be about FLVmeta and a few use cases that might interest potential users.