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

[Dennis Mungai]

On Fri, Mar 29, 2019, 00:16 Yufei He  wrote:

> On 03/28/2019 04:18 PM, Dennis Mungai wrote:
> > On Thu, 28 Mar 2019 at 22:40, Nicolas George  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@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [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  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@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@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.




___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Dennis Mungai]

On Thu, 28 Mar 2019 at 22:40, Nicolas George  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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Thomas Volkert]

On 28.03.2019 13:40, Yufei He wrote:
> On 03/27/2019 11:35 AM, Nicolas George wrote:
>
> Yufei He (12019-03-27):
>
>
> Here is the fixed patch for a new H.264 codec with Matrox M264 card.
>
> It calls the default library from the card's driver installation.
> Please review.
>
>
>
> You are still using programmatic dynamic linking instead of normal
> dynamic linking, and you have not given a good reason for that. Please
> fix.
>
> Regards,
>
>
> Hi Nicolas
>
> 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..

I personally prefer this way of dynamic linking for such cases. Intel
does it in a similar way via their mfx_dispatcher. They use it as dll
loader for ondemand access to the Intel QuickSync specific dlls during
the runtime of the corresponding application.
But they published the source of this special dll loader as open source
release.

Best regards,
Thomas.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Nicolas George]

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


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Yufei He]

On 03/28/2019 10:00 AM, Jean-Baptiste Kempf wrote:
>
> On Thu, 28 Mar 2019, at 13:41, Yufei He wrote:
>> 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.
> Why does mvM264.dll return 0 Google Search result?
>
>
>
Hi Jean-Baptiste

I just did the same Google search, yes, it seems most of the .dlls made 
in last 2 or 3 years can not be found.
I can find some old .dll files, e.g. mvcDCT.dll.

Yufei.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Carl Eugen Hoyos]

2019-03-28 13:40 GMT+01:00, Yufei He :

> In windows, we need provide the interface library mvM264.lib

And you should.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Jean-Baptiste Kempf]

On Thu, 28 Mar 2019, at 13:41, Yufei He wrote:
> 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.

Why does mvM264.dll return 0 Google Search result?



-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Yufei He]

On 03/27/2019 11:35 AM, Nicolas George wrote:

Yufei He (12019-03-27):


Here is the fixed patch for a new H.264 codec with Matrox M264 card.

It calls the default library from the card's driver installation.
Please review.



You are still using programmatic dynamic linking instead of normal
dynamic linking, and you have not given a good reason for that. Please
fix.

Regards,


Hi Nicolas

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

Thanks.

Yufei.






___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with 
subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Carl Eugen Hoyos]

2019-03-27 16:30 GMT+01:00, Yufei He :

> Here is the fixed patch for a new H.264 codec with Matrox
> M264 card.

Please do not send another version of this patch that doesn't
add the non-free requirement in configure (or open-source
your library).

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Nicolas George]

Yufei He (12019-03-27):
> Here is the fixed patch for a new H.264 codec with Matrox M264 card.
> 
> It calls the default library from the card's driver installation.
> Please review.

You are still using programmatic dynamic linking instead of normal
dynamic linking, and you have not given a good reason for that. Please
fix.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Yufei He]

Hi

Here is the fixed patch for a new H.264 codec with Matrox M264 card.

It calls the default library from the card's driver installation.
Please review.

Thanks.

Yufei.
  

From da521d4e1315199a5fb781adf8a56efdc64c2b42 Mon Sep 17 00:00:00 2001
From: yhe 
Date: Wed, 27 Mar 2019 11:05:41 -0400
Subject: [PATCH] h.264 decoder and encoder support with M264

---
 Changelog  |   1 +
 configure  |   2 +
 libavcodec/Makefile|   2 +
 libavcodec/allcodecs.c |   2 +
 libavcodec/m264dec.c   | 357 +
 libavcodec/m264dec.h   |  40 ++
 libavcodec/m264enc.c   | 335 ++
 libavcodec/m264enc.h   |  38 ++
 8 files changed, 777 insertions(+)
 create mode 100644 libavcodec/m264dec.c
 create mode 100644 libavcodec/m264dec.h
 create mode 100644 libavcodec/m264enc.c
 create mode 100644 libavcodec/m264enc.h

diff --git a/Changelog b/Changelog
index 4d80e5b..ce0daf8 100644
--- a/Changelog
+++ b/Changelog
@@ -19,6 +19,7 @@ version :
 - ARBC decoder
 - libaribb24 based ARIB STD-B24 caption support (profiles A and C)
 - Support decoding of HEVC 4:4:4 content in nvdec and cuviddec
