Thu Jul 16 20:54:00 CEST 2009
Le 16 juil. 09 ? 20:26, M?ns Rullg?rd a ?crit :
> Jean-Daniel Dupas <devlists at shadowlab.org> writes:
>> I'm new to this list and to this project. I'm looking to use
>> libavformat & libavcodec in some application and would like to
>> contribute to improve ffmpeg.
>> And so, to try to get into the code, I did a little patch to improve
>> alias support in dref in mov files on OS X. This patch uses native
>> OS X API to resolve the alias if possible instead of trying to infer
>> the path from opaque data.
> I'd rather improve our own code if it is incomplete. Can you
> elaborate on what it's missing?
> <big elephant in the room> Why native Mac OS X API? </big elephant
> in the room>
I will answer the two questions.
First, an alias as defined by the Mac OS File Manager reference is a
blob of "data that is private to the Alias Manager". There is
absolutely no guarantee about what it contains. And so, the native API
is the only futur proof and reliable way to resolve it. That why I
suggest to use it when available.
Now, about what is missing in the current code. The actual code assume
the alias contains a path (either relative or absolute), but an alias
is more than that. It contains enough informations to locate a file
that was renamed and moved (as long as it remain on the same volume).
As this is an opaque struct, I never tried to look at what it does,
but I assume it is using FSVolumeRefNum, and nodeID (inode) under the
In fact, the alias manager is even able to resolve path on file that
are stored on remove volumes and to mount this volume if needed.
I'm not again the idea to improve the actual code to get support for
relative path (and maybe inode) (by reverse engineering the content of
the blob), but I thought it would be fine to use the most reliable way
More information about the ffmpeg-devel