[FFmpeg-devel] [Patch]Qualification task for TrueHD encoder

[Disha Singh]

This patch has an lpc issue, and needs some work with passing of parameters
in ff_lpc_calc_coeff(), which my mentor said he would help with.

Thanks!

-Disha
From 9ab9819c2e2bb0759944a69204918fad10102ef1 Mon Sep 17 00:00:00 2001
From: dinux5 
Date: Mon, 4 Apr 2016 08:41:56 +0530
Subject: [PATCH] MLP ENCODER.

---
 Changelog  |1 +
 configure  |1 +
 libavcodec/Makefile|1 +
 libavcodec/allcodecs.c |2 +-
 libavcodec/mlp.h   |4 +
 libavcodec/mlpenc.c| 2496 
 6 files changed, 2504 insertions(+), 1 deletion(-)
 create mode 100755 libavcodec/mlpenc.c

diff --git a/Changelog b/Changelog
index 7b0187d..c682b01 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest within each release,
 releases are sorted from youngest to oldest.
 
 version :
+- mlp audio decoder
 - DXVA2-accelerated HEVC Main10 decoding
 - fieldhint filter
 - loop video filter and aloop audio filter
diff --git a/configure b/configure
index 94a66d8..9fab017 100755
--- a/configure
+++ b/configure
@@ -2383,6 +2383,7 @@ mjpeg_decoder_select="blockdsp hpeldsp exif idctdsp jpegtables"
 mjpeg_encoder_select="aandcttables jpegtables mpegvideoenc"
 mjpegb_decoder_select="mjpeg_decoder"
 mlp_decoder_select="mlp_parser"
+mlp_encoder_select="mlp_parser"
 motionpixels_decoder_select="bswapdsp"
 mp1_decoder_select="mpegaudio"
 mp1float_decoder_select="mpegaudio"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 801cccd..6c169fd 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -360,6 +360,7 @@ OBJS-$(CONFIG_MJPEG_DECODER)   += mjpegdec.o
 OBJS-$(CONFIG_MJPEG_ENCODER)   += mjpegenc.o mjpegenc_common.o
 OBJS-$(CONFIG_MJPEGB_DECODER)  += mjpegbdec.o
 OBJS-$(CONFIG_MLP_DECODER) += mlpdec.o mlpdsp.o
+OBJS-$(CONFIG_MLP_ENCODER) += mlpenc.o mlpdsp.o
 OBJS-$(CONFIG_MMVIDEO_DECODER) += mmvideo.o
 OBJS-$(CONFIG_MOTIONPIXELS_DECODER)+= motionpixels.o
 OBJS-$(CONFIG_MOVTEXT_DECODER) += movtextdec.o ass.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 0bbf7d3..138ff6b 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -414,7 +414,7 @@ void avcodec_register_all(void)
 REGISTER_DECODER(MACE3, mace3);
 REGISTER_DECODER(MACE6, mace6);
 REGISTER_DECODER(METASOUND, metasound);
-REGISTER_DECODER(MLP,   mlp);
+REGISTER_ENCDEC(MLP,   mlp);
 REGISTER_DECODER(MP1,   mp1);
 REGISTER_DECODER(MP1FLOAT,  mp1float);
 REGISTER_ENCDEC (MP2,   mp2);
diff --git a/libavcodec/mlp.h b/libavcodec/mlp.h
index 05d8dba..bc1e2f0 100644
--- a/libavcodec/mlp.h
+++ b/libavcodec/mlp.h
@@ -72,6 +72,10 @@
 
 /** filter data */
 typedef struct FilterParams {
+int coeff[MAX_FIR_ORDER];
+int coeff_bits;
+int coeff_shift;
+
 uint8_t order; ///< number of taps in filter
 uint8_t shift; ///< Right shift to apply to output of filter.
 
diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
new file mode 100755
index 000..1c96200
--- /dev/null
+++ b/libavcodec/mlpenc.c
@@ -0,0 +1,2496 @@
+/**
+ * MLP encoder
+ * Copyright (c) 2008 Ramiro Polla 
+ *
+ * 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
+ */
+
+#include "avcodec.h"
+#include "put_bits.h"
+#include "libavutil/crc.h"
+#include "libavutil/avstring.h"
+#include "mlp.h"
+#include "lpc.h"
+
+#include "libavutil/internal.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/channel_layout.h"
+#include "internal.h"
+#include "mlpdsp.h"
+#include "get_bits.h"
+
+#define MAJOR_HEADER_INTERVAL 16
+
+#define MLP_MIN_LPC_ORDER  1
+#define MLP_MAX_LPC_ORDER  8
+#define MLP_MIN_LPC_SHIFT  8
+#define MLP_MAX_LPC_SHIFT 15
+
+typedef struct {
+uint8_t min_channel; ///< The index of the first channel coded in this substream.
+uint8_t max_channel; ///< The index of the last channel coded in this substream.
+uint8_t max_matrix_channel;  ///< The number of channels input into the rematrix 

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Timothy Gu]

On Mon, Apr 04, 2016 at 06:06:28PM -0400, Aaron Boxer wrote:
> I could  give you an OS image that has a version of FFmpeg that uses
> proprietary codecs.

Aside from Carl's comment, please define "proprietary codecs." Proprietary
codecs have different licenses, just like how both ISC and GNU AGPL are
"open-source" licenses.

In fact, let me list out all the possibilities for such a "proprietary codec"
you can possibly talk about:

- cuda: No OS I know distribute CUDA by default. Not even Ubuntu.
- faac: Ditto.
- nvenc: Ditto.
- fdk-aac: The OS can distribute it legally if GPL is not enabled.
- openssl: Ditto.

Some other proprietary libraries not listed here do not need
"--enabled-nonfree" since they are system libraries (explicitly excluded in
GPL), and are irrelevant to this discussion.

> If you run it without knowing and without paying license, then you have a
> similar problem.

False. For all the libraries above, running alone does not pose any problems
with licensing.

cuda: "2.1  Rights and Limitations of Grant.  NVIDIA hereby grants Customer
the following non-exclusive, non-transferable right to use the SOFTWARE, with
the following limitations:" 2.1.1 says users cannot copy NVIDIA products.
2.1.2 gives an additional permission for Linux users. 2.1.3 concerns reverse
engineering, separation of components, and rentals.

faac: "ISO/IEC gives users of the MPEG-2 NBC/MPEG-4 Audio standards free
license to this software module or modifications thereof for use in hardware
or software products claiming conformance to the MPEG-2 NBC/ MPEG-4 Audio
standards."

nvenc: "Subject to Licensee’s compliance with the terms of this Agreement,
NVIDIA grants to Licensee a nonexclusive, non-transferable, worldwide,
royalty-free, fully paid-up license and right to install, use, reproduce,
display, perform, modify the Source Code of the Software" Limitations do not
include running.

fdk-aac: "Redistribution and use in source and binary forms, with or without
modification, are permitted without payment of copyright license fees provided
that you satisfy the following conditions" For the five conditions that
follow, 1, 2, and 4 concern only redistribution, and 3 and 5 concern only
documentation and advertising.

openssl: The clauses that makes OpenSSL GPL-incompatible are about
advertising.

> Should we then ban closed source codecs from FFmpeg?

No. Why ban them if it's perfectly legal to run them?

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

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 6:54 PM, Timothy Gu  wrote:

> Hi,
>
> On Mon, Apr 04, 2016 at 03:54:11PM -0400, Aaron Boxer wrote:
> > >
> > > >
> > > > The following changes were made:
> > > >
> > > > 1. Removed bpp (redundant as this information is already stored in
> > > precision)
> > >
> > > Does compilation still work without this change?
> > >
> >
> > Yes.
>
> Then the change is unrelated, and either needs to be in a separate patch or
> not commited at all.
>
> > >
> > > Does the compilation of OpenJPEG break _now_ without the patch? If so,
> > > submit
> > > a bug report, if not, then this change merits further discussion.
> > >
> >
> > Compilation against OpenJPEG master is broken, but everything works with
> > the latest release
> > of OpenJPEG (2.1)
>
> Would be great if you post the compilation log and file a ticket.
>
> > >
> > > If there isn't a way to detect Grok from OpenJPEG, there should be one.
> > >
> > > If it is not clear to you why we are so against AGPL, it is because it
> > > incurs
> > > additional restrictions on the work that we don't consider to be in the
> > > spirit
> > > of free software, regardless of what FSF says. But I think you already
> know
> > > about that.
> > >
> >
> > Why do you consider it to not be in the spirit of free software?
> > So far, nobody has given me a convincing argument against the use of  the
> > AGPL.
>
> I believe most members of the FFmpeg community consider free software the
> same
> way Linus Torvalds (among others) considers it: share the
> sources/modifications if you are distributing them, and do whatever you
> want
> with it if you are not.
>

Yes. Well, AGPL extends the definition of distribution to include use over
the network.


>
> We have no problem whatsoever with the entities using FFmpeg on their
> server
> without distributing the binaries or releasing their sources, or
> tivoization
> (which is a related, but different issue). Sure, it's better if they submit
> the patches, and we think that they are missing out by not submitting them,
> but we don't have any problems with it.
>

Fair enough.

>
> We do have a problem with the people that are preventing others from using
> the
> software under the aforementioned legitimate circumstances. For existing
> non-free software, we really don't have a choice, and it is clear to the
> user
> that such a copy of FFmpeg is non-free. But licenses like AGPL which claim
> it
> is "free" but fail our criteria of freedom are deemed to be "evil." In
> fact,
> AGPL is much more restrictive than most non-free licenses we deal with,
> since
> it concerns use in addition to distribution (see also Reimar's comments).
>

I see. So, licenses that fail your criteria of freedom are considered
"evil".
That is a pretty black and white view of the software world.
Also, I would point out that proprietary licenses most definitely restrict
use in addition to distribution.


>
> Moving forward, thanks to the explicit GPL compatibility shoehorned into
> Chapter 13 of AGPLv3, there isn't anything that makes us license our _own
> work_ as AGPL simply because FFmpeg binary is linked to an AGPL work (in
> fact,
> we cannot relicense our own code from LGPL to AGPLv3 like we can from LGPL
> to
> GPL). But using such a resultant mixture of licenses isn't something we
> want
> our users, personal or enterprise, to deal with.
>
>
This is a bit like parents thinking if they don't tell their kids about
sex, then they won't have sex.
We all know how that turns out.



> And that is why we are making more fuss about AGPL than most non-free
> libraries.
>
> Well, I don't want to flog a dead horse, so I guess we can all end the
discussion here:

Interesting points were raised, and  I learned some new things about
licensing.

Cheers,
Aaron





> Timothy
>
> P.S. I am not a lawyer.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 6:19 PM, Carl Eugen Hoyos  wrote:

> Aaron Boxer  gmail.com> writes:
>
> > I could  give you an OS image that has a version of
> > FFmpeg that uses proprietary codecs.
>
> You could, but you are not allowed to.
>

True.

Well, I guess you have come up with one disadvantage of the AGPL vs. GPL3:

1) You could receive a copy of FFmpeg that has an AGPL component, which the
person who
gave you the copy did not tell you about, and if you run this copy over the
network, and someone uses it
and asks you for source code, and you don't give it to them (because you
don't believe you are required to do so),
and if that person later discovers that your copy has an AGPL component,
then you are violating the AGPL.

I still think the advantages (i.e. closing the application server loophole)
outweigh this disadvantage.

Cheers,
Aaron
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Timothy Gu]

Hi,

On Mon, Apr 04, 2016 at 03:54:11PM -0400, Aaron Boxer wrote:
> >
> > >
> > > The following changes were made:
> > >
> > > 1. Removed bpp (redundant as this information is already stored in
> > precision)
> >
> > Does compilation still work without this change?
> >
> 
> Yes.

Then the change is unrelated, and either needs to be in a separate patch or
not commited at all.

> >
> > Does the compilation of OpenJPEG break _now_ without the patch? If so,
> > submit
> > a bug report, if not, then this change merits further discussion.
> >
> 
> Compilation against OpenJPEG master is broken, but everything works with
> the latest release
> of OpenJPEG (2.1)

Would be great if you post the compilation log and file a ticket.

> >
> > If there isn't a way to detect Grok from OpenJPEG, there should be one.
> >
> > If it is not clear to you why we are so against AGPL, it is because it
> > incurs
> > additional restrictions on the work that we don't consider to be in the
> > spirit
> > of free software, regardless of what FSF says. But I think you already know
> > about that.
> >
> 
> Why do you consider it to not be in the spirit of free software?
> So far, nobody has given me a convincing argument against the use of  the
> AGPL.

I believe most members of the FFmpeg community consider free software the same
way Linus Torvalds (among others) considers it: share the
sources/modifications if you are distributing them, and do whatever you want
with it if you are not.

We have no problem whatsoever with the entities using FFmpeg on their server
without distributing the binaries or releasing their sources, or tivoization
(which is a related, but different issue). Sure, it's better if they submit
the patches, and we think that they are missing out by not submitting them,
but we don't have any problems with it.

We do have a problem with the people that are preventing others from using the
software under the aforementioned legitimate circumstances. For existing
non-free software, we really don't have a choice, and it is clear to the user
that such a copy of FFmpeg is non-free. But licenses like AGPL which claim it
is "free" but fail our criteria of freedom are deemed to be "evil." In fact,
AGPL is much more restrictive than most non-free licenses we deal with, since
it concerns use in addition to distribution (see also Reimar's comments).

Moving forward, thanks to the explicit GPL compatibility shoehorned into
Chapter 13 of AGPLv3, there isn't anything that makes us license our _own
work_ as AGPL simply because FFmpeg binary is linked to an AGPL work (in fact,
we cannot relicense our own code from LGPL to AGPLv3 like we can from LGPL to
GPL). But using such a resultant mixture of licenses isn't something we want
our users, personal or enterprise, to deal with.

And that is why we are making more fuss about AGPL than most non-free
libraries.

Timothy

P.S. I am not a lawyer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Carl Eugen Hoyos]

Aaron Boxer  gmail.com> writes:

> I could  give you an OS image that has a version of 
> FFmpeg that uses proprietary codecs.

You could, but you are not allowed to.

Carl Eugen 




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

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Apr 4, 2016 5:12 PM, "Reimar Döffinger"  wrote:
>
> On Mon, Apr 04, 2016 at 03:48:38PM -0400, Aaron Boxer wrote:
> > On Mon, Apr 4, 2016 at 3:16 PM, Reimar Döffinger <
reimar.doeffin...@gmx.de>
> > wrote:
> >
> > > The really huge, gigantic, elephant sized issue with AGPL for me is
> > > that it is _completely_ unclear to me what you actually have to
> > > do to fulfill the license requirements of that "frankenmonster".
> > >
> >
> > Read the license, then.
>
> Which tells me exactly NOTHING.
> It says each piece is covered by ITS license.
> I.e. there isn't ONE license that covers the whole
> thing?!
> Their nice compatibility matrix shows what applies for
> other license combinations, but they left the AGPLv3
> out of that one!
> The license also never defines what exactly
> "if you modify the Program" would mean
> (so, if a company, for example Canonical, modified it and
> never gave me the source or even told me it was modified,
> is only the company in trouble or am I too? If I am,
> that's a problem, if I am not that's a loophole almost
> as big as the one it meant to fix).

Good question. There are legal grey zones for all licences. Doesn't mean we
have to stop using them

>
> > > No restrictions on use makes GPL very simple: if you don't
> > > redistribute, you don't need to do anything.
> > > What if you somehow got an OS image that happens to use
> > > a FFmpeg compiled against AGPL components (without you being
> > > aware, since you never use or care about the AGPL parts)
> > > and then use FFmpeg to stream over the net (or even your proprietary
> > > code), are you suddenly in violation of the license?
> > >
> >
> > What if you get a version of FFmeg compiled against GPLv3, without being
> > aware that this is the case,
> > and then combine it with a proprietary application ?  Same situation.
>
> No, absolutely no problem. None at all. Completely fine.
> Sure if you pass it on you have to check things (but also,
> only if you distribute the FFmpeg compiled as GPLv3, not if
> you simply distribute your binary, and also not if you
> distribute e.g. within your organization).
> And by accident distributing binary doesn't really happen,
> whereas accidentally having a server service run or exposed
> wider than expected happens all the time.
>
> > If the answer is "yes", I am against such a version of FFmpeg
> > > working without each _use_ of it requiring a special action
> > > that confirms users are aware of the license obligations.
> > >
> >
> > The same logic applies to GPLv3 distributions of FFmpeg.
>
> There is NO way that simply RUNNING a GPLv3 version of FFmpeg
> EVER triggers ANY license obligation.
> 

I could  give you an OS image that has a version of FFmpeg that uses
proprietary codecs. If you run it without knowing and without paying
license, then you have a similar problem.  Should we then ban closed source
codecs from FFmpeg?

Cheers,
Aaron

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

Re: [FFmpeg-devel] [PATCH] ffplay: fix silence insertion on error or pause

[Marton Balint]

On Mon, 4 Apr 2016, Lukasz Marek wrote:


On 03.04.2016 21:37, Marton Balint wrote:

Insertion of silence was a bit broken since
df34b700981de606ca4847e1ed0bfdf9ac3e9104 because the info whether or not the
source buffer supposed to be silence must be kept between callbacks. Failing to
do so causes rogue samples from the last buffer to be presented, I guess even a
crash can occur under some circumstances.

This patch uses a NULL audio_buf to keep the silence state across audio
callbacks.

Signed-off-by: Marton Balint 
---
 ffplay.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)


mea culpa


No problem, I missed it too :)


LGFM


Thanks, pushed.

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

Re: [FFmpeg-devel] [PATCH] ffplay: fix silence insertion on error or pause

[Marton Balint]

On Mon, 4 Apr 2016, Michael Niedermayer wrote:


On Sun, Apr 03, 2016 at 09:37:58PM +0200, Marton Balint wrote:

Insertion of silence was a bit broken since
df34b700981de606ca4847e1ed0bfdf9ac3e9104 because the info whether or not the
source buffer supposed to be silence must be kept between callbacks. Failing to
do so causes rogue samples from the last buffer to be presented, I guess even a
crash can occur under some circumstances.

This patch uses a NULL audio_buf to keep the silence state across audio
callbacks.

Signed-off-by: Marton Balint 
---
 ffplay.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)


slightly off topic but
does it sound better to repeat the last packet or to fill in
silence for damaged packets ?



IMHO silence is better, especially when multiple damaged packets follow 
each other. But in the current version of ffplay it's not really relevant 
because we simply ignore the decoding errors, and error is only returned 
from audio_decode_frame in case of issues like ENOMEM.


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

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Reimar Döffinger]

