Because Sophie uses Quicktime for all its media needs. Quicktime supports Flash just fine.
I didn't know that at all. Thank you for pointing it out./ /
I wrote the Flash player for Disney projects and we used it there. The reason it was never updated was because Macromedia (which owned Flash at this point) changed their policy on releasing the SWF spec - in order to obtain the spec for SWF> 3.0 one had to agree to NOT write any player for SWF files; you were only allowed to use that documentation to CREATE output in SWF. So a complete no-go for us (I have not checked what recent policy is).
That's interesting. That explains to me how I perceived that all interest in Flash had stopped. The code goes up to that point and that's all I could see.
I wrote the memo, I own the site, and methinks I'm still around ...
I do appreciate the truth of that statement. Talking about these things here makes me a bit self-conscious, as I like to describe things in historical terms, while all the players are right here. But silence teaches me nothing, so...
Your site is invaluable to anybody interested in Tweak, which includes anybody who has ever had doubts about Morphic.
Chris
Ok, well it is great that someone is attempting to drag that movie player out of sophie. Since we must have re-written it 7 times over four years.
Now I think there are some things consider once one figures out how tweak works, which you are discovering is a key part of the puzzle, at least from the viewpoint of how the heck do we go from here to there.
The concept is that logic is handled a URL for a media object (video or audio). It must then determine what type of media that is, using features of Quicktime or MimeTypes to figure out a optimal guess at the concrete decoder class to use. For that a weighted matrix of choices is used because if we have quicktime, use that, but maybe not if it's an OGG movie since quicktime doesn't support OGG natively, but there is a plugin... Frankly this is the important piece of the whole architecture.
Next we extract some meta data from the movie (frame size, length, etc) and store in the SophieResourceManager. That helps the visual composing later make decisions about how to place the tweak UI for the playback of the movie. We do that instead of digging into the movie via decoder calls every frame or every time we need to render a place holder for the movie. You don't need to drag the SophieResourceManager over, just enable something to store the meta-data. Hint "how big is the frame of this movie?" and we don't want to wade thru a million instructions decoding the meta-data to say 640x480...
Now the decoder logic has a number of goals, play, stop, rewind, close.. More interesting is play, what happens then is the decoder's objective is to start at a particular position in the movie, and on each frame change signal to tweak the frame has changed. It also has an obligation to keep sane when the use pounds the controls in some frantic set of sense of movement, and the various decodes have a bit of hysteria when you attempt to herd them too fast...
So on top of that we have a Tweak UI to provide the UI controls for the play, stop,rewind, head tracking. That of course send cmd requests to the decoded for the various actions, but it's also listening for the frame did change message. When it gets that, it then has the responsibility to gather up the bits and ask tweak to splash them onto the tweak UI. Obviously since you are not migrating Tweak into Squeak, then you'll need a morphic replacement for that part of the puzzle. That part is the least interesting because it' just a shell for forwarding UI actions to the sophie movie model, and ensuring it paints bits when ask (immediately)...
BTW lurking in here are two types of timing loops. Relies on the quicktime plugin which has one sole function, that is to signal a semaphore when Quicktime tells us the frame has changed, which triggers of course a paint. We only did the plugin for os-x as it's optional. What other platforms do is setup a timing loop based on the movie frame rate to trigger the frame draw with hopes that it's not too CPU intensive.
On 2010-12-29, at 10:16 AM, Chris Cunnington wrote:
I do appreciate the truth of that statement. Talking about these things here makes me a bit self-conscious, as I like to describe things in historical terms, while all the players are right here. But silence teaches me nothing, so...
Your site is invaluable to anybody interested in Tweak, which includes anybody who has ever had doubts about Morphic.
Chris
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
John M McIntosh wrote:
Ok, well it is great that someone is attempting to drag that movie player out of sophie. Since we must have re-written it 7 times over four years.
John, there are a bunch of semaphore critical blocks in the movie code. Is this because Tweak scripts run in separate processes, or does it have something to do with the QuickTime API? If all code was running in one process, could they be removed?
Thanks. Sean
As for the quicktime plugin it provides two concepts.
(a) we get quicktime to write bits to a squeak surfaceplugin guy which means for for a 480x640 pixel move we don't move 36MB of memory around every second. That can result in *better* fps and for the minor amount of code involved it's win win.
(b) we get quicktime to tell us when a frame is ready to be rendered to the display based on when quicktime has finished rendering the frame. That prevents tearing... Plus if the compression algorithm is really smart it can so, oh don't need to alter the frame because this frame is the same as the last frame...
As for the semaphore, notes say...
"If you recall we added that a few years back when we had race conditions on the movie, is it open, is it closed? Who's closing it, when's it opened..."
The situation is you open and preroll the movie, that is running as a tweak process, you tap stop, that is running as a tweak process. Lots of multi-threading going on. So is the movie open or closed? Got a race condition? Oh yes... Because of that complexity over the years we *managed, just managed* to convince the logic not to crash if the user tapped close at any random point in time during critical phases like when you assume you have an open viable movie, not a zombie...
On 2011-01-01, at 11:36 AM, Sean P. DeNigris wrote:
John M McIntosh wrote:
Ok, well it is great that someone is attempting to drag that movie player out of sophie. Since we must have re-written it 7 times over four years.
John, there are a bunch of semaphore critical blocks in the movie code. Is this because Tweak scripts run in separate processes, or does it have something to do with the QuickTime API? If all code was running in one process, could they be removed?
Thanks. Sean -- View this message in context: http://forum.world.st/Playing-Flash-movies-in-image-tp3167383p3170351.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
squeak-dev@lists.squeakfoundation.org