[FFmpeg-devel] Hello,

[Måns Rullgård]

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:
>>
>>> Hello,
>>>
>>> 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
>>> Mac
>>> 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
> hood.
> 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.

-- 
M?ns Rullg?rd
mans at mansr.com