On Mon, Apr 04, 2016 at 03:48:38PM -0400, Aaron Boxer wrote:
> On Mon, Apr 4, 2016 at 3:16 PM, Reimar Döffinger 
> wrote:
> 
> > The really huge, gigantic, elephant sized issue with AGPL for me is
> > that it is _completely_ unclear to me what you actually have to
> > do to fulfill the license requirements of that "frankenmonster".
> >
> 
> Read the license, then.

Which tells me exactly NOTHING.
It says each piece is covered by ITS license.
I.e. there isn't ONE license that covers the whole
thing?!
Their nice compatibility matrix shows what applies for
other license combinations, but they left the AGPLv3
out of that one!
The license also never defines what exactly
"if you modify the Program" would mean
(so, if a company, for example Canonical, modified it and
never gave me the source or even told me it was modified,
is only the company in trouble or am I too? If I am,
that's a problem, if I am not that's a loophole almost
as big as the one it meant to fix).

> > No restrictions on use makes GPL very simple: if you don't
> > redistribute, you don't need to do anything.
> > What if you somehow got an OS image that happens to use
> > a FFmpeg compiled against AGPL components (without you being
> > aware, since you never use or care about the AGPL parts)
> > and then use FFmpeg to stream over the net (or even your proprietary
> > code), are you suddenly in violation of the license?
> >
> 
> What if you get a version of FFmeg compiled against GPLv3, without being
> aware that this is the case,
> and then combine it with a proprietary application ?  Same situation.

No, absolutely no problem. None at all. Completely fine.
Sure if you pass it on you have to check things (but also,
only if you distribute the FFmpeg compiled as GPLv3, not if
you simply distribute your binary, and also not if you
distribute e.g. within your organization).
And by accident distributing binary doesn't really happen,
whereas accidentally having a server service run or exposed
wider than expected happens all the time.

> If the answer is "yes", I am against such a version of FFmpeg
> > working without each _use_ of it requiring a special action
> > that confirms users are aware of the license obligations.
> >
> 
> The same logic applies to GPLv3 distributions of FFmpeg.

There is NO way that simply RUNNING a GPLv3 version of FFmpeg
EVER triggers ANY license obligation.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/exr : add support for compression in tile

[Martin Vignali]

2016-04-04 22:48 GMT+02:00 Paul B Mahol :

> On 4/4/16, Martin Vignali  wrote:
> > Hello,
> >
> > In attach a patch, in order to enable compression in tile.
> >
> > With modification inside PIZ uncompress, B44 uncompress, and PXR24
> > uncompress.
> >
> > s->xdelta is replace by s->xsize.
> > For scanline it doesn't make any change, because s->xsize == s->xdelta.
> > In tile s->xsize is the width of the tile or less (if we are at the right
> > of the datawindow).
> >
> > RLE, ZIP1, ZIP16 works without modification inside uncompress function.
> >
> >
> > Tile PIZ sample GoldenGate.exr works now
> > (can be found here :
> >
> http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz
> > )
> >
> > Martin
> > Jokyo Images
> >
>
> Applied, are you gonna add support for mip-maps and rip-maps?
>
> Thanks.

Yes i will add soon, support for mipmap and ripmap, in order to decode the
highest resolution level.

Martin
Jokyo Images
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffplay: fix silence insertion on error or pause

[Lukasz Marek]

On 03.04.2016 21:37, Marton Balint wrote:
> Insertion of silence was a bit broken since
> df34b700981de606ca4847e1ed0bfdf9ac3e9104 because the info whether or not the
> source buffer supposed to be silence must be kept between callbacks. Failing 
> to
> do so causes rogue samples from the last buffer to be presented, I guess even 
> a
> crash can occur under some circumstances.
> 
> This patch uses a NULL audio_buf to keep the silence state across audio
> callbacks.
> 
> Signed-off-by: Marton Balint 
> ---
>  ffplay.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

mea culpa
LGFM

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

Re: [FFmpeg-devel] libavcodec/exr : add support for compression in tile

[Paul B Mahol]

On 4/4/16, Martin Vignali  wrote:
> Hello,
>
> In attach a patch, in order to enable compression in tile.
>
> With modification inside PIZ uncompress, B44 uncompress, and PXR24
> uncompress.
>
> s->xdelta is replace by s->xsize.
> For scanline it doesn't make any change, because s->xsize == s->xdelta.
> In tile s->xsize is the width of the tile or less (if we are at the right
> of the datawindow).
>
> RLE, ZIP1, ZIP16 works without modification inside uncompress function.
>
>
> Tile PIZ sample GoldenGate.exr works now
> (can be found here :
> http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz
> )
>
> Martin
> Jokyo Images
>

Applied, are you gonna add support for mip-maps and rip-maps?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Added more tests to libswscale/utils.c

[Michael Niedermayer]

