[FFmpeg-devel] Hello,

[Jean-Daniel Dupas]

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.

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  
when possible.