- About the Projects
- Prerequisites
- Planning the Projects
- Project: Navigation Cue Points in a .flv File
- Project: ActionScript Cue Points for Captions in an XML File
- Project: Basic Caption Display Template
- Project: Channeling Cue Points to the Caption Display
- Project: Code for Audio-only Captions
- Project: Advanced Captioning Template
- Project: Synchronized Images Template
- Exploring the Support Classes
- Final Thoughts
This chapter is from the book
This chapter is from the book
This chapter is from the book
Planning the Projects
Almost all the work for these projects is done in the preproduction stage. If you do a good job preparing everything, the projects will go more smoothly than a television cooking show (where everything is measured and chopped up in advance). The preparation here involves gathering the transcript of the captions that will appear and identifying the places at which those captions should appear.
After you have your captions prepared, you’ll move on to creating a few text display templates. On the surface, this is nothing more than selecting a variety of fonts to use; however, you’ll also add an animation effect for when the text changes. The text display templates you create can be used with any future project you build where you want captions. The rest of the chapter shows you how to implement the support class I built called EventChannel. It handles all the grunt work of reading in the captions and making them appear in synch with your audio or video.
I should note that captions are good for much more than simply displaying the movie’s dialogue for hearing-impaired folks (although captions obviously do that well, too). I’ve used the techniques from this chapter to display captions in multiple languages for a museum kiosk. I’ve also used the techniques in this chapter to display the lyrics for music where the singer might not annunciate the words clearly. The projects you build in this chapter can apply to any situation in which you want something to appear (such as text) in synch with your audio or video.
Cue Points and Captions
There’s one huge chore when captioning audio or video: transcribing—someone needs to type in all the text. Plus, that text needs to be segmented into blocks that both fit within a given screen space and match the tempo of the video. Preparing a transcript for cue points is nothing more than creating a text file with every block of text on its own line, as in this example:
There once was a man who loved a woman. She was the one he ate that apple for. and so on...
You simply want to make sure that each line fits in the space you’re allotting for the captions and that, when synched with the audio, the captions appear on screen long enough to read. For example, if you have space for only one or two words to appear at a time, they’d have to fly by so fast no one could read them.
The final step of synchronizing the captions with the media goes very quickly after you have the transcript prepared. With the tools I built for this chapter, you’ll see that you can identify cue points in real time while watching the video. All the investments you make to prepare the captions will make this otherwise tedious process go smoothly.
Cue Point Types
There are no fewer than five types of video cue points: Event, Navigation, ActionScript, Caption, and Marker. Although each has its respective benefits depending on your application, they’re mostly equivalent. The idea of any cue point is the same: to associate a block of information you want to appear—or, at least, get sent to your application—at a specific time in the video. Generally, the exact content for a cue point is whatever you decide. However, the exact form and where the cue point information resides are what vary in the different cue point types.
Videos produced in Flash Professional 8 (or the accompanying Flash Video Encoder) can be permanently injected with Event or Navigation cue points. The difference with Navigation cue points is that they are seekable (unlike Event cue points). That is, the Encoder places a keyframe in the video at the exact frame you place a Navigation cue point. This way, users can navigate directly to such keyframes by clicking the Next or Previous button in the FLVPlayback component shown in Figure 3.1 (which triggers the seekToNextNavCuePoint() and seekToPrevNavCuePoint() methods). You can find the FLVPlayback component by selecting Window, Components.
)
Figure 3.1 The FLVPlayback component lets the user seek to the next or previous Navigation type cue point.
ActionScript cue points aren’t permanently embedded into the FLV, which makes them different from all the other types of cue points. I’ll talk about the advantages or disadvantages of this approach in the next section. For now, just realize that ActionScript cue points are set at runtime; therefore, they require additional scripting before the video starts. (As an added bonus, the project "Implement Code for Audio-only Captions" shows you how to use ActionScript cue points with an audio source instead of a video source.)
Each of these three Macromedia cue point types (Event, Navigation, and ActionScript) have properties for time and name. The time corresponds to where the cue point appears in the video, and the name is an arbitrary string you specify. You can include any text you want, such as a caption or a description of what’s happening onscreen. Plus, each cue point has room for additional parameters—namely, as many name/value pairs as you want. In this way, you can associate more than just a single line of text with a particular cue point. For example, you could store captions in different languages such as the following name/value pairs:
name:value en:"Hello Friends" es:"Hola Amigos" fr:"bonjour amis"
Remember that you’re packing information into a moment in time; you can store just a name or as many other parameters as you want.
Finally, although the third-party product Captionate (shown in Figure 3.2) is needed to inject Caption and Marker cue points, these cue point types are definitely worth including in this list. Captionate Markers are simple: They’re just text labels associated with a moment in time. However, Captionate Captions are similar to Macromedia cue points because they have room for additional, optional information (in addition to the caption itself). Captionate Captions also let you identify a speaker (that is, the person talking) with each caption.
)
Figure 3.2 The Captionate interface lets you inject captions and markers.
In fact, Captionate’s Caption type of cue point supports multiple tracks for multilingual applications. You could probably squeeze this same kind of information into the Macromedia cue point format (Event, Navigation, or ActionScript), but the logical and convenient structure is already built in to the Captionate Caption cue point. (If nothing else, you’ll want to get Captionate because it lets you modify any cue points—including Macromedia ones—embedded in the .flv file; otherwise, these are uneditable.)
You can use any or all of these cue point types in a single video. You can also write code that responds to each type differently, perhaps displaying Caption cue points in a text field and then using Event cue points to jump to a different frame in a movie clip. Instead of learning the different syntaxes to handle all the cue point types, the projects in this chapter channel all the cue points through a single clearinghouse: the EventChannel class. This class triggers events in your project for every cue point type you want to listen for.
Embedded Cue Points Versus Separate Text Files
One of the coolest features in Flash Professional 8 is that, during the video encoding stage, you can embed cue points right into the video. As great as this feature is, though, it does have some disadvantages.
The biggest problem with embedding cue points into the video is that they’re uneditable after the .flv file is encoded. (Well, the excellent third-party application called Captionate does let you edit cue points.) Although embedded cue points might be convenient because the data and video stay together, the data isn’t left open for easy access. The alternative is to keep all the details of your cue points in an external source, such as an XML text file.
Saving cue point information in XML (a separate file from your video) can have its advantages. For example, if you have the same video encoded for different bandwidths, you can use a single XML file for the cue points. After all, the captions are the same for each bandwidth, so making an edit involves just one file instead of each .flv file. Plus, as you’ll see in the tool I built for adding cue points, there are more convenient ways to specify cue points than through the Flash video encoder’s interface. For one thing, when specifying cue points in Flash, you can’t hear the audio track, which makes finding cue points very difficult indeed.
As great as storing cue point information in separate files is, if you choose that approach, you have to perform the additional step of importing and parsing the data. Also, although the FLVPlayback component has an addASCuePoint() method (to inject ActionScript cue points at runtime), you’re pretty much taking a home-grown approach that might not match other developers’ ways of working. I should note that, even though the only logical format for an external file containing cue point information is XML, the exact structure of that file (that is, its schema) is up to you. As long as you leave room for all the cue point types, the exact schema is completely subjective. However, for this project to work, you have to use a single format. The structure I’m using is based on the output from Captionate—which, I suppose, makes this format "better" only because it’s consistent with another product.