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

2019-03-28 Thread 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.

2019-03-28 Thread 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.

2019-03-28 Thread 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.

2019-03-28 Thread 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.

2019-03-28 Thread 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.

2019-03-28 Thread 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.

2019-03-28 Thread 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.

2019-03-28 Thread 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.

2019-03-28 Thread 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.

2019-03-27 Thread 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.

2019-03-27 Thread 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.

2019-03-27 Thread 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.

2019-03-17 Thread 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.

2019-03-15 Thread 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.

2019-03-15 Thread 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.

2019-03-15 Thread 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.

2019-03-15 Thread 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.

2019-03-15 Thread 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.

2019-03-15 Thread 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.

2019-03-15 Thread 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.

2019-03-15 Thread 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.

2019-03-15 Thread 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.

2019-03-14 Thread 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
+#include

Re: [FFmpeg-devel] patch for a new H.264 codec

2019-03-11 Thread Michael Niedermayer 
On Mon, Mar 11, 2019 at 01:28:18PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Mar 11, 2019 at 12:21 PM Soft Works  wrote:
> 
> > > From: Nicolas George
> > >
> > > Yufei He (12019-03-11):
> > > > Matrox M264 is similar to other hardware codecs.
> > > >
> > > > I saw amf_load_library and nvenc_load_library in ffmpeg.
> > >
> > > Past practices do not constitute precedents.
> > >
> > > > We got a lot customers using ffmpeg and they want to use Matrox M264
> > to do transcoding.
> > >
> > > If you make the driver GPL-compatible, there will be no problem at all.
> > >
> > > Regards,
> > >
> > > --
> > >   Nicolas George
> >
> > While I don’t care much about Matrox, I’m a bit surprised about the
> > recent sounds here. Should  we expect ffmpeg to drop most hw
> > accelerations, then?
> >
> > IANAL, but aren’t drivers clearly considered to be system components?
> > In this case they would  be exempted from the GPL afaic?
> >
> 
> Getting very legal here for someone who's not a lawyer :), but my reading
> of the GPL is not that it says "something that acts at system level" (e.g.
> hardware), but something that is provided by the base system (i.e. you can
> assume it to be installed in some way shape or form regardless of the exact
> license that it is accompanied by). For example, you can assume your system
> has a libc, even though it might not be a GPL libc.
> 

> However, my objection is not legal, it is philosophical. 

> I would prefer
> that we (FFmpeg) as a project do not encourage the use of closed-source
> software or endorse particular closed-source software 

I agree


> (by including support
> for it in FFmpeg). We are an open source project, and thus (again: in my
> personal opinion) we should only endorse other open source software. That
> does not mean closed source software is bad or should not be used. It
> merely means we do not endorse it by including support for it.

I disagree that giving users the choice is encouraging a specific choice. Or
That including an option is endorsing it.
I also disagree that closed source software is not bad. It is in my
personal oppinion bad. In fact IMHO its bad for everyone both for the
authors as well as the users.
I agree though that using it if thats what one needs to get something done
is perfectly fine.

And the last useless comment from me today :)
It seems many in these recent threads assume that supporting some interfaces
to non free software harms open source. This sounds logic but iam not so sure
here this is actually true and maybe this is why iam disagreeing a bit.

and btw i do not understand why hw companies are not just making their
software free&open. This might actually increase their hw sales and decrease
their sw maintaince expenses ...

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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

2019-03-11 Thread Ronald S. Bultje 
Hi,

On Mon, Mar 11, 2019 at 12:21 PM Soft Works  wrote:

> > From: Nicolas George
> >
> > Yufei He (12019-03-11):
> > > Matrox M264 is similar to other hardware codecs.
> > >
> > > I saw amf_load_library and nvenc_load_library in ffmpeg.
> >
> > Past practices do not constitute precedents.
> >
> > > We got a lot customers using ffmpeg and they want to use Matrox M264
> to do transcoding.
> >
> > If you make the driver GPL-compatible, there will be no problem at all.
> >
> > Regards,
> >
> > --
> >   Nicolas George
>
> While I don’t care much about Matrox, I’m a bit surprised about the
> recent sounds here. Should  we expect ffmpeg to drop most hw
> accelerations, then?
>
> IANAL, but aren’t drivers clearly considered to be system components?
> In this case they would  be exempted from the GPL afaic?
>

Getting very legal here for someone who's not a lawyer :), but my reading
of the GPL is not that it says "something that acts at system level" (e.g.
hardware), but something that is provided by the base system (i.e. you can
assume it to be installed in some way shape or form regardless of the exact
license that it is accompanied by). For example, you can assume your system
has a libc, even though it might not be a GPL libc.

However, my objection is not legal, it is philosophical. I would prefer
that we (FFmpeg) as a project do not encourage the use of closed-source
software or endorse particular closed-source software (by including support
for it in FFmpeg). We are an open source project, and thus (again: in my
personal opinion) we should only endorse other open source software. That
does not mean closed source software is bad or should not be used. It
merely means we do not endorse it by including support for it.

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

2019-03-11 Thread Jean-Baptiste Kempf 
On Mon, 11 Mar 2019, at 17:46, Soft Works wrote:
> I still wonder why recent discussions are often referring to GPL even 
> though ffmpeg is released under LGPL.

Because LGPL is a derivative of the GPL, unfortunately.
And there are a lot more jurisprudence on the GPL, than on the LGPL.
And LGPL has an upgradability clause to GPL.

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

2019-03-11 Thread Soft Works 
> From: Jean-Baptiste Kempf
>
> On Mon, 11 Mar 2019, at 17:21, Soft Works wrote:
> > While I don’t care much about Matrox, I’m a bit surprised about the
> > recent sounds here. Should  we expect ffmpeg to drop most hw
> > accelerations, then?
>
> Absolutely not.

I very glad to hear that :-)

> > IANAL, but aren’t drivers clearly considered to be system components?
>
> Sure, but here, it does not seem to call a driver, but a specific library 
> called libmvM264Ffmpeg that is being called.
>
> Maybe this is just a mis-communication, though.

Well, it probably was then, thanks for the clarification.

I came to think that it's hardware related because:

> Nicolas wrote:
>> If you make the driver GPL-compatible, there will be no problem at all.


I still wonder why recent discussions are often referring to GPL even though 
ffmpeg is released under LGPL.


Best regards,
softworkz
___
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

