[FFmpeg-devel] Hello,

[Baptiste Coudurier]

On 07/16/2009 12:29 PM, M?ns Rullg?rd wrote:
> 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.

That's user's problem, we cannot do much about it anyway.

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

I'm ok to deal with that. If code can avoid failing on one architecture 
the better it is.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org