Hi All -

I'm not a flash programmer, I'm just trying to play flash content using =
the swflash8 OCX in VB6. I'm not sure if there's a better place to post =
-- please direct me if so.

If anyone has a complete layout of the swflash8 object model with =
explanations of the methods and properties, I'd love to see it. There =
seems to be a shortage of good information about the OCX.

For the most part it's pretty intuitive and I've been using it =
successfully. But now I'm up against something I can't crack.

The material I'm playing is linear and continuous -- either plain =
animations or embedded FLVs or a mix of both.

I can use the .TotalFrames property to determine the number of frames in =
the SWF file, but I can't seem to translate that into a number of =
seconds. There doesn't seem to be a "frames per second" property that =
would allow me to compute the true running time. I've tried just using =
30 as the frame rate, but the results don't jibe.

Am I just missing something obvious? I appreciate any pointers or tips.

--=20

[quoted text, click to view]

Thanks for the response. I've seen 'em all, I think, and none of these =
notes gives a complete picture. But if that's all there is, then I guess =
there's nothing else to do.

I was mainly looking for a way to determine the playing time of a =
timeline. I gather that for many SWFs that's not a meaningful thing, =
though in my case it would be since they play linearly from start to =
end.

Can the author specify a frame rate in that situation?=20


[quoted text, click to view]

Any idea where, and in what form? Any docs on the header info?

--=20

[quoted text, click to view]

For anyone else following this, most of the links to this out there are =
dead -- Macromedia has apparently taken this private. =
http://www.adobe.com/licensing/developer/ to get a free license to DL =
the spec. Unfortunately I got a corrupted file, but I did manage to find =
a spec elsewhere.

So following the spec as I read it, the header looks like this:

offset field length
0 sig/vers 4
4 file size 4
8 rect 9 (5 + 64 bits, rounded up to next byte)
17 framerate 2 (int16)
19 framecount 2 (int16)

Does anyone see a problem with this? I'm assuming little-endian format =
for numerics.

If I apply it to a couple of files I have on hand (with a 'vers' of 4), =
I get the correct file size, but the frame rate and frame count are way, =
way off. This tells me that I'm probably misinterpreting the RECT =
structure, but the spec is fairly clear about how it should be read -- 5 =
bits followed by 4 fields of 16 bits each, padded to the next byte =
boundary.

Any clues? Thanks.

--=20

[quoted text, click to view]

The spec I have says that this particular RECT always has a nbits of 15, =
which I verified in every SWF I have. If the nbits is 15, that makes =
each of the 4 folowing members 16 bits (since they're signed). 16 x 4 =
=3D 64, plus the 5 for nbits gives 69 bits. or 8.xx bytes, which =
requires 9 bytes to store. Is there a flaw in this logic?


[quoted text, click to view]

As I explained, I did that and got a corrupted file.


[quoted text, click to view]

Nothing I've read indicates that the header itself is different, or that =
the framerate field is at a different offset. Is that wrong?

--=20

[quoted text, click to view]


I apologize -- the spec I'm using is clearly wrong in this regard, since =
I just pulled down a few more SWFs and indeed this field is not fixed. =
But where the value of nbits _is_ 15, the number of bytes should be 9, =
and that value isn't working.

I won't bother you again until I can get a good copy of the official =
spec.

--=20
Jim

[quoted text, click to view]

Finally got a good file, and while it didn't add much, I did have an =
epiphany.

Because the FrameRate field is defined as UI16, I was treating it as an =
integer. In fact the documents all say that it's "Frame delay in 8.8 =
fixed number of frames per second".

I was reading that as a note about a difference in a version numbered =
8.8, but I see now that what it's saying is that the field is an 8.8 =
fixed point number, not the 16-bit integer that UI16 would suggest.

I'm still a bit confused about why the terms "frame delay" and "frame =
rate" are used in the same sentence, but it does give a reasonable value =
in every case so far.

Thanks for sticking with this. If the OCX team is reading, I'd strongly =
suggest that you expose this value as a property in the next version. =
It's too useful to require all this fiddling to get.

--=20

[quoted text, click to view]

Info on that is on Adboe web site. Look for tech notes on calling flash
methods from javascript etc.

[quoted text, click to view]

You need to look at the file itself (its a binary file) .. the frame rate is
in the file header.
--
Jeckyl

[quoted text, click to view]

The SWF file format
--
Jeckyl

[quoted text, click to view]

Yes .. you cannot count on the number of bit per field for the rect .. it is
NOT fixed.

Please get the SWF file spec where it is all explained. Last time I got the
latest version, one had do fill in a request and then get emailed a link.

Also be aware of the compressed SWF format differences.
--
Jeckyl

[quoted text, click to view]

It is not always the case. The spec is incorrect in that regard. its a
regular rect, which has variable number of bits.

[quoted text, click to view]

Please complain to Adboe .. it should not be a corrupt file

[quoted text, click to view]

You've not read enough then

here is an extract .. firstly the header

[quoted text, click to view]
Signature UI8 Signature byte: "F" indicates uncompressed "C" indicates
compressed (SWF 6 and later only)
Signature UI8 Signature byte always "W"
Signature UI8 Signature byte always "S"
Version UI8 Single byte file version (for example, 0x06 for SWF 6)
FileLength UI32 Length of entire file in bytes
FrameSize RECT Frame size in twips
FrameRate UI16 Frame delay in 8.8 fixed number of frames per second
FrameCount UI16 Total number of frames in file
[quoted text, click to view]

and what it means

[quoted text, click to view]
The header begins with a three-byte signature of either 0x46, 0x57, 0x53
("FWS"); or 0x43, 0x57, 0x53 ("CWS"). An FWS signature indicates an
uncompressed SWF file; CWS indicates that the entire file after the first 8
bytes (that is, after the FileLength field) was compressed by using the ZLIB
open standard. The data format that the ZLIB library uses is described by
Request for Comments (RFCs) documents 1950 to 1952. CWS file compression is
permitted in SWF 6 or later only.

A one-byte version number follows the signature. The version number is not
an ASCII character, but an 8-bit number. For example, for SWF 4, the version
byte is 0x04, not the ASCII character "4" (0x35).

The FileLength field is the total length of the SWF file, including the
header. If this is an uncompressed SWF file (FWS signature), the FileLength
field should exactly match the file size. If this is a compressed SWF file
(CWS signature), the FileLength field indicates the total length of the file
after decompression, and thus generally does not match the file size. Having
the uncompressed size available can make the decompression process more
efficient.

The FrameSize field defines the width and height of the on-screen display.
This field is stored as a RECT structure, meaning that its size may vary
according to the number of bits needed to encode the coordinates. The
FrameSize RECT always has Xmin and Ymin of 0; the Xmax and Ymax members
define the width and height (see Using bit values).

The FrameRate is the desired playback rate in frames per second. This rate
is not guaranteed if, for example, Flash Player is running on a slow or busy
CPU.

The FrameCount is the total number of frames in this SWF file.
[quoted text, click to view]

Note what is says about compressed swf (CWS), and about the FrameSize field.
--
Jeckyl