JPEGPush - Grabbing out particular frames

Difficulty level:
Information for:
                     
surfer
"John Doe"layman
expert
 
web-master

[ Language ] :: [ Main Index ] :: [ Site Navigation ] :: [ Tutorials ] :: [ Downloads ] :: [ Contact ]

I mention at article about Java videos that you need not to build a player for technologies as JPEGPush, because their video-files are just frames as valid JPEG images stuffed together into single-file. I have planned to shows you this kind of player, but that one, I have had been interesting of, is patent pending.

Anyway, here is the link for a part of sample video-file it is playing. As you will see, sometimes it is unnecessary to build up its own player and capture screen to obtain classic video file. In this one, we are going to extract all frames and then weld them together into animation.

 

Download this file (it is a 225 kBy cut from its original more than 14 MBy length) and open it in any binary viewer or editor. FHex, or BinEdit are nice freeware applications you can use for this purpose. BinEdit is more suitable, if you want to try extract data as I am going to describe later. If you use any Norton Commander’s clone try to press F3 and some kind of hexadecimal dump should open.

Hexadecimal numbers are usually written in form used at language C. For example FFh, which means 255 in decimal system. I will use a Pascal form – instead of postfix ‘h’, I will write prefix ‘$’. Two and four bytes numbers can be written in Intel or Motorola form. Intel form, where bytes are in reversible order (the lowest byte is first) is more popular. However, this is irrelevant, now.

00000000:12 2F 08 B4 6B 04 66 FF D8|FF E0 00 10 4A 46 49|°/°´k°fÿØÿà°°JFI
00000010:46 00 01 01 00 00 01 00 01|00 00 FF DB 00 43 00|F°°°°°°°°°°ÿÛ°C°
00000020:0D 09 0A 0B 0A 08 0D 0B 0A|0B 0E 0E 0D 0F 13 20|°°°°°°°°°°°°°°°
00000030:15 13 12 12 13 27 1C 1E 17|20 2E 29 31 30 2E 29|°°°°°'°°° .)10.)
00000040:2D 2C 33 3A 4A 3E 33 36 46|37 2C 2D 40 57 41 46|-,3:J>36F7,-@WAF

Picture 1: Hexadecimal dump of the file "Ann.vsq" - part from the begin of mentioned file

First two bytes (see picture 1) are total numbers of frames. Next byte is clip’s frames frequency per second (i.e. 8 fps). And following 4 bytes are checksum – the Adler checksum, to be strict. And also a reason, why I decide to wrote about this. Well, player is programmed to stop playback, as soon as that checksum is matching. So, it is not necessary true, that you must see a full clip. But you can still download to cache everything. Or even download it through Net Transport, because the simple HTTP shorten URL is used.

In fact, in this one you will see only the first 59 frames – which is count of the first chapter. But scene contains more than 4650 frames. Very elegant blockade – after you pay, they will send you a new self-destructed player, which does not control a checksum at all.

So, we have three possibilities – except payment, of course. We can calculate a checksum for full clip – this is very hard task and high-level intelligence exercise, because in most cases we have no idea which one algorithm among that almost 30 existed, is in use. We can crack player to ignore this value – it is much more easy, when you have correct tools, knowledge and experience. Or we can extract all frames, because they are valid JPEGs – as string JFIF suggested.

CRC is an acronym of Cyclic Redundant Check – a method originally developed for military transmission checking. It can only say if the transmission has been (probably) error-free. It cannot repair eventually errors. In general, the probability that checksum will not recognize modifications is, at maximum, inverse to number 2 powered on its bit-length (e.g. 1:2^32 = 1 : 4294967296).

There are a few criteria to compare and choose the right algorithm. The most important are its speed, minimal data length and computations robustness (severity for implement to hardware-only devices). Presently are widely use the following:

CRC32, or CRC16 are good for general purposes. Adler and ELF checksum (both 32-bits) are extremely quick because of simple algorithm. However, they need at least 0.5 kBy of binary data to achieve desired probability. MD4 and MD5 are used only at cases, when “zero-tolerance” is needed. They achieve their 128-bit accuracy even on single byte. But they algorithm is really complicated.

Back to our file. What is JPEG, by the way? JPEG is name of Direct Cosine Transformation (or DCT) loose compression and two special loose-less processes for real-world true colors images. Nothing else has been norm by ISO, back at 1982. JPEG file is almost always a block, or segment based file built according to JFIF by C-Cube Microsystem. JPEG is acronym for Joint Photographic Expert Group, JFIF means JPEG File Interchange Format. Sound similar RIFF? – it should, it is also short-name. So called mathematics JPEGs which use Iterative Fractal compression (IFF) are very rare – thanks to patent of IBM and its hardware severity: it can spin up fans even on present processors. The same can be said about Wavelet JPEGs or JPEG2000: their problem is that no free tools for converting into are available.