On Mon, Apr 04, 2016 at 06:41:51PM +, Petru Rares Sincraian wrote:
> Hi,
> 
> Now the function computes the sum of the values and displays the result.
> 
> 
> Thanks,
> Petru Rares.
> 
> 
> From: ffmpeg-devel  on behalf of Michael 
> Niedermayer 
> Sent: Wednesday, March 30, 2016 4:18 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] Added more tests to libswscale/utils.c
> 
> On Wed, Mar 30, 2016 at 10:12:29AM +, Petru Rares Sincraian wrote:
> > Hi,
> >
> > I solved the problems with swscale_license() and alloc_gamma_tbl() 
> > functions. I am working to solve alphaless_fmt() function in a different 
> > way.
> >
> > 
> > From: ffmpeg-devel  on behalf of Michael 
> > Niedermayer 
> > Sent: Sunday, March 27, 2016 9:43 PM
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH] Added more tests to libswscale/utils.c
> >
> > On Sun, Mar 27, 2016 at 04:39:39PM +, Petru Rares Sincraian wrote:
> > >
> > >   - Added test for: swscale_license()
> > >   - Added test for: alphaless_fmt()
> > >   - Added test for: alloc_gamma_tbl()
> > [...]
> >
> > > +static void test_alloc_gamma_tbl(void)
> > > +{
> > > +uint16_t *tbl = alloc_gamma_tbl(1.);
> > > +int i;
> > > +
> > > +// print only 32 elements
> > > +printf("e = 1.0\n");
> > > +for (i = 0; i < 65536; i += 2048)
> > > +printf("it: %d\t value: %d\n", i, tbl[i]);
> > > +
> > > +tbl = alloc_gamma_tbl(0.75);
> > > +printf("\ne = 0.75\n");
> > > +for (i = 0; i < 65536; i += 2048)
> > > +printf("it: %d\t value: %d\n", i, tbl[i]);
> > > +
> > > +tbl = alloc_gamma_tbl(2.8);
> > > +printf("\ne = 2.8\n");
> > > +for (i = 0; i < 65536; i += 2048)
> > > +printf("it: %d\t value: %d\n", i, tbl[i]);
> >
> > this leaks memory
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > In a rich man's house there is no place to spit but his face.
> > -- Diogenes of Sinope
> 
> >  libswscale/Makefile   |1
> >  libswscale/utils.c|   49 +
> >  tests/Makefile|1
> >  tests/fate/libswscale.mak |6 ++
> >  tests/ref/fate/utils  |  105 
> > ++
> >  5 files changed, 162 insertions(+)
> > f3e7cf692c31bf2df982eeeb97fc6fef8e3ec736  
> > 0001-Added-more-tests-to-libswscale-utils.c.patch
> > From ebefe53b13c878d50f5a388022c894d2b2c5ee96 Mon Sep 17 00:00:00 2001
> > From: Petru Rares Sincraian 
> > Date: Thu, 24 Mar 2016 18:46:02 +0100
> > Subject: [PATCH] Added more tests to libswscale/utils.c
> >
> >   - Added test for: swscale_license()
> >   - Added test for: alloc_gamma_tbl()
> > ---
> >  libswscale/Makefile   |   1 +
> >  libswscale/utils.c|  49 ++
> >  tests/Makefile|   1 +
> >  tests/fate/libswscale.mak |   6 +++
> >  tests/ref/fate/utils  | 105 
> > ++
> >  5 files changed, 162 insertions(+)
> >  create mode 100644 tests/fate/libswscale.mak
> >  create mode 100644 tests/ref/fate/utils
> >
> > diff --git a/libswscale/Makefile b/libswscale/Makefile
> > index a9f9e03..a6ae81d 100644
> > --- a/libswscale/Makefile
> > +++ b/libswscale/Makefile
> > @@ -27,3 +27,4 @@ SLIBOBJS-$(HAVE_GNU_WINDRES) += swscaleres.o
> >
> >  TESTPROGS = colorspace  \
> >  swscale \
> > +utils   \
> > diff --git a/libswscale/utils.c b/libswscale/utils.c
> > index ba409d6..b572a11 100644
> > --- a/libswscale/utils.c
> > +++ b/libswscale/utils.c
> > @@ -2410,3 +2410,52 @@ struct SwsContext *sws_getCachedContext(struct 
> > SwsContext *context, int srcW,
> >  }
> >  return context;
> >  }
> > +
> > +#ifdef TEST
> > +
> 
> > +static void test_swscale_license(void)
> > +{
> > +const char *license = swscale_license();
> > +if (!strcmp(FFMPEG_LICENSE, license))
> > +printf("License OK\n");
> > +else
> > +printf("License don't match.\nExpect: %s\nGiven: %s\n",
> > +FFMPEG_LICENSE, license);
> > +}
> 
> 
> > +
> > +static void test_alloc_gamma_tbl(void)
> > +{
> > +uint16_t *tbl;
> > +int i;
> > +
> > +// print only 32 elements
> > +tbl = alloc_gamma_tbl(1.);
> > +printf("e = 1.0\n");
> > +for (i = 0; i < 65536; i += 2048)
> > +printf("it: %d\t value: %d\n", i, tbl[i]);
> > +av_free(tbl);
> > +
> > +tbl = alloc_gamma_tbl(0.75);
> > +printf("\ne = 0.75\n");
> > +for (i = 0; i < 65536; i += 2048)
> > +printf("it: %d\t value: 

[FFmpeg-devel] libavcodec/exr : add support for compression in tile

[Martin Vignali]

Hello,

In attach a patch, in order to enable compression in tile.

With modification inside PIZ uncompress, B44 uncompress, and PXR24
uncompress.

s->xdelta is replace by s->xsize.
For scanline it doesn't make any change, because s->xsize == s->xdelta.
In tile s->xsize is the width of the tile or less (if we are at the right
of the datawindow).

RLE, ZIP1, ZIP16 works without modification inside uncompress function.


Tile PIZ sample GoldenGate.exr works now
(can be found here :
http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz
)

Martin
Jokyo Images
From dd7db17ac71a1517b57a5a81a70dc5ee1acaa0e5 Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Mon, 4 Apr 2016 22:00:31 +0200
Subject: [PATCH] libavcodec/exr : add support for compression in tile

---
 libavcodec/exr.c | 39 +--
 1 file changed, 17 insertions(+), 22 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index b0573d5..0e3974b 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -780,9 +780,9 @@ static int piz_uncompress(EXRContext *s, const uint8_t *src, int ssize,
 int size = channel->pixel_type;
 
 for (j = 0; j < size; j++)
-wav_decode(ptr + j, s->xdelta, size, s->ysize,
-   s->xdelta * size, maxval);
-ptr += s->xdelta * s->ysize * size;
+wav_decode(ptr + j, s->xsize, size, s->ysize,
+   s->xsize * size, maxval);
+ptr += s->xsize * s->ysize * size;
 }
 
 apply_lut(td->lut, tmp, dsize / sizeof(uint16_t));
@@ -790,9 +790,9 @@ static int piz_uncompress(EXRContext *s, const uint8_t *src, int ssize,
 out = td->uncompressed_data;
 for (i = 0; i < s->ysize; i++)
 for (j = 0; j < s->nb_channels; j++) {
-uint16_t *in = tmp + j * s->xdelta * s->ysize + i * s->xdelta;
-memcpy(out, in, s->xdelta * 2);
-out += s->xdelta * 2;
+uint16_t *in = tmp + j * s->xsize * s->ysize + i * s->xsize;
+memcpy(out, in, s->xsize * 2);
+out += s->xsize * 2;
 }
 
 return 0;
@@ -830,11 +830,11 @@ static int pxr24_uncompress(EXRContext *s, const uint8_t *src,
 switch (channel->pixel_type) {
 case EXR_FLOAT:
 ptr[0] = in;
-ptr[1] = ptr[0] + s->xdelta;
-ptr[2] = ptr[1] + s->xdelta;
-in = ptr[2] + s->xdelta;
+ptr[1] = ptr[0] + s->xsize;
+ptr[2] = ptr[1] + s->xsize;
+in = ptr[2] + s->xsize;
 
-for (j = 0; j < s->xdelta; ++j) {
+for (j = 0; j < s->xsize; ++j) {
 uint32_t diff = (*(ptr[0]++) << 24) |
 (*(ptr[1]++) << 16) |
 (*(ptr[2]++) << 8);
@@ -844,9 +844,9 @@ static int pxr24_uncompress(EXRContext *s, const uint8_t *src,
 break;
 case EXR_HALF:
 ptr[0] = in;
-ptr[1] = ptr[0] + s->xdelta;
-in = ptr[1] + s->xdelta;
-for (j = 0; j < s->xdelta; j++) {
+ptr[1] = ptr[0] + s->xsize;
+in = ptr[1] + s->xsize;
+for (j = 0; j < s->xsize; j++) {
 uint32_t diff = (*(ptr[0]++) << 8) | *(ptr[1]++);
 
 pixel += diff;
@@ -922,8 +922,8 @@ static int b44_uncompress(EXRContext *s, const uint8_t *src, int compressed_size
 int c, iY, iX, y, x;
 
 /* calc B44 block count */
-nbB44BlockW = s->xdelta / 4;
-if ((s->xdelta % 4) != 0)
+nbB44BlockW = s->xsize / 4;
+if ((s->xsize % 4) != 0)
 nbB44BlockW++;
 
 nbB44BlockH = s->ysize / 4;
@@ -957,8 +957,8 @@ static int b44_uncompress(EXRContext *s, const uint8_t *src, int compressed_size
 indexHgY = iY * 4;
 
 for (y = indexHgY; y < FFMIN(indexHgY + 4, s->ysize); y++) {
-for (x = indexHgX; x < FFMIN(indexHgX + 4, s->xdelta); x++) {
-indexOut = (c * s->xdelta + y * s->xdelta * s->nb_channels + x) * 2;
+for (x = indexHgX; x < FFMIN(indexHgX + 4, s->xsize); x++) {
+indexOut = (c * s->xsize + y * s->xsize * s->nb_channels + x) * 2;
 indexTmp = (y-indexHgY) * 4 + (x-indexHgX);
 td->uncompressed_data[indexOut] = tmpBuffer[indexTmp] & 0xff;
 td->uncompressed_data[indexOut + 1] = tmpBuffer[indexTmp] >> 8;
@@ -1532,11 +1532,6 @@ static int decode_header(EXRContext *s)
 av_log(s->avctx, AV_LOG_ERROR, "Invalid tile attribute.\n");
 return AVERROR_INVALIDDATA;
 }
-
-if (s->compression != EXR_RAW) {
-avpriv_report_missing_feature(s->avctx, "Compression in tile %d", s->compression);
-return AVERROR_PATCHWELCOME;
-}
 }
 

Re: [FFmpeg-devel] [PATCH 1/2] fate: Add fate-ts-opus-demux

[Kieran Kunhya]

On Mon, 4 Apr 2016 at 18:41 Michael Niedermayer 
wrote:

> On Mon, Apr 04, 2016 at 03:26:30PM +, Kieran Kunhya wrote:
> > On Mon, 4 Apr 2016 at 01:43 Michael Niedermayer 
> > wrote:
> >
> > > On Sun, Apr 03, 2016 at 04:02:55AM +0200, Michael Niedermayer wrote:
> > > > On Sun, Apr 03, 2016 at 12:20:59AM +0200, Michael Niedermayer wrote:
> > > > > On Sat, Apr 02, 2016 at 11:14:29PM +0200, wm4 wrote:
> > > > > > On Sat, 2 Apr 2016 18:01:47 -0300
> > > > > > James Almer  wrote:
> > > > > >
> > > > > > > On 4/2/2016 5:53 PM, wm4 wrote:
> > > > > > > > On Sat,  2 Apr 2016 22:05:35 +0200
> > > > > > > > Michael Niedermayer  wrote:
> > > > > > > >
> > > > > > > >> Signed-off-by: Michael Niedermayer 
> > > > > > > >> ---
> > > > > > > >>  tests/fate/demux.mak |3 +
> > > > > > > >>  tests/ref/fate/ts-opus-demux |  514
> > > ++
> > > > > > > >>  2 files changed, 517 insertions(+)
> > > > > > > >>  create mode 100644 tests/ref/fate/ts-opus-demux
> > > > > > > >>
> > > > > > > >
> > > > > > > > Maybe you should wait with all these new tests until the
> codecpar
> > > > > > > > changes have been merged.
> > > > > > >
> > > > > > > Why? None of these new tests should generate conflicts when the
> > > > > > > codecpar branch is rebased to current git head. And they may
> even
> > > > > > > reveal new regressions once they are run afterwards.
> > > > > >
> > > > > > I'm sure they will reveal regressions, because michaelni seems
> to be
> > > > > > specifically hunting for them. When the branch gets merged, there
> > > > > > should be no failing fate tests, so adding such tests would hold
> back
> > > > > > the merge.
> > > > > >
> > > > > > While it's normally a good thing to catch such regressions (and
> to
> > > fix
> > > > > > them before a big thing is merged), the codecpar merge has been
> going
> > > > > > on for weeks. It's holding back merging of other important
> features
> > > > > > (like vaapi encoding to name a particularly popular one), and
> > > there's a
> > > > > > limit to which extend we can load further work on daemon and nev.
> > > > > >
> > > > > > So I suggest that such arguably less important tests/regressions
> are
> > > > > > applied and fixed later, so that merging can go on and none of
> the
> > > devs
> > > > > > have to die from stress.
> > > > >
> > > > > We can add the tests now and then just disable them in the merge
> > > > > if the people working on the merge belive that that is the best
> choice.
> > > > > It should make it easier to keep track of issues
> > > >
> > > > note, i intend to push these soon
> > > > if someone objects, please state so
> > >
> > > tested with and without codecpar, pass in both cases now
> > > (so this should not add any stress to anyone)
> > >
> > > applied
> > >
> > > Where does this 7.1 sample come from?
> > Kieran
>
> it should be a part cut out of
> http://chui-pas.net/~fun/test-8-7.1.opus.ts
>
>
>
Has this file been compared with the Opus in TS spec:
https://wiki.xiph.org/OpusTS

Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v3] libxvid: Create extradata in init using a dummy frame

[Derek Buitenhuis]

Modifying global header extradata in encode_frame is an API violation
and only happens to work currently because mov writes its header
at the end of the file.

Heavily based off of a patch from 2012.

Original-by: Nicolas George 
Signed-off-by: Derek Buitenhuis 
---
 libavcodec/libxvid.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/libavcodec/libxvid.c b/libavcodec/libxvid.c
index 76e725e..b362921 100644
--- a/libavcodec/libxvid.c
+++ b/libavcodec/libxvid.c
@@ -96,6 +96,9 @@ struct xvid_ff_pass1 {
 };
 
 static int xvid_encode_close(AVCodecContext *avctx);
+static int xvid_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
+ const AVFrame *picture, int *got_packet);
+
 
 /*
  * Xvid 2-Pass Kludge Section
@@ -707,6 +710,43 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 av_assert0(xvid_enc_create.num_plugins + (!!x->ssim) + (!!x->variance_aq) 
+ (!!x->lumi_aq) <= FF_ARRAY_ELEMS(plugins));
 
+/* Encode a dummy frame to get the extradata immediately */
+if (x->quicktime_format) {
+AVFrame *picture;
+AVPacket packet;
+int size, got_packet, ret;
+
+av_init_packet();
+
+picture = av_frame_alloc();
+if (!picture)
+return AVERROR(ENOMEM);
+
+xerr = xvid_encore(NULL, XVID_ENC_CREATE, _enc_create, NULL);
+if( xerr ) {
+av_frame_free();
+av_log(avctx, AV_LOG_ERROR, "Xvid: Could not create encoder 
reference\n");
+return AVERROR_EXTERNAL;
+}
+x->encoder_handle = xvid_enc_create.handle;
+size = ((avctx->width + 1) & ~1) * ((avctx->height + 1) & ~1);
+picture->data[0] = av_malloc(size + size / 2);
+if (!picture->data[0]) {
+av_frame_free();
+return AVERROR(ENOMEM);
+}
+picture->data[1] = picture->data[0] + size;
+picture->data[2] = picture->data[1] + size / 4;
+memset(picture->data[0], 0, size);
+memset(picture->data[1], 128, size / 2);
+ret = xvid_encode_frame(avctx, , picture, _packet);
+if (!ret && got_packet)
+av_packet_unref();
+av_free(picture->data[0]);
+av_frame_free();
+xvid_encore(x->encoder_handle, XVID_ENC_DESTROY, NULL, NULL);
+}
+
 /* Create encoder context */
 xerr = xvid_encore(NULL, XVID_ENC_CREATE, _enc_create, NULL);
 if (xerr) {
-- 
2.8.0.rc3

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

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 1:51 PM, Timothy Gu  wrote:

> On Sun, Apr 03, 2016 at 05:34:15PM -0400, Aaron Boxer wrote:
>
> > From d12c685578f21b403f6c03505edd84db367306c5 Mon Sep 17 00:00:00 2001
> > From: Aaron Boxer 
> > Date: Sun, 27 Mar 2016 00:15:20 -0400
>
> > Subject: [PATCH] Support the following jpeg 2000 codecs:
> >
> > a) latest release of openjpeg (2.1)
> > b) master branch of openjpeg
> > c) grok (https://github.com/GrokImageCompression/grok)
>
> The commit message should be changed to:
>
> build: Support additional OpenJPEG-compatible libraries
>
> Support OpenJPEG 2.1, master, as well as Grok.
>

No problem.


>
> >
> > The following changes were made:
> >
> > 1. Removed bpp (redundant as this information is already stored in
> precision)
>
> Does compilation still work without this change?
>

Yes.



>
> > 2. Removed OPJ_STATIC flag in configure: in master branch of openjpeg
> and in
> > grok, this flag indicates a static build, so codec API functions are
> marked
> > as hidden. This prevents FFmpeg from using a dynamic build of these
> codecs.
>
> This will break Windows DLL MinGW support. See
>
> https://github.com/uclouvain/openjpeg/blob/master/src/lib/openjp2/openjpeg.h#L79-L108
> .
> When Windows is used and OPJ_STATIC is not defined, __declspec(dllimport)
> is used, which asks GCC to mangle
> the symbol name when compiling. However, under MinGW environment, such
> mangling doesn't work, since the DLL is all that is needed for linking
> under
> MinGW.
>

Let me look into this.


>
> Does the compilation of OpenJPEG break _now_ without the patch? If so,
> submit
> a bug report, if not, then this change merits further discussion.
>


Compilation against OpenJPEG master is broken, but everything works with
the latest release
of OpenJPEG (2.1)



>
> > 3. link to libdl. This is needed by grok, as it supports a plugin
> > architecture that allows plugins to be dynamically loaded at runtime.
>
> Is there a way to detect Grok? Linking to a library that is unnecessary
> for a
> specific case doesn't sound appealing to me.
>

Currently no way of detecting Grok vs OpenJPEG


>
> Also it should be made clear that if Grok is linked into FFmpeg, the
> resulting
> binary is a mixture of AGPL and GPL works. If --enable-gpl or
> --enable-version3 is not enabled, the compilation should fail.
>

No problem.


>
> If there isn't a way to detect Grok from OpenJPEG, there should be one.
>
> If it is not clear to you why we are so against AGPL, it is because it
> incurs
> additional restrictions on the work that we don't consider to be in the
> spirit
> of free software, regardless of what FSF says. But I think you already know
> about that.
>

Why do you consider it to not be in the spirit of free software?
So far, nobody has given me a convincing argument against the use of  the
AGPL.

Cheers,
Aaron



"I disapprove of what you say, but I will defend to the death your right to
say it"
Voltaire





>
> Timothy
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 3:16 PM, Reimar Döffinger 
wrote:

> On Mon, Apr 04, 2016 at 10:51:23AM -0700, Timothy Gu wrote:
> > On Sun, Apr 03, 2016 at 05:34:15PM -0400, Aaron Boxer wrote:
> > Also it should be made clear that if Grok is linked into FFmpeg, the
> resulting
> > binary is a mixture of AGPL and GPL works. If --enable-gpl or
> > --enable-version3 is not enabled, the compilation should fail.
> >
> > If there isn't a way to detect Grok from OpenJPEG, there should be one.
> >
> > If it is not clear to you why we are so against AGPL, it is because it
> incurs
> > additional restrictions on the work that we don't consider to be in the
> spirit
> > of free software, regardless of what FSF says. But I think you already
> know
> > about that.
>
> The really huge, gigantic, elephant sized issue with AGPL for me is
> that it is _completely_ unclear to me what you actually have to
> do to fulfill the license requirements of that "frankenmonster".
>

Read the license, then.


> No restrictions on use makes GPL very simple: if you don't
> redistribute, you don't need to do anything.
> What if you somehow got an OS image that happens to use
> a FFmpeg compiled against AGPL components (without you being
> aware, since you never use or care about the AGPL parts)
> and then use FFmpeg to stream over the net (or even your proprietary
> code), are you suddenly in violation of the license?
>

What if you get a version of FFmeg compiled against GPLv3, without being
aware that this is the case,
and then combine it with a proprietary application ?  Same situation.


If the answer is "yes", I am against such a version of FFmpeg
> working without each _use_ of it requiring a special action
> that confirms users are aware of the license obligations.
>

The same logic applies to GPLv3 distributions of FFmpeg.

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

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Reimar Döffinger]

On Mon, Apr 04, 2016 at 10:51:23AM -0700, Timothy Gu wrote:
> On Sun, Apr 03, 2016 at 05:34:15PM -0400, Aaron Boxer wrote:
> Also it should be made clear that if Grok is linked into FFmpeg, the resulting
> binary is a mixture of AGPL and GPL works. If --enable-gpl or
> --enable-version3 is not enabled, the compilation should fail.
> 
> If there isn't a way to detect Grok from OpenJPEG, there should be one.
> 
> If it is not clear to you why we are so against AGPL, it is because it incurs
> additional restrictions on the work that we don't consider to be in the spirit
> of free software, regardless of what FSF says. But I think you already know
> about that.

The really huge, gigantic, elephant sized issue with AGPL for me is
that it is _completely_ unclear to me what you actually have to
do to fulfill the license requirements of that "frankenmonster".
No restrictions on use makes GPL very simple: if you don't
redistribute, you don't need to do anything.
What if you somehow got an OS image that happens to use
a FFmpeg compiled against AGPL components (without you being
aware, since you never use or care about the AGPL parts)
and then use FFmpeg to stream over the net (or even your proprietary
code), are you suddenly in violation of the license?
If the answer is "yes", I am against such a version of FFmpeg
working without each _use_ of it requiring a special action
that confirms users are aware of the license obligations.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [Patch][GSoC] Motion Estimation filter

[Michael Niedermayer]

On Sun, Apr 03, 2016 at 08:45:46PM +, Davinder Singh wrote:
> sorry about that,
> here is recreated patch.
> 
> 
> DSM_
> 
> On Sun, Apr 3, 2016 at 11:09 PM Davinder Singh  wrote:
> 
> > Qualification task for Motion interpolation project.
> >
> > here is basic motion estimation filter which uses block matching
> > technique, does full search in (default) 7 px region by 1px step.
> >
> > Thanks,
> > DSM_
> >

>  Makefile   |1 
>  allfilters.c   |1 
>  vf_mestimate.c |  236 
> +
>  3 files changed, 238 insertions(+)
> 911ca4024e19e3629b34340761542655dcf55d68  0001-motion-estimation-filter.patch
> From 68560d7d4764587ad72f1901edc45450391f1378 Mon Sep 17 00:00:00 2001
> From: dsmudhar 
> Date: Mon, 4 Apr 2016 01:06:07 +0530
> Subject: [PATCH] motion estimation filter

missing documentation

ive tested it as in
./ffplay matrixbench_mpeg2.mpg -vf mestimate=16,codecview=mv=7
or
./ffplay ~/videos/matrixbench_mpeg2.mpg -vf mestimate=16:32,codecview=mv=7

the vectors do not seem to represent motion, they all point in the
same direction more or less

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH] Added more tests to libswscale/utils.c

[Petru Rares Sincraian]

Hi,

Now the function computes the sum of the values and displays the result.


Thanks,
Petru Rares.


From: ffmpeg-devel  on behalf of Michael 
Niedermayer 
Sent: Wednesday, March 30, 2016 4:18 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] Added more tests to libswscale/utils.c

On Wed, Mar 30, 2016 at 10:12:29AM +, Petru Rares Sincraian wrote:
> Hi,
>
> I solved the problems with swscale_license() and alloc_gamma_tbl() functions. 
> I am working to solve alphaless_fmt() function in a different way.
>
> 
> From: ffmpeg-devel  on behalf of Michael 
> Niedermayer 
> Sent: Sunday, March 27, 2016 9:43 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] Added more tests to libswscale/utils.c
>
> On Sun, Mar 27, 2016 at 04:39:39PM +, Petru Rares Sincraian wrote:
> >
> >   - Added test for: swscale_license()
> >   - Added test for: alphaless_fmt()
> >   - Added test for: alloc_gamma_tbl()
> [...]
>
> > +static void test_alloc_gamma_tbl(void)
> > +{
> > +uint16_t *tbl = alloc_gamma_tbl(1.);
> > +int i;
> > +
> > +// print only 32 elements
> > +printf("e = 1.0\n");
> > +for (i = 0; i < 65536; i += 2048)
> > +printf("it: %d\t value: %d\n", i, tbl[i]);
> > +
> > +tbl = alloc_gamma_tbl(0.75);
> > +printf("\ne = 0.75\n");
> > +for (i = 0; i < 65536; i += 2048)
> > +printf("it: %d\t value: %d\n", i, tbl[i]);
> > +
> > +tbl = alloc_gamma_tbl(2.8);
> > +printf("\ne = 2.8\n");
> > +for (i = 0; i < 65536; i += 2048)
> > +printf("it: %d\t value: %d\n", i, tbl[i]);
>
> this leaks memory
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope

>  libswscale/Makefile   |1
>  libswscale/utils.c|   49 +
>  tests/Makefile|1
>  tests/fate/libswscale.mak |6 ++
>  tests/ref/fate/utils  |  105 
> ++
>  5 files changed, 162 insertions(+)
> f3e7cf692c31bf2df982eeeb97fc6fef8e3ec736  
> 0001-Added-more-tests-to-libswscale-utils.c.patch
> From ebefe53b13c878d50f5a388022c894d2b2c5ee96 Mon Sep 17 00:00:00 2001
> From: Petru Rares Sincraian 
> Date: Thu, 24 Mar 2016 18:46:02 +0100
> Subject: [PATCH] Added more tests to libswscale/utils.c
>
>   - Added test for: swscale_license()
>   - Added test for: alloc_gamma_tbl()
> ---
>  libswscale/Makefile   |   1 +
>  libswscale/utils.c|  49 ++
>  tests/Makefile|   1 +
>  tests/fate/libswscale.mak |   6 +++
>  tests/ref/fate/utils  | 105 
> ++
>  5 files changed, 162 insertions(+)
>  create mode 100644 tests/fate/libswscale.mak
>  create mode 100644 tests/ref/fate/utils
>
> diff --git a/libswscale/Makefile b/libswscale/Makefile
> index a9f9e03..a6ae81d 100644
> --- a/libswscale/Makefile
> +++ b/libswscale/Makefile
> @@ -27,3 +27,4 @@ SLIBOBJS-$(HAVE_GNU_WINDRES) += swscaleres.o
>
>  TESTPROGS = colorspace  \
>  swscale \
> +utils   \
> diff --git a/libswscale/utils.c b/libswscale/utils.c
> index ba409d6..b572a11 100644
> --- a/libswscale/utils.c
> +++ b/libswscale/utils.c
> @@ -2410,3 +2410,52 @@ struct SwsContext *sws_getCachedContext(struct 
> SwsContext *context, int srcW,
>  }
>  return context;
>  }
> +
> +#ifdef TEST
> +

> +static void test_swscale_license(void)
> +{
> +const char *license = swscale_license();
> +if (!strcmp(FFMPEG_LICENSE, license))
> +printf("License OK\n");
> +else
> +printf("License don't match.\nExpect: %s\nGiven: %s\n",
> +FFMPEG_LICENSE, license);
> +}


> +
> +static void test_alloc_gamma_tbl(void)
> +{
> +uint16_t *tbl;
> +int i;
> +
> +// print only 32 elements
> +tbl = alloc_gamma_tbl(1.);
> +printf("e = 1.0\n");
> +for (i = 0; i < 65536; i += 2048)
> +printf("it: %d\t value: %d\n", i, tbl[i]);
> +av_free(tbl);
> +
> +tbl = alloc_gamma_tbl(0.75);
> +printf("\ne = 0.75\n");
> +for (i = 0; i < 65536; i += 2048)
> +printf("it: %d\t value: %d\n", i, tbl[i]);
> +av_free(tbl);
> +
> +tbl = alloc_gamma_tbl(2.8);
> +printf("\ne = 2.8\n");
> +for (i = 0; i < 65536; i += 2048)
> +printf("it: %d\t value: %d\n", i, tbl[i]);
> +av_free(tbl);
> +
> +}

missing malloc failure checks
also a better way to test matematical tables is to check how close
they are to the ideal double 

Re: [FFmpeg-devel] Libavcodec/exr : add support for tile

[Paul B Mahol]

On 4/4/16, Martin Vignali  wrote:
> 2016-04-03 17:38 GMT+02:00 Paul B Mahol :
>
>> On 4/3/16, Martin Vignali  wrote:
>> > 2016-04-03 17:12 GMT+02:00 Paul B Mahol :
>> >
>> >> On 4/3/16, Martin Vignali  wrote:
>> >> > Hello,
>> >> >
>> >> > In attach a patch in order to add support for exr Tile (One Level)
>> >> >
>> >> > Some samples can be found here : https://we.tl/IC4XTrEJf4
>> >> > Theses samples can also be add to ./fate-suite/exr/
>> >> > (i will make a fate test soon).
>> >> >
>> >> > Details of the sample files :
>> >> > rgb_tile_half_raw_12x8.exr : uncompress half float file, in tile
>> >> > (only
>> >> one
>> >> > tile in the file)
>> >> > rgb_tile_float_raw_12x8.exr : uncompress float file, in tile (only
>> >> > one
>> >> tile
>> >> > in the file)
>> >> > rgb_tile_float_raw_150x130.exr : uncompress float file, in tile
>> >> > (multiple
>> >> > tile in the file)
>> >> >
>> >> > In this patch, compression in tile is not enabled. (i will make new
>> >> patchs
>> >> > for that after making more tests)
>> >> >
>> >> > I tried to keep the most code common with the scanline mode (reason
>> why,
>> >> > scanline code part have had some modifications).
>> >> > Tile data are reorganized, to be more like scanline uncompress data.
>> >> >
>> >> > Pass fate-exr tests.
>> >> >
>> >> > More information about tile in exr can be found here :
>> >> > http://www.openexr.com/TechnicalIntroduction.pdf
>> >> >
>> >> > Comments welcome.
>> >> >
>> >> > Martin
>> >> > Jokyo Images
>> >> >
>> >>
>> >> Pushed. Note that tile with PIZ compression crashes
>>
>
> In tile :
> RLE, ZIP1, ZIP16, PXR24 will work fine without modification, because they
> don't use s->xdelta (the datawindow width)
>
> PIZ, B44, B44A, use s->xdelta, so now, they will have some trouble for
> datawindow bigger than tile size in X.
>
> I will make a patch soon, for this.
>
> Can you send me your PIZ sample who make ffmpeg crash to check  (with
> wetransfer or something similar) ?

Its standard sample available in openexr-images-1.7.0/Tiles/GoldenGate.exr

available from OpenEXR site.

>
> Thanks by advance
>
> Martin
> Jokyo Images
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] added support for hardware assist H264 video encoding for the Raspberry Pi

[Amancio Hasty]

> On Apr 4, 2016, at 10:41 AM, wm4  wrote:
> 
> On Mon, 4 Apr 2016 10:08:56 -0700
> Amancio Hasty > wrote:
> 
>>> On Mar 31, 2016, at 7:27 PM, Amancio Hasty  wrote:
>>> 
>>> I am not a lawyer…
>>> 
>>> 
>>> I updated the patch.  vc264.c now has a the copyright notice embedded in 
>>> a volatile global so if a binary is compiled against vc264.o , the 
>>> copyright notice
>>> can be displayed by:
>>> strings ffmpeg | grep -i copyright
>>> 
>>> LICENSE.md has been updated to include Broadcom’s copyright notice.
>>> 
>>> A distribution of a  binary that includes vc264.o should include LICENSE.md 
>>> and if 
>>> that is missing,  the copyright notice can be displayed via the shell
>>> command ‘strings’ .
>>> 
>>> Amancio
>>>   
 On Mar 22, 2016, at 12:12 PM, Lou Logan  wrote:
 
 On Mon, 21 Mar 2016 20:07:01 -0700, Amancio Hasty wrote:
 
> From 874a72eec2a78f4935fea091003e534b5f8d5413 Mon Sep 17 00:00:00 2001
> From: Amancio Hasty 
> Date: Mon, 21 Mar 2016 18:56:05 -0700
> Subject: [PATCH] added support for hardware assist H264  video encoding 
> for
> the Raspberry Pi
> 
> ---
> configure  |  12 ++
> libavcodec/Makefile|   1 +
> libavcodec/allcodecs.c |   2 +
> libavcodec/vc264.c | 387 
> +
> 4 files changed, 402 insertions(+)
> create mode 100644 libavcodec/vc264.c
> 
 [...]  
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 2a25d66..3c7bd9b 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -74,6 +74,7 @@ void avcodec_register_all(void)
>   initialized = 1;
> 
 
 Nit: Whitespace on the line above should be removed.
 
 [...]  
> --- /dev/null
> +++ b/libavcodec/vc264.c
> @@ -0,0 +1,387 @@
> +/*  H.264 hardware assist video encoding code taken from
> + * raspberry's os :
> + *   /opt/vc/src/hello_pi/hello_encode/encode.c
> + */
> +
> +/*
> +Copyright (c) 2012, Broadcom Europe Ltd
> +Copyright (c) 2012, Kalle Vahlman 
> +Tuomas Kulve 
> +All rights reserved.
> +
> +Redistribution and use in source and binary forms, with or without
> +modification, are permitted provided that the following conditions are 
> met:
> +* Redistributions of source code must retain the above copyright
> +  notice, this list of conditions and the following disclaimer.
> +  * Redistributions in binary form must reproduce the above copyright
> +  notice, this list of conditions and the following disclaimer in the
> +  documentation and/or other materials provided with the 
> distribution.
> +  * Neither the name of the copyright holder nor the
> +  names of its contributors may be used to endorse or promote 
> products
> +  derived from this software without specific prior written 
> permission.
> +
> +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS" AND
> +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
> IMPLIED
> +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> +DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE 
> LIABLE FOR ANY
> +DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
> DAMAGES
> +(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
> SERVICES;
> +LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED 
> AND
> +ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR 
> TORT
> +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
> THIS
> +SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.  
 
 I wonder if any of the above legalese is compatible. Granted, I see a
 similar paragraph in "libavformat/aadec.c".
 
> + * ffmpeg driver for hardware assist video H.264 encoding using 
> Broadcom's GPU
> + * Copyright (C) 2016 Amancio Hasty aha...@gmail.com
> + *
> + *
> + * 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 

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Timothy Gu]

On Sun, Apr 03, 2016 at 05:34:15PM -0400, Aaron Boxer wrote:

> From d12c685578f21b403f6c03505edd84db367306c5 Mon Sep 17 00:00:00 2001
> From: Aaron Boxer 
> Date: Sun, 27 Mar 2016 00:15:20 -0400

> Subject: [PATCH] Support the following jpeg 2000 codecs:
> 
> a) latest release of openjpeg (2.1)
> b) master branch of openjpeg
> c) grok (https://github.com/GrokImageCompression/grok)

The commit message should be changed to:

build: Support additional OpenJPEG-compatible libraries

Support OpenJPEG 2.1, master, as well as Grok.

> 
> The following changes were made:
> 
> 1. Removed bpp (redundant as this information is already stored in precision)

Does compilation still work without this change?

> 2. Removed OPJ_STATIC flag in configure: in master branch of openjpeg and in
> grok, this flag indicates a static build, so codec API functions are marked
> as hidden. This prevents FFmpeg from using a dynamic build of these codecs.

This will break Windows DLL MinGW support. See
https://github.com/uclouvain/openjpeg/blob/master/src/lib/openjp2/openjpeg.h#L79-L108.
When Windows is used and OPJ_STATIC is not defined, __declspec(dllimport) is 
used, which asks GCC to mangle
the symbol name when compiling. However, under MinGW environment, such
mangling doesn't work, since the DLL is all that is needed for linking under
MinGW.

Does the compilation of OpenJPEG break _now_ without the patch? If so, submit
a bug report, if not, then this change merits further discussion.

> 3. link to libdl. This is needed by grok, as it supports a plugin
> architecture that allows plugins to be dynamically loaded at runtime.

Is there a way to detect Grok? Linking to a library that is unnecessary for a
specific case doesn't sound appealing to me.

Also it should be made clear that if Grok is linked into FFmpeg, the resulting
binary is a mixture of AGPL and GPL works. If --enable-gpl or
--enable-version3 is not enabled, the compilation should fail.

If there isn't a way to detect Grok from OpenJPEG, there should be one.

If it is not clear to you why we are so against AGPL, it is because it incurs
additional restrictions on the work that we don't consider to be in the spirit
of free software, regardless of what FSF says. But I think you already know
about that.

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

Re: [FFmpeg-devel] [PATCH 1/2] fate: Add fate-ts-opus-demux

[Michael Niedermayer]

On Mon, Apr 04, 2016 at 03:26:30PM +, Kieran Kunhya wrote:
> On Mon, 4 Apr 2016 at 01:43 Michael Niedermayer 
> wrote:
> 
> > On Sun, Apr 03, 2016 at 04:02:55AM +0200, Michael Niedermayer wrote:
> > > On Sun, Apr 03, 2016 at 12:20:59AM +0200, Michael Niedermayer wrote:
> > > > On Sat, Apr 02, 2016 at 11:14:29PM +0200, wm4 wrote:
> > > > > On Sat, 2 Apr 2016 18:01:47 -0300
> > > > > James Almer  wrote:
> > > > >
> > > > > > On 4/2/2016 5:53 PM, wm4 wrote:
> > > > > > > On Sat,  2 Apr 2016 22:05:35 +0200
> > > > > > > Michael Niedermayer  wrote:
> > > > > > >
> > > > > > >> Signed-off-by: Michael Niedermayer 
> > > > > > >> ---
> > > > > > >>  tests/fate/demux.mak |3 +
> > > > > > >>  tests/ref/fate/ts-opus-demux |  514
> > ++
> > > > > > >>  2 files changed, 517 insertions(+)
> > > > > > >>  create mode 100644 tests/ref/fate/ts-opus-demux
> > > > > > >>
> > > > > > >
> > > > > > > Maybe you should wait with all these new tests until the codecpar
> > > > > > > changes have been merged.
> > > > > >
> > > > > > Why? None of these new tests should generate conflicts when the
> > > > > > codecpar branch is rebased to current git head. And they may even
> > > > > > reveal new regressions once they are run afterwards.
> > > > >
> > > > > I'm sure they will reveal regressions, because michaelni seems to be
> > > > > specifically hunting for them. When the branch gets merged, there
> > > > > should be no failing fate tests, so adding such tests would hold back
> > > > > the merge.
> > > > >
> > > > > While it's normally a good thing to catch such regressions (and to
> > fix
> > > > > them before a big thing is merged), the codecpar merge has been going
> > > > > on for weeks. It's holding back merging of other important features
> > > > > (like vaapi encoding to name a particularly popular one), and
> > there's a
> > > > > limit to which extend we can load further work on daemon and nev.
> > > > >
> > > > > So I suggest that such arguably less important tests/regressions are
> > > > > applied and fixed later, so that merging can go on and none of the
> > devs
> > > > > have to die from stress.
> > > >
> > > > We can add the tests now and then just disable them in the merge
> > > > if the people working on the merge belive that that is the best choice.
> > > > It should make it easier to keep track of issues
> > >
> > > note, i intend to push these soon
> > > if someone objects, please state so
> >
> > tested with and without codecpar, pass in both cases now
> > (so this should not add any stress to anyone)
> >
> > applied
> >
> > Where does this 7.1 sample come from?
> Kieran

it should be a part cut out of
http://chui-pas.net/~fun/test-8-7.1.opus.ts

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


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

Re: [FFmpeg-devel] [PATCH] added support for hardware assist H264 video encoding for the Raspberry Pi

[wm4]

On Mon, 4 Apr 2016 10:08:56 -0700
Amancio Hasty  wrote:

> > On Mar 31, 2016, at 7:27 PM, Amancio Hasty  wrote:
> > 
> > I am not a lawyer…
> > 
> > 
> > I updated the patch.  vc264.c now has a the copyright notice embedded in 
> > a volatile global so if a binary is compiled against vc264.o , the 
> > copyright notice
> > can be displayed by:
> > strings ffmpeg | grep -i copyright
> > 
> > LICENSE.md has been updated to include Broadcom’s copyright notice.
> > 
> > A distribution of a  binary that includes vc264.o should include LICENSE.md 
> > and if 
> > that is missing,  the copyright notice can be displayed via the shell
> > command ‘strings’ .
> > 
> > Amancio
> >   
> >> On Mar 22, 2016, at 12:12 PM, Lou Logan  wrote:
> >> 
> >> On Mon, 21 Mar 2016 20:07:01 -0700, Amancio Hasty wrote:
> >>   
> >>> From 874a72eec2a78f4935fea091003e534b5f8d5413 Mon Sep 17 00:00:00 2001
> >>> From: Amancio Hasty 
> >>> Date: Mon, 21 Mar 2016 18:56:05 -0700
> >>> Subject: [PATCH] added support for hardware assist H264  video encoding 
> >>> for
> >>> the Raspberry Pi
> >>> 
> >>> ---
> >>> configure  |  12 ++
> >>> libavcodec/Makefile|   1 +
> >>> libavcodec/allcodecs.c |   2 +
> >>> libavcodec/vc264.c | 387 
> >>> +
> >>> 4 files changed, 402 insertions(+)
> >>> create mode 100644 libavcodec/vc264.c
> >>>   
> >> [...]  
> >>> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> >>> index 2a25d66..3c7bd9b 100644
> >>> --- a/libavcodec/allcodecs.c
> >>> +++ b/libavcodec/allcodecs.c
> >>> @@ -74,6 +74,7 @@ void avcodec_register_all(void)
> >>>initialized = 1;
> >>>   
> >> 
> >> Nit: Whitespace on the line above should be removed.
> >> 
> >> [...]  
> >>> --- /dev/null
> >>> +++ b/libavcodec/vc264.c
> >>> @@ -0,0 +1,387 @@
> >>> +/*  H.264 hardware assist video encoding code taken from
> >>> + * raspberry's os :
> >>> + *   /opt/vc/src/hello_pi/hello_encode/encode.c
> >>> + */
> >>> +
> >>> +/*
> >>> +Copyright (c) 2012, Broadcom Europe Ltd
> >>> +Copyright (c) 2012, Kalle Vahlman 
> >>> +Tuomas Kulve 
> >>> +All rights reserved.
> >>> +
> >>> +Redistribution and use in source and binary forms, with or without
> >>> +modification, are permitted provided that the following conditions are 
> >>> met:
> >>> +* Redistributions of source code must retain the above copyright
> >>> +  notice, this list of conditions and the following disclaimer.
> >>> +  * Redistributions in binary form must reproduce the above copyright
> >>> +  notice, this list of conditions and the following disclaimer in the
> >>> +  documentation and/or other materials provided with the 
> >>> distribution.
> >>> +  * Neither the name of the copyright holder nor the
> >>> +  names of its contributors may be used to endorse or promote 
> >>> products
> >>> +  derived from this software without specific prior written 
> >>> permission.
> >>> +
> >>> +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> >>> IS" AND
> >>> +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
> >>> IMPLIED
> >>> +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> >>> +DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE 
> >>> LIABLE FOR ANY
> >>> +DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
> >>> DAMAGES
> >>> +(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
> >>> SERVICES;
> >>> +LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED 
> >>> AND
> >>> +ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR 
> >>> TORT
> >>> +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
> >>> THIS
> >>> +SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.  
> >> 
> >> I wonder if any of the above legalese is compatible. Granted, I see a
> >> similar paragraph in "libavformat/aadec.c".
> >>   
> >>> + * ffmpeg driver for hardware assist video H.264 encoding using 
> >>> Broadcom's GPU
> >>> + * Copyright (C) 2016 Amancio Hasty aha...@gmail.com
> >>> + *
> >>> + *
> >>> + * 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 

Re: [FFmpeg-devel] [PATCH] added support for hardware assist H264 video encoding for the Raspberry Pi

[Amancio Hasty]

> On Mar 31, 2016, at 7:27 PM, Amancio Hasty  wrote:
> 
> I am not a lawyer…
> 
> 
> I updated the patch.  vc264.c now has a the copyright notice embedded in 
> a volatile global so if a binary is compiled against vc264.o , the copyright 
> notice
> can be displayed by:
> strings ffmpeg | grep -i copyright
> 
> LICENSE.md has been updated to include Broadcom’s copyright notice.
> 
> A distribution of a  binary that includes vc264.o should include LICENSE.md 
> and if 
> that is missing,  the copyright notice can be displayed via the shell
> command ‘strings’ .
> 
> Amancio
> 
>> On Mar 22, 2016, at 12:12 PM, Lou Logan  wrote:
>> 
>> On Mon, 21 Mar 2016 20:07:01 -0700, Amancio Hasty wrote:
>> 
>>> From 874a72eec2a78f4935fea091003e534b5f8d5413 Mon Sep 17 00:00:00 2001
>>> From: Amancio Hasty 
>>> Date: Mon, 21 Mar 2016 18:56:05 -0700
>>> Subject: [PATCH] added support for hardware assist H264  video encoding for
>>> the Raspberry Pi
>>> 
>>> ---
>>> configure  |  12 ++
>>> libavcodec/Makefile|   1 +
>>> libavcodec/allcodecs.c |   2 +
>>> libavcodec/vc264.c | 387 
>>> +
>>> 4 files changed, 402 insertions(+)
>>> create mode 100644 libavcodec/vc264.c
>>> 
>> [...]
>>> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
>>> index 2a25d66..3c7bd9b 100644
>>> --- a/libavcodec/allcodecs.c
>>> +++ b/libavcodec/allcodecs.c
>>> @@ -74,6 +74,7 @@ void avcodec_register_all(void)
>>>initialized = 1;
>>> 
>> 
>> Nit: Whitespace on the line above should be removed.
>> 
>> [...]
>>> --- /dev/null
>>> +++ b/libavcodec/vc264.c
>>> @@ -0,0 +1,387 @@
>>> +/*  H.264 hardware assist video encoding code taken from
>>> + * raspberry's os :
>>> + *   /opt/vc/src/hello_pi/hello_encode/encode.c
>>> + */
>>> +
>>> +/*
>>> +Copyright (c) 2012, Broadcom Europe Ltd
>>> +Copyright (c) 2012, Kalle Vahlman 
>>> +Tuomas Kulve 
>>> +All rights reserved.
>>> +
>>> +Redistribution and use in source and binary forms, with or without
>>> +modification, are permitted provided that the following conditions are met:
>>> +* Redistributions of source code must retain the above copyright
>>> +  notice, this list of conditions and the following disclaimer.
>>> +  * Redistributions in binary form must reproduce the above copyright
>>> +  notice, this list of conditions and the following disclaimer in the
>>> +  documentation and/or other materials provided with the distribution.
>>> +  * Neither the name of the copyright holder nor the
>>> +  names of its contributors may be used to endorse or promote products
>>> +  derived from this software without specific prior written permission.
>>> +
>>> +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
>>> IS" AND
>>> +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
>>> IMPLIED
>>> +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
>>> +DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE 
>>> LIABLE FOR ANY
>>> +DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
>>> +(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
>>> SERVICES;
>>> +LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
>>> +ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>>> +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
>>> THIS
>>> +SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> 
>> I wonder if any of the above legalese is compatible. Granted, I see a
>> similar paragraph in "libavformat/aadec.c".
>> 
>>> + * ffmpeg driver for hardware assist video H.264 encoding using Broadcom's 
>>> GPU
>>> + * Copyright (C) 2016 Amancio Hasty aha...@gmail.com
>>> + *
>>> + *
>>> + * 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 vc264.c
>>> + * Broadcom bm2865's Visual Core hardware assist h264 using
>>> +   openMax interface to the GPU.
>>> +
>>> +*/
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#define 

Re: [FFmpeg-devel] Libavcodec/exr : add support for tile

[Martin Vignali]

2016-04-03 17:38 GMT+02:00 Paul B Mahol :

> On 4/3/16, Martin Vignali  wrote:
> > 2016-04-03 17:12 GMT+02:00 Paul B Mahol :
> >
> >> On 4/3/16, Martin Vignali  wrote:
> >> > Hello,
> >> >
> >> > In attach a patch in order to add support for exr Tile (One Level)
> >> >
> >> > Some samples can be found here : https://we.tl/IC4XTrEJf4
> >> > Theses samples can also be add to ./fate-suite/exr/
> >> > (i will make a fate test soon).
> >> >
> >> > Details of the sample files :
> >> > rgb_tile_half_raw_12x8.exr : uncompress half float file, in tile (only
> >> one
> >> > tile in the file)
> >> > rgb_tile_float_raw_12x8.exr : uncompress float file, in tile (only one
> >> tile
> >> > in the file)
> >> > rgb_tile_float_raw_150x130.exr : uncompress float file, in tile
> >> > (multiple
> >> > tile in the file)
> >> >
> >> > In this patch, compression in tile is not enabled. (i will make new
> >> patchs
> >> > for that after making more tests)
> >> >
> >> > I tried to keep the most code common with the scanline mode (reason
> why,
> >> > scanline code part have had some modifications).
> >> > Tile data are reorganized, to be more like scanline uncompress data.
> >> >
> >> > Pass fate-exr tests.
> >> >
> >> > More information about tile in exr can be found here :
> >> > http://www.openexr.com/TechnicalIntroduction.pdf
> >> >
> >> > Comments welcome.
> >> >
> >> > Martin
> >> > Jokyo Images
> >> >
> >>
> >> Pushed. Note that tile with PIZ compression crashes
>

In tile :
RLE, ZIP1, ZIP16, PXR24 will work fine without modification, because they
don't use s->xdelta (the datawindow width)

PIZ, B44, B44A, use s->xdelta, so now, they will have some trouble for
datawindow bigger than tile size in X.

I will make a patch soon, for this.

Can you send me your PIZ sample who make ffmpeg crash to check  (with
wetransfer or something similar) ?

Thanks by advance

Martin
Jokyo Images
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Michael Niedermayer]

Hi

On Mon, Apr 04, 2016 at 10:32:24AM -0400, Aaron Boxer wrote:
[...]

> Someone has mentioned the extra effort required to make the source
> available over the network.
> I would be happy to work on this.

its maybe not the right thread to discuss this (as people look at
it from a agpl dislike biased point of view)
but speaking just for myself here, i think making it possible (not
legally binding) to get the source out of a binary FFmpeg and even
over the network sounds like a potentially interresting feature


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle


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

Re: [FFmpeg-devel] How to handled gzip'd files?

[compn]

On Sun, 3 Apr 2016 09:02:27 -0400
"Ronald S. Bultje"  wrote:

> Hi,
> 
> On Sat, Apr 2, 2016 at 12:29 PM, Reimar Döffinger
>  wrote:
> 
> > Do we have a way to transparently decompress?
> 
> 
> Why would we? It's not like this is commonplace across all formats,
> it's only present in a handful, and we can deal with it on a
> case-by-case basis, just as we handle compressed mov. Right?

if we have gzip demuxer and probe gzip compression... then pass it onto
probe after decompressing?

its not like compressed mov because the compressed mov header is inside
of the regular mov container (iirc).

there are a lot of video files that are zipped or rared.
also zip compressed image files , example cbz/cbr.

can we get zip/rar demuxer?

some video players are able to play multipart rar video files.

i understand that its still a low priority.

https://trac.ffmpeg.org/ticket/4374

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

[FFmpeg-devel] libavcodec/exr : small cosmetic change

[Martin Vignali]

In attach a patch with a small cosmetic (introduce with tile patch).

Martin
Jokyo Images
From 7101d2ab3e9d7270545f247fd2ba9a8073c7a9c2 Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Mon, 4 Apr 2016 17:23:42 +0200
Subject: [PATCH 2/2] libavcodec/exr : cosmetic change

---
 libavcodec/exr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index b0573d5..e25fe83 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1201,8 +1201,7 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 channel_buffer[2] += channelLineSize;
 if (channel_buffer[3])
 channel_buffer[3] += channelLineSize;
-}
-else{
+} else {
 channel_buffer[0] += s->scan_line_size;
 channel_buffer[1] += s->scan_line_size;
 channel_buffer[2] += s->scan_line_size;
-- 
1.9.3 (Apple Git-50)

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

Re: [FFmpeg-devel] [PATCH 1/2] fate: Add fate-ts-opus-demux

[Kieran Kunhya]

On Mon, 4 Apr 2016 at 01:43 Michael Niedermayer 
wrote:

> On Sun, Apr 03, 2016 at 04:02:55AM +0200, Michael Niedermayer wrote:
> > On Sun, Apr 03, 2016 at 12:20:59AM +0200, Michael Niedermayer wrote:
> > > On Sat, Apr 02, 2016 at 11:14:29PM +0200, wm4 wrote:
> > > > On Sat, 2 Apr 2016 18:01:47 -0300
> > > > James Almer  wrote:
> > > >
> > > > > On 4/2/2016 5:53 PM, wm4 wrote:
> > > > > > On Sat,  2 Apr 2016 22:05:35 +0200
> > > > > > Michael Niedermayer  wrote:
> > > > > >
> > > > > >> Signed-off-by: Michael Niedermayer 
> > > > > >> ---
> > > > > >>  tests/fate/demux.mak |3 +
> > > > > >>  tests/ref/fate/ts-opus-demux |  514
> ++
> > > > > >>  2 files changed, 517 insertions(+)
> > > > > >>  create mode 100644 tests/ref/fate/ts-opus-demux
> > > > > >>
> > > > > >
> > > > > > Maybe you should wait with all these new tests until the codecpar
> > > > > > changes have been merged.
> > > > >
> > > > > Why? None of these new tests should generate conflicts when the
> > > > > codecpar branch is rebased to current git head. And they may even
> > > > > reveal new regressions once they are run afterwards.
> > > >
> > > > I'm sure they will reveal regressions, because michaelni seems to be
> > > > specifically hunting for them. When the branch gets merged, there
> > > > should be no failing fate tests, so adding such tests would hold back
> > > > the merge.
> > > >
> > > > While it's normally a good thing to catch such regressions (and to
> fix
> > > > them before a big thing is merged), the codecpar merge has been going
> > > > on for weeks. It's holding back merging of other important features
> > > > (like vaapi encoding to name a particularly popular one), and
> there's a
> > > > limit to which extend we can load further work on daemon and nev.
> > > >
> > > > So I suggest that such arguably less important tests/regressions are
> > > > applied and fixed later, so that merging can go on and none of the
> devs
> > > > have to die from stress.
> > >
> > > We can add the tests now and then just disable them in the merge
> > > if the people working on the merge belive that that is the best choice.
> > > It should make it easier to keep track of issues
> >
> > note, i intend to push these soon
> > if someone objects, please state so
>
> tested with and without codecpar, pass in both cases now
> (so this should not add any stress to anyone)
>
> applied
>
> Where does this 7.1 sample come from?
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Nicolas George]

Le sextidi 16 germinal, an CCXXIV, Aaron Boxer a écrit :
> You are right, I don't understand.  So far, nobody has provided a
> reasonable explanation for why AGPL is not acceptable, while GPL v3 is.

GPLv3 is already there, the question to accept it or not is not on the
table. Maybe if the question was raised today we would reject it too.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] fate : add test for exr PXR24 float, and tile uncompress

[Martin Vignali]

Hello,

In attach patch, in order to add fate test for recently add features in
openExr decoder :

Details of tests :
rgb_scanline_pxr24_float_12x8 : float inside PXR 24 (in scanline)
rgb_tile_float_raw_12x8.exr : Tile uncompress float. Only one tile in the
file. One level tile
rgb_tile_float_raw_150x130.exr : Tile uncompress float. Multiple tile in
the file. One level tile
rgb_tile_half_raw_12x8.exr : Tile uncompress half float. Only one tile in
the file. One level tile

Sample can be found here : https://we.tl/KLPUFGspwu
And need to be put inside ./fate-suite/exr/

You can forget the previous patch with fate test for only PXR24 (it's
integrated inside this patch).


Martin
Jokyo Images
From 365a5ee3435e6d7e8f0c00958c0a46c382bea14a Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Mon, 4 Apr 2016 16:42:00 +0200
Subject: [PATCH] fate/exr : add test for PXR24 Float and tile uncompress

---
 tests/fate/image.mak | 12 
 tests/ref/fate/exr-rgb-scanline-pxr24-float-12x8 |  2 ++
 tests/ref/fate/exr-rgb-tile-float-raw-12x8   |  2 ++
 tests/ref/fate/exr-rgb-tile-float-raw-150x130|  2 ++
 tests/ref/fate/exr-rgb-tile-half-raw-12x8|  2 ++
 5 files changed, 20 insertions(+)
 create mode 100644 tests/ref/fate/exr-rgb-scanline-pxr24-float-12x8
 create mode 100644 tests/ref/fate/exr-rgb-tile-float-raw-12x8
 create mode 100644 tests/ref/fate/exr-rgb-tile-float-raw-150x130
 create mode 100644 tests/ref/fate/exr-rgb-tile-half-raw-12x8

diff --git a/tests/fate/image.mak b/tests/fate/image.mak
index 4155d6b..9e0736b 100644
--- a/tests/fate/image.mak
+++ b/tests/fate/image.mak
@@ -65,6 +65,9 @@ fate-exr-slice-zip16: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_slice_zip16.e
 FATE_EXR += fate-exr-slice-pxr24
 fate-exr-slice-pxr24: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_slice_pxr24.exr -pix_fmt rgb48le
 
+FATE_EXR += fate-exr-rgb-scanline-pxr24-float-12x8
+fate-exr-rgb-scanline-pxr24-float-12x8: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_scanline_pxr24_float_12x8.exr -pix_fmt rgb48le
+
 FATE_EXR += fate-exr-rgba-multiscanline-half-b44
 fate-exr-rgba-multiscanline-half-b44: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_multiscanline_half_b44.exr -pix_fmt rgba64le
 
@@ -77,6 +80,15 @@ fate-exr-rgb-scanline-half-b44-12x8: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb
 FATE_EXR += fate-exr-rgb-scanline-half-b44-13x9
 fate-exr-rgb-scanline-half-b44-13x9: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_scanline_half_b44_13x9.exr -pix_fmt rgb48le
 
+FATE_EXR += fate-exr-rgb-tile-float-raw-12x8
+fate-exr-rgb-tile-float-raw-12x8: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_tile_float_raw_12x8.exr -pix_fmt rgb48le
+
+FATE_EXR += fate-exr-rgb-tile-float-raw-150x130
+fate-exr-rgb-tile-float-raw-150x130: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_tile_float_raw_150x130.exr -pix_fmt rgb48le
+
+FATE_EXR += fate-exr-rgb-tile-half-raw-12x8
+fate-exr-rgb-tile-half-raw-12x8: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_tile_half_raw_12x8.exr -pix_fmt rgb48le
+
 FATE_EXR-$(call DEMDEC, IMAGE2, EXR) += $(FATE_EXR)
 
 FATE_IMAGE += $(FATE_EXR-yes)
diff --git a/tests/ref/fate/exr-rgb-scanline-pxr24-float-12x8 b/tests/ref/fate/exr-rgb-scanline-pxr24-float-12x8
new file mode 100644
index 000..0f3a112
--- /dev/null
+++ b/tests/ref/fate/exr-rgb-scanline-pxr24-float-12x8
@@ -0,0 +1,2 @@
+#tb 0: 1/25
+0,  0,  0,1,  576, 0x7120e072
diff --git a/tests/ref/fate/exr-rgb-tile-float-raw-12x8 b/tests/ref/fate/exr-rgb-tile-float-raw-12x8
new file mode 100644
index 000..1c20982
--- /dev/null
+++ b/tests/ref/fate/exr-rgb-tile-float-raw-12x8
@@ -0,0 +1,2 @@
+#tb 0: 1/25
+0,  0,  0,1,  576, 0x6b950ce3
diff --git a/tests/ref/fate/exr-rgb-tile-float-raw-150x130 b/tests/ref/fate/exr-rgb-tile-float-raw-150x130
new file mode 100644
index 000..4efacaa
--- /dev/null
+++ b/tests/ref/fate/exr-rgb-tile-float-raw-150x130
@@ -0,0 +1,2 @@
+#tb 0: 1/25
+0,  0,  0,1,   117000, 0xabc5eab2
diff --git a/tests/ref/fate/exr-rgb-tile-half-raw-12x8 b/tests/ref/fate/exr-rgb-tile-half-raw-12x8
new file mode 100644
index 000..e03753e
--- /dev/null
+++ b/tests/ref/fate/exr-rgb-tile-half-raw-12x8
@@ -0,0 +1,2 @@
+#tb 0: 1/25
+0,  0,  0,1,  576, 0x667903f5
-- 
1.9.3 (Apple Git-50)

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

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

Hi Josh,


On Mon, Apr 4, 2016 at 9:30 AM, Josh de Kock  wrote:

> On 04/04/2016 14:21, Aaron Boxer wrote:
> > All of your arguments could be applied equally to GPL v3 components. And
> > yet,
> > FFmpeg is happy to allow distribution under GPL v3. So, I don't see what
> > the problem is here.
> The problem is AGPL can make certain builds of FFmpeg _unusable_, it's a
> pain to work with. Most of all, people just don't want AGPL in FFmpeg.
> As wm4 said: "If you really want your lib to be useful, you should
> relicense it to LGPL2.1 or later".
> >
> > Yes, Google has a no-AGPL policy, so they won't be able to use it. I am
> > sure they will
> > survive somehow without my J2k codec.
> A lot of people could survive without it. In-fact, I reckon everyone who
> is currently using FFmpeg could.
>
> On 04/04/2016 14:24, Aaron Boxer wrote:
> > Of course, it is not my place to say what should happen with the
> > project.
> > I just want to make sure everyone understands the issues involved
> > before making a decision.
> I'm almost 100% sure they do, I think it's you who rather doesn't
> understand the issues involved with putting AGPL into FFmpeg.
>


You are right, I don't understand.  So far, nobody has provided a
reasonable explanation for
why AGPL is not acceptable, while GPL v3 is.

Someone has mentioned the extra effort required to make the source
available over the network.
I would be happy to work on this.

The only other possible explanation is that people would like to make use
of the GPLv3
loophole whereby one can use GPL v3 code over the network and not be
required to
make code modifications available.

Google, for example, which makes its $$ on closed services that use GPL
code, clearly will not tolerate
AGPL.


So, is this the reason why some are opposed to AGPL ?  There is nothing
wrong with this, it is allowed by the license,
just want to be clear.

Anyways,  I am happy to maintain my two-line fork of FFmpeg if this patch
is not accepted.

And, by the way, these changes will be needed in the future when OpenJPEG
releases its next version,
or FFmpeg will not work with OpenJPEG dynamic builds.

Kind Regards,
Aaron













>
> Josh
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec: rawenc: Use the AVCodecContext pix_fmt/width/height

[Clément Bœsch]

On Mon, Apr 04, 2016 at 03:56:31PM +0200, Hugo Beauzée-Luyssen wrote:
> Instead of using the ones in the AVFrame which can be uninitialized

In what context?

> ---
>  libavcodec/rawenc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/rawenc.c b/libavcodec/rawenc.c
> index d837056..27e4a29 100644
> --- a/libavcodec/rawenc.c
> +++ b/libavcodec/rawenc.c
> @@ -60,8 +60,8 @@ static int raw_encode(AVCodecContext *avctx, AVPacket *pkt,
>  return ret;
>  if ((ret = av_image_copy_to_buffer(pkt->data, pkt->size,
> (const uint8_t **)frame->data, 
> frame->linesize,
> -   frame->format,
> -   frame->width, frame->height, 1)) < 0)
> +   avctx->pix_fmt,
> +   avctx->width, avctx->height, 1)) < 0)
>  return ret;
>  
>  if(avctx->codec_tag == AV_RL32("yuv2") && ret > 0 &&
> -- 
> 2.8.0.rc3
> 

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] libavcodec: rawenc: Use the AVCodecContext pix_fmt/width/height

