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:

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:

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.

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.

If someone reads the aforementioned specification in detail, there’s one thing that will immediatly be noticed. The specification is not about FLV, but FLV and F4V.
What is F4V ? In a nutshell, it is a subset of the MPEG-4 standard destined to be a container for video, audio, and various metadata. Exactly what FLV is supposed to be too, you’ll tell me. That’s only partly true. FLV has a few limitations as a media container.

First of all, FLV fails as a streaming format. Ok, it’s widely used on major sites like Youtube, dailymotion, and many others, but it’s not true streaming, because all it does is playing an already existing file, not a stream generated on-the-fly, and playing continuously, like a TV channel.
Even for random access seeking, an encoder producing FLV files has to add some specific metadata, that tell the player where it can seek.
Some tricks are needed on the server side, like using specific modules for the web server (eg: mod_flv_streaming for Lighttpd), or using some scripting, in PHP or other server languages.
Unhappily, free encoders like ffmpeg or mencoder are unable to add those precious metadata while encoding the files.
That problem drove me to write the FLVMeta tool, that precisely does this, taking an existing FLV file to update with the needed metadata. To be fair, there are several existing tools doing the same thing, but none of them worked well enough for my taste

Another problem with the FLV format is that each frame belongs to its own “packet”. Every frame is accessible in a standalone way, even when a frame is not a keyframe, a frame containing enough information to be fully rendered, without relying on information from previous frames.
That means that a FLV file can only contain video data that can adapt to that layout. Basically, a FLV file can contain video data that belongs only to a hard-coded list of codec families, like Sorenson Spark and ON2 True Motion VP6. Unfortunately, Sorenson Spark, derived from H.263, is outdated and is not on par with the modern codecs in terms of image quality. On2 VP6 is much better as a codec, but is a proprietary format, and it’s known that On2 is not exactly friends with people who try to implement their format.

On the other hand, H.264 has been implemented as Free Software, like the encoder x264, even though the standard is encumbered by many patents that can be enforced in countries like the USA. H.264 has already superseded Divx as a highly compressed movie format, and is expected to be used more and more as a streaming format.

Therefore, realizing the limitations of the existing video formats, Adobe chose to implement H.264 in its Flash Player software.
However, as the FLV format is unable to contain H.264 video, Adobe pushed a variation of the MPEG-4 multimedia container format, and heralded it as its new champion, the F4V format !

This “new” format is able to contain any video and audio format, leaving more space for Adobe if they wish to widen their offer. It is also able to contain more diverse metadata, for instance in the recently introduced AMF3 format, as FLV was limited in being only able to contain AMF0 encoded data.

So, the most recent Flash Player (version 9.0.124.0) supports both H.264 playback as well as F4V. It’s only a matter of time before developers will upgrade their Flash authoring tools to versions able to output Flash9 files, using ActionScript 3. And then, will there be a reason to continue to support FLV ?
I’m pretty sure that the major players in the league will switch to H.264, to avoid paying license fees to On2, and to provide better High Definition contents.

So what will be the point of keeping on using FLV ? Pretty much none, in my opinion. Maybe the F4V format is somewhat harder to implement than FLV, but most of the existing encoding software will just have to adapt their already mature MPEG-4 code, making the F4V format even more well supported than FLV is today.

So yes, FLV is dead, long live F4V.

PS: Fear not for FLVMeta, I’ll continue supporting it and developing the latest 1.1 version, FLV will be around for a few months at least, but I will focus my efforts on developing my AMF0/3 parser/serializer libamf which should allow C and C++ code at least to fully support Adobe’s metadata.