JFIF file (see picture 1) always start with Start of Image header: it is two bytes $FFD8. The last two bytes of file represent End of Image header: they are $FFD9.

In classic JPEGs the JFIF Application header follows immediately after SOI. It is marked by two bytes $FFE0, followed by two bytes represent its length (usually $0010, because almost no one puts image preview directly to header), and then with clearly visible string ‘JFIF’. Next byte is always zero, and next two bytes defines file version: e.g. version 1.2 will be marked as $0102. After this application segment usually follows segment with Huffman table’s definition ($FFC4) and segment with Quantization matrix ($FFDB) and finally baseline JPEG segment called Start of Frame ($F0C0, rarely $FFC1).

This has been true at golden old times. Presently, you can encounter that there will be concrete application’s specific data on the beginning. It is also not rare situation that there is an Exif block as the very first. And, to be more funny, there is a possibility of using more JFIF Application headers in the single file.

Any parser should be able to handle this. It should figure out for itself where the file begins, how to initiate decompressor and where are particular image data. For us, it has only one big advantage: when we will copy accidentally more bytes – I mean, that if our file will not finish with $FFD9 – nothing happened. It will be legal image.

Picture 2: Cutting-out the first 7 bytes at BinEdit.

Do you want to try? Open the video-file in any hexadecimal editor. I suppose, you use BinEdit. You can use also FHex but it has more complicated entry in Find dialog box. As the first save it under different name – you should do it always. Then allow file editing by switching on Edit > Write mode enabled (or press Alt + R). And finally cut the first seven bytes, so you file will start with sentence $FF $$D8 $FF $E0 etc. (see picture 1 or picture 2): click on the first byte, press Ctrl + Shift and click on the 7th byte. Selected part will highlighted (see picture 2) and you can cut it. Save as JPEG if you want to, or just save it and open it in your favorite viewer. I personally use IrfanView, but browsers like Microsoft Internet Explorer or Opera also opens JPEGs. You should see a first frame of whole video-sequence.

All present format behave like this. Including all images, music files, most of video and animation formats and also a lot of applications documents. This behaviour you can use for simple camouflage, or fake, or hidden files a front of hungry eyes or mail-client’s restrictions. But be aware: do not be surprise if someone calls you to responsibility for this kind of fun! And do not use Microsoft Excel sheets – they are self-repaired.

Take, e.g. any JPEG and any MP3. Say they names are a.jpg and a.mp3. Join them binary at DOS window: “copy /b a.jpg+a.mp3 b.mp3”. Now, when you simply double-click b.mp3, your player will start play the music – exactly as it has been just original a.mp3. When you drop it at e.g. IrfanView window, you will get a warning that it is a JPEG with incorrect extension. And your image will be displayed.
When you have none, please download this image (a.jpg) of harmonic colours (4 kBy), this sound (a.mp3) of women calling "I'll be out soon!" through doors (10 kBy) and resulted binary joined file (b.mp3) you can drop to image viewer as well as to player (15 kBy).
If you are not familiar with DOS console (look e.g. here), use FHex and its File > Append file ... command.

Maybe it is a time to explain you, why am I telling you all of these stuffs. Because, I personally think, you have to know them to not fall into any trap. What can you enter into the Find edit box? There can be a few $FFD8 pairs all over binary file. Not necessary all of them are beginning of JPEG. There can be a few ‘JFIF’ strings close each another. All of them will belongs to the same file. There can be an Exif block on the begin, followed by remark like “This file has been written with Adobe Photoshop ver. 4.0” and later will be another two segments with Adobe Photoshop settings. And just after all of that stuffs, there will be at last an application header with mentioned string ‘JFIF’.

Picture 3: Finding the beggining of the next JPEG header.
Please note, that there are two bytes, in concrete $0D1A, between the end of previous JPEG image (bytes $FFD9) and the begin of the next JPEG image (bytes $FFD8).

So, we are going to extract. If you did not cut out the first seven bytes as described, do it now. Click on the first byte – it should be $FF – and choose Edit > Find. Select Find Hex and enter ‘ffd8ff’ – as we know, this is a start of JPEG image ($FFD8) and first byte ($FF) of next segment. Because, this next segment can be anything, we do not specify it further. If you use FHex, enter "<bh:ff><bh:d8><bh:ff>"! Press Find and the next header should be highlighted (see picture 3). As we can see, bytes before it are not $FFD9 – i.e. end of JPEG image but $0D1A. For curiosity it is an empty new line. Click on byte $1A, or $D9 – no matter which one, but if you select $1A you will save your work later – drag the window possition to the begin of file by dragging a vertical scroolbar, press Ctrl + Shift and click on the first byte $FF. Selected block is JPEG – just cut it to clipboard, open a new empty file, paste it at inserting values mode and finally save it as e.g. 001.jpg.