[wm4]

On Mon,  4 Apr 2016 15:56:31 +0200
Hugo Beauzée-Luyssen  wrote:

> Instead of using the ones in the AVFrame which can be uninitialized

When? It's quite broken to send such AVFrames to the encoder?

> ---
>  libavcodec/rawenc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/rawenc.c b/libavcodec/rawenc.c
> index d837056..27e4a29 100644
> --- a/libavcodec/rawenc.c
> +++ b/libavcodec/rawenc.c
> @@ -60,8 +60,8 @@ static int raw_encode(AVCodecContext *avctx, AVPacket *pkt,
>  return ret;
>  if ((ret = av_image_copy_to_buffer(pkt->data, pkt->size,
> (const uint8_t **)frame->data, 
> frame->linesize,
> -   frame->format,
> -   frame->width, frame->height, 1)) < 0)
> +   avctx->pix_fmt,
> +   avctx->width, avctx->height, 1)) < 0)
>  return ret;
>  
>  if(avctx->codec_tag == AV_RL32("yuv2") && ret > 0 &&

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

[FFmpeg-devel] [PATCH] libavcodec: rawenc: Use the AVCodecContext pix_fmt/width/height

[Hugo Beauzée-Luyssen]

Instead of using the ones in the AVFrame which can be uninitialized
---
 libavcodec/rawenc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/rawenc.c b/libavcodec/rawenc.c
index d837056..27e4a29 100644
--- a/libavcodec/rawenc.c
+++ b/libavcodec/rawenc.c
@@ -60,8 +60,8 @@ static int raw_encode(AVCodecContext *avctx, AVPacket *pkt,
 return ret;
 if ((ret = av_image_copy_to_buffer(pkt->data, pkt->size,
(const uint8_t **)frame->data, 
frame->linesize,
-   frame->format,
-   frame->width, frame->height, 1)) < 0)
+   avctx->pix_fmt,
+   avctx->width, avctx->height, 1)) < 0)
 return ret;
 
 if(avctx->codec_tag == AV_RL32("yuv2") && ret > 0 &&
-- 
2.8.0.rc3

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

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Josh de Kock]

