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/>
_______________________________________________
Swfdec mailing list
Swfdec@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/swfdec
