Thu Jul 16 21:10:03 CEST 2009
Jean-Daniel Dupas <devlists at shadowlab.org> writes:
> 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.
Such a ridiculous feature is best left unsupported in my opinion.
mans at mansr.com
More information about the ffmpeg-devel