+- Support h.264 encoding and decoding with Matrox M264 card.
 
 
 version 4.1:
diff --git a/configure b/configure
index dcead3a..3be416e 100755
--- a/configure
+++ b/configure
@@ -2697,6 +2697,8 @@ h263p_decoder_select="h263_decoder"
 h263p_encoder_select="h263_encoder"
 h264_decoder_select="cabac golomb h264chroma h264dsp h264parse h264pred h264qpel videodsp"
 h264_decoder_suggest="error_resilience"
+h264_m264_decoder_deps_any="libdl"
+h264_m264_encoder_deps_any="libdl libswscale"
 hap_decoder_select="snappy texturedsp"
 hap_encoder_deps="libsnappy"
 hap_encoder_select="texturedspenc"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 15c43a8..8e8f9ab 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -348,6 +348,8 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o h264_cabac.o h264_cavlc.o \
   h264_slice.o h264data.o
 OBJS-$(CONFIG_H264_AMF_ENCODER)+= amfenc_h264.o
 OBJS-$(CONFIG_H264_CUVID_DECODER)  += cuviddec.o
+OBJS-$(CONFIG_H264_M264_DECODER)   += m264dec.o
+OBJS-$(CONFIG_H264_M264_ENCODER)   += m264enc.o
 OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o
 OBJS-$(CONFIG_H264_MMAL_DECODER)   += mmaldec.o
 OBJS-$(CONFIG_H264_NVENC_ENCODER)  += nvenc_h264.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b26aeca..c03a5a3 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -737,6 +737,8 @@ extern AVCodec ff_libopenh264_encoder;
 extern AVCodec ff_libopenh264_decoder;
 extern AVCodec ff_h264_amf_encoder;
 extern AVCodec ff_h264_cuvid_decoder;
+extern AVCodec ff_h264_m264_decoder;
+extern AVCodec ff_h264_m264_encoder;
 extern AVCodec ff_h264_nvenc_encoder;
 extern AVCodec ff_h264_omx_encoder;
 extern AVCodec ff_h264_qsv_encoder;
diff --git a/libavcodec/m264dec.c b/libavcodec/m264dec.c
new file mode 100644
index 000..f6cc65f
--- /dev/null
+++ b/libavcodec/m264dec.c
@@ -0,0 +1,357 @@
+/*
+ * M264 H.264 video decoder
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Matrox M264 card supports h.264 encoding and decoding.
+ */
+
+#include "decode.h"
+#include "cabac.h"
+#include "error_resilience.h"
+#include "h264_parse.h"
+#include "h264_ps.h"
+#include "h264_sei.h"
+#include "h2645_parse.h"
+#include "h264chroma.h"
+#include "h264dsp.h"
+#include "h264pred.h"
+#include "h264qpel.h"
+#include "internal.h"
+#include "mpegutils.h"
+#include "parser.h"
+#include "qpeldsp.h"
+#include "rectangle.h"
+#include "videodsp.h"
+#include "config.h"
+#include "libswscale/swscale.h"
+#include "libavutil/opt.h"
+#include "m264dec.h"
+#ifdef _WIN32
+#include "compat/w32dlfcn.h"
+#else
+#include 
+#endif
+
+typedef struct {
+   uint16_t input_width;
+   uint16_t input_height;
+   uint16_t output_width;
+   uint16_t output_height;
+   uint16_t scale;
+   uint16_t rate;
+   uint16_t gop_size;
+   uint32_t bitrate;
+   uint8_t  field_order;
+} M264DecoderInfo;
+
+typedef struct {
+AVClass *class;
+int (*init_m264_decoder)(void *decoder_info, void **m264_decoder_object);

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

[Tomas Härdin]

fre 2019-03-15 klockan 18:45 +0100 skrev Nicolas George:
> Yufei He (12019-03-15):
> > I did not find a better way to make this work.
> 
> It exists: make your client libraries GPL-compatible.

I second this

/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Michael Niedermayer]

On Thu, Mar 14, 2019 at 05:55:41PM +, Yufei He wrote:
> Hi
> 
> Here is the patch for a new H.264 codec with Matrox m264 card.
> 
> Please review.
> 
> Thanks.
> 
> Yufei.
> 
> 