Repeat it once again – you will cut to clipboard a second frame – and save it as 002.jpg. And so on.

True, that only the most patient among us will extract more than dozen frames in this way. But, I like to show you only a principle. Maybe you will be surprised how many images, sounds and even videos are stored somewhere in binary files in their “status nascendi”. When you know a file format structure, you know at least what are you looking for.

Before you start to analyze any binary file, you should check if it is not a valid file of some application, if its not a kind of archive, or if the application does not extract files into some temporary directory (usually at its own directory or at Windows directory).

A lot of binary files - a specially those of games - are archives. Such as *.gob or *.pk?. HTML help files (*.chm) are also an archive. Please surf to http://www.totalcmd.nm.ru/ which is domain concerned about Total Commander by Christian Ghisler. There is about 80 utils of miscelanous kinds of archive. There are additionally more than 100 Total Commander plug-ins which allows you at least browse archives.

The file extension could not be a guide presently. The only mechanism which need the correct extension is MIME. Anyway, it is a good starting point. Here you can download a list of almost 2800 file extensions with application label and short description (packed TXT: 45 kBy). Thanksfully, almost all viewers can recognize a file according its header. There are two universal identify-the-file utilities for Mucrosoft Windows: shareware WhatFormat by J. Zwart (download WhatFormat here), or freeware project file(1) Command by Ian F. Darwin and Christos Zoulas (download a file(1) Win32 executables from here) which has been transported from UNIX. WhatFormat is more frendly.

When you have completelly no idea what kind of file it could be, or you are sure, that there are a few files stuffed together into some custom pseudo-archive, you can try to identify wanted resource according its header. Probably the best starting point are "magic" files of file(1) Command application. Their name is magic, or their extension is mgc. They are normally readable. You can find there by what header is a concrete file identified. For complete description of file format, please surf to What's It Archive at http://www.wotsit.org/. Other good resource is File Format Encyclopedia by Salvatore Meschini.

Of course, the question is, what format could be used. If application needs no extra DLL, you can try:

If need something, try to figure-out to what format DLL belongs.
Also please note, that it is not rare situation that file header just miss, because all used files has the same characteristics. So there is not necessary to pack e.g. image size, used color pallette, video size and its fps (a specially at MPEG-I) etc.

To not provocative your nerves and spare your time, you can download this pack of one-time utils. I wrote them, when I need to extract from one file all GIFs and JPEGs from one binary file. You can see how an util evolution, and how not to program. The first compiled util extracts all GIFs, the second all JPEGs and finally the third one looks for all RIFF-WAVs. I left a JPEG recognition to JFIF classic format for demonstration. Maybe you encounter that it will extract 1 kBy JPEG, than 2 kBy JPEG and after that 150 kBy JPEGs – the first will have no image data, the second and third will have only preview with wrong colors.

And our last stage – converting image serie into single animation. The cheapest and quickest way is RAD VideoTools. I highly recommend you this applications pack because it can handle most of Apple QuickTime movies and its native formats Bink and Smacker are widely use by game and screen-savers developers. Other possibility is e.g. commercial Macromedia Flash, or another excellent freeware Quake Video Maker.

Anyway, select just the first image and all of mentioned application should ask if you want to import whole sequence. Then just select convert (or save as), choose output format as AVI, set fps to value you read at html source (or guess – usually is set to 5, 8, 10, or 12 fps) and let generate video. When prompted for codec choose Intel Indeo or XviD – because both of them can be set based on quality (choose at least 85) and not only on constant-bit-rate.

If you cannot set a correct fps, leave it as is. You can change it easily at VirtualDub: just choose Direct Stream Copy from menu Video and then set Frame rate to correct value. Save under a new name. Final movie (74 kBy) compressed with XviD on one-pass constant-quality 95, can be downloaded here. Here is another movie (172 kBy) made from the same serie - but all images has been modified by my GIMP script - you can do the same much more easily at Adobe Photoshop by processing directory with prerecorded action - before they have been joined together into video-stream.

You can translate or link this tutorial under conditions written at this domain's "Legal Stuff" page and followed. If any doubts, please contact me.

Copyrights, trademarks and credits are collected here.

A sample image has been created using plug-in Harmonic Colors for GIMP programmed by Heinz Sollich, Apr. 1998. A sample sounds probably becomes from game Return to Castle of Wolfenstein by id Software, 2002.

Marián Stach
Prešov, Slovakia Central Europe
2004-04-20

[ Language ] :: [ Main Index ] :: [ Site Navigation ] :: [ Tutorials ] :: [ Downloads ] :: [ Contact ]