2019-03-11 Thread Jean-Baptiste Kempf 
On Mon, 11 Mar 2019, at 17:21, Soft Works wrote:
> While I don’t care much about Matrox, I’m a bit surprised about the
> recent sounds here. Should  we expect ffmpeg to drop most hw
> accelerations, then?

Absolutely not.

> IANAL, but aren’t drivers clearly considered to be system components?

Sure, but here, it does not seem to call a driver, but a specific library 
called libmvM264Ffmpeg that is being called.

Maybe this is just a mis-communication, though.

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

2019-03-11 Thread Soft Works 
> From: Nicolas George
>
> Yufei He (12019-03-11):
> > Matrox M264 is similar to other hardware codecs.
> >
> > I saw amf_load_library and nvenc_load_library in ffmpeg.
>
> Past practices do not constitute precedents.
>
> > We got a lot customers using ffmpeg and they want to use Matrox M264 to do 
> > transcoding.
>
> If you make the driver GPL-compatible, there will be no problem at all.
>
> Regards,
>
> --
>   Nicolas George

While I don’t care much about Matrox, I’m a bit surprised about the
recent sounds here. Should  we expect ffmpeg to drop most hw
accelerations, then?

IANAL, but aren’t drivers clearly considered to be system components?
In this case they would  be exempted from the GPL afaic?

Anyway, I thought that ffmpeg is LGPL, not GPL. It only becomes GPL
as soon as someone is including GPL libraries, right?

And in that case: wouldn’t it be true that only the owners of
such an included GPL component could pursue and make demands
against a potential violator (violating GPL but not LGPL terms)?

Since ffmpeg code is LGPL, my understanding is that ffmpeg could only
pursue violations of the license under which it is publishing its code,
and that would be LGPL but not GPL.


I’m just wondering – are those assumptions incorrect?

Regards,
softworkz



___
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

2019-03-11 Thread Nicolas George 
Yufei He (12019-03-11):
> Matrox M264 is similar to other hardware codecs.
> 
> I saw amf_load_library and nvenc_load_library in ffmpeg.

Past practices do not constitute precedents.

> We got a lot customers using ffmpeg and they want to use Matrox M264 to do 
> transcoding.

If you make the driver GPL-compatible, there will be no problem at all.

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

2019-03-11 Thread Yufei He 
Hi Carl

Matrox M264 is similar to other hardware codecs.

I saw amf_load_library and nvenc_load_library in ffmpeg.

Matrox M264 is the same.

We got a lot customers using ffmpeg and they want to use Matrox M264 to do 
transcoding.

Thanks a lot.

Yufei.