On 04/04/2016 14:21, Aaron Boxer wrote:
> All of your arguments could be applied equally to GPL v3 components. And
> yet,
> FFmpeg is happy to allow distribution under GPL v3. So, I don't see what
> the problem is here.
The problem is AGPL can make certain builds of FFmpeg _unusable_, it's a
pain to work with. Most of all, people just don't want AGPL in FFmpeg.
As wm4 said: "If you really want your lib to be useful, you should
relicense it to LGPL2.1 or later".
> 
> Yes, Google has a no-AGPL policy, so they won't be able to use it. I am
> sure they will
> survive somehow without my J2k codec.
A lot of people could survive without it. In-fact, I reckon everyone who
is currently using FFmpeg could.

On 04/04/2016 14:24, Aaron Boxer wrote:
> Of course, it is not my place to say what should happen with the
> project.
> I just want to make sure everyone understands the issues involved
> before making a decision.
I'm almost 100% sure they do, I think it's you who rather doesn't
understand the issues involved with putting AGPL into FFmpeg.

Josh



signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Ronald S. Bultje]

Hi,

On Mon, Apr 4, 2016 at 9:21 AM, Aaron Boxer  wrote:

> Hi Ronald,
>
>
> On Mon, Apr 4, 2016 at 8:56 AM, Ronald S. Bultje 
> wrote:
>
> > Hi,
> >
> > On Mon, Apr 4, 2016 at 8:43 AM, Aaron Boxer  wrote:
> >
> > > Hi Ronald,
> > >
> > >
> > > On Mon, Apr 4, 2016 at 8:34 AM, Ronald S. Bultje 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > On Mon, Apr 4, 2016 at 7:59 AM, Aaron Boxer 
> wrote:
> > > >
> > > > > On Mon, Apr 4, 2016 at 7:13 AM, wm4  wrote:
> > > > >
> > > > > > On Sun, 3 Apr 2016 17:31:25 -0400
> > > > > > Aaron Boxer  wrote:
> > > > > >
> > > > > > > Hi Folks,
> > > > > > >
> > > > > > > Here is a small patch to get FFmpeg working with both OpenJPEG
> > > master
> > > > > and
> > > > > > > Grok master, for J2K support.  The comment on the commit has
> all
> > of
> > > > the
> > > > > > > details; the main change is to remove the OPJ_STATIC flag from
> > > > > configure,
> > > > > > > so that FFmpeg can be configured with a dynamic build of both
> > > codecs.
> > > > > > >
> > > > > > > I also want to reiterate that because FFmpeg can be distributed
> > > under
> > > > > GPL
> > > > > > > v3, and Grok is licensed under the AGPL, there are no licensing
> > > > issues
> > > > > > > regarding distributing FFmpeg together with Grok.
> > > > > > >
> > > > > > > Quoting from Wikipedia:
> > > > > > >
> > > > > > > "By contrast, GPLv3 and AGPLv3 each include clauses (in section
> > 13
> > > of
> > > > > > each
> > > > > > > license) that together achieve a form of mutual compatibility
> for
> > > the
> > > > > two
> > > > > > > licenses. These clauses explicitly allow the "conveying
> > > > > > > " of a work formed
> > by
> > > > > > linking
> > > > > > > code licensed under the one license against code licensed under
> > the
> > > > > other
> > > > > > > license,[3]
> > > > > > > <
> > > > >
> > >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-3
> > > > > > >
> > > > > > > despite the licenses otherwise not allowing relicensing under
> the
> > > > terms
> > > > > > of
> > > > > > > each other.[4]
> > > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > > > > >
> > > > > > > In this way, the copyleft of each license is relaxed to allow
> > > > > > distributing
> > > > > > > such combinations.[4] "
> > > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > > > > >
> > > > > > >
> > > > > > > So, this patch will expand the choice of J2K codecs for all
> users
> > > who
> > > > > use
> > > > > > > FFmpeg under the GPLv3 license.
> > > > > >
> > > > > > AGPL is evil. That alone warrants creating a better, actually
> free
> > > > > > version of the decoder.
> > > > > >
> > > > >
> > > > > The only difference between AGPL and GPL is the proviso that users
> > > > > connecting to a program using AGPL code
> > > > > must be provided with the full source code for the program. This is
> > to
> > > > > close the loophole in the GPL where
> > > > > someone can take free software, put it in the "cloud", and then
> treat
> > > it
> > > > as
> > > > > closed, non-free software, because they
> > > > > do not have to distribute modifications.
> > > > >
> > > > > Please explain why you think this is a Bad Thing (TM)  ?
> > > >
> > > >
> > > > Because it's a fork, not in the codebase sense but in the licensing
> > > sense,
> > > > but the effect is the same. We will not be able to combine multiple
> > > > branches of the fork because each of them is only compatible in its
> own
> > > > direction - "LGPL code can be merged into AGPL code to create AGPL
> > code"
> > > > but not the other way around.
> > > >
> > > > That is fundamentally unfair for those of us that actually _want_ a
> > > > LGPLv2.1-or-later codebase. Why would you get all our spoils but not
> > the
> > > > other way around?
> > > >
> > >
> > > Sorry, I was wrong in my original statements. I've learned a bit more
> > about
> > > how these
> > > licenses work.
> > >
> > > This is not a fork. FSF allows GPL 3 and AGPL 3 code to be combined.
> > > If FFmpeg can be distributed according to GPL 3, then it can included
> > AGPL
> > > 3 code.
> > >
> > > Very simple.
> >
> >
> > Oh, no, no, no. Very simple for _you_, with your _simple_ goal of using
> > ffmpeg and profiting from it by AGPL'ing your component.
> >
> > But for me, as a maintainer, can I combine GPLv2 with AGPLv3? For
> example,
> > can I link a GPLv2 application with a AGPLv3 build of ffmpeg and
> distribute
> > the result? Can I link an AGPLv3 build of ffmpeg with a closed-source
> > application and distribute the result? Can "big" users of ffmpeg,
> companies
> > that fund out project (through e.g. GSoC), like, say, Google, 

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