>  Changelog   |1 
>  configure   |2 
>  libavcodec/Makefile |2 
>  libavcodec/allcodecs.c  |2 
>  libavcodec/codec_desc.c |1 
>  libavcodec/m264dec.c|  315 
> 
>  libavcodec/m264dec.h|   39 +
>  libavcodec/m264enc.c|  296 +
>  libavcodec/m264enc.h|   38 +
>  9 files changed, 695 insertions(+), 1 deletion(-)
> 0ea83a5b3013cb0658872bee0f4c451ddf2ef473  
> 0001-H.264-encoder-and-decoder-support-with-Matrox-M264.patch
> From b1f7779028378f3e0d5360766a8591d0cf5a0a71 Mon Sep 17 00:00:00 2001
> From: yhe 
> Date: Thu, 14 Mar 2019 10:10:46 -0400
> Subject: [PATCH] H.264 encoder and decoder support with Matrox M264.

This breaks "make -j12 testprogs"

libavcodec/libavcodec.a(m264enc.o): In function `ff_m264_send_frame':
m264enc.c:(.text+0x88): undefined reference to `sws_scale'
m264enc.c:(.text+0x15e): undefined reference to `sws_getContext'
libavcodec/libavcodec.a(m264enc.o): In function `ff_m264_encode_close':
m264enc.c:(.text.unlikely+0x21c): undefined reference to `sws_freeContext'
collect2: error: ld returned 1 exit status
make: *** [libavcodec/tests/snowenc] Error 1

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Marton Balint]

On Fri, 15 Mar 2019, Ronald S. Bultje wrote:


Hi guys,

On Thu, Mar 14, 2019 at 1:55 PM Yufei He  wrote:


Hi

Here is the patch for a new H.264 codec with Matrox m264 card.



I want to bring up again that this library is closed-source. I don't think
FFmpeg should link to closed-source software in its public mainline
version. Matrox is obviously free :-) to maintain their own modified
version as long as they comply with all licensing conditions.

On IRC, we just discussed the following:
- --enable-nonfree was initially intended for dealing sort of roughly with
incompatible opensource licenses, for example AAC encoders or GPL +
LGPL-compatible-but-LGPL-incomptible libraries;
- nowadays, --enable-nonfree is also used for NDI (which Kieran sent a
patch to remove already) and now this.

I would like to request a vote amongst frequent developers (and if you
don't count me amongst that, that's fine) to decide whether closed-source
software integration in general, as well as this one in particular, is OK.
I don't think the system library provision applies here, since you'll be
hard-pressed to find a system with Matrox hardware (it's high-$$$
enterprise stuff).


I think it is a mistake to tackle this from a licensing point of view 
because it is debatable what counts as a system library or what counts as 
a closed plugin of an LGPL library. Instead of debates about components we

will get debates about licensing. Totally pointless.

Therefore I don't think a generic vote about closed source is a good idea. 
To allow or not a certain closed source component is mostly subjective so 
doing a vote on a case by case basis seems the most fair to me. We don't 
have _that_ many closed source submissions.


When voting, the following can be considered by each voter:
- submitter reputation (past contributions/license awareness/maintenance 
capability)
- capability to build the component (headers/SDK price/licensing/NDA)
- capability to use the component (library/driver/HW price)
- component target (consumer/professional/enterprise)
- potentional user base

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Ronald S. Bultje]

Hi,

On Fri, Mar 15, 2019 at 2:19 PM BIGLER Don (Framatome) <
don.big...@framatome.com> wrote:

> >Yufei He (12019-03-15):
> >> I did not find a better way to make this work.
>
> >It exists: make your client libraries GPL-compatible.
>
> Or alternatively creating open-source headers that allow the m264 drivers
> to be used similar to NVidia's Video Codec SDK:
>

No, that doesn't address the issue at all. Release the nvidia SDK as open
source, *that* addresses the issue.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[BIGLER Don (Framatome)]

>Yufei He (12019-03-15):
>> I did not find a better way to make this work.

>It exists: make your client libraries GPL-compatible.

Or alternatively creating open-source headers that allow the m264 drivers to be 
used similar to NVidia's Video Codec SDK:
https://github.com/FFmpeg/nv-codec-headers
https://github.com/FFmpeg/FFmpeg/blob/master/compat/cuda/dynlink_loader.h

Regards,
Don Bigler
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Nicolas George]

Yufei He (12019-03-15):
> I did not find a better way to make this work.

It exists: make your client libraries GPL-compatible.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Yufei He]

Hi Jean-Baptiste

Sorry for the complexity and confusion to so many people involved on 
this new patch.

We have been working on this for 4 months because some of our big 
customers on internet business have been asking Matrox to make our M264 
card to support FFmpeg on h.264 transcoding, esp on 4k and HD files.

M264 is very powerful on 4k and HD decoding and encoding.

M264 uses a h.264 encoding chip made by Matrox, and there are a lot of 
modules involved to make it work. Those modules are not public in 
Matrox, which is a company of 40 years.

Yes, mvM264Ffmpeg.dll is a wrapper to those modules, it involves all the 
interfaces talking to the chip.

I did not find a better way to make this work.

Thanks a lot to all people involved.

Yufei.


On 03/15/2019 11:23 AM, Jean-Baptiste Kempf wrote:
> On Fri, 15 Mar 2019, at 15:02, Tomas Härdin wrote:
>>> +#ifdef _WIN32
>>> +lib_handle = dlopen("mvM264Ffmpeg.dll", RTLD_LAZY);
>>> +#else
>>> +lib_handle = dlopen("libmvM264Ffmpeg.so", RTLD_LAZY);
>>> +#endif
>> Still dlopen() I see. You should link to these libraries properly, as
>> others have said, and add appropriate license stuff to configure.
> What are those libraries? Are they drivers/system libraries?
>
> They seem to be a wrapper done just for the FFMpeg integration. If so, what 
> is the license of those?
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jean-Baptiste Kempf]

On Fri, 15 Mar 2019, at 15:02, Tomas Härdin wrote:
> > +#ifdef _WIN32
> > +lib_handle = dlopen("mvM264Ffmpeg.dll", RTLD_LAZY);
> > +#else   
> > +lib_handle = dlopen("libmvM264Ffmpeg.so", RTLD_LAZY);
> > +#endif
> 
> Still dlopen() I see. You should link to these libraries properly, as
> others have said, and add appropriate license stuff to configure.

What are those libraries? Are they drivers/system libraries?

They seem to be a wrapper done just for the FFMpeg integration. If so, what is 
the license of those?

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Ronald S. Bultje]

Hi guys,

On Thu, Mar 14, 2019 at 1:55 PM Yufei He  wrote:

> Hi
>
> Here is the patch for a new H.264 codec with Matrox m264 card.
>

I want to bring up again that this library is closed-source. I don't think
FFmpeg should link to closed-source software in its public mainline
version. Matrox is obviously free :-) to maintain their own modified
version as long as they comply with all licensing conditions.

On IRC, we just discussed the following:
- --enable-nonfree was initially intended for dealing sort of roughly with
incompatible opensource licenses, for example AAC encoders or GPL +
LGPL-compatible-but-LGPL-incomptible libraries;
- nowadays, --enable-nonfree is also used for NDI (which Kieran sent a
patch to remove already) and now this.

I would like to request a vote amongst frequent developers (and if you
don't count me amongst that, that's fine) to decide whether closed-source
software integration in general, as well as this one in particular, is OK.
I don't think the system library provision applies here, since you'll be
hard-pressed to find a system with Matrox hardware (it's high-$$$
enterprise stuff).

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Tomas Härdin]

tor 2019-03-14 klockan 17:55 + skrev Yufei He:
> Hi
> 
> Here is the patch for a new H.264 codec with Matrox m264 card.
> 
> Please review.

> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1705,7 +1705,6 @@ static const AVCodecDescriptor
> codec_descriptors[] = {
>  .long_name = NULL_IF_CONFIG_SMALL("Gryphon's Anim
> Compressor"),
>  .props = AV_CODEC_PROP_LOSSY,
>  },
> -
>  /* various PCM "codecs" */
>  {
>  .id= AV_CODEC_ID_PCM_S16LE,
> diff --git a/libavcodec/m264dec.c b/libavcodec/m264dec.c

Stray hunk?

> +#ifdef _WIN32
> +lib_handle = dlopen("mvM264Ffmpeg.dll", RTLD_LAZY);
> +#else   
> +lib_handle = dlopen("libmvM264Ffmpeg.so", RTLD_LAZY);
> +#endif

Still dlopen() I see. You should link to these libraries properly, as
others have said, and add appropriate license stuff to configure.

/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Yufei He]

Hi

Here is the patch for a new H.264 codec with Matrox m264 card.

Please review.

Thanks.

Yufei.


From b1f7779028378f3e0d5360766a8591d0cf5a0a71 Mon Sep 17 00:00:00 2001
From: yhe 
Date: Thu, 14 Mar 2019 10:10:46 -0400
Subject: [PATCH] H.264 encoder and decoder support with Matrox M264.

---
 Changelog   |   1 +
 configure   |   2 +
 libavcodec/Makefile |   2 +
 libavcodec/allcodecs.c  |   2 +
 libavcodec/codec_desc.c |   1 -
 libavcodec/m264dec.c| 315 
 libavcodec/m264dec.h|  39 ++
 libavcodec/m264enc.c| 296 +
 libavcodec/m264enc.h|  38 ++
 9 files changed, 695 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/m264dec.c
 create mode 100644 libavcodec/m264dec.h
 create mode 100644 libavcodec/m264enc.c
 create mode 100644 libavcodec/m264enc.h

diff --git a/Changelog b/Changelog
index 4d80e5b..ce0daf8 100644
--- a/Changelog
+++ b/Changelog
@@ -19,6 +19,7 @@ version :
 - ARBC decoder
 - libaribb24 based ARIB STD-B24 caption support (profiles A and C)
 - Support decoding of HEVC 4:4:4 content in nvdec and cuviddec
+- Support h.264 encoding and decoding with Matrox M264 card.
 
 
 version 4.1:
diff --git a/configure b/configure
index dcead3a..5a5d7d5 100755
--- a/configure
+++ b/configure
@@ -2697,6 +2697,8 @@ h263p_decoder_select="h263_decoder"
 h263p_encoder_select="h263_encoder"
 h264_decoder_select="cabac golomb h264chroma h264dsp h264parse h264pred h264qpel videodsp"
 h264_decoder_suggest="error_resilience"
+h264_m264_decoder_deps_any="libdl"
+h264_m264_encoder_deps_any="libdl"
 hap_decoder_select="snappy texturedsp"
 hap_encoder_deps="libsnappy"
 hap_encoder_select="texturedspenc"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 15c43a8..8e8f9ab 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -348,6 +348,8 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o h264_cabac.o h264_cavlc.o \
   h264_slice.o h264data.o
 OBJS-$(CONFIG_H264_AMF_ENCODER)+= amfenc_h264.o
 OBJS-$(CONFIG_H264_CUVID_DECODER)  += cuviddec.o
+OBJS-$(CONFIG_H264_M264_DECODER)   += m264dec.o
+OBJS-$(CONFIG_H264_M264_ENCODER)   += m264enc.o
 OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o
 OBJS-$(CONFIG_H264_MMAL_DECODER)   += mmaldec.o
 OBJS-$(CONFIG_H264_NVENC_ENCODER)  += nvenc_h264.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b26aeca..c03a5a3 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -737,6 +737,8 @@ extern AVCodec ff_libopenh264_encoder;
 extern AVCodec ff_libopenh264_decoder;
 extern AVCodec ff_h264_amf_encoder;
 extern AVCodec ff_h264_cuvid_decoder;
+extern AVCodec ff_h264_m264_decoder;
+extern AVCodec ff_h264_m264_encoder;
 extern AVCodec ff_h264_nvenc_encoder;
 extern AVCodec ff_h264_omx_encoder;
 extern AVCodec ff_h264_qsv_encoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index a3de8e1..55c02a8 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1705,7 +1705,6 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("Gryphon's Anim Compressor"),
 .props = AV_CODEC_PROP_LOSSY,
 },
-
 /* various PCM "codecs" */
 {
 .id= AV_CODEC_ID_PCM_S16LE,
diff --git a/libavcodec/m264dec.c b/libavcodec/m264dec.c
new file mode 100644
index 000..f16716e
--- /dev/null
+++ b/libavcodec/m264dec.c
@@ -0,0 +1,315 @@
+/*
+ * M264 H.264 video decoder
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Matrox M264 card supports h.264 encoding and decoding.
+ */
+
+#include "decode.h"
+#include "cabac.h"
+#include "error_resilience.h"
+#include "h264_parse.h"
+#include "h264_ps.h"
+#include "h264_sei.h"
+#include "h2645_parse.h"
+#include "h264chroma.h"
+#include "h264dsp.h"
+#include "h264pred.h"
+#include "h264qpel.h"
+#include "internal.h"
+#include "mpegutils.h"
+#include "parser.h"
+#include "qpeldsp.h"
+#include "rectangle.h"
+#include "videodsp.h"
+#include "config.h"
+#include "libswscale/swscale.h"
+#include "m264dec.h"
+#ifdef _WIN32
+#include "compat/w32dlfcn.h"
+#else