[Swfdec] Mac OS X Port Update

[Nick Zitzmann]

On Sep 13, 2008, at 4:50 AM, Benjamin Otte wrote:

> Usually the image is decoded once and then cached until the cache is
> reclaimed. So it might very well be a problem with Cairo's OS X
> backend or our caching as well as the JPEG decoder. Someone would need
> to experiment and profile there.


If it's cached, then I think I know the problem... Right now my  
drawing code deletes the SwfdecRenderer and the Cairo structures,  
because I was working under the assumption that view graphics contexts  
weren't reused.

I guess I'd better recode that to retain the Cairo structures and the  
SwfdecRenderer, and only delete them in response to a bounds change  
(since I can't find any way of changing a Cairo surface's extents)...

> It's weird if it's only happening on OS X, might be your problem. The
> last garbage collection is somewhat tricky, because it happens in a
> pretty much random order, and sometimes objects refer to each other in
> their destructors (aka dispose/finalize vfuncs), which shouldn't
> happen.
> Anyway, if you get a crash, the file that caused it and a stacktrace
> are a good start.

Well, more often than not, it's happening when browsing Homestar  
Runner, which is a site that doesn't currently run correctly in Swfdec  
anyway. For example, you can't see the reflection of Strong Bad's face  
in the e-mail 'toons. I haven't had that happen often outside there.

> Nope, you get just the frames. Making available the container doesn't
> work because Swfdec needs to access the data parts of the stream, so
> needs to parse it itself.

D'oh!

> I'd have thought quicktime gives you access to the video codecs
> somehow in its low level APIs. How would other people integrate their
> codecs/containers with Quicktime otherwise?

In the Cocoa frameworks, the class for decoding images is NSImage, and  
the class for decoding movies is QTMovie. Both classes require  
containers & don't deal with raw data, unless a description of the raw  
data can be provided in advance so it can be decoded.

Since the Swfdec audio classes do provide the container information up  
front, I was able to write an MP3 decoder that uses Apple's AudioFile  
& AudioDecoder classes to figure out the MP3 stream description, get a  
maximum packet size for VBR MP3s, etc. I can't do that with video if I  
don't have a container or an up-front description.

Of course, I could also just link this into ffmpeg directly... I want  
this to be a first-class Mac OS X port that uses existing Apple  
technologies rather than re-inventing the wheel or requiring the  
installation of GStreamer plugins.

Nick Zitzmann
<http://seiryu.home.comcast.net/>
S/MIME signature available upon request