FLV Metadata injectors shootout
My quest for a FLV metadata injector started in early 2007, when I was tasked to implement random-access seeking for video files played via a Flash media player and encoded in-house using ffmpeg. I realized quite fast that I needed to inject specific metadata, keyframe times and positions. So I tried flvtool2, which performed quite bad on the large files I had to handle.
So I started the FLVmeta project, as I needed much better performance than flvtool2, especially in terms of memory consumption and processing speed. I was not aware of the existence of any other tool, except the Windows only flvmdi, but I needed Linux compatibility.
Since 2007, I learned about a few other programs, and some appeared over time. Here I am going to review those that I know, and compare them to FLVmeta when possible.
This is the first tool I found (has there ever been an FLVTool ‘1’ ?). It is an open-source Ruby program developed by German developer Norman Timmler since 2005, with the last official release being 1.0.6, in february 2007. It is still somewhat maintained and forked on Github though, albeit only to improve packaging.
It is a quite powerful utility, boasting interesting functionalities such as batch processing, directory recursion, command chaining, FLV files cutting, onCuePoint tag insertion via XML files, insertion of custom onMetaData key-value pairs, meta data printing in XML or YAML format, in addition to metadata computation and insertion.
It is available as a Rubygems package, and can be simply installed by typing:
gem install flvtool2
What makes this tool powerful is the fact that it entirely loads the file in memory, and then manipulates it at will in memory before writing it back to disk. This is a double-edged sword, because it means even huge files will be handled in that way, causing performance issues. That was especially true in 2007, when servers had much less RAM than nowadays.
There is also an issue with raw performance, as Ruby is not a fast language.
- powerful features
- portable, easy to install
- open-source, with permissive BSD-like license
- slow, and memory inefficient
- not actively maintained, might not be up-to-date concerning the FLV format evolution
I found this tool approximatively at the same time as FLVTool2, but as I said earlier, I discarded it immediately because I needed a tool that could run on Linux servers.
It is a closed-source Windows proprietary software, available free of charge, developed by Burak Kalayci, part of Manitu Group. Development most likely started in 2004, before FLV and AMF specifications became widely available, so this was a great job from the start. Latest version is 2.96, released in March 2010. A Windows graphical frontend named FLVMDIGUI is also available from the same website.
The most interesting feature of FLVMDI is its ability to not only inject keyframe information, but also a set of standard metadata properties used as hints for players and for flash code. FLVMDI is pretty thorough, and can guess the resolution of the video stream for pretty much all supported formats, including H.264 since 2010. As a side note, H.264 support was added to FLVmeta in 2009, albeit with a few limitations that have been solved by a contributor since then.
Unfortunately, the program’s performances are not quite impressive. Even though it’s faster than FLVTool2, it uses up to twice as much memory as the input file size, which is even worse than FLVTool2.
According to the author, the maximum file size FLVMDI can handle is around 700-750MB, and the maximum FLV duration is about 4 hours. An hypothetical 3.0 version is mentioned, but it seems unlikely to be released any time soon.
It would be interesting to have access to the program’s source code, however the authors mention that it makes use of a proprietary FLV library that they do not want to release. There are also restrictions on the redistribution of the package that make it not exactly “freeware”.
- able to inject many useful tags
- has a GUI frontend
- Windows only
- very inefficient memory usage
- unable to handle large files
- not actively maintained since 2010
- proprietary software
The first of two tools with the same name. I found this one while starting FLVmeta. It was developed in 2006 by Andrew Brampton as a C++ re-write of a FLVMDI and FLVTool2 because of the lack of large file support in those tools. It was released under the terms of the BSD license. I could download a version of the program’s source code in 2007, but since then, the author has removed all download links, and it will most likely never be updated or released again. For those interested, I can provide the code source that I have in my possession, but I will not make it publicly available unless I get clearance from Andrew.
flvtool++ compiles cleanly on Unix systems by using a provided Makefile, as well as on Windows, with a Visual Studio project.
It features fast metadata injection and a small memory footprint while supporting large files, basic metadata and FLV tags dumping, as well as arbitrary file cutting.
I haven’t spent much time evaluating it because I encountered some random crashes when testing this tool with sample FLV files.
- open-source with BSD license
- fast with a small memory footprint
- large file support
- compiles and works in Linux and Windows
- not maintained anymore, completely unavailable as of 2012
- the most recent version crashes often (at least for me)
flvtool++ (Facebook version)
The second tool with the same name. It was originally created by Dan Weatherford from Facebook for their video project, but has been since then abandoned upon reaching version 1.2.1. It is now maintained by a third-party developer named Andras Elso, on Github.
It is another C++ program directly inspired by FLVTool2, with the same goal as its namesake. This program has originally used Scons as its build system in order to be portable, and depends on the Boost library. It is therefore a little bit trickier to build than other tools, even though Andras Elso has recently added basic support for CMake.
It has the standard functionality to inject metadata, dump those when done, and several options to control output file generation. However, as a relatively straight port from FLVTool2 it operates from memory, and suffers from the same problem as the ruby tool. It is also unable to handle large files.
- open-source with BSD license
- uses the powerful Boost library, so should build and run anywhere
- maintained, but not by the original author
- depends on Scons and Boost for compiling, might not be trivial on Windows
- SConstruct file uses deprecated methods
- no large file support
- memory inefficient
Yet Another MetaData Injector. This is probably the most popular metadata injector besides FLVTool2. It is developped by Ingo Oppermann as an alternative to FLVMDI and FLVTool2 with the specific goal to be very fast and able to handle very large files. Just like FLVmeta, it is written in the C language, but with an emphasis on the Linux platform. The latest available version is 1.9, released in December 2012. It is also released under a BSD-like license.
yamdi offers standard standard injection functionality, and boasts compatibility with even the H.264 video streams to compute video size. It is a pretty fast tool that is quite memory efficient. It is also one of the few tools that can correctly handle extended timestamps. It should be noted that FLVmeta was the first of the two that got the aforementioned features. It seems both tools follow a quite similar parallel evolution 🙂
My personal preference goes to FLVmeta, because of a larger choice of commands, notably dumping and checking, but yamdi does a pretty good job as an injector.
The main problem with yamdi is that it does not compile as-is on Windows, and as of 1.8 needs cygwin to be compiled and run on that platform. A Makefile is provided for Mingw32, but it does not compile successfully. There is only one Unix Makefile provided, which can bring compatibility and small performances issues. For example, in yamdi, endianness is checked at runtime, while for FLVmeta, this is the job of the build system, CMake or autotools, and once determined, there’s no runtime overhead.
The code source is comprised of only one C file, which I don’t like much, because it limits readability, modularity and probably makes the whole code harder to maintain.
- great performance, low memory consumption
- open-source, BSD-like license
- actively maintained
- exhaustive injection features
- compiles and installs easily on Linux
- large file support
- no native Windows compatibility, Cygwin only
- lacks a decent build system
- only one big source file