Hi Hendrik,

On Mon, Apr 4, 2016 at 9:06 AM, Hendrik Leppkes  wrote:

> On Mon, Apr 4, 2016 at 2:49 PM, Aaron Boxer  wrote:
> > On Mon, Apr 4, 2016 at 5:37 AM, Michael Niedermayer
> 
> > wrote:
> >
> >> On Sun, Apr 03, 2016 at 05:31:25PM -0400, Aaron Boxer wrote:
> >> > Hi Folks,
> >> >
> >> > Here is a small patch to get FFmpeg working with both OpenJPEG master
> and
> >> > Grok master, for J2K support.  The comment on the commit has all of
> the
> >> > details; the main change is to remove the OPJ_STATIC flag from
> configure,
> >> > so that FFmpeg can be configured with a dynamic build of both codecs.
> >> >
> >>
> >> > I also want to reiterate that because FFmpeg can be distributed under
> GPL
> >> > v3, and Grok is licensed under the AGPL, there are no licensing issues
> >> > regarding distributing FFmpeg together with Grok.
> >>
> >> FFmpeg support a wide varity of network protools, from low level
> >> tcp to higher level http, ftp, rtp, rtsp, rtmp, mms, ...
> >>
> >> the AGPL requires "if you modify the Program, your modified version must
> >> prominently offer all users interacting with it remotely through a
> computer
> >> network (if your version supports such interaction) an opportunity to
> >> receive the Corresponding Source of your version by providing access to
> the
> >> Corresponding Source from a network server at no charge, through some
> >> standard or customary means of facilitating copying of software."
> >>
> >> yet you here suggest to link AGPL software to GPL where the GPL sw
> >> will not offer any source though any of its quite numerous network
> >> interfaces
> >>
> >> Iam no lawyer so i dont know if you can do that or not but
> >> either the combination needs to offer source code through its network
> >> protocols or you just suggested to circumvent your own licenses main
> >> point
> >>
> >>
> > Here is clarification from the horse's mouth AKA FSF:
>
> You should understand one thing:
> For us, its not really about if its legally possible to link to such a
> library, but if we want to open the door to such licensed libraries.
> And the answer to that question seems to go in favor of no.
>
>
Of course, it is not my place to say what should happen with the project.
I just want to make sure everyone understands the issues involved
before making a decision.

Cheers,
Aaron




> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

Hi Ronald,


On Mon, Apr 4, 2016 at 8:56 AM, Ronald S. Bultje  wrote:

> Hi,
>
> On Mon, Apr 4, 2016 at 8:43 AM, Aaron Boxer  wrote:
>
> > Hi Ronald,
> >
> >
> > On Mon, Apr 4, 2016 at 8:34 AM, Ronald S. Bultje 
> > wrote:
> >
> > > Hi,
> > >
> > > On Mon, Apr 4, 2016 at 7:59 AM, Aaron Boxer  wrote:
> > >
> > > > On Mon, Apr 4, 2016 at 7:13 AM, wm4  wrote:
> > > >
> > > > > On Sun, 3 Apr 2016 17:31:25 -0400
> > > > > Aaron Boxer  wrote:
> > > > >
> > > > > > Hi Folks,
> > > > > >
> > > > > > Here is a small patch to get FFmpeg working with both OpenJPEG
> > master
> > > > and
> > > > > > Grok master, for J2K support.  The comment on the commit has all
> of
> > > the
> > > > > > details; the main change is to remove the OPJ_STATIC flag from
> > > > configure,
> > > > > > so that FFmpeg can be configured with a dynamic build of both
> > codecs.
> > > > > >
> > > > > > I also want to reiterate that because FFmpeg can be distributed
> > under
> > > > GPL
> > > > > > v3, and Grok is licensed under the AGPL, there are no licensing
> > > issues
> > > > > > regarding distributing FFmpeg together with Grok.
> > > > > >
> > > > > > Quoting from Wikipedia:
> > > > > >
> > > > > > "By contrast, GPLv3 and AGPLv3 each include clauses (in section
> 13
> > of
> > > > > each
> > > > > > license) that together achieve a form of mutual compatibility for
> > the
> > > > two
> > > > > > licenses. These clauses explicitly allow the "conveying
> > > > > > " of a work formed
> by
> > > > > linking
> > > > > > code licensed under the one license against code licensed under
> the
> > > > other
> > > > > > license,[3]
> > > > > > <
> > > >
> > https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-3
> > > > > >
> > > > > > despite the licenses otherwise not allowing relicensing under the
> > > terms
> > > > > of
> > > > > > each other.[4]
> > > > > > <
> > > > >
> > > >
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > > > >
> > > > > > In this way, the copyleft of each license is relaxed to allow
> > > > > distributing
> > > > > > such combinations.[4] "
> > > > > > <
> > > > >
> > > >
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > > > >
> > > > > >
> > > > > > So, this patch will expand the choice of J2K codecs for all users
> > who
> > > > use
> > > > > > FFmpeg under the GPLv3 license.
> > > > >
> > > > > AGPL is evil. That alone warrants creating a better, actually free
> > > > > version of the decoder.
> > > > >
> > > >
> > > > The only difference between AGPL and GPL is the proviso that users
> > > > connecting to a program using AGPL code
> > > > must be provided with the full source code for the program. This is
> to
> > > > close the loophole in the GPL where
> > > > someone can take free software, put it in the "cloud", and then treat
> > it
> > > as
> > > > closed, non-free software, because they
> > > > do not have to distribute modifications.
> > > >
> > > > Please explain why you think this is a Bad Thing (TM)  ?
> > >
> > >
> > > Because it's a fork, not in the codebase sense but in the licensing
> > sense,
> > > but the effect is the same. We will not be able to combine multiple
> > > branches of the fork because each of them is only compatible in its own
> > > direction - "LGPL code can be merged into AGPL code to create AGPL
> code"
> > > but not the other way around.
> > >
> > > That is fundamentally unfair for those of us that actually _want_ a
> > > LGPLv2.1-or-later codebase. Why would you get all our spoils but not
> the
> > > other way around?
> > >
> >
> > Sorry, I was wrong in my original statements. I've learned a bit more
> about
> > how these
> > licenses work.
> >
> > This is not a fork. FSF allows GPL 3 and AGPL 3 code to be combined.
> > If FFmpeg can be distributed according to GPL 3, then it can included
> AGPL
> > 3 code.
> >
> > Very simple.
>
>
> Oh, no, no, no. Very simple for _you_, with your _simple_ goal of using
> ffmpeg and profiting from it by AGPL'ing your component.
>
> But for me, as a maintainer, can I combine GPLv2 with AGPLv3? For example,
> can I link a GPLv2 application with a AGPLv3 build of ffmpeg and distribute
> the result? Can I link an AGPLv3 build of ffmpeg with a closed-source
> application and distribute the result? Can "big" users of ffmpeg, companies
> that fund out project (through e.g. GSoC), like, say, Google, use AGPLv3
> builds of ffmpeg without a change in their respective requirements for
> complying with the license terms?
>
> Or, to say it differently: who profits from AGPLv3 components? FFmpeg? Or
> just you? I think it's just you, and that's extremely selfish. It's not in
> the best interest of our project to accept AGPLv3 components, it's only in
> your self-interest that it be accepted. 

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Hendrik Leppkes]

On Mon, Apr 4, 2016 at 2:49 PM, Aaron Boxer  wrote:
> On Mon, Apr 4, 2016 at 5:37 AM, Michael Niedermayer 
> wrote:
>
>> On Sun, Apr 03, 2016 at 05:31:25PM -0400, Aaron Boxer wrote:
>> > Hi Folks,
>> >
>> > Here is a small patch to get FFmpeg working with both OpenJPEG master and
>> > Grok master, for J2K support.  The comment on the commit has all of the
>> > details; the main change is to remove the OPJ_STATIC flag from configure,
>> > so that FFmpeg can be configured with a dynamic build of both codecs.
>> >
>>
>> > I also want to reiterate that because FFmpeg can be distributed under GPL
>> > v3, and Grok is licensed under the AGPL, there are no licensing issues
>> > regarding distributing FFmpeg together with Grok.
>>
>> FFmpeg support a wide varity of network protools, from low level
>> tcp to higher level http, ftp, rtp, rtsp, rtmp, mms, ...
>>
>> the AGPL requires "if you modify the Program, your modified version must
>> prominently offer all users interacting with it remotely through a computer
>> network (if your version supports such interaction) an opportunity to
>> receive the Corresponding Source of your version by providing access to the
>> Corresponding Source from a network server at no charge, through some
>> standard or customary means of facilitating copying of software."
>>
>> yet you here suggest to link AGPL software to GPL where the GPL sw
>> will not offer any source though any of its quite numerous network
>> interfaces
>>
>> Iam no lawyer so i dont know if you can do that or not but
>> either the combination needs to offer source code through its network
>> protocols or you just suggested to circumvent your own licenses main
>> point
>>
>>
> Here is clarification from the horse's mouth AKA FSF:

You should understand one thing:
For us, its not really about if its legally possible to link to such a
library, but if we want to open the door to such licensed libraries.
And the answer to that question seems to go in favor of no.

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

Re: [FFmpeg-devel] libavcodec/exr : Add support for UINT32

[Martin Vignali]

2016-04-03 21:11 GMT+02:00 Martin Vignali :

>
>
> 2016-04-03 21:03 GMT+02:00 Paul B Mahol :
>
>> On 4/3/16, Martin Vignali  wrote:
>> > 2016-04-03 19:31 GMT+02:00 wm4 :
>> >
>> >> On Sun, 3 Apr 2016 19:19:25 +0200
>> >> Paul B Mahol  wrote:
>> >>
>> >> > On 4/3/16, Martin Vignali  wrote:
>> >> > > Hello,
>> >> > >
>> >> > > In attach a patch to add support for UINT32 pixel type.
>> >> > >
>> >> > > Sample of UINT 32 file (scanline only in that case) can be found
>> here
>> >> > > :
>> >> > > https://we.tl/sFB0NYlQVW
>> >> > >
>> >> > > For colorprocessing, UINT32, are converted to float, and follow a
>> >> similar
>> >> > > way for color process than float.
>> >> > >
>> >> > > I not enable in this patch PXR24 in UINT32, who need modification
>> >> inside
>> >> > > pxr24_uncompress.
>> >> > >
>> >> > > Comments welcome
>> >> >
>> >> > So UINT_32 is processed as it was FLOAT, that is strange.
>> >>
>> >> And then the float data is converted back to integer for output? That's
>> >> very funny.
>> >>
>> >>
>> > New patch attach, without the UINT32_MAX define and clean empty line
>> >
>> > For color processing :
>> > The actual exr decoder of ffmpeg, make color conversion inside the
>> decoding
>> > process in float (trc_func, seems to expect to have a float, and
>> one_gamma
>> > is also a float)
>> > After the color conversion, data are converted to uint16.
>> >
>> > uint32 is convert to float (but map in the range 0., 1.0). Some software
>> > decode UINT32 Exr as float without conversion (so the picture is most of
>> > the time white and more). But i doesn't think this way is very
>> convenient
>> > (specially if the rest of the process is not in float)
>> >
>> > Seems you're both not agree. What solution you recommend ?
>>
>> Put } and else in same line.
>>
>
> New patch in attach.
>

In attach, a new version of this patch, adding support for PXR24 uint32.

Sorry for multi post.


Martin
Jokyo Images
From 8a27aff23da67f2689e72a7dad4248445f2f5735 Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Mon, 4 Apr 2016 15:08:41 +0200
Subject: [PATCH] libavcodec/exr : add support for uint32

---
 libavcodec/exr.c | 70 ++--
 1 file changed, 63 insertions(+), 7 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index b0573d5..878a1f5 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -3,7 +3,7 @@
  * Copyright (c) 2006 Industrial Light & Magic, a division of Lucas Digital Ltd. LLC
  * Copyright (c) 2009 Jimmy Christensen
  *
- * B44/B44A, Tile added by Jokyo Images support by CNC - French National Center for Cinema
+ * B44/B44A, Tile, uint32 added by Jokyo Images support by CNC - French National Center for Cinema
  *
  * This file is part of FFmpeg.
  *
@@ -853,6 +853,22 @@ static int pxr24_uncompress(EXRContext *s, const uint8_t *src,
 bytestream_put_le16(, pixel);
 }
 break;
+case EXR_UINT:
+ptr[0] = in;
+ptr[1] = ptr[0] + s->xdelta;
+ptr[2] = ptr[1] + s->xdelta;
+ptr[3] = ptr[2] + s->xdelta;
+in = ptr[3] + s->xdelta;
+
+for (j = 0; j < s->xdelta; ++j) {
+uint32_t diff = (*(ptr[0]++) << 24) |
+(*(ptr[1]++) << 16) |
+(*(ptr[2]++) << 8 ) |
+(*(ptr[3]++));
+pixel += diff;
+bytestream_put_le32(, pixel);
+}
+break;
 default:
 return AVERROR_INVALIDDATA;
 }
@@ -1096,7 +1112,7 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 if (s->is_tile) {
 indexSrc = 0;
 channelLineSize = s->xsize * 2;
-if (s->pixel_type == EXR_FLOAT)
+if ((s->pixel_type == EXR_FLOAT)||(s->pixel_type == EXR_UINT))
 channelLineSize *= 2;
 
 /* reorganise tile data to have each channel one after the other instead of line by line */
@@ -1181,7 +1197,7 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 *ptr_x++ = exr_flt2uint(bytestream_get_le32());
 }
 }
