[Swfdec] Mac OS X Port Update
seiryu at comcast.net
Sat Sep 13 13:15:14 PDT 2008
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
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
> 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.
> 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.
S/MIME signature available upon request
More information about the Swfdec