static int amf_load_library(AVCodecContext *avctx)
{
AmfContext *ctx = avctx->priv_data;
AMFInit_Fn init_fun;
AMFQueryVersion_Fn version_fun;
AMF_RESULT res;
ctx->delayed_frame = av_frame_alloc();
if (!ctx->delayed_frame) {
return AVERROR(ENOMEM);
}
// hardcoded to current HW queue size - will realloc in 
timestamp_queue_enqueue() if too small
ctx->timestamp_list = av_fifo_alloc((avctx->max_b_frames + 16) * 
sizeof(int64_t));
if (!ctx->timestamp_list) {
return AVERROR(ENOMEM);
}
ctx->dts_delay = 0;
ctx->library = dlopen(AMF_DLL_NAMEA, RTLD_NOW | RTLD_LOCAL);
AMF_RETURN_IF_FALSE(ctx, ctx->library != NULL,
AVERROR_UNKNOWN, "DLL %s failed to open\n", AMF_DLL_NAMEA);
init_fun = (AMFInit_Fn)dlsym(ctx->library, AMF_INIT_FUNCTION_NAME);
AMF_RETURN_IF_FALSE(ctx, init_fun != NULL, AVERROR_UNKNOWN, "DLL %s failed to 
find function %s\n", AMF_DLL_NAMEA, AMF_INIT_FUNCTION_NAME);
version_fun = (AMFQueryVersion_Fn)dlsym(ctx->library, 
AMF_QUERY_VERSION_FUNCTION_NAME);
AMF_RETURN_IF_FALSE(ctx, version_fun != NULL, AVERROR_UNKNOWN, "DLL %s failed 
to find function %s\n", AMF_DLL_NAMEA, AMF_QUERY_VERSION_FUNCTION_NAME);


static av_cold int nvenc_load_libraries(AVCodecContext *avctx)
{
NvencContext *ctx = avctx->priv_data;
NvencDynLoadFunctions *dl_fn = &ctx->nvenc_dload_funcs;
NVENCSTATUS err;
uint32_t nvenc_max_ver;
int ret;
ret = cuda_load_functions(&dl_fn->cuda_dl, avctx);
if (ret < 0)
return ret;
ret = nvenc_load_functions(&dl_fn->nvenc_dl, avctx);
if (ret < 0) {
nvenc_print_driver_requirement(avctx, AV_LOG_ERROR);
return ret;
}
err = dl_fn->nvenc_dl->NvEncodeAPIGetMaxSupportedVersion(&nvenc_max_ver);
if (err != NV_ENC_SUCCESS)
return nvenc_print_error(avctx, err, "Failed to query nvenc max version");
av_log(avctx, AV_LOG_VERBOSE, "Loaded Nvenc version %d.%d\n", nvenc_max_ver >> 
4, nvenc_max_ver & 0xf);
if ((NVENCAPI_MAJOR_VERSION << 4 | NVENCAPI_MINOR_VERSION) > nvenc_max_ver) {
av_log(avctx, AV_LOG_ERROR, "Driver does not support the required nvenc API 
version. "
"Required: %d.%d Found: %d.%d\n",
NVENCAPI_MAJOR_VERSION, NVENCAPI_MINOR_VERSION,
nvenc_max_ver >> 4, nvenc_max_ver & 0xf);
On 03/11/2019 07:04 AM, Carl Eugen Hoyos wrote:

2019-03-11 11:57 GMT+01:00, Ronald S. Bultje 
:



- How do we set up a fate station with m264 support?



We do not test any external libraries with fate.

[...]



- How do we test that it still works after we make innocent
changes to some API?



Same as so far: We remove the feature that isn't updated.



- If we add new H264 files to our conformance suite, how
do we confirm that m264dec passes them?



That wouldn't work for any of our external codecs (at least
for some it wouldn't), in some cases the reason is that
the external codec supports things unsupported by FFmpeg,
in some cases there are license issues even with
open-source software.

Sorry, but some of this sounds like a solution in search of a
problem.

No strong opinion here about Matrox but we accepted AMD
in spite of their mails, so I don't see why we can't accept a
non-free Matrox codec (as long as the patch is reasonably
clean).

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


___
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

2019-03-11 Thread Carl Eugen Hoyos 
2019-03-11 11:57 GMT+01:00, Ronald S. Bultje :

> - How do we set up a fate station with m264 support?

We do not test any external libraries with fate.

[...]

> - How do we test that it still works after we make innocent
> changes to some API?

Same as so far: We remove the feature that isn't updated.

> - If we add new H264 files to our conformance suite, how
> do we confirm that m264dec passes them?

That wouldn't work for any of our external codecs (at least
for some it wouldn't), in some cases the reason is that
the external codec supports things unsupported by FFmpeg,
in some cases there are license issues even with
open-source software.

Sorry, but some of this sounds like a solution in search of a
problem.

No strong opinion here about Matrox but we accepted AMD
in spite of their mails, so I don't see why we can't accept a
non-free Matrox codec (as long as the patch is reasonably
clean).

Carl Eugen
___
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

2019-03-11 Thread Ronald S. Bultje 
Hi,

On Mon, Mar 11, 2019 at 4:53 AM Moritz Barsnick  wrote:

> On Mon, Mar 11, 2019 at 01:59:47 +0100, Carl Eugen Hoyos wrote:
> > The library needs non-free in configure and please
> > use dynamic linking, not loading at run-time.
>
> There is also no indication whatsoever where to get mvM264Ffmpeg.dll
> and libmvM264Ffmpeg.so from. No-one can even attempt to run (or - once
> you, Yufei, have fixed it - compile) this functionality without this.
> That's hopeless.
>

I want to reiterate my point from the other thread here that I think it's
time that we set an official project policy w.r.t. closed-source software.

I believe we should either choose that there is no place in FFmpeg for this
sort of things (I support this point of view), or we should set specific
guidelines about the software (I understand some developers lean more
towards this, and I respect that). Right now it's all random and that's not
good.

- How do we set up a fate station with m264 support? Or will matrox provide
one? Or will it be available to FFmpeg developers at no charge?
- How do we test that it still works after we make innocent changes to some
API?
- If we add new H264 files to our conformance suite, how do we confirm that
m264dec passes them?
- If we see particular optimizations or code changes that would make this
wrapper work better, how do we test that it still works? (If we can't, then
is the wrapper truly open source software?)
Etc.

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

2019-03-11 Thread Moritz Barsnick 
On Mon, Mar 11, 2019 at 01:59:47 +0100, Carl Eugen Hoyos wrote:
> The library needs non-free in configure and please
> use dynamic linking, not loading at run-time.

There is also no indication whatsoever where to get mvM264Ffmpeg.dll
and libmvM264Ffmpeg.so from. No-one can even attempt to run (or - once
you, Yufei, have fixed it - compile) this functionality without this.
That's hopeless.

Moritz
___
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

2019-03-10 Thread Carl Eugen Hoyos 
2019-02-25 21:41 GMT+01:00, Yufei He :

> Please review this one.

The library needs non-free in configure and please
use dynamic linking, not loading at run-time.

Please find out what top-posting means and avoid it here, Carl Eugen
___
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

2019-02-26 Thread Tomas Härdin 
tis 2019-02-26 klockan 14:26 + skrev Yufei He:
> Hi Tomas
> 
> Thanks for the review.
> 
> My codec is a hardware codec, it depends an dynamic library that goes 
> with the M264 card.
> 
> The way it works will be:
> 
> 1>Our customers buy the card and install the drivers of it.
> 
> 2>They Compile ffmpeg.
>
> 3>Call ffmpeg with codec option of m264.
> 
> That's why I use dlopen to load the dynamic library that talks with the 
> hardware.

Nothing in there indicates why dlopen() is a requirement. It is almost
always used for GPL circumvention, so you'd need to provide a very good
reason for why you need to do things via libdl.

I suggest taking a look at the other hwaccel codecs, and the
documentation as Nicolas suggests.

> Please help us check if it works in ffmpeg.

Testing if it works is kind of hard without the hardware.

/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

2019-02-26 Thread Nicolas George 
Yufei He (12019-02-26):
> My codec is a hardware codec, it depends an dynamic library that goes 
> with the M264 card.
> 
> The way it works will be:
> 
> 1>Our customers buy the card and install the drivers of it.
> 
> 2>They Compile ffmpeg.
> 
> 3>Call ffmpeg with codec option of m264.
> 
> That's why I use dlopen to load the dynamic library that talks with the 
> hardware.

That is not how FFmpeg does things; FFmpeg uses standard linking, unless
there is a very very good reason not to.

> Please help us check if it works in ffmpeg.

If you want to contribute, you need to learn how to interact with this
project. Read the documentation, read the development policy, look how
people who actually contribute act on the mailing list, etc. For
example, look up the thing about top-posting.

Unless you do that, you will not be able to contribute. And it will be
the last time you hear from me.

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

2019-02-26 Thread Yufei He 
Hi Moritz

It's the first time that I send patch to ffmpeg, for sure I don't know a 
lot of things for ffmpeg.

Thanks a lot for your detailed review.

I'll read the doc and fix the issues you said.

Yufei.


On 02/25/2019 04:21 PM, Moritz Barsnick wrote:
> Hi Yufei,
> before providing large patches here, do read this mailing list and the
> ffmpeg codebase for a while. It will help you to understand the
> process, and to understand how ffmpeg's sources are organized.
>
> I'm sure you missed this:
> https://www.ffmpeg.org/developer.html
>
> Read all of it thoroughly.
>
> The content of this section:
> https://www.ffmpeg.org/developer.html#Coding-Rules-1
> especially comes to mind. Your code uses totally different formatting
> than the rest of the ffmpeg codebase. You should take a look around as
> see how others do it, and what that style guide says.
>
> Apart from that: Everything that Nicolas wrote.
>
> In addition this:
>
> On Mon, Feb 25, 2019 at 19:49:43 +, Yufei He wrote:
>> index c90f119..f70368b 100644
>> --- a/Changelog
>> +++ b/Changelog
>> @@ -11,6 +11,7 @@ version :
>>   - dhav demuxer
>>   - PCM-DVD encoder
>>   - GIF parser
>> +- M264 encoder
> Your patch is against an at least two months old version of ffmpeg git.
> Please merge it to latest git HEAD and create a new patch. Your patch
> won't apply currently, and therefore noone will bother to test it.
>
> And even if I try to work around that, here's what happens:
>
> LD  ffmpeg_g
> /usr/bin/ld: libavcodec/libavcodec.a(m264enc.o): in function 
> `ff_m264_encode_init':
> /home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:98: 
> undefined reference to `dlopen'
> /usr/bin/ld: 
> /home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:108: 
> undefined reference to `dlsym'
> /usr/bin/ld: 
> /home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:109: 
> undefined reference to `dlsym'
> /usr/bin/ld: 
> /home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:110: 
> undefined reference to `dlsym'
> /usr/bin/ld: 
> /home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:111: 
> undefined reference to `dlsym'
> /usr/bin/ld: 
> /home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:112: 
> undefined reference to `dlsym'
> /usr/bin/ld: 
> libavcodec/libavcodec.a(m264enc.o):/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:113:
>  more undefined references to `dlsym' follow
> /usr/bin/ld: libavcodec/libavcodec.a(m264enc.o): in function 
> `ff_m264_encode_close':
> /home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:264: 
> undefined reference to `dlclose'
> collect2: error: ld returned 1 exit status
> make: *** [Makefile:108: ffmpeg_g] Error 1
>
> You need to get your dependencies right.
>
>> +   if(*got_output)
>> +   {
>> +  if(decoded_frame->width == 0)
>> +  {
>> + av_log(NULL, AV_LOG_DEBUG, "Frame parameters mismatch context 
>> %d,%d,%d != %d,%d,%d\n",
>> +   decoded_frame->width,
>> +   decoded_frame->height,
>> +   decoded_frame->format,
>> +   ist->dec_ctx->width,
>> +   ist->dec_ctx->height,
>> +   ist->dec_ctx->pix_fmt);
>> +  }
>> +   }
> This is debug code and does not belong into a released codec.
> Furthermore, ffmpeg provides av_log() functions.
>
>> index 000..dc1852f
>> --- /dev/null
>> +++ b/libavcodec/.vscode/settings.json
> Don't commit your local development environment's settings, please.
>
>>   OBJS-$(CONFIG_DNXHD_DECODER)   += dnxhddec.o dnxhddata.o
>>   OBJS-$(CONFIG_DNXHD_ENCODER)   += dnxhdenc.o dnxhddata.o
>> +OBJS-$(CONFIG_M264_ENCODER)+= m264enc.o
>> +OBJS-$(CONFIG_M264_DECODER)+= m264dec.o
>>   OBJS-$(CONFIG_DOLBY_E_DECODER) += dolby_e.o kbdwin.o
>>   OBJS-$(CONFIG_DPX_DECODER) += dpx.o
> Do you realize that the rest of this list is in alphabetical order?
>
>>   OBJS-$(CONFIG_VP9_SUPERFRAME_SPLIT_BSF)   += vp9_superframe_split_bsf.o
>>   
>> +
>> +
>> +
>>   # thread libraries
> Why do you add useless empty lines, and commit them?
>
>>   extern AVCodec ff_dnxhd_encoder;
>>   extern AVCodec ff_dnxhd_decoder;
>> +extern AVCodec ff_m264_encoder;
>> +extern AVCodec ff_m264_decoder;
>>   extern AVCodec ff_dpx_encoder;
>>   extern AVCodec ff_dpx_decoder;
> Alphabetical order, again.
>
>>   if (c)
>> -*opaque = (void*)(i + 1);
>> -
>> +  *opaque = (void*)(i + 1);
>> +
>>   return c;
> Useless change. And please don't ever leave whitespace at your line
> endings, it won't be accepted. (Your IDE surely can fix this for you.)
>
>> +#define FF_PROFILE_M264 0
> What is this?
>
>> +.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_REORDER,
>> +.profiles  = NULL_IF_CONFIG_SMALL(ff_h264_profiles),
> Does the encoder even honor any of the profiles?
>
>> +   #ifdef _WIN32
>> +   av_log(avctx, AV_LOG_DEBUG, "_WIN32\n");
>

Re: [FFmpeg-devel] patch for a new H.264 codec

2019-02-26 Thread Yufei He 
Hi Tomas

Thanks for the review.

My codec is a hardware codec, it depends an dynamic library that goes 
with the M264 card.

The way it works will be:

1>Our customers buy the card and install the drivers of it.

2>They Compile ffmpeg.

3>Call ffmpeg with codec option of m264.

That's why I use dlopen to load the dynamic library that talks with the 
hardware.

Please help us check if it works in ffmpeg.

Thanks.

Yufei.



On 02/25/2019 03:45 PM, Tomas Härdin wrote:
> Hi
>
>> +void convert_to_annexb(unsigned char * dest, unsigned long
>> data_size)
>> +{
>> +   unsigned char *current = dest;
>> +   union
>> +   {
>> +  unsigned char by4[4];
>> +  uint32_t length;
>> +   } union_u32_byte;
>> +
>> +   while ((dest + data_size) > (current + 4))
>> +   {
>> +  if((current[0] == 0) &&
>> + (current[1] == 0) &&
>> + (current[2] == 0) &&
>> + (current[3] == 1))
>> +  {
>> + // in case it is already in annex B
>> + break;
>> +  }
>> +
>> +  union_u32_byte.by4[3] = current[0];
>> +  union_u32_byte.by4[2] = current[1];
>> +  union_u32_byte.by4[1] = current[2];
>> +  union_u32_byte.by4[0] = current[3];
> This won't work on certain machines. Type punning is also undefined if
> memory serves me right, and may not work right in all compilers.
> Definitely not recommended. There are macros in FFmpeg for this already
> (AV_RL32 and friends)
>
>> +#ifdef _WIN32
>> +   lib_handle = dlopen("mvM264Ffmpeg.dll", RTLD_LAZY);
>> +#else
>> +   lib_handle = dlopen("libmvM264Ffmpeg.so", RTLD_LAZY);
>> +#endif
> I believe FFmpeg has policy specifically against stuff like this. Link
> the dynamic library properly, and put appropriate license stuff in
> configure. The resulting ffmpeg binaries will more than likely not be
> redistributable, libav* might also be depending on what the Matrox
> library's license is.
>
>> +   printf("m264_encode_init_h264: avctx->width = %d\n", avctx->width);
>> +   printf("m264_encode_init_h264: avctx->height = %d\n", avctx->height);
>> +   printf("m264_encode_init_h264: avctx->framerate.num = %d\n", 
>> avctx->framerate.num);
>> +   printf("m264_encode_init_h264: avctx->framerate.den = %d\n", 
>> avctx->framerate.den);
>> +   printf("m264_encode_init_h264: avctx->gop_size = %d\n", avctx->gop_size);
>> +   printf("m264_encode_init_h264: avctx->bit_rate = %" PRId64 "\n", 
>> avctx->bit_rate);
> Forgotten debug stuff? printf() is definitely not OK
>
> There are other issues with this patch, but there's no point in looking
> more for now
>
> /Tomas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
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

2019-02-25 Thread Moritz Barsnick 
Hi Yufei,
before providing large patches here, do read this mailing list and the
ffmpeg codebase for a while. It will help you to understand the
process, and to understand how ffmpeg's sources are organized.

I'm sure you missed this:
https://www.ffmpeg.org/developer.html

Read all of it thoroughly.

The content of this section:
https://www.ffmpeg.org/developer.html#Coding-Rules-1
especially comes to mind. Your code uses totally different formatting
than the rest of the ffmpeg codebase. You should take a look around as
see how others do it, and what that style guide says.

Apart from that: Everything that Nicolas wrote.

In addition this:

On Mon, Feb 25, 2019 at 19:49:43 +, Yufei He wrote:
> index c90f119..f70368b 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -11,6 +11,7 @@ version :
>  - dhav demuxer
>  - PCM-DVD encoder
>  - GIF parser
> +- M264 encoder

Your patch is against an at least two months old version of ffmpeg git.
Please merge it to latest git HEAD and create a new patch. Your patch
won't apply currently, and therefore noone will bother to test it.

And even if I try to work around that, here's what happens:

LD  ffmpeg_g
/usr/bin/ld: libavcodec/libavcodec.a(m264enc.o): in function 
`ff_m264_encode_init':
/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:98: 
undefined reference to `dlopen'
/usr/bin/ld: 
/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:108: 
undefined reference to `dlsym'
/usr/bin/ld: 
/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:109: 
undefined reference to `dlsym'
/usr/bin/ld: 
/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:110: 
undefined reference to `dlsym'
/usr/bin/ld: 
/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:111: 
undefined reference to `dlsym'
/usr/bin/ld: 
/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:112: 
undefined reference to `dlsym'
/usr/bin/ld: 
libavcodec/libavcodec.a(m264enc.o):/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:113:
 more undefined references to `dlsym' follow
/usr/bin/ld: libavcodec/libavcodec.a(m264enc.o): in function 
`ff_m264_encode_close':
/home/barsnick/Development/ffmpeg-stuff/ffmpeg/libavcodec/m264enc.c:264: 
undefined reference to `dlclose'
collect2: error: ld returned 1 exit status
make: *** [Makefile:108: ffmpeg_g] Error 1

You need to get your dependencies right.

> +   if(*got_output)
> +   {
> +  if(decoded_frame->width == 0)
> +  {
> + av_log(NULL, AV_LOG_DEBUG, "Frame parameters mismatch context 
> %d,%d,%d != %d,%d,%d\n",
> +   decoded_frame->width,
> +   decoded_frame->height,
> +   decoded_frame->format,
> +   ist->dec_ctx->width,
> +   ist->dec_ctx->height,
> +   ist->dec_ctx->pix_fmt);
> +  }
> +   }

This is debug code and does not belong into a released codec.
Furthermore, ffmpeg provides av_log() functions.

> index 000..dc1852f
> --- /dev/null
> +++ b/libavcodec/.vscode/settings.json

Don't commit your local development environment's settings, please.

>  OBJS-$(CONFIG_DNXHD_DECODER)   += dnxhddec.o dnxhddata.o
>  OBJS-$(CONFIG_DNXHD_ENCODER)   += dnxhdenc.o dnxhddata.o
> +OBJS-$(CONFIG_M264_ENCODER)+= m264enc.o
> +OBJS-$(CONFIG_M264_DECODER)+= m264dec.o
>  OBJS-$(CONFIG_DOLBY_E_DECODER) += dolby_e.o kbdwin.o
>  OBJS-$(CONFIG_DPX_DECODER) += dpx.o

Do you realize that the rest of this list is in alphabetical order?

>  OBJS-$(CONFIG_VP9_SUPERFRAME_SPLIT_BSF)   += vp9_superframe_split_bsf.o
>  
> +
> +
> +
>  # thread libraries

Why do you add useless empty lines, and commit them?

>  extern AVCodec ff_dnxhd_encoder;
>  extern AVCodec ff_dnxhd_decoder;
> +extern AVCodec ff_m264_encoder;
> +extern AVCodec ff_m264_decoder;
>  extern AVCodec ff_dpx_encoder;
>  extern AVCodec ff_dpx_decoder;

Alphabetical order, again.

>  if (c)
> -*opaque = (void*)(i + 1);
> -
> +  *opaque = (void*)(i + 1);
> +  
>  return c;

Useless change. And please don't ever leave whitespace at your line
endings, it won't be accepted. (Your IDE surely can fix this for you.)

> +#define FF_PROFILE_M264 0

What is this?

> +.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_REORDER,
> +.profiles  = NULL_IF_CONFIG_SMALL(ff_h264_profiles),

Does the encoder even honor any of the profiles?

> +   #ifdef _WIN32
> +   av_log(avctx, AV_LOG_DEBUG, "_WIN32\n");
> +   #elif defined _WIN64
> +   av_log(avctx, AV_LOG_DEBUG, "_WIN64\n");
> +   #else
> +   av_log(avctx, AV_LOG_DEBUG, "linux\n");
> +   #endif

What for?

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

I'm not sure this is acceptable within ffmpeg.

> +   if (!lib_handle)
> +   {
> +  av_log(avctx, AV_LOG_ERROR, "failed t

Re: [FFmpeg-devel] patch for a new H.264 codec

2019-02-25 Thread Tomas Härdin 
Hi

> +void convert_to_annexb(unsigned char * dest, unsigned long
> data_size)
> +{
> +   unsigned char *current = dest;
> +   union 
> +   {
> +  unsigned char by4[4];
> +  uint32_t length;
> +   } union_u32_byte;
> +  
> +   while ((dest + data_size) > (current + 4))
> +   {
> +  if((current[0] == 0) &&
> + (current[1] == 0) &&
> + (current[2] == 0) &&
> + (current[3] == 1))
> +  {
> + // in case it is already in annex B
> + break;
> +  }
> +
> +  union_u32_byte.by4[3] = current[0];
> +  union_u32_byte.by4[2] = current[1];
> +  union_u32_byte.by4[1] = current[2];
> +  union_u32_byte.by4[0] = current[3];

This won't work on certain machines. Type punning is also undefined if
memory serves me right, and may not work right in all compilers.
Definitely not recommended. There are macros in FFmpeg for this already
(AV_RL32 and friends)

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

I believe FFmpeg has policy specifically against stuff like this. Link
the dynamic library properly, and put appropriate license stuff in
configure. The resulting ffmpeg binaries will more than likely not be
redistributable, libav* might also be depending on what the Matrox
library's license is.

> +   printf("m264_encode_init_h264: avctx->width = %d\n", avctx->width);
> +   printf("m264_encode_init_h264: avctx->height = %d\n", avctx->height);
> +   printf("m264_encode_init_h264: avctx->framerate.num = %d\n", 
> avctx->framerate.num);
> +   printf("m264_encode_init_h264: avctx->framerate.den = %d\n", 
> avctx->framerate.den);
> +   printf("m264_encode_init_h264: avctx->gop_size = %d\n", avctx->gop_size);
> +   printf("m264_encode_init_h264: avctx->bit_rate = %" PRId64 "\n", 
> avctx->bit_rate);

Forgotten debug stuff? printf() is definitely not OK

There are other issues with this patch, but there's no point in looking
more for now

/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

2019-02-25 Thread Yufei He 
Hi

Please review this one.

Thanks.

Yufei.


On 02/25/2019 02:58 PM, Nicolas George wrote:

Yufei He (12019-02-25):


From 7dd17409a22858f3c18d832c301fb904508dea3b Mon Sep 17 00:00:00 2001
From: yhe 
Date: Mon, 25 Feb 2019 14:38:21 -0500
Subject: [PATCH] M264 codec support



Quick comments.

They are in no way to be taken as any kind of endorsement for the patch.




---
 .vscode/settings.json|  27 +++



No, thanks.



 Changelog|   1 +
 configure|   1 +
 doc/general.texi |   1 +
 fftools/ffmpeg.c |  14 ++
 libavcodec/.vscode/settings.json |   5 +
 libavcodec/Makefile  |   5 +
 libavcodec/allcodecs.c   |   6 +-
 libavcodec/avcodec.h |   3 +
 libavcodec/codec_desc.c  |   9 +
 libavcodec/m264dec.c | 476 +++
 libavcodec/m264dec.h |  42 
 libavcodec/m264enc.c | 289 
 libavcodec/m264enc.h |  39 
 libavcodec/profiles.c|   5 +
 libavcodec/profiles.h|   1 +
 16 files changed, 922 insertions(+), 2 deletions(-)
 create mode 100644 .vscode/settings.json
 create mode 100644 libavcodec/.vscode/settings.json
 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/.vscode/settings.json b/.vscode/settings.json
new file mode 100644
index 000..4cdd683
--- /dev/null
+++ b/.vscode/settings.json
@@ -0,0 +1,27 @@
+{
+   "files.associations": {
+  "avcodec.h": "c",
+  "nvdec.h": "c",
+  "config.h": "c",
+  "avassert.h": "c",
+  "iostream": "cpp",
+  "profiles.h": "c",
+  "swscale.h": "c",
+  "array": "c",
+  "functional": "c",
+  "hash_map": "c",
+  "initializer_list": "c",
+  "utility": "c",
+  "*.tcc": "cpp",
+  "deque": "cpp",
+  "list": "cpp",
+  "vector": "cpp",
+  "system_error": "cpp",
+  "bitset": "cpp",
+  "valarray": "cpp",
+  "adpcm_data.h": "c",
+  "blockdsp.h": "c",
+  "channel_layout.h": "c",
+  "h264chroma.h": "c"
+   }
+}
\ No newline at end of file
diff --git a/Changelog b/Changelog
index c90f119..f70368b 100644
--- a/Changelog
+++ b/Changelog
@@ -11,6 +11,7 @@ version :
 - dhav demuxer
 - PCM-DVD encoder
 - GIF parser
+- M264 encoder


 version 4.1:
diff --git a/configure b/configure
index b062b63..161beee 100755
--- a/configure
+++ b/configure
@@ -2618,6 +2618,7 @@ dds_decoder_select="texturedsp"
 dirac_decoder_select="dirac_parse dwt golomb videodsp mpegvideoenc"
 dnxhd_decoder_select="blockdsp idctdsp"
 dnxhd_encoder_select="blockdsp fdctdsp idctdsp mpegvideoenc pixblockdsp"





+#m264_encoder_select="blockdsp fdctdsp idctdsp mpegvideoenc pixblockdsp"



Leftover debug.



 dolby_e_decoder_select="mdct"
 dvvideo_decoder_select="dvprofile idctdsp"
 dvvideo_encoder_select="dvprofile fdctdsp me_cmp pixblockdsp"
diff --git a/doc/general.texi b/doc/general.texi
index 2bc33d1..e012bad 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -828,6 +828,7 @@ following image formats are supported:
 @item Deluxe Paint Animation @tab @tab  X
 @item DNxHD  @tab   X @tab  X
 @tab aka SMPTE VC3





+@item M264   @tab   X @tab



Does not belong there.



 @item Duck TrueMotion 1.0   @tab @tab  X
 @tab fourcc: DUCK
 @item Duck TrueMotion 2.0@tab @tab  X
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 6abcc57..b8fa266 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2418,6 +2418,20 @@ static int decode_video(InputStream *ist, AVPacket *pkt, 
int *got_output, int64_
 if (!*got_output || ret < 0)
 return ret;






+   if(*got_output)
+   {
+  if(decoded_frame->width == 0)
+  {
+ av_log(NULL, AV_LOG_DEBUG, "Frame parameters mismatch context 
%d,%d,%d != %d,%d,%d\n",
+   decoded_frame->width,
+   decoded_frame->height,
+   decoded_frame->format,
+   ist->dec_ctx->width,
+   ist->dec_ctx->height,
+   ist->dec_ctx->pix_fmt);
+  }
+   }
+



Unrelated. And coding style inconsistent.



 if(ist->top_field_first>=0)
 decoded_frame->top_field_first = ist->top_field_first;

diff --git a/libavcodec/.vscode/settings.json b/libavcodec/.vscode/settings.json
new file mode 100644
index 000..dc1852f
--- /dev/null
+++ b/libavcodec/.vscode/settings.json
@@ -0,0 +1,5 @@
+{
+   "files.associations": {
+  "amfenc.h": "c"
+   }
+}
\ No newline at end of file
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index d53b8ff..32d147f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -266,6 +266,8 @@ OBJS-$(CONFIG_DIRAC_DECODER)   += diracdec.o 
dirac.o diracdsp.o diractab
 OBJS-$(CONFIG_DFA_DECODER) += dfa.o
 OBJ

Re: [FFmpeg-devel] patch for a new H.264 codec

2019-02-25 Thread Nicolas George 
Yufei He (12019-02-25):
> From 7dd17409a22858f3c18d832c301fb904508dea3b Mon Sep 17 00:00:00 2001
> From: yhe 
> Date: Mon, 25 Feb 2019 14:38:21 -0500
> Subject: [PATCH] M264 codec support

Quick comments.

They are in no way to be taken as any kind of endorsement for the patch.

> 
> ---
>  .vscode/settings.json|  27 +++

No, thanks.

>  Changelog|   1 +
>  configure|   1 +
>  doc/general.texi |   1 +
>  fftools/ffmpeg.c |  14 ++
>  libavcodec/.vscode/settings.json |   5 +
>  libavcodec/Makefile  |   5 +
>  libavcodec/allcodecs.c   |   6 +-
>  libavcodec/avcodec.h |   3 +
>  libavcodec/codec_desc.c  |   9 +
>  libavcodec/m264dec.c | 476 
> +++
>  libavcodec/m264dec.h |  42 
>  libavcodec/m264enc.c | 289 
>  libavcodec/m264enc.h |  39 
>  libavcodec/profiles.c|   5 +
>  libavcodec/profiles.h|   1 +
>  16 files changed, 922 insertions(+), 2 deletions(-)
>  create mode 100644 .vscode/settings.json
>  create mode 100644 libavcodec/.vscode/settings.json
>  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/.vscode/settings.json b/.vscode/settings.json
> new file mode 100644
> index 000..4cdd683
> --- /dev/null
> +++ b/.vscode/settings.json
> @@ -0,0 +1,27 @@
> +{
> +   "files.associations": {
> +  "avcodec.h": "c",
> +  "nvdec.h": "c",
> +  "config.h": "c",
> +  "avassert.h": "c",
> +  "iostream": "cpp",
> +  "profiles.h": "c",
> +  "swscale.h": "c",
> +  "array": "c",
> +  "functional": "c",
> +  "hash_map": "c",
> +  "initializer_list": "c",
> +  "utility": "c",
> +  "*.tcc": "cpp",
> +  "deque": "cpp",
> +  "list": "cpp",
> +  "vector": "cpp",
> +  "system_error": "cpp",
> +  "bitset": "cpp",
> +  "valarray": "cpp",
> +  "adpcm_data.h": "c",
> +  "blockdsp.h": "c",
> +  "channel_layout.h": "c",
> +  "h264chroma.h": "c"
> +   }
> +}
> \ No newline at end of file
> diff --git a/Changelog b/Changelog
> index c90f119..f70368b 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -11,6 +11,7 @@ version :
>  - dhav demuxer
>  - PCM-DVD encoder
>  - GIF parser
> +- M264 encoder
>  
>  
>  version 4.1:
> diff --git a/configure b/configure
> index b062b63..161beee 100755
> --- a/configure
> +++ b/configure
> @@ -2618,6 +2618,7 @@ dds_decoder_select="texturedsp"
>  dirac_decoder_select="dirac_parse dwt golomb videodsp mpegvideoenc"
>  dnxhd_decoder_select="blockdsp idctdsp"
>  dnxhd_encoder_select="blockdsp fdctdsp idctdsp mpegvideoenc pixblockdsp"

> +#m264_encoder_select="blockdsp fdctdsp idctdsp mpegvideoenc pixblockdsp"

Leftover debug.

>  dolby_e_decoder_select="mdct"
>  dvvideo_decoder_select="dvprofile idctdsp"
>  dvvideo_encoder_select="dvprofile fdctdsp me_cmp pixblockdsp"
> diff --git a/doc/general.texi b/doc/general.texi
> index 2bc33d1..e012bad 100644
> --- a/doc/general.texi
> +++ b/doc/general.texi
> @@ -828,6 +828,7 @@ following image formats are supported:
>  @item Deluxe Paint Animation @tab @tab  X
>  @item DNxHD  @tab   X @tab  X
>  @tab aka SMPTE VC3

> +@item M264   @tab   X @tab  

Does not belong there.

>  @item Duck TrueMotion 1.0   @tab @tab  X
>  @tab fourcc: DUCK
>  @item Duck TrueMotion 2.0@tab @tab  X
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 6abcc57..b8fa266 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2418,6 +2418,20 @@ static int decode_video(InputStream *ist, AVPacket 
> *pkt, int *got_output, int64_
>  if (!*got_output || ret < 0)
>  return ret;
>  

> +   if(*got_output)
> +   {
> +  if(decoded_frame->width == 0)
> +  {
> + av_log(NULL, AV_LOG_DEBUG, "Frame parameters mismatch context 
> %d,%d,%d != %d,%d,%d\n",
> +   decoded_frame->width,
> +   decoded_frame->height,
> +   decoded_frame->format,
> +   ist->dec_ctx->width,
> +   ist->dec_ctx->height,
> +   ist->dec_ctx->pix_fmt);
> +  }
> +   }
> +

Unrelated. And coding style inconsistent.

>  if(ist->top_field_first>=0)
>  decoded_frame->top_field_first = ist->top_field_first;
>  
> diff --git a/libavcodec/.vscode/settings.json 
> b/libavcodec/.vscode/settings.json
> new file mode 100644
> index 000..dc1852f
> --- /dev/null
> +++ b/libavcodec/.vscode/settings.json
> @@ -0,0 +1,5 @@
> +{
> +   "files.associations": {
> +  "amfenc.h": "c"
> +   }
> +}
> \ No newline at end of file
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index d53b8ff..32d147f 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
>

[FFmpeg-devel] patch for a new H.264 codec

2019-02-25 Thread Yufei He 
Hi

Here is the patch.

Please check.

Thanks.

Yufei.


From 7dd17409a22858f3c18d832c301fb904508dea3b Mon Sep 17 00:00:00 2001
From: yhe 
Date: Mon, 25 Feb 2019 14:38:21 -0500
Subject: [PATCH] M264 codec support

---
 .vscode/settings.json|  27 +++
 Changelog|   1 +
 configure|   1 +
 doc/general.texi |   1 +
 fftools/ffmpeg.c |  14 ++
 libavcodec/.vscode/settings.json |   5 +
 libavcodec/Makefile  |   5 +
 libavcodec/allcodecs.c   |   6 +-
 libavcodec/avcodec.h |   3 +
 libavcodec/codec_desc.c  |   9 +
 libavcodec/m264dec.c | 476 +++
 libavcodec/m264dec.h |  42 
 libavcodec/m264enc.c | 289 
 libavcodec/m264enc.h |  39 
 libavcodec/profiles.c|   5 +
 libavcodec/profiles.h|   1 +
 16 files changed, 922 insertions(+), 2 deletions(-)
 create mode 100644 .vscode/settings.json
 create mode 100644 libavcodec/.vscode/settings.json
 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/.vscode/settings.json b/.vscode/settings.json
new file mode 100644
index 000..4cdd683
--- /dev/null
+++ b/.vscode/settings.json
@@ -0,0 +1,27 @@
+{
+   "files.associations": {
+  "avcodec.h": "c",
+  "nvdec.h": "c",
+  "config.h": "c",
+  "avassert.h": "c",
+  "iostream": "cpp",
+  "profiles.h": "c",
+  "swscale.h": "c",
+  "array": "c",
+  "functional": "c",
+  "hash_map": "c",
+  "initializer_list": "c",
+  "utility": "c",
+  "*.tcc": "cpp",
+  "deque": "cpp",
+  "list": "cpp",
+  "vector": "cpp",
+  "system_error": "cpp",
+  "bitset": "cpp",
+  "valarray": "cpp",
+  "adpcm_data.h": "c",
+  "blockdsp.h": "c",
+  "channel_layout.h": "c",
+  "h264chroma.h": "c"
+   }
+}
\ No newline at end of file
diff --git a/Changelog b/Changelog
index c90f119..f70368b 100644
--- a/Changelog
+++ b/Changelog
@@ -11,6 +11,7 @@ version :
 - dhav demuxer
 - PCM-DVD encoder
 - GIF parser
+- M264 encoder
 
 
 version 4.1:
diff --git a/configure b/configure
index b062b63..161beee 100755
--- a/configure
+++ b/configure
@@ -2618,6 +2618,7 @@ dds_decoder_select="texturedsp"
 dirac_decoder_select="dirac_parse dwt golomb videodsp mpegvideoenc"
 dnxhd_decoder_select="blockdsp idctdsp"
 dnxhd_encoder_select="blockdsp fdctdsp idctdsp mpegvideoenc pixblockdsp"
+#m264_encoder_select="blockdsp fdctdsp idctdsp mpegvideoenc pixblockdsp"
 dolby_e_decoder_select="mdct"
 dvvideo_decoder_select="dvprofile idctdsp"
 dvvideo_encoder_select="dvprofile fdctdsp me_cmp pixblockdsp"
diff --git a/doc/general.texi b/doc/general.texi
index 2bc33d1..e012bad 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -828,6 +828,7 @@ following image formats are supported:
 @item Deluxe Paint Animation @tab @tab  X
 @item DNxHD  @tab   X @tab  X
 @tab aka SMPTE VC3
+@item M264   @tab   X @tab  
 @item Duck TrueMotion 1.0   @tab @tab  X
 @tab fourcc: DUCK
 @item Duck TrueMotion 2.0@tab @tab  X
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 6abcc57..b8fa266 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2418,6 +2418,20 @@ static int decode_video(InputStream *ist, AVPacket *pkt, int *got_output, int64_
 if (!*got_output || ret < 0)
 return ret;
 
+   if(*got_output)
+   {
+  if(decoded_frame->width == 0)
+  {
+ av_log(NULL, AV_LOG_DEBUG, "Frame parameters mismatch context %d,%d,%d != %d,%d,%d\n",
+   decoded_frame->width,
+   decoded_frame->height,
+   decoded_frame->format,
+   ist->dec_ctx->width,
+   ist->dec_ctx->height,
+   ist->dec_ctx->pix_fmt);
+  }
+   }
+
 if(ist->top_field_first>=0)
 decoded_frame->top_field_first = ist->top_field_first;
 
diff --git a/libavcodec/.vscode/settings.json b/libavcodec/.vscode/settings.json
new file mode 100644
index 000..dc1852f
--- /dev/null
+++ b/libavcodec/.vscode/settings.json
@@ -0,0 +1,5 @@
+{
+   "files.associations": {
+  "amfenc.h": "c"
+   }
+}
\ No newline at end of file
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index d53b8ff..32d147f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -266,6 +266,8 @@ OBJS-$(CONFIG_DIRAC_DECODER)   += diracdec.o dirac.o diracdsp.o diractab
 OBJS-$(CONFIG_DFA_DECODER) += dfa.o
 OBJS-$(CONFIG_DNXHD_DECODER)   += dnxhddec.o dnxhddata.o
 OBJS-$(CONFIG_DNXHD_ENCODER)   += dnxhdenc.o dnxhddata.o
+OBJS-$(CONFIG_M264_ENCODER)+= m264enc.o
+OBJS-$(CONFIG_M264_DECODER)+= m264dec.o
 OBJS-$(CONFIG_DOLBY_E_DECODER) += dolby_e.o kbdwin.o
 OBJS-$(

[FFmpeg-devel] patch for a new H.264 codec

2019-02-25 Thread Yufei He 
Hi

I just finished a new codec for h.264, how to send patches to review ?

This  is my first piece of code  for ffmpeg.


When you submit your patch, please use git format-patch or git send-email.
/

I did "git format-patch", but where is the patch?

My git said " git: 'send-email' is not a git command. See 'git --help'."

Please help.

Thanks.

Yufei.



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