SWF and FLV (and later F4V) were once dominant formats for online videos, including marketing content, e-Learning courses, and online sites like YouTube and Hulu. They’re also, however, buggy formats, SWF most notoriously, and they created problems for video translation projects like subtitles and dubbing.
In today’s post we’ll look at what phasing out FLV and SWF means for localization, and how to prepare for it.
[Average read time: 5 mins]
FLV and SWF – a history
FLV and SWF became ubiquitous formats as Adobe Flash, Premiere and After Effects started to dominate the market for online video.
FLV was generally used to compress larger video content from SD or HD sources, so that they could be played, or streamed, over the internet. Because the format interacted seamlessly with Flash Player, and Flash Player became ubiquitous, FLV did as well. FLV was also an OK format – it supported codecs that could compress video at low bit rates but still maintain a decent image quality.
SWF (pronounced “swiff”) has a very different story – it was created initially by FutureWave Software in 1996 as part of a program called FutureSplash Animator. Macromedia bought the program that same year and called it Flash, and the format Shockwave File (they already used “Shockwave” as a brand) – thus the name SWF. Adobe bought the program after that, and retained the naming for the most part. The SWF format used a very low frame rate of 15 fps and compressed audio at low bit rates, which meant that the files were minuscule, and could be downloaded over dial-up or low-bandwidth connections. It didn’t render video very well, however, meaning that SWF files could not be localized easily (or sometimes almost at all) without source files.
So why did Adobe discontinue them?
In a nutshell, better formats came along.
HMTL5 pretty much killed the SWF – the new specification is more stable and uses less bandwidth than SWF-based file structures. The backwards-compatibility issues with SWF were also addressed by HTML5. The death knell came when Adobe “discontinued” Flash and replaced it with Animate CC, which has HTML5 output but no SWF.
As for FLV, newer formats like MP4 (and the intermediate F4V) came along that were more secure, supported more codecs, and integrated better with online content (including HTML5). Thus, Adobe programs no longer support FLV: Adobe Media Encoder, Premiere and After Effects CC won’t output to FLV any more, though they'll still import it (for now).
The problem for localization
Translation often deals with legacy content that may be a few years old – meaning that you may see SWFs, FLVs and F4Vs. There are two main scenarios in which you may encounter them:
1. Published e-Learning courses
If you work in e-Learning, you’ve seen folders like this one:
It looks intimidating, but fear not – in the root folder, there should be an HTML (.html) file that you can click, usually called “story” or “index,” which will call up the course and play it in a browser like Chrome or Firefox.
e-Learning authoring programs have been publishing to SWF files for several years – Flash, of course, was the first program to use it, and Articulate, Articulate Storyline, Presenter and Captivate all followed suit. Fortunately, most e-Learning software is embracing HTML5, which uses a combination of graphics and audio files, so that legacy courses can re-publish in this format with minor tweaks.
2. Legacy video content
This is where you may run into some trouble. Because Flash, Premiere and After Effects interfaced so well with FLV files, a lot of legacy content is saved as FLV. This includes videos incorporated into e-Learning courses, video games, marketing videos, and just about any other non-broadcast video environments.
For example, picture this workflow: an editor cuts green-screen footage in Premiere, then outputs the cuts as FLV files. Those are then imported into After Effects to add the backgrounds, and then the composited videos are output as FLVs once again. Those videos are then compressed at a lower bit rate for internet use – again, as FLV files. You now have a workflow completely dependent on FLV files, which also outputs to FLV files.
How to deal with legacy FLV content
There are three options:
- Work in legacy versions of the software. While the CC versions of Adobe programs don’t support FLV, CS6 and earlier do. If it’s absolutely necessary, it’s possible to work in legacy version of the software, but we don’t recommend this. Adobe is no longer updating these formats, which makes them vulnerable to attacks from hackers, and the legacy programs themselves don’t get updated either, so that they’re vulnerable and slower.
- Get the source files and re-export. Always recommended for any video translation project, and in this case, it’s especially useful. In the above FLV workflow scenario, getting the source Premiere files (top of the workflow) would allow a localization editor to output in a format other than FLV – something like MP4, which is like a next-generation FLV (and fully supported by Adobe). The editor would then re-link the MP4 in the After Effects source, re-key if necessary, and export once again to MP4. Keep in mind that any environments that used this video – from LMS, to websites, to video games – would have to be updated as well. But this would resolve any issues from legacy files, since even though Adobe programs can still import FLV files, they no longer export to them, and there are plans to completely phase out FLV. Thus, a complete workflow refresh is best.
- Re-encode assets. If source files aren’t available – for example, if all you have are the final FLV files – then re-encoding is necessary. Fortunately, Media Encoder still imports the FLV format, and can output it to MP4 or another fully-supported format.
Any one of these processes will add a considerable file prep time, especially since re-encoding the video files may cause small issues with the rest of the workflow – for example, keying or titles may have to re-done on the videos, or code may have to be tweaked in final environments. It’s also good to plan for a QA of the re-done English during file prep, to make sure that it is completely bug-free before localization. Otherwise, mistakes will have to be fixed in multiple languages. The key, as with any localization project, is that proper prep is crucial if you want to avoid issues during the project – and even more so when dealing with legacy FLV and SWF files.