Re: [Gnash-dev] YouTube using SWF10 today

[Alessandro Pignotti]

On Wednesday 24 March 2010 17:38:07 strk wrote:
> On Wed, Mar 24, 2010 at 10:24:58AM -0600, Rob Savoye wrote:
> > On 03/23/10 09:16, strk wrote:
> > > Easiest is probably looking at the npapi/plugin.cpp code as all it
> > > does is spawning the standalone.
> > >
> > > The proof of concept would be to export
> > > GNASH_PLAYER=/usr/local/bin/lightspark in the browser environment and
> > > see it magically work.
> >
> >   Actually, while a command line interface is a good start, it's not
> > really sufficient. For one thing, this would only work for sites that
> > you knew before hand were v10. Gnash doesn't know the version of the swf
> > file until after it's been started, so that's where a tighter
> > integration would be required.
> 
> Gnash saves the whole content to a temporary file, so it could, when
> it figures it's an AVM2 one, rewind it and send to lightspark stdin.
I'm quite favorable to have as soon as possible, even a primitive, gnash-
compatible command line interface. Right now I definitely need to give 
visibility to lightspark, and  having an established project such as Gnash use 
it as a "fallback" engine looks very promising. I'm gonna work on a xembed 
based render thread as soon as I fix the plugin mode.
> 
> > Ideally if lightspark has a v10 file
> > loading a v7 file, then it would need to be able to use Gnash for that.
> > LocalConnection in Gnash does work, so that would be one way of
> > communicating.
> 
> I guess the question is "what" to communicate in those cases.
> If there's no communication between the two VM (which I think
> I've heard it is supposed to hold true) we could see a v7 running
> into a v10 as two completely separated videos one within another.
> In that case all we'd need would be a way to feed the players
> and fetch audio and video out of them.
> Gnash isn't ready for that atm.

To have at least graphics working would not be difficult using the current 
lightspark architecture. If gnash could pass (by shared memory, for example) 
the graphics buffer, lightspark would load it as a GL texture and transform and 
render it.

Moreover, it seems to me that (at least for clip loaded using 
flash.display::Loader the only way to communicate for the VMs is through the 
sharedEvents interface, which could be a good gateway to integrate the 
execution.

Cheers,
Alessandro

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