[Swfdec] Still Alive

[Nick Zitzmann]

On Nov 20, 2008, at 1:49 AM, Benjamin Otte wrote:

> We should probably start adding a swfdec-osx repository to git and you
> can track your changes there. If so, you should follow
> http://www.freedesktop.org/wiki/AccountRequests to get an account and
> afterwards we can setup the repository.

OK, I'll put in a request. But I don't think a new repository is  
necessary, since I have not modified the engine source code; only  
implemented some extensions to integrate Swfdec with Apple  
CoreGraphics (drawing and event handling), CoreAudio (for sound), and  
NSURLConnection (for URL loading). I keep all my changes in a single  
"macosx" folder that exists in the root of the source code.

> I'm still pretty sure you can do it if you were a Quicktime guru,
> because GStreamer does exactly this, but as I have no clue how to do
> it either, I'll just shut up. :)

Well, I don't know. I'm not a GStreamer expert, but it appears that  
GStreamer doesn't need up-front descriptions of audio or video  
streams, and QuickTime does. I wrote some code to integrate Swfdec  
with QuickTime's MP3 decoder, because the MP3 header data is passed  
along, and I can parse that to get an audio stream description, but  
that was the exception.

> As there is no synchronization happening between the video and audio
> parts (yes, this is somewhat by design, blame Adobe), the likeliest
> reason is that you don't call swfdec_player_advance() at the correct
> speed. No clue what exactly could cause it though, maybe not
> inspecting the return value?

Here is the code I am using to handle updates:

- (void)scheduleNextEvent
{
	glong millisecondsToNextEvent = swfdec_player_get_next_event(_private- 
 >_player);
	
	[_private->_nextEventTimer release];
	_private->_nextEventTimer = nil;
	
	if (millisecondsToNextEvent == -1)	// nothing's going on, so do  
nothing for now, but we might have something to do later
		[[NSRunLoop currentRunLoop]  
performSelector:@selector(scheduleNextEvent) target:self argument:nil  
order:50 modes:[NSArray arrayWithObject:NSRunLoopCommonModes]];
	else if (millisecondsToNextEvent == 0)	// we need to trigger the next  
event immediately
	{
		swfdec_player_advance(_private->_player, millisecondsToNextEvent);
		[[NSRunLoop currentRunLoop]  
performSelector:@selector(scheduleNextEvent) target:self argument:nil  
order:100 modes:[NSArray arrayWithObject:NSRunLoopCommonModes]];
	}
	else
	{
		NSTimeInterval fMillisecondsToNextEvent = millisecondsToNextEvent;
		
		fMillisecondsToNextEvent /= 1000.0;	// translate to seconds so we  
can use NSTimer
		_private->_timeOfLastTimer = CFAbsoluteTimeGetCurrent();
		_private->_nextEventTimer = [[NSTimer  
scheduledTimerWithTimeInterval:fMillisecondsToNextEvent target:self  
selector:@selector(triggerNextEvent:) userInfo:nil repeats:NO] retain];
	}
}


- (void)triggerNextEvent:(NSTimer *)timer
{
	CFAbsoluteTime timeElapsed = CFAbsoluteTimeGetCurrent()-_private- 
 >_timeOfLastTimer;
	
	swfdec_player_advance(_private->_player, timeElapsed*1000.0);	// load  
in the next event
	[self scheduleNextEvent];
}

In this code, _private->_player is an SwfdecPlayer, _private- 
 >_nextEventTimer is an NSTimer (Apple's run loop timer class), and  
_private->_timeOfLastTimer is a double that gets set to the number of  
seconds that have passed since a reference time. CFAbsoluteTime and  
NSTimeInterval are both double typedefs.

So yeah, the return value of swfdec_player_advance() is ignored  
because I don't know what to do with it. What do I need to do with it?

> I don't think you need Pango's OS X backend at all, just using the
> Cairo one should be perfetly fine. Plus, the Cairo one will likely use
> the newer APIs already, so everything should just work.
> As far as I know, the Pango backends are from pre-Cairo times and
> Pango is slowly going Cairo-only. Certainly Swfdec only uses the Cairo
> bits of Pango.


Unless Pango has a Cairo-based glyph generator, Pango also does glyph  
generation for Cairo. On GNU I think Pango uses FreeType for glyph  
generation, but on Mac OS X it uses ATSUI, a glyph generator written  
ten years ago (ancient times when dinosaurs ruled the earth) that has  
been replaced & was taken out of the 64-bit frameworks. This is the  
only thing that's holding me back from doing an X86-64 build of  
Swfdec...

I already tried running Pango without any glyph generator engines  
present, and the result was a bunch of boxes where glyphs were  
supposed to be placed.

Nick Zitzmann
<http://seiryu.home.comcast.net/>