Swfdec - Oct 2008 - swf file parsing

Hi,

Company and I had a discussion about local swf file parsing
yestoday.And I still have some related questions. So I continue the
topic here.  (Sorry to Comanpy, my laptop was out of battery power
yestoday, and I didn't notice the power warning, so just quited IRC
accidently).

Here is my test(the test is already verified here):

test file: bigswf.swf, size: 5.1MB, total frames: 233

as in frame1(the first frame at root):
  trace(_root._framesloaded);  // output: 52, swfdec behaves correctly here
  trace(_root._currentframe);   // output:1,   swfdec is also correct here
  _root.gotoAndPlay(1000);     // try jump to an unparsed frame.
  trace(_root._currentframe);  // expected output: 53,  swfdec's output: 1

The parsing policy of local swfs inside swfdec should be correct.
gotoFrame implementation is a bit different agains the proprietory
player, though.(I don't mean swfdec need to be full compatible here,
just describe the tested result. We all know pp do weird things
sometimes).


Question about parsing the network data:

How does swfdec fetch and parse the network data?

Gnash has a separate thread for parsing both local swf and network
data, so the parsing process would never block the movie advancing
process, and the GUI is always responsive even the network speed is
slow. The advantage is that the threading mode is easier for thinking.
But there are also disadvantage, like much mutex protection overhead
and dead-lock risks.
swfdec uses a single thread model. So I am wondering how does it avoid
the blocking problem when network speed is slow? eg. the network might
be down right after you buffered half a swf tag.

I am hacking on swfdec recently, so I ask those questions that help me
understand the code better.

Thanks ahead.

--zou

On Tue, Oct 28, 2008 at 5:05 AM, zou lunkai <zoulunkai at gmail.com>
wrote:
> Here is my test(the test is already verified here):
>
> test file: bigswf.swf, size: 5.1MB, total frames: 233
>
> as in frame1(the first frame at root):
>  trace(_root._framesloaded);  // output: 52, swfdec behaves correctly here
>  trace(_root._currentframe);   // output:1,   swfdec is also correct here
>  _root.gotoAndPlay(1000);     // try jump to an unparsed frame.
>  trace(_root._currentframe);  // expected output: 53,  swfdec's output:
1
>
> The parsing policy of local swfs inside swfdec should be correct.
> gotoFrame implementation is a bit different agains the proprietory
> player, though.
>
That's a bug in Swfdec. Looks like Swfdec behaves wrong when it gets
an out-of-range goto. Could you file this in bugzilla?
> (I don't mean swfdec need to be full compatible here,
> just describe the tested result. We all know pp do weird things
> sometimes).
>
Swfdec absolutely must produce the same output as the proprietary
player, even if that looks completely stupid. If you create a Flash
file that produces a noticably different (visual, trace or audible)
output as the Adobe Player, that's a bug in Swfdec.
> How does swfdec fetch and parse the network data?
>
Each SwfdecPlayer keeps a list of things to do and when to do them
inside a SwfdecTimeout structure. The list of things to do next is
keep in SwfdecPlayerPrivate's timeouts variable.
Whenever swfdec_player_advance() advances the time so far that it hits
the time of the first timeout, it executes this timeout.

Whenever new data is provided to the player using swfdec_stream_push()
- the whole file in the local cae, the chunks read asynchronously from
the HTTP input, RTMP or XML sockets - a new timeout is cued to be
executed immediately. This timeout will the cause the resource's parse
callback to be executed (the stuff we talked about yesterday). As the
parse callback is fast (it just scans the data), this is not really a
problem, even if you hand it a huge file.

This in turn means that the asynchronous behavior is done by the
application and not by Swfdec itself. The Gtk backend achieves this
using the glib main loop.
> I am hacking on swfdec recently, so I ask those questions that help me
> understand the code better.
>
:)

Cheers,
Benjamin