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

[Dennis Mungai]

On Fri, Mar 29, 2019, 00:16 Yufei He <yhe at matrox.com> wrote:

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


Then understand *how* the development process works. If you're told to
> withdraw a patch for some reason (see what Carlos cited earlier), comply.
> And only resubmit it when

it meets the requirements.


Your role, be it an employee of Matrox or an independent contributor, means
little as far as compliance to the development process is concerned.

The same rules and development guidelines apply to *all* contributors here,
irrespective of the nature of ties they hold to the products and companies
whose support exists in FFmpeg.

The examples you're going through (Decklink, ffnvcodec, etc) are a good
starting point.

We don't enforce these guidelines to discourage contributions to FFmpeg,
but rather, to ensure that such contributions are maintainable, and in a
way that respects the license under which they fall under.