If, like me, you have to work with a bunch of .fla files that have to be published regularly, then you have certainly realized that working within the Flash IDE is far from optimal.
First of all, opening an IDE to publish a file with all the clicking involved is far from the Unix philosophy that I have learned to appreciate for a long time (
./configure && make && make install…).
Also, apart from navigating through menus to publish a SWF, the keyboard shortcut that performs the same operation is a little bit contrived (
Multiply this by a large number of .fla files, and you get an insufferable mess.
This post will introduce a method to automate SWF publishing in a certain measure by leveraging the JSFL API and the Ruby programming language.
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.
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.
Source code and binaries can be downloaded at Github or Google Code.
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 been using SVN for years, basically since 2004, when I got really fed up with CVS, which was used at my work back then. What seduced me in SVN was the ability to easily configure it as an Apache module, coupled with our central LDAP authentication, and SSL encryption, and its ability to track file renames/moves.
I also enjoy its wide platform compatibility, as well as its excellent windows companion tool : TortoiseSVN, which works wonders compared to the horrible WinCVS.
It took me a little bit of time to fully understand the benefit of atomic commit numbers, as opposed to file versions in CVS, as well as the directory structure used to simulate branches and tags (seems like implemented as an afterthought, doesn’t it ?).
Then came the DCVS. (more…)
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
FLV is dead.
That can seem like a rather bold statement, but let’s face the truth. After Adobe’s recent publication of updated and open specifications for the FLV/F4V and SWF formats, that seems to be about the most logical conclusion. (more…)