[FFmpeg-devel] Hello,

Måns Rullgård mans
Thu Jul 16 21:29:06 CEST 2009

Baptiste Coudurier <baptiste.coudurier at gmail.com> writes:

> On 07/16/2009 12:10 PM, M?ns Rullg?rd wrote:
>> 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.
> Well, I'd like to support this feature, the patch is small and does
> not cause any harm IMHO.

Q: What happens if the file is copied to another computer, perhaps not
even running macos?  A: It fails.

I don't want to deal with bug reports resulting from this lunacy being
handled on macos and not elsewhere.  Better to have it fail
consistently everywhere.

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list