-} else {
+} else if (s->pixel_type == EXR_HALF) {
 // 16-bit
 for (x = 0; x < s->xsize; x++) {
 *ptr_x++ = s->gamma_table[bytestream_get_le16()];
@@ -1190,6 +1206,44 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 if (channel_buffer[3])
 *ptr_x++ = exr_halflt2uint(bytestream_get_le16());
 }
+} else {
+//UINT 32
+if (trc_func) {
+for (x = 0; x < s->xsize; x++) {
+ 

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[wm4]

On Mon, 4 Apr 2016 08:43:10 -0400
Aaron Boxer  wrote:

> Sorry, I was wrong in my original statements. I've learned a bit more about
> how these
> licenses work.
> 
> This is not a fork. FSF allows GPL 3 and AGPL 3 code to be combined.
> If FFmpeg can be distributed according to GPL 3, then it can included AGPL
> 3 code.
> 
> Very simple.

FFmpeg is mainly distributed as "LGPL2.1 or later". If you really want
your lib to be useful, you should relicense it to LGPL2.1 or later
(which is the most compatible GPL license possible).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Ronald S. Bultje]

Hi,

On Mon, Apr 4, 2016 at 8:43 AM, Aaron Boxer  wrote:

> Hi Ronald,
>
>
> On Mon, Apr 4, 2016 at 8:34 AM, Ronald S. Bultje 
> wrote:
>
> > Hi,
> >
> > On Mon, Apr 4, 2016 at 7:59 AM, Aaron Boxer  wrote:
> >
> > > On Mon, Apr 4, 2016 at 7:13 AM, wm4  wrote:
> > >
> > > > On Sun, 3 Apr 2016 17:31:25 -0400
> > > > Aaron Boxer  wrote:
> > > >
> > > > > Hi Folks,
> > > > >
> > > > > Here is a small patch to get FFmpeg working with both OpenJPEG
> master
> > > and
> > > > > Grok master, for J2K support.  The comment on the commit has all of
> > the
> > > > > details; the main change is to remove the OPJ_STATIC flag from
> > > configure,
> > > > > so that FFmpeg can be configured with a dynamic build of both
> codecs.
> > > > >
> > > > > I also want to reiterate that because FFmpeg can be distributed
> under
> > > GPL
> > > > > v3, and Grok is licensed under the AGPL, there are no licensing
> > issues
> > > > > regarding distributing FFmpeg together with Grok.
> > > > >
> > > > > Quoting from Wikipedia:
> > > > >
> > > > > "By contrast, GPLv3 and AGPLv3 each include clauses (in section 13
> of
> > > > each
> > > > > license) that together achieve a form of mutual compatibility for
> the
> > > two
> > > > > licenses. These clauses explicitly allow the "conveying
> > > > > " of a work formed by
> > > > linking
> > > > > code licensed under the one license against code licensed under the
> > > other
> > > > > license,[3]
> > > > > <
> > >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-3
> > > > >
> > > > > despite the licenses otherwise not allowing relicensing under the
> > terms
> > > > of
> > > > > each other.[4]
> > > > > <
> > > >
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > > >
> > > > > In this way, the copyleft of each license is relaxed to allow
> > > > distributing
> > > > > such combinations.[4] "
> > > > > <
> > > >
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > > >
> > > > >
> > > > > So, this patch will expand the choice of J2K codecs for all users
> who
> > > use
> > > > > FFmpeg under the GPLv3 license.
> > > >
> > > > AGPL is evil. That alone warrants creating a better, actually free
> > > > version of the decoder.
> > > >
> > >
> > > The only difference between AGPL and GPL is the proviso that users
> > > connecting to a program using AGPL code
> > > must be provided with the full source code for the program. This is to
> > > close the loophole in the GPL where
> > > someone can take free software, put it in the "cloud", and then treat
> it
> > as
> > > closed, non-free software, because they
> > > do not have to distribute modifications.
> > >
> > > Please explain why you think this is a Bad Thing (TM)  ?
> >
> >
> > Because it's a fork, not in the codebase sense but in the licensing
> sense,
> > but the effect is the same. We will not be able to combine multiple
> > branches of the fork because each of them is only compatible in its own
> > direction - "LGPL code can be merged into AGPL code to create AGPL code"
> > but not the other way around.
> >
> > That is fundamentally unfair for those of us that actually _want_ a
> > LGPLv2.1-or-later codebase. Why would you get all our spoils but not the
> > other way around?
> >
>
> Sorry, I was wrong in my original statements. I've learned a bit more about
> how these
> licenses work.
>
> This is not a fork. FSF allows GPL 3 and AGPL 3 code to be combined.
> If FFmpeg can be distributed according to GPL 3, then it can included AGPL
> 3 code.
>
> Very simple.


Oh, no, no, no. Very simple for _you_, with your _simple_ goal of using
ffmpeg and profiting from it by AGPL'ing your component.

But for me, as a maintainer, can I combine GPLv2 with AGPLv3? For example,
can I link a GPLv2 application with a AGPLv3 build of ffmpeg and distribute
the result? Can I link an AGPLv3 build of ffmpeg with a closed-source
application and distribute the result? Can "big" users of ffmpeg, companies
that fund out project (through e.g. GSoC), like, say, Google, use AGPLv3
builds of ffmpeg without a change in their respective requirements for
complying with the license terms?

Or, to say it differently: who profits from AGPLv3 components? FFmpeg? Or
just you? I think it's just you, and that's extremely selfish. It's not in
the best interest of our project to accept AGPLv3 components, it's only in
your self-interest that it be accepted. And _that_'s a fundamental problem.

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

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 5:37 AM, Michael Niedermayer 
wrote:

> On Sun, Apr 03, 2016 at 05:31:25PM -0400, Aaron Boxer wrote:
> > Hi Folks,
> >
> > Here is a small patch to get FFmpeg working with both OpenJPEG master and
> > Grok master, for J2K support.  The comment on the commit has all of the
> > details; the main change is to remove the OPJ_STATIC flag from configure,
> > so that FFmpeg can be configured with a dynamic build of both codecs.
> >
>
> > I also want to reiterate that because FFmpeg can be distributed under GPL
> > v3, and Grok is licensed under the AGPL, there are no licensing issues
> > regarding distributing FFmpeg together with Grok.
>
> FFmpeg support a wide varity of network protools, from low level
> tcp to higher level http, ftp, rtp, rtsp, rtmp, mms, ...
>
> the AGPL requires "if you modify the Program, your modified version must
> prominently offer all users interacting with it remotely through a computer
> network (if your version supports such interaction) an opportunity to
> receive the Corresponding Source of your version by providing access to the
> Corresponding Source from a network server at no charge, through some
> standard or customary means of facilitating copying of software."
>
> yet you here suggest to link AGPL software to GPL where the GPL sw
> will not offer any source though any of its quite numerous network
> interfaces
>
> Iam no lawyer so i dont know if you can do that or not but
> either the combination needs to offer source code through its network
> protocols or you just suggested to circumvent your own licenses main
> point
>
>
Here is clarification from the horse's mouth AKA FSF:

http://www.gnu.org/licenses/gpl-faq.html#AGPLv3CorrespondingSource

Under AGPLv3, when I modify the Program under section 13, what
Corresponding Source does it have to offer? (#AGPLv3CorrespondingSource
)

“Corresponding Source” is defined in section 1 of the license, and you
should provide what it lists. So, if your modified version depends on
libraries under other licenses, such as the Expat license or GPLv3, the
Corresponding Source should include those libraries (unless they are System
Libraries). If you have modified those libraries, you must provide your
modified source code for them.

The last sentence of the first paragraph of section 13 is only meant to
reinforce what most people would have naturally assumed: even though
combinations with code under GPLv3 are handled through a special exception
in section 13, the Corresponding Source should still include the code that
is combined with the Program this way. This sentence does not mean that you
*only* have to provide the source that's covered under GPLv3; instead it
means that such code is *not* excluded from the definition of Corresponding
Source.


In GPLv3 and AGPLv3, what does it mean when it says “notwithstanding any
other provision of this License”? (#v3Notwithstanding
)

This simply means that the following terms prevail over anything else in
the license that may conflict with them. For example, without this text,
some people might have claimed that you could not combine code under GPLv3
with code under AGPLv3, because the AGPL's additional requirements would be
classified as “further restrictions” under section 7 of GPLv3. This text
makes clear that our intended interpretation is the correct one, and you
can make the combination.

This text only resolves conflicts between different terms of the license.
When there is no conflict between two conditions, then you must meet them
both. These paragraphs don't grant you carte blanche to ignore the rest of
the license—instead they're carving out very limited exceptions.
Under AGPLv3, when I modify the Program under section 13, what
Corresponding Source does it have to offer? (#AGPLv3CorrespondingSource
)

“Corresponding Source” is defined in section 1 of the license, and you
should provide what it lists. So, if your modified version depends on
libraries under other licenses, such as the Expat license or GPLv3, the
Corresponding Source should include those libraries (unless they are System
Libraries). If you have modified those libraries, you must provide your
modified source code for them.

The last sentence of the first paragraph of section 13 is only meant to
reinforce what most people would have naturally assumed: even though
combinations with code under GPLv3 are handled through a special exception
in section 13, the Corresponding Source should still include the code that
is combined with the Program this way. This sentence does not mean that you
*only* have to provide the source that's covered under GPLv3; instead it
means that such code is *not* excluded from the definition of Corresponding
Source.

So, if I distribute both GPL 3 and APGL 3 code 

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

Hi Ronald,


On Mon, Apr 4, 2016 at 8:34 AM, Ronald S. Bultje  wrote:

> Hi,
>
> On Mon, Apr 4, 2016 at 7:59 AM, Aaron Boxer  wrote:
>
> > On Mon, Apr 4, 2016 at 7:13 AM, wm4  wrote:
> >
> > > On Sun, 3 Apr 2016 17:31:25 -0400
> > > Aaron Boxer  wrote:
> > >
> > > > Hi Folks,
> > > >
> > > > Here is a small patch to get FFmpeg working with both OpenJPEG master
> > and
> > > > Grok master, for J2K support.  The comment on the commit has all of
> the
> > > > details; the main change is to remove the OPJ_STATIC flag from
> > configure,
> > > > so that FFmpeg can be configured with a dynamic build of both codecs.
> > > >
> > > > I also want to reiterate that because FFmpeg can be distributed under
> > GPL
> > > > v3, and Grok is licensed under the AGPL, there are no licensing
> issues
> > > > regarding distributing FFmpeg together with Grok.
> > > >
> > > > Quoting from Wikipedia:
> > > >
> > > > "By contrast, GPLv3 and AGPLv3 each include clauses (in section 13 of
> > > each
> > > > license) that together achieve a form of mutual compatibility for the
> > two
> > > > licenses. These clauses explicitly allow the "conveying
> > > > " of a work formed by
> > > linking
> > > > code licensed under the one license against code licensed under the
> > other
> > > > license,[3]
> > > > <
> > https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-3
> > > >
> > > > despite the licenses otherwise not allowing relicensing under the
> terms
> > > of
> > > > each other.[4]
> > > > <
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > >
> > > > In this way, the copyleft of each license is relaxed to allow
> > > distributing
> > > > such combinations.[4] "
> > > > <
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > >
> > > >
> > > > So, this patch will expand the choice of J2K codecs for all users who
> > use
> > > > FFmpeg under the GPLv3 license.
> > >
> > > AGPL is evil. That alone warrants creating a better, actually free
> > > version of the decoder.
> > >
> >
> > The only difference between AGPL and GPL is the proviso that users
> > connecting to a program using AGPL code
> > must be provided with the full source code for the program. This is to
> > close the loophole in the GPL where
> > someone can take free software, put it in the "cloud", and then treat it
> as
> > closed, non-free software, because they
> > do not have to distribute modifications.
> >
> > Please explain why you think this is a Bad Thing (TM)  ?
>
>
> Because it's a fork, not in the codebase sense but in the licensing sense,
> but the effect is the same. We will not be able to combine multiple
> branches of the fork because each of them is only compatible in its own
> direction - "LGPL code can be merged into AGPL code to create AGPL code"
> but not the other way around.
>
> That is fundamentally unfair for those of us that actually _want_ a
> LGPLv2.1-or-later codebase. Why would you get all our spoils but not the
> other way around?
>

Sorry, I was wrong in my original statements. I've learned a bit more about
how these
licenses work.

This is not a fork. FSF allows GPL 3 and AGPL 3 code to be combined.
If FFmpeg can be distributed according to GPL 3, then it can included AGPL
3 code.

Very simple.

Cheers,
Aaron



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

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Ronald S. Bultje]

Hi,

On Mon, Apr 4, 2016 at 7:59 AM, Aaron Boxer  wrote:

> On Mon, Apr 4, 2016 at 7:13 AM, wm4  wrote:
>
> > On Sun, 3 Apr 2016 17:31:25 -0400
> > Aaron Boxer  wrote:
> >
> > > Hi Folks,
> > >
> > > Here is a small patch to get FFmpeg working with both OpenJPEG master
> and
> > > Grok master, for J2K support.  The comment on the commit has all of the
> > > details; the main change is to remove the OPJ_STATIC flag from
> configure,
> > > so that FFmpeg can be configured with a dynamic build of both codecs.
> > >
> > > I also want to reiterate that because FFmpeg can be distributed under
> GPL
> > > v3, and Grok is licensed under the AGPL, there are no licensing issues
> > > regarding distributing FFmpeg together with Grok.
> > >
> > > Quoting from Wikipedia:
> > >
> > > "By contrast, GPLv3 and AGPLv3 each include clauses (in section 13 of
> > each
> > > license) that together achieve a form of mutual compatibility for the
> two
> > > licenses. These clauses explicitly allow the "conveying
> > > " of a work formed by
> > linking
> > > code licensed under the one license against code licensed under the
> other
> > > license,[3]
> > > <
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-3
> > >
> > > despite the licenses otherwise not allowing relicensing under the terms
> > of
> > > each other.[4]
> > > <
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > >
> > > In this way, the copyleft of each license is relaxed to allow
> > distributing
> > > such combinations.[4] "
> > > <
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > >
> > >
> > > So, this patch will expand the choice of J2K codecs for all users who
> use
> > > FFmpeg under the GPLv3 license.
> >
> > AGPL is evil. That alone warrants creating a better, actually free
> > version of the decoder.
> >
>
> The only difference between AGPL and GPL is the proviso that users
> connecting to a program using AGPL code
> must be provided with the full source code for the program. This is to
> close the loophole in the GPL where
> someone can take free software, put it in the "cloud", and then treat it as
> closed, non-free software, because they
> do not have to distribute modifications.
>
> Please explain why you think this is a Bad Thing (TM)  ?


Because it's a fork, not in the codebase sense but in the licensing sense,
but the effect is the same. We will not be able to combine multiple
branches of the fork because each of them is only compatible in its own
direction - "LGPL code can be merged into AGPL code to create AGPL code"
but not the other way around.

That is fundamentally unfair for those of us that actually _want_ a
LGPLv2.1-or-later codebase. Why would you get all our spoils but not the
other way around?

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

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 3:39 AM, Tobias Rapp  wrote:

