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

[Chris]

I had written an extremely wordy reply to your last message.  Banging away at
what I saw as some mild inaccuracies. I've just deleted it.  Hurrah!!

Why?  Because the oozlum bird springs to mind here.  Either that, or you and I 
are on a jolly trip down Mobius Strip lane with no way off. ;o)

In essence what you are getting at, is basically this:

At what point in a dynamic swf ought one to take a static jpeg snapshot of a
snapshot of the dynamic SWF inside that, and the dynamic swf inside that, and
the dynamic swf inside that.. und se weite, und se weite, und se weite.. and
have the result be representative of the swf as a whole.  Right?

If the resulting swf was document style, then no problem.  Game or multimedia 
output would be way trickier, nigh impossible, or downright stupid, i.e. say the
dynamic content was a wav file or streamed mp3.   I doubt anyone would expect a 
tool such as pdf2swf to handle it, let alone attempt to use it.

If Gnash makes swf stop motion capture easier, then great.  Can it also export 
at a
suitable break point to JPEG?  Why JPEG, or more correctly JFIF?  It's lossy, 
and
not yet, as far as I am aware, an open format.  Does it do .png as well?  Is it
also  straightforward to use, and quick to configure, on both Linux and Mac?  
Because that is what the original questioner asked ( I think ).  

Finally, a similar effect could also be obtained by controlling the swf 
playback  with actionscript/swfc, then dumping the appropriate frame.  Only 
thing missing
is the final graphic export.  I'm sure that could be got round.

Regards,



Chris.

>On Wed, 13 Oct 2010 16:59:21 +0200
>Benjamin Wolsey <address@hidden> wrote:

> > > 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!

It is for the purposes of the Flash player ( and pdf2swf )! ;o)

> 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).

I have version 10 of the swf format spec document here, so I know the sequence;
process all tags in SWF until meeting a ShowFrame Tag, at which point render to
screen. Also it states quite specifically, that while there is no specific tag
layout sequence, tags can only depend on preceding tags, not later ones.  I take
it Gnash differs in this respect?

The Action model has tags associated with it, but is not defined a a tag.  It 
also
appears to be independent of the tag structure, which makes sense.

> > > 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.

I wasn't aware that it did?  Merely replay the control tags which control the
flow of the file. 

I'm still not quite sure why people have the need to turn pdf into swf.   I've
never personally been a fan, especially of flipping books!   I'd rather render
pdf to html!

> >  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.

That's not quite what I said. Obviously it has to update the previous frame,
but, the resulting ( updated ) frame rendered to the screen is *still*, very
much a self-contained entity in it's own right.
  
> > > 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!

Nope, I hadn't forgotten about it.  What you seem to be talking about is a 
having
a dynamic preview. Snag: jpegs are not dynamic, so how can you possibly generate
such a beast?  Further, dynamic implies movement, i.e. frame change, or frame 
change within the currently being viewed frame. Since a static preview can't 
have movement, your only choice is a snapshot at a given point in time.

> > > 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.

Badly phrased.  If the first frame of your swf contains dynamic content within 
itself, as in another movie element, then it has dependencies surely?
 
> Contrary to the SWF documentation, resources defined in later *tags* can
> sometimes be used in a frame, but that's another matter.

I'll take your word on that one. ;o)

> 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.

No problem with that.

> > > So, in short and for future reference: you need to know exactly what you
> > > want before selecting a tool to produce a preview:

No argument there either.  Personal preference!

> > 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!

And I didn't take it as one.  Merely subjective opinion. I didn't write pdf2swf!

> They are questions one (not you!)

Why not?  I like questions.. ;o)

>.. has to answer before making a decision about generating previews.

I think you need to decide yourself exactly what type of *preview* you want to
see.  Dynamic or static.  If static, then you let the flash player or external
renderer produce the first frame, then snapshot it.  No more, no less.

> 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.

A snapshot for me Ben, is a stop-motion capture in time.  A cessation in 
activity.
A break point. In other words, *static* content. What is is for you?

> > > 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:

If you don't mind me saying so, and with reference to my original function
definition, *you* are making it complicated.
 
> A preview image is generally an image you'd consider to be representative of 
> the > SWF. 'Representative' is pretty vague even for humans.

And at the point you do it, it becomes static content. No frames, no movement.

> 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.

I don't disagree at all there.  Where our stumbling block is, is 

> 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
> 


-- 
Chris <address@hidden>