Re: [Swftools-common] Preview JPEG of a SWF

[Benjamin Wolsey]

> > I will now be explicit: producing a preview of a SWF is a complicated
> > business!
> 
> Then we a slight difference of opinion.  Putting a frame together is simply
> a matter of reading the tags associated that frame, and applying them.

This isn't nearly enough for the reasons explained in my previous email!
The way a frame is composed relies not only tags associated with that
frame, but also on previous frames, previous or later tags, external
events, and ActionScript both from previous frames and from that frame
(though you could consider ActionScript as a tag, I suppose).

> > If you look at the output of a tool like pdf2swf, you'll see it's a very
> > rare case: each frame is static and self-contained, so you can process
> > the data for that frame to get a perfect screenshot.
> 
> Not that rare, surely?

Yes, because completely recomposing each frame instead of adapting the
previous frame isn't efficient, and not what the SWF format was really
designed for. This is why SWFs that aren't simply PDF documents in
disguise rarely do it.

>  For at it's most basic level, that's exactly what the
> Flash player plug-in does, render each frame as a self-contained entity.

No, it renders each frame by updating the previous frame. This is also
what other players such as Gnash do.
 
> > To generate a screenshot of any particular frame, you usually can't just
> > look at it in isolation.
> 
> Ahh.  Is there any reason why you would wish to?  The flash player plug-in 
> does
> that for you.  Once it's done it's job, you get the frame.

To generate a preview JPEG! It seems the original question has got a bit
lost!

> > Even for the very first frame, which obviously doesn't depend on other 
> > frames

> It obviously does if it contains any dynamic content.  Because that is the 
> way it works.  *All* pertinent Tags are evaluated and the frame rendered 
> *before* being
> displayed.  

The very first frame, as in the very first one played, doesn't depend on
other frames under any circumstances. Only resources from previous
frames are usable.

Contrary to the SWF documentation, resources defined in later *tags* can
sometimes be used in a frame, but that's another matter.

Evidently if you jump or loop back to frame 0, it can be affected by
what was placed on stage in later frames, but then it isn't the first
frame played any more.

> > So, in short and for future reference: you need to know exactly what you
> > want before selecting a tool to produce a preview:
> 
> Ever so slightly pedantic if I may say so.  As stated above, pdf2swf was 
> never intended to be an interactive flash player.

This isn't intended as a criticism of swftools! They are questions one
(not you!) has to answer before making a decision about generating
previews. For a limited set of SWFs that you know everything about, you
can make a tool to do it. For an unlimited range of SWFs that you have
no control over, it is difficult to do it well and impossible to do it
perfectly.

> The only way to get anywhere near
> what you describe would be to combine player and rendererer on a frame by 
> frame
> basis, i.e.  process, snapshot, process, snapshot.

That's what you can do with Gnash, and why I suggested it! But I assume
only one snapshot is needed.

> > And finally: if you want to produce reliably a meaningful preview of any
> > SWF out there, there is no tool or algorithm that can do it for you!
> 
> In your opinion.. ;o)

I explained the reasons why it's complex in my previous email, but here
is a more detailed explanation:

A preview image is generally an image you'd consider to be
representative of the SWF. 'Representative' is pretty vague even for
humans.

I think we can agree that a simple frame with the text 'Loading' isn't
representative of, say, a game or an animation, but deciding what is
suitable involves judgment about the content of the SWF, some knowledge
about the possible different frames in the SWF, and the judgment about
which one of those many frames is suitable.

A machine is even less capable of making such a decision, and even if it
could: how do you get to that frame? A human can easily choose which of
the buttons 'help', 'exit' and 'play' does what you want (it's 'exit',
of course), but for a machine it's difficult to decide which of the
buttons it detects takes a path that is representative of the SWF.

Then even if the machine decides on the correct path, the frame that the
user sees may depend on all those external or dynamic things I listed in
my previous mail. 

This is why you need a player in *most cases* to produce a meaningful
preview.

> On a slightly different note,  I found your blog entry on 'Re-Entrancy' quite 
> entertaining.  So, with Gnash, one can now juggle as many balls as one likes,
> and not drop any?  If I may say so, this doesn't sound like a feature, more 
> like
> the fix of a nasty bug!! :o)  [ humble non-programmer opinion there]

It was a nasty restriction before. It would have been a nasty bug if we
hadn't put the nasty restriction on it!

bwy

-- 
--
Free Flash, use Gnash
http://www.gnu.org/software/gnash/

Benjamin Wolsey, Software Developer - http://benjaminwolsey.de
C++ and Open-Source Flash blog - http://www.benjaminwolsey.de/bwysblog

xmpp:address@hidden
http://identi.ca/bwy

signature.asc
Description: This is a digitally signed message part