After a few months of development, FLVmeta 1.1 is nearing completion.
Snapshots can be downloaded on the Google Code project page at: http://code.google.com/p/flvmeta/downloads/list
A lot of new features have been added, here is an exhaustive list:
- Added proper command line handling and help.
- Added the possibility to overwrite the input file when the output file is not specified or when both files are physically the same.
- Added support for CMake builds in addition to autotools. It is now the official way to build flvmeta on Windows.
- Added metadata and full file dumping, integrating former flvdump functionality into flvmeta.
- Added support for XML, YAML, and JSON formats for dumping.
- Added XML schemas describing the various formats used by flvmeta.
- Added a file checking feature (currently unimplemented).
- Added the possibility to print output file metadata after a successful update using one of the supported formats.
- Added a feature to insert custom metadata strings while updating.
- Added an option to disable insertion of the onLastSecond event.
- Added an option to preserve existing metadata tags if possible.
- Added an option to fix invalid tags while updating (this is a highly experimental feature, should be used with caution)
- Added an option to ignore invalid tags as much as possible instead of exiting at the first error detected.
- Added an option to reset the file timestamps in order to correctly start at zero, for example if the file has been incorrectly split by buggy tools.
- Added an option to display informative messages while processing (not quite exhaustive for the moment)
A few things are still missing for the next stable release, for example some proper user documentation, now that a complete set of command line options are available, as well as the implementation of the check command.
Everyone is welcome to test the software and report bugs on the issue tracker.
I’m also still pondering the benefits of using gettext in order to fully internationalize the output of the program. On one hand, there are many people who don’t speak english, and adding the potential to reach a wider audience is tempting. It is also a must-have in order to be featured in distros like Debian.
On the other hand, I still have issues with building flvmeta with gettext enabled. First of all the cmake/windows combination would be kind of experimental at best, and using autotools, I still need to fully understand which files must and must not be added to the repository.
There’s also the question of performance, since flvmeta is mostly used as an automated tool for update purpose. Dynamically loading strings in that setting is kind of pointless since speed and memory can be affected and there’s noone to ever read those messages anyways.
After version 1.1, which is transitional in the sense that it really represents the maturation of flvmeta into a real CLI tool, a 1.2 version will be in development.
Features expected for 1.2 include:
- insertion of custom data tags, notably cuepoints, from XML files
- extraction of individual audio and video streams
- creation of a GUI tool wrapping flvmeta’s functionalities, and adding a bit more, like batch processing, and integration with various file managers (Nautilus, Windows Explorer ?)
- eventually a streaming mode, to create some sort of “real time” playback of FLV files to devices or sockets, which could really be interesting in conjunction with a HTTP server, to better control bandwidth usage when using the now widespread “pseudo-streaming” of FLV files
To add a quick follow-up to my previous post, I might add that… no, FLV is not quite dead yet, since H.264 streams in FLV containers are working quite well in the Flash Player, and major sites have adopted that combination.
I think we also might even expect support for On2 VP8 in FLV files before the end of the year. If Google really open-sources its code, alternative flash implementations will certainly jump the wagon before maybe even Adobe.
Of course, due to Adobe being a major On2 licensee, as well as thanks to the rather good relationship between them and Google, the official Flash Player might support this codec fast enough for it to become a viable alternative to the increasingly controversial H.264.