[FFmpeg-devel] patch for a new H.264 codec with Matrox m264 card.

[Yufei He]

On 03/28/2019 04:18 PM, Dennis Mungai wrote:
> On Thu, 28 Mar 2019 at 22:40, Nicolas George <george at nsup.org> wrote:
>
>> No need to Cc me, I am subscribed to the list.
>>
>> Yufei He (12019-03-28):
>>> In windows, we need provide the interface library mvM264.lib to our
>>> customers so that they can build. But driver installation of the card
>>> does not have the interface library. It just install mvM264.dll.
>>>
>>> We call dlopen to load mvM264.dll on runtime.  It's simpler. That's
>>> the way we are doing now in other projects..
>> It may be simpler for your infrastructure, but it is not simpler for
>> FFmpeg users, and it actually feels like a deliberate attempt at
>> circumventing the license.
>>
>> Regards,
>>
>> --
>>    Nicolas George
>>
>>
> It's actually a deliberate attempt at circumventing the license.
> Clearly that dynamic library *can* be built from source, as its' separable
> from the device driver.
> What's preventing Matrox from releasing this library such that users can
> build it themselves?
> And why should FFmpeg  inherit the maintenance burden of dealing with an
> opaque ABI whose breakage is guaranteed with version bumps?
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
Actually, I'm just a software engineer, and very new to FFmpeg.
I know little about license. It's impossible to figure out some ideas to 
circumvent the license.

For me, the most important thing is to get it work. Most of my time is 
on studying code of FFmpeg and figure out how to support M264.

The way I'm doing now is all from study of current code in FFmpeg.
I'm still studying the way how companies like blackmagic support FFmpeg.

Regards.

Yufei.