Source Files?

If the video file only contained the series of bits that needed to be fed into the video buffer to produce the moving image, then, yes, it would be fairly trivial to write a program that imprints a particular overlay onto the video image. It's more complicated than that, though. For one thing, let's say your "2003" text didn't have perfectly sharp edges (i.e. it's antialiased). Then you're going to need some sort of edge detection to make sure that you're changing video values within the boundaries of the text. You're also going to need some way to add in the background information so that pixels that were in the "2003" but were not in the "2004" could be built up by looking at what the background is, over time (this could get hairy). The real problem, though, is encoding. Most files, especially video and audio files, use heavy duty encoding to reduce the filesize. For instance, http://www.recordingforums.com/articles/mp3encoding.php. This sort of encoding can't be easily changed without: 1. Decoding the encoded file (sometimes it would be possible to only decode part of the file. sometimes not.). 2. Doing whatever manipulations you want to do. 3. Reencoding the file. So you see, this sort of manipulation gets hard to do pretty quickly. On a side note, one of the reasons things like XML get so much hype is that XML data files are (usually) human readable. XML rocks for text and numerical data, but is not so good for image, sound or video.

The more general question is: why is it so rare to find programs that can manipulate binary files? If you want to change the wording of some text in a swf file, why do you have to go back to the source fla? I'm not too sure of swf, but for most binary software you can change some text using a 'hex editor'. I've seen some video games translated from Japanese to English by people without access to the source, by just manipulating the binary file. The problem is the results might be unpredictable and introduce bugs and crashes. Could you edit some wording in a swf file? Probably. If it was your own program it might be simpler to have the program grab text from a human readable text file, then you wouldn't have to recompile each time you change some text.

Thanks for all your answers, folks. Bobo, I'd assume that the reason a hex editor would likely introduce bugs and crashes is because the user wouldn't know anything about the structure of the binary file he was editing. Most binary editors are presumable "hacking tools," not made by the vendors of the original software. But here's a different scenario: how hard would it be for Macromedia to make a program that would let you edit a swf and, say, change some text. Macromedia created the swf format, so presumably they know what would be safe to tamper with and what wouldn't. I'm imagining a tool that wouldn't show you hex or binary. It would be have a GUI that would list all the text stored in the file and allow you to make changes. I'm not sure I would actually have use for such a file. I'm just interested in how hard it is for the original programmers to reach into their own binary code.

I think the problem is that depending on how the video is encoded and compressed, they might do things such as for a particular frame, only encode what has changed since the last frame, in order to save space. Therefore if you change one frame, you need to change the previous frame and the next frame, and the one previous and next to that one, and so on, and can get pretty messy so it's a lot easier to decode the video into a format that is easier to change and then reencode it. Sorry this is just an educated guess based on some CS courses I've taken but I think it's correct.

I'm not sure I would actually have use for such a file. I'm just interested in how hard it is for the original programmers to reach into their own binary code. It wouldn't be hard for them to read any given data from an swf file, since they have the spec for the format. I'd guess that they probably already have some in-house functions that can translate human-readable data to and from swf files. This said, I agree that if they were going to make an "swf editor", they would most likely decode the entire file, allow the user to make changes, and then reencode everything to a new file. They probably would not edit the original file in-place. If you know enough about a binary file's format to fully decode it, editing it in-place usually isn't worth the extra trouble. As gyc and bshort note, the amount of extra trouble can become pretty large when you're talking about video files. By the way, I found a http://www.srctec.com/flashdecompiler/ that you might like to play around with. I know that the swf thing is just an example, but it might be a fun way to get an idea of just how much a programmer can get out of a binary file, given some idea of the format.

In general, a compiler translates source code into binary and in the process makes all sorts of http://en2.wikipedia.org/wiki/Compiler_optimization which may render it unreadable and in fundamental ways different than the more readable source code. Compilers are optimized for the particular platform they run on and being able to reverse-engineer what the original algorithm was from a long series of arithmetical functions is almost impossible. That said, it depends on the degree of optimization and data stored within the file (such as text, clips etc) is just that, data, and is more easy to manipulate in a binary than code.

The real reasons programs are designed to have separate "source" files are twofold: 1) The source file can contain material that you would not necessarily want to distribute with the final version of the file for a number of reasons, e.g. performance, file size, etc. You might want to compress graphics for distribution, for example, but you sure wouldn't want to keep them in JPEG format while you're working on them, as each load/save cycle would reduce quality. And comments in a compiled program would be dead weight, since the computer ignores them. 2) Having separate source and object file formats provides a modicum of protection for digital content. People can't easily modify your SWF files to claim credit for them, for instance, or steal your proprietary Flash tricks for their own work.

But here's a different scenario: how hard would it be for Macromedia to make a program that would let you edit a swf and, say, change some text. Macromedia created the swf format, so presumably they know what would be safe to tamper with and what wouldn't. How hard it would be depends a lot on the specific structure of the binary file. bobo123 brought up some good points on that. One specific example: consider a binary file that contains some text you want to change. The text is stored as a series of bytes. The program expects the section of data where your text lives to be packed in a certain way, each entry in a long list of text files to be a specific length and exactly FOO bytes into the binary file. When some part of the program refers to that bit of text you want to change, it looks counts FOO bytes into the file and then reads BAR bytes, the exactly length of the text in question. Now, assume you go in and change the length of that specific bit of text. Say your new text is three bytes longer than the old text. Now every bit of data in the binary file after that is going to be three bytes out of place. Any attempt to read any of that data is going to lead to nasty corruption. And the program might still be expecting the text you've changed to be it's original length, which might lead to bad things happening when it tries to manipulate the text you changed. And maybe the text you changed is used not only as text for being displayed on screen, but also as a bit of unrelated data for some other portion of the program. Even if you replaced the text with some other text of the exact same length (avoiding some of the previous issues), you've fucked the program elsewhere. And so on. Binary files are, generally, a tool for trading flexibility/accessibility for compactness/security/efficiency. With specific exceptions (raw binary files, such as uncompressed images, uncompressed audio), a binary file isn't made for editing so much as for just Using as-is.

All valid points above, but I think the most significant reason is just that if there is a source format for some file, most people are going to be working with that, and so the demand for an object-file-manipulating tool is small. The source format is designed to be manipulable and understandable, so it's almost always going to be easier to perform a given manipulation on the source than on the object. With respect to Flash, I remember some parts of the SWF format from reading a reverse engineering project's notes, and it wouldn't be impossibly difficult to write something to tweak a Flash file. The most general solution is probably to write a decompiler, though. With respect to video, I think mplayer can add overlays while 'displaying' into a file (I know it can do each operation independently, I assume it can combine them). You'd probably lose some quality by decoding and recoding the video, unless one or both of the formats were lossless, but you could add the overlay. Some formats, like PDF, are designed to be easy to manipulate in certain ways. In any case, any object file is designed to be read by some software somewhere (a video player, a Flash plugin, the OS that runs a program, etc.), and so that software, and that software's author(s), must understand the structure of the file.