> On 04.04.2016 02:36, Aaron Boxer wrote:
>
>> [...]
>>
> >
>
>> Thanks, Michael. Here is an updated patch with the bpp change removed.
>>
>> Aaron
>>
>> From fb7551a8f9fe6a5317f01c9f33a76f8ae67ad979 Mon Sep 17 00:00:00 2001
>> From: Aaron Boxer 
>> Date: Sun, 3 Apr 2016 20:30:04 -0400
>> Subject: [PATCH] Support the following jpeg 2000 codecs:
>>
>> a) latest release of openjpeg (2.1)
>> b) master branch of openjpeg
>> c) grok (https://github.com/GrokImageCompression/grok)
>>
>> The following changes were made:
>>
>> 1. Removed OPJ_STATIC flag in configure: in master branch of openjpeg and
>> in grok, this flag indicates a static build, so codec API functions are
>> marked as hidden. This prevents FFmpeg from using a dynamic build of these
>> codecs.
>> 2. link to libdl. This is needed by grok, as it supports a plugin
>> architecture that allows plugins to be dynamically loaded at runtime.
>>
>> I have tested these changes with openjpeg 2.1, openjpeg master, and grok
>> master.Test was to make sure ./configure and make showed no errors, and
>> then to decompress a J2K file.  Everything worked for all three
>> configurations, with no errors.
>> ---
>>  configure   | 2 +-
>>  libavcodec/libopenjpegdec.c | 2 +-
>>  libavcodec/libopenjpegenc.c | 2 +-
>>  3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 94a66d8..4e81385 100755
>> --- a/configure
>> +++ b/configure
>> @@ -5561,7 +5561,7 @@ enabled libopencv && { check_header
>> opencv2/core/core_c.h &&
>>   require opencv opencv2/core/core_c.h
>> cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
>> require_pkg_config opencv opencv/cxcore.h
>> cvCreateImageHeader; }
>>  enabled libopenh264   && require_pkg_config openh264
>> wels/codec_api.h WelsGetCodecVersion
>> -enabled libopenjpeg   && { check_lib openjpeg-2.1/openjpeg.h
>> opj_version -lopenjp2 -DOPJ_STATIC ||
>> +enabled libopenjpeg   && { check_lib openjpeg-2.1/openjpeg.h
>> opj_version -lopenjp2 -ldl ||
>>
>
> This breaks (cross-)compilation of FFmpeg and OpenJpeg-2.1 with mingw-64
> on my machine.
>

Thanks, I will take a look.

Cheers,
Aaron
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 5:37 AM, Michael Niedermayer 
wrote:

> On Sun, Apr 03, 2016 at 05:31:25PM -0400, Aaron Boxer wrote:
> > Hi Folks,
> >
> > Here is a small patch to get FFmpeg working with both OpenJPEG master and
> > Grok master, for J2K support.  The comment on the commit has all of the
> > details; the main change is to remove the OPJ_STATIC flag from configure,
> > so that FFmpeg can be configured with a dynamic build of both codecs.
> >
>
> > I also want to reiterate that because FFmpeg can be distributed under GPL
> > v3, and Grok is licensed under the AGPL, there are no licensing issues
> > regarding distributing FFmpeg together with Grok.
>
> FFmpeg support a wide varity of network protools, from low level
> tcp to higher level http, ftp, rtp, rtsp, rtmp, mms, ...
>
> the AGPL requires "if you modify the Program, your modified version must
> prominently offer all users interacting with it remotely through a computer
> network (if your version supports such interaction) an opportunity to
> receive the Corresponding Source of your version by providing access to the
> Corresponding Source from a network server at no charge, through some
> standard or customary means of facilitating copying of software."
>
> yet you here suggest to link AGPL software to GPL where the GPL sw
> will not offer any source though any of its quite numerous network
> interfaces
>
> Iam no lawyer so i dont know if you can do that or not but
> either the combination needs to offer source code through its network
> protocols or you just suggested to circumvent your own licenses main
> point
>
>
The GPL v3 code would continue to be bound by GPL v3,(no need to distribute
source if connected over network) and the AGPL
code would continue to be bound by AGPL (must distribute source if
connected over network)

I will try to get clarification from FSF.

Cheers,
Aaron


>
> >
> > Quoting from Wikipedia:
>
> quoting Wikipedia as well
> https://en.wikipedia.org/wiki/Wikipedia:Legal_disclaimer
>
> WIKIPEDIA DOES NOT GIVE LEGAL OPINIONS
>
> Wikipedia contains articles on many legal topics; however, no warranty
> whatsoever is made that any of the articles are accurate. There is
> absolutely no assurance that any statement contained in an article touching
> on legal matters is true, correct or precise. Law varies from place to
> place and it evolves over time—sometimes quite quickly. Even if a statement
> made about the law is accurate, it may only be accurate in the jurisdiction
> of the person posting the information; as well, the law may have changed,
> been modified or overturned by subsequent development since the entry was
> made on Wikipedia.
>
> The legal information provided on Wikipedia is, at best, of a general
> nature and cannot substitute for the advice of a licensed professional,
> i.e., by a competent authority with specialised knowledge who can apply it
> to the particular circumstances of your case. Please contact a local bar
> association, law society or similar association of jurists in your legal
> jurisdiction to obtain a referral to a competent legal professional if you
> do not have other means of contacting an attorney-at-law, lawyer, civil law
> notary, barrister or solicitor.
>
> Neither the individual contributors, system operators, developers, nor
> sponsors of Wikipedia nor anyone else connected to Wikipedia can take any
> responsibility for the results or consequences of any attempt to use or
> adopt any of the information or disinformation presented on this web site.
>
> Nothing on Wikipedia.org or of any project of Wikimedia Foundation, Inc.,
> should be construed as an attempt to offer or render a legal opinion or
> otherwise engage in the practice of law.
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No great genius has ever existed without some touch of madness. --
> Aristotle
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: add aac test which occasionally crashes (Ticket 1784)

[Claudio Freire]

On Sun, Apr 3, 2016 at 10:41 PM, James Almer  wrote:
> On 4/3/2016 3:29 PM, Claudio Freire wrote:
>> On Sun, Apr 3, 2016 at 3:05 PM, Claudio Freire  
>> wrote:
>>> On Sat, Apr 2, 2016 at 4:00 PM, Michael Niedermayer
>>>  wrote:
 Ideally that should be fixed before its pushed

 Signed-off-by: Michael Niedermayer 
 ---
  tests/fate/aac.mak |   11 +++
  1 file changed, 11 insertions(+)

 diff --git a/tests/fate/aac.mak b/tests/fate/aac.mak
 index 324b05d..3d64031 100644
 --- a/tests/fate/aac.mak
 +++ b/tests/fate/aac.mak
 @@ -213,6 +213,17 @@ fate-aac-ltp-encode: CMP_TARGET = 1270
  fate-aac-ltp-encode: SIZE_TOLERANCE = 3560
  fate-aac-ltp-encode: FUZZ = 17

 +#Ticket1784
 +FATE_AAC_ENCODE += fate-aac-yoraw-encode
 +fate-aac-yoraw-encode: CMD = enc_dec_pcm adts wav s16le 
 $(TARGET_SAMPLES)/audio-reference/yo.raw-short.wav -c:a aac -fflags 
 +bitexact -flags +bitexact
 +fate-aac-yoraw-encode: CMP = stddev
 +fate-aac-yoraw-encode: REF = $(SAMPLES)/audio-reference/yo.raw-short.wav
 +fate-aac-yoraw-encode: CMP_SHIFT = -12288
 +fate-aac-yoraw-encode: CMP_TARGET = 259
 +fate-aac-yoraw-encode: SIZE_TOLERANCE = 3560
 +fate-aac-yoraw-encode: FUZZ = 17
 +
 +
  FATE_AAC_ENCODE += fate-aac-pred-encode
  fate-aac-pred-encode: CMD = enc_dec_pcm adts wav s16le 
 $(TARGET_SAMPLES)/audio-reference/luckynight_2ch_44kHz_s16.wav -profile:a 
 aac_main -c:a aac -aac_is 0 -aac_pns 0 -aac_ms 0 -aac_tns 0 -b:a 128k 
 -cutoff 22050
  fate-aac-pred-encode: CMP = stddev
>>>
>>>
>>> Fixed now, feel free to push this
>>
>>
>> Never mind, pushed it myself, kept your signoff.
>
> http://fate.ffmpeg.org/report.cgi?time=20160403222945=x86_64-archlinux-gcc-valgrindundef
>
> No memleaks, but a handful of "Conditional jump or move depends on 
> uninitialised value(s)" errors.


Strange. This shouldn't be new or related to this commit.

I'll take a look nonetheless.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 7:13 AM, wm4  wrote:

> On Sun, 3 Apr 2016 17:31:25 -0400
> Aaron Boxer  wrote:
>
> > Hi Folks,
> >
> > Here is a small patch to get FFmpeg working with both OpenJPEG master and
> > Grok master, for J2K support.  The comment on the commit has all of the
> > details; the main change is to remove the OPJ_STATIC flag from configure,
> > so that FFmpeg can be configured with a dynamic build of both codecs.
> >
> > I also want to reiterate that because FFmpeg can be distributed under GPL
> > v3, and Grok is licensed under the AGPL, there are no licensing issues
> > regarding distributing FFmpeg together with Grok.
> >
> > Quoting from Wikipedia:
> >
> > "By contrast, GPLv3 and AGPLv3 each include clauses (in section 13 of
> each
> > license) that together achieve a form of mutual compatibility for the two
> > licenses. These clauses explicitly allow the "conveying
> > " of a work formed by
> linking
> > code licensed under the one license against code licensed under the other
> > license,[3]
> >  >
> > despite the licenses otherwise not allowing relicensing under the terms
> of
> > each other.[4]
> > <
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> >
> > In this way, the copyleft of each license is relaxed to allow
> distributing
> > such combinations.[4] "
> > <
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> >
> >
> > So, this patch will expand the choice of J2K codecs for all users who use
> > FFmpeg under the GPLv3 license.
>
> AGPL is evil. That alone warrants creating a better, actually free
> version of the decoder.
>

The only difference between AGPL and GPL is the proviso that users
connecting to a program using AGPL code
must be provided with the full source code for the program. This is to
close the loophole in the GPL where
someone can take free software, put it in the "cloud", and then treat it as
closed, non-free software, because they
do not have to distribute modifications.

Please explain why you think this is a Bad Thing (TM)  ?




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

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[wm4]

On Sun, 3 Apr 2016 17:31:25 -0400
Aaron Boxer  wrote:

> Hi Folks,
> 
> Here is a small patch to get FFmpeg working with both OpenJPEG master and
> Grok master, for J2K support.  The comment on the commit has all of the
> details; the main change is to remove the OPJ_STATIC flag from configure,
> so that FFmpeg can be configured with a dynamic build of both codecs.
> 
> I also want to reiterate that because FFmpeg can be distributed under GPL
> v3, and Grok is licensed under the AGPL, there are no licensing issues
> regarding distributing FFmpeg together with Grok.
> 
> Quoting from Wikipedia:
> 
> "By contrast, GPLv3 and AGPLv3 each include clauses (in section 13 of each
> license) that together achieve a form of mutual compatibility for the two
> licenses. These clauses explicitly allow the "conveying
> " of a work formed by linking
> code licensed under the one license against code licensed under the other
> license,[3]
> 
> despite the licenses otherwise not allowing relicensing under the terms of
> each other.[4]
> 
> In this way, the copyleft of each license is relaxed to allow distributing
> such combinations.[4] "
> 
> 
> So, this patch will expand the choice of J2K codecs for all users who use
> FFmpeg under the GPLv3 license.

AGPL is evil. That alone warrants creating a better, actually free
version of the decoder.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffplay: fix silence insertion on error or pause

[Michael Niedermayer]

On Sun, Apr 03, 2016 at 09:37:58PM +0200, Marton Balint wrote:
> Insertion of silence was a bit broken since
> df34b700981de606ca4847e1ed0bfdf9ac3e9104 because the info whether or not the
> source buffer supposed to be silence must be kept between callbacks. Failing 
> to
> do so causes rogue samples from the last buffer to be presented, I guess even 
> a
> crash can occur under some circumstances.
> 
> This patch uses a NULL audio_buf to keep the silence state across audio
> callbacks.
> 
> Signed-off-by: Marton Balint 
> ---
>  ffplay.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

slightly off topic but
does it sound better to repeat the last packet or to fill in
silence for damaged packets ?

[]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] libxvid: Create extradata in init using a dummy frame

[Michael Niedermayer]

On Sun, Apr 03, 2016 at 04:54:47PM -0400, Derek Buitenhuis wrote:
> Modifying global header extradata in encode_frame is an API violation
> and only happens to work currently because mov writes its header
> at the end of the file.
> 
> Heavily based off of a patch from 2012.
> 
> Original-by: Nicolas George 
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavcodec/libxvid.c | 39 +++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/libavcodec/libxvid.c b/libavcodec/libxvid.c
> index 76e725e..e353154 100644
> --- a/libavcodec/libxvid.c
> +++ b/libavcodec/libxvid.c
> @@ -96,6 +96,9 @@ struct xvid_ff_pass1 {
>  };
>  
>  static int xvid_encode_close(AVCodecContext *avctx);
> +static int xvid_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
> + const AVFrame *picture, int *got_packet);
> +
>  
>  /*
>   * Xvid 2-Pass Kludge Section
> @@ -707,6 +710,42 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  
>  av_assert0(xvid_enc_create.num_plugins + (!!x->ssim) + 
> (!!x->variance_aq) + (!!x->lumi_aq) <= FF_ARRAY_ELEMS(plugins));
>  
> +/* Encode a dummy frame to get the extradata immediately */
> +if (x->quicktime_format) {
> +AVFrame *picture;
> +AVPacket packet;
> +int size, got_packet, ret;
> +
> +av_init_packet();
> +
> +picture = av_frame_alloc();
> +if (!picture)
> +return AVERROR(ENOMEM);
> +
> +xerr = xvid_encore(NULL, XVID_ENC_CREATE, _enc_create, NULL);

> +if( xerr ) {
> +av_log(avctx, AV_LOG_ERROR, "Xvid: Could not create encoder 
> reference\n");
> +return AVERROR_EXTERNAL;
> +}

leaks pictures

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

Re: [FFmpeg-devel] Support AS-10 MXF

[Gaullier Nicolas]

>On Tue, 2016-03-29 at 22:29 +0200, NabFab wrote:
>> Hi,
>> Could you please tell me if ffmpeg is supporting AS-10 or AS-11 MXF 
>> format according to AMWA specifications ?
>> Thank you
>
>Do you mean muxing or demuxing? I expect mxfdec should be perfectly capable of 
>demuxing.
>
>It's been a while since I looked at AS-10 but I recall it simply being a 
>narrower version of OP1a (but not as narrow as OPAtom). So just mux >something 
>with the codecs AS-10 expects and run it through an AS-10 analyzer to see if 
>mxfenc spits out the right thing.
>
>/Tomas

To be compliant with AS10, it is required to insert a specific metadata (the 
ShimName, at least), this is quite some dev work, manipulating DMS Schemes...
Body partitions are also restricted to 10s max, and there are many other 
constraints.
For now, bmx is much more broadcast-oriented, already support as11 and has an 
as10 branch.
The AMWA thing is all about certification and respect of the constraints to 
facilitate interoperability, it is not that easy to achieve.
This said, AS10/11 are based on Op1A, and in some cases, people may say they 
"require" AS10/AS11 to "feel safe" despite the fact that more generic Op1A that 
ffmpeg can provide would probably be sufficient for their workflow to work.

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

Re: [FFmpeg-devel] [PATCH] sws/aarch64: restore hscale for a limited subset of filter sizes

[Clément Bœsch]

On Mon, Apr 04, 2016 at 10:35:16AM +0200, Clément Bœsch wrote:
> From: Clément Bœsch 
> 
> ---
> I need to add a &3 (mod4) version now... I don't know if it can be any 
> smaller.
> ---
>  libswscale/aarch64/hscale.S  | 2 +-
>  libswscale/aarch64/swscale.c | 5 +++--
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 

Please disregard this patch.

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Michael Niedermayer]

On Sun, Apr 03, 2016 at 05:31:25PM -0400, Aaron Boxer wrote:
> Hi Folks,
> 
> Here is a small patch to get FFmpeg working with both OpenJPEG master and
> Grok master, for J2K support.  The comment on the commit has all of the
> details; the main change is to remove the OPJ_STATIC flag from configure,
> so that FFmpeg can be configured with a dynamic build of both codecs.
> 

> I also want to reiterate that because FFmpeg can be distributed under GPL
> v3, and Grok is licensed under the AGPL, there are no licensing issues
> regarding distributing FFmpeg together with Grok.

FFmpeg support a wide varity of network protools, from low level
tcp to higher level http, ftp, rtp, rtsp, rtmp, mms, ...

the AGPL requires "if you modify the Program, your modified version must 
prominently offer all users interacting with it remotely through a computer 
network (if your version supports such interaction) an opportunity to receive 
the Corresponding Source of your version by providing access to the 
Corresponding Source from a network server at no charge, through some standard 
or customary means of facilitating copying of software."

yet you here suggest to link AGPL software to GPL where the GPL sw
will not offer any source though any of its quite numerous network
interfaces

Iam no lawyer so i dont know if you can do that or not but
either the combination needs to offer source code through its network
protocols or you just suggested to circumvent your own licenses main
point


> 
> Quoting from Wikipedia:

quoting Wikipedia as well
https://en.wikipedia.org/wiki/Wikipedia:Legal_disclaimer

WIKIPEDIA DOES NOT GIVE LEGAL OPINIONS

Wikipedia contains articles on many legal topics; however, no warranty 
whatsoever is made that any of the articles are accurate. There is absolutely 
no assurance that any statement contained in an article touching on legal 
matters is true, correct or precise. Law varies from place to place and it 
evolves over time—sometimes quite quickly. Even if a statement made about the 
law is accurate, it may only be accurate in the jurisdiction of the person 
posting the information; as well, the law may have changed, been modified or 
overturned by subsequent development since the entry was made on Wikipedia.

The legal information provided on Wikipedia is, at best, of a general nature 
and cannot substitute for the advice of a licensed professional, i.e., by a 
competent authority with specialised knowledge who can apply it to the 
particular circumstances of your case. Please contact a local bar association, 
law society or similar association of jurists in your legal jurisdiction to 
obtain a referral to a competent legal professional if you do not have other 
means of contacting an attorney-at-law, lawyer, civil law notary, barrister or 
solicitor.

Neither the individual contributors, system operators, developers, nor sponsors 
of Wikipedia nor anyone else connected to Wikipedia can take any responsibility 
for the results or consequences of any attempt to use or adopt any of the 
information or disinformation presented on this web site.

Nothing on Wikipedia.org or of any project of Wikimedia Foundation, Inc., 
should be construed as an attempt to offer or render a legal opinion or 
otherwise engage in the practice of law.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle


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

[FFmpeg-devel] [PATCH] sws/aarch64: restore hscale for a limited subset of filter sizes

[Clément Bœsch]

From: Clément Bœsch 

---
I need to add a &3 (mod4) version now... I don't know if it can be any smaller.
---
 libswscale/aarch64/hscale.S  | 2 +-
 libswscale/aarch64/swscale.c | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/libswscale/aarch64/hscale.S b/libswscale/aarch64/hscale.S
index c32394c..e6bd365 100644
--- a/libswscale/aarch64/hscale.S
+++ b/libswscale/aarch64/hscale.S
@@ -20,7 +20,7 @@
 
 #include "libavutil/aarch64/asm.S"
 
-function ff_hscale_8_to_15_neon, export=1
+function ff_hscale_8_to_15_X8_neon, export=1
 add x10, x4, w6, UXTW #1// filter2 = filter + 
filterSize*2 (x2 because int16)
 1:  ldr w8, [x5], #4// filterPos[0]
 ldr w9, [x5], #4// filterPos[1]
diff --git a/libswscale/aarch64/swscale.c b/libswscale/aarch64/swscale.c
index ebf76a5..f38effe 100644
--- a/libswscale/aarch64/swscale.c
+++ b/libswscale/aarch64/swscale.c
@@ -21,7 +21,7 @@
 #include "libswscale/swscale_internal.h"
 #include "libavutil/aarch64/cpu.h"
 
-void ff_hscale_8_to_15_neon(SwsContext *c, int16_t *dst, int dstW,
+void ff_hscale_8_to_15_X8_neon(SwsContext *c, int16_t *dst, int dstW,
 const uint8_t *src, const int16_t *filter,
 const int32_t *filterPos, int filterSize);
 
@@ -31,7 +31,8 @@ av_cold void ff_sws_init_swscale_aarch64(SwsContext *c)
 
 if (have_neon(cpu_flags)) {
 if (c->srcBpc == 8 && c->dstBpc <= 14) {
-//c->hyScale = c->hcScale = ff_hscale_8_to_15_neon;
+if (c->hLumFilterSize & 7) c->hyScale = ff_hscale_8_to_15_X8_neon;
+if (c->hChrFilterSize & 7) c->hcScale = ff_hscale_8_to_15_X8_neon;
 }
 }
 }
-- 
2.7.4

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

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Tobias Rapp]

On 04.04.2016 02:36, Aaron Boxer wrote:

[...]

>

Thanks, Michael. Here is an updated patch with the bpp change removed.

Aaron

From fb7551a8f9fe6a5317f01c9f33a76f8ae67ad979 Mon Sep 17 00:00:00 2001
From: Aaron Boxer 
Date: Sun, 3 Apr 2016 20:30:04 -0400
Subject: [PATCH] Support the following jpeg 2000 codecs:

a) latest release of openjpeg (2.1)
b) master branch of openjpeg
c) grok (https://github.com/GrokImageCompression/grok)

The following changes were made:

1. Removed OPJ_STATIC flag in configure: in master branch of openjpeg and in 
grok, this flag indicates a static build, so codec API functions are marked as 
hidden. This prevents FFmpeg from using a dynamic build of these codecs.
2. link to libdl. This is needed by grok, as it supports a plugin architecture 
that allows plugins to be dynamically loaded at runtime.

I have tested these changes with openjpeg 2.1, openjpeg master, and grok 
master.Test was to make sure ./configure and make showed no errors, and then to 
decompress a J2K file.  Everything worked for all three configurations, with no 
errors.
---
 configure   | 2 +-
 libavcodec/libopenjpegdec.c | 2 +-
 libavcodec/libopenjpegenc.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 94a66d8..4e81385 100755
--- a/configure
+++ b/configure
@@ -5561,7 +5561,7 @@ enabled libopencv && { check_header opencv2/core/core_c.h 
&&
  require opencv opencv2/core/core_c.h 
cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
require_pkg_config opencv opencv/cxcore.h 
cvCreateImageHeader; }
 enabled libopenh264   && require_pkg_config openh264 wels/codec_api.h 
WelsGetCodecVersion
-enabled libopenjpeg   && { check_lib openjpeg-2.1/openjpeg.h opj_version 
-lopenjp2 -DOPJ_STATIC ||
+enabled libopenjpeg   && { check_lib openjpeg-2.1/openjpeg.h opj_version 
-lopenjp2 -ldl ||


This breaks (cross-)compilation of FFmpeg and OpenJpeg-2.1 with mingw-64 
on my machine.



check_lib openjpeg-2.0/openjpeg.h opj_version 
-lopenjp2 -DOPJ_STATIC ||
check_lib openjpeg-1.5/openjpeg.h opj_version 
-lopenjpeg -DOPJ_STATIC ||
check_lib openjpeg.h opj_version -lopenjpeg 
-DOPJ_STATIC ||
diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 65167e6..f116c8b 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -24,7 +24,7 @@
  * JPEG 2000 decoder using libopenjpeg
  */

-#define  OPJ_STATIC
+

 #include "libavutil/common.h"
 #include "libavutil/imgutils.h"
diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
index 56c8219..e55 100644
--- a/libavcodec/libopenjpegenc.c
+++ b/libavcodec/libopenjpegenc.c
@@ -24,7 +24,7 @@
  * JPEG 2000 encoder using libopenjpeg
  */

-#define  OPJ_STATIC
+

 #include "libavutil/avassert.h"
 #include "libavutil/common.h"
--
2.6.3.windows.1



Regards,
Tobias

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