On Mon, Apr 04, 2016 at 04:55:37PM +0200, Martin Vignali wrote:
> 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
On Mon, Apr 04, 2016 at 03:59:27PM -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: Nicol
F.Sluiter gmail.com> writes:
> I wrote a new filter for ffmpeg and would value your comments.
> Files attached are not proper git or diff patches, but the
> filter itself is only a single file.
We can only read unified diffs as made with git format-patch;-(
I suspect that your filter should
Aaron Boxer gmail.com> writes:
> 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.
As was already discussed before, this is simply not true:
The
Aaron Boxer gmail.com> writes:
> I still think the advantages (i.e. closing the application
> server loophole)c outweigh this disadvantage.
I believe the mistake you make here is the main reason for
this whole fruitless discussion including the misunderstandings.
Carl Eugen
_
Indeed, working with Paul Mahol and he changed it. Almost ready to publish
Op 5 apr. 2016 11:47 schreef "Carl Eugen Hoyos" :
> F.Sluiter gmail.com> writes:
>
> > I wrote a new filter for ffmpeg and would value your comments.
>
> > Files attached are not proper git or diff patches, but the
> > fil
On Saturday 02 April 2016 03:23:31 pm Michael Niedermayer wrote:
> On Sat, Apr 02, 2016 at 10:29:20AM +0200, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached is a probe function for gsm and a patch for a gsm muxer to allow
> > testing. The file format is for example supported by sox.
> >
> > Please
Paul B Mahol gmail.com> writes:
> > Attached is a probe function for gsm
> What heuristic you used to write this code?
The decoder rejects frames that do not start with 0xdx.
Are you unhappy with the probe function?
Is it too hard or too soft?
Carl Eugen
_
>
> Yes. Well, AGPL extends the definition of distribution to include use over
> the network.
Would we need then to send a copy of the AGPL to every viewer of our
channels?
How do we even know who they are when it's a terrestrial (OTA) broadcast?
Should we just send one to every citizen on earth
On 4/5/16, Carl Eugen Hoyos wrote:
> Paul B Mahol gmail.com> writes:
>
>> > Attached is a probe function for gsm
>
>> What heuristic you used to write this code?
>
> The decoder rejects frames that do not start with 0xdx.
>
> Are you unhappy with the probe function?
> Is it too hard or too soft?
On Tue, 05 Apr 2016 10:12:09 +
Kieran Kunhya wrote:
> >
> > Yes. Well, AGPL extends the definition of distribution to include use over
> > the network.
>
>
> Would we need then to send a copy of the AGPL to every viewer of our
> channels?
> How do we even know who they are when it's a ter
Paul B Mahol gmail.com> writes:
> > Are you unhappy with the probe function?
> > Is it too hard or too soft?
>
> It seems it breaks fate.
The gsm muxer (not the probe function) broke fate
because I badly edited allformats.c and "removed"
the gif demuxer: As said, I consider this an
interesti
Hi,
On Tue, Apr 5, 2016 at 6:15 AM, wm4 wrote:
> On Tue, 05 Apr 2016 10:12:09 +
> Kieran Kunhya wrote:
>
> > >
> > > Yes. Well, AGPL extends the definition of distribution to include use
> over
> > > the network.
> >
> >
> > Would we need then to send a copy of the AGPL to every viewer of o
Hello,
Currently i am integrating third party PCM decoder,where the input of the
decoder function should be s16/s24 and output will be of float type.
In Init function, i have updated,avctx->bits_per_raw_sample = 32 and
in decode_frame function, i have updated the AVFrame->format
to AV_SAMPLE_FM
Suresh Kumar gmail.com> writes:
> Currently i am integrating third party PCM decoder, where
> the input of the decoder function should be s16/s24 and
> output will be of float type.
Did you look at the aresample filter and libswresample?
Carl Eugen
___
On 4/5/2016 10:26 AM, Michael Niedermayer wrote:
> should be ok fro ffmpegs side, i dont know the xvid API
As far as I can tell from its documentation, this is the official / correct
way. The API is kinda bad in that sense.
Thanks,
- Derek
___
ffmpeg-de
Hi,
I've almost finished my qualfication task for GSoC, and would love some
input on my work till now.
Currently, the mlp encoder compiles, but does not produce valid
bitstream (crashes). This is because AVCodec's encode2 function prototype has
changed, but the mlp_encode_frame assumes the old ap
On date Saturday 2016-04-02 15:56:55 +0200, Michael Niedermayer encoded:
> On Sat, Apr 02, 2016 at 12:46:57PM +0200, Stefano Sabatini wrote:
> > This allows to recognize ID3 packets from the stream type.
> > ---
> > libavformat/mpegts.c | 1 +
> > 1 file changed, 1 insertion(+)
>
> breaks ticket
On Tue, Apr 05, 2016 at 09:54:45AM +, Carl Eugen Hoyos wrote:
> Aaron Boxer gmail.com> writes:
>
> > I still think the advantages (i.e. closing the application
> > server loophole)c outweigh this disadvantage.
>
> I believe the mistake you make here is the main reason for
> this whole frui
> 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
On Mon, Apr 04, 2016 at 08:18:47PM +, Kieran Kunhya wrote:
> 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
Hello,
Mipmap and ripmap is two way to store several resolution of the picture
inside an exr file
The difference between these two mode, is the number of subres level (lot
more subres in ripmap, than mipmap).
These files are mainly design to store maps for 3D render.
After some tests on official
Hi,
patch attached.
From 0ffba4b4b9bd9bcb76b90be1a212672951a40ba0 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Tue, 5 Apr 2016 14:05:10 +0200
Subject: [PATCH] avformat: add aix demuxer
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/aixdec.c | 129 +++
Hi,
patch attached.
From 16a4e29da415ff211ceee3d0bbdbd54edc2d9852 Mon Sep 17 00:00:00 2001
From: "F.Sluiter"
Date: Tue, 5 Apr 2016 09:36:37 +0200
Subject: [PATCH] avfilter: add remap filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 8 ++
libavfilter/Makefile | 1 +
lib
On 4/5/16, Martin Vignali wrote:
> Hello,
>
> Mipmap and ripmap is two way to store several resolution of the picture
> inside an exr file
> The difference between these two mode, is the number of subres level (lot
> more subres in ripmap, than mipmap).
> These files are mainly design to store map
Hi
On Tue, Apr 05, 2016 at 09:03:07PM +0530, Jai Luthra wrote:
> Hi,
>
> I've almost finished my qualfication task for GSoC, and would love some
> input on my work till now.
>
> Currently, the mlp encoder compiles, but does not produce valid
> bitstream (crashes). This is because AVCodec's encod
Hi mentors
Please make sure you volunteer for mentoring any students you consider
to mentor in the web interfaces for
Outreachy (Willing to Mentor" button) and GSoC ("WANT TO MENTOR" button)
Its in no case possible to accept projects without a mentor and even
if it was possible that would make no
Hi Disha
On Tue, Apr 05, 2016 at 06:50:33AM +0530, Disha Singh wrote:
> 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.
[...]
> +static ChannelParams restart_channel_params[MAX_CHANNELS];
> +static De
On Tue, Apr 05, 2016 at 12:00:26PM -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
Hi,
On Tue, Apr 05, 2016 at 10:31:44PM +0200, Michael Niedermayer wrote:
> > Should I squash the commits and send a single patch instead?
>
> a single patch makes more sense for reviewing
Cool. I've attached the squashed patch for review.
> > PS: I noticed Disha Singh is also working on this for
2016-04-05 22:31 GMT+02:00 Paul B Mahol :
> On 4/5/16, Martin Vignali wrote:
> > Hello,
> >
> > Mipmap and ripmap is two way to store several resolution of the picture
> > inside an exr file
> > The difference between these two mode, is the number of subres level (lot
> > more subres in ripmap, t
On Tue, Apr 05, 2016 at 10:45:18PM +0200, Michael Niedermayer wrote:
> Hi Disha
>
> On Tue, Apr 05, 2016 at 06:50:33AM +0530, Disha Singh wrote:
> > 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.
> [.
On Wed, Apr 06, 2016 at 02:55:08AM +0530, Jai Luthra wrote:
> Hi,
>
> On Tue, Apr 05, 2016 at 10:31:44PM +0200, Michael Niedermayer wrote:
> > > Should I squash the commits and send a single patch instead?
> >
> > a single patch makes more sense for reviewing
> Cool. I've attached the squashed pa
On Sat, Apr 02, 2016 at 03:49:12AM +0200, Michael Niedermayer wrote:
> If someone can create a smaller test file (its 2.5Mb) that still has the same
> coverage that is welcome.
> otherwise ill upload the sample attached to the ticket
>
> Signed-off-by: Michael Niedermayer
> ---
> tests/fate/fil
On Wed, Apr 06, 2016 at 02:55:08AM +0530, Jai Luthra wrote:
> Hi,
>
> On Tue, Apr 05, 2016 at 10:31:44PM +0200, Michael Niedermayer wrote:
> > > Should I squash the commits and send a single patch instead?
> >
> > a single patch makes more sense for reviewing
> Cool. I've attached the squashed pa
On Tue, Apr 05, 2016 at 06:50:33AM +0530, Disha Singh wrote:
> 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
> Changelog |1
> configure |1
On Tue, Apr 05, 2016 at 11:06:48PM +0200, Michael Niedermayer wrote:
> On Tue, Apr 05, 2016 at 12:00:26PM -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 copyrig
On Thu, Mar 31, 2016 at 08:29:37PM -0400, Ronald S. Bultje wrote:
> The intent here is similar to colormatrix, but it's LGPLv2.1-or-later
> (instead of GPLv2.0) and supports gamma/chromaticity correction.
> ---
> doc/filters.texi | 183 +++
> libavfilter/Makefile
On 01/04/16 03:27, Amancio Hasty wrote:
> LICENSE.md | 36 +
> MAINTAINERS| 1 +
> configure | 11 ++
> libavcodec/Makefile| 1 +
> libavcodec/allcodecs.c | 2 +
> libavcodec/vc264.c | 389
> +
On Fri, Apr 01, 2016 at 01:02:56AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> tests/fate/filter-video.mak |9 ++
> tests/ref/fate/filter-meta-4560-rotate0 | 259
> +++
> 2 files changed, 268 insertions(+)
> create
> On Apr 5, 2016, at 3:57 PM, Michael Niedermayer
> wrote:
>
> On Tue, Apr 05, 2016 at 11:06:48PM +0200, Michael Niedermayer wrote:
>> On Tue, Apr 05, 2016 at 12:00:26PM -0700, Amancio Hasty wrote:
>>>
On Mar 31, 2016, at 7:27 PM, Amancio Hasty wrote:
I am not a lawyer…
Hello,
can the patchset be applied as it is now? ( I don't want to hurry you,
just reminding :) )
Jan S.
On 04/04/2016 12:06 AM, sebechlebsky...@gmail.com wrote:
From: Jan Sebechlebsky
Adds per slave option 'onfail' to the tee muxer allowing an output to
fail,so other slave outputs can conti
Here's another audio filter. I hinted at this a few months ago, but I found out
that
finishing the last 5% took almost as long as the first 95%. This is an EBU R128
dynamic loudness normalization filter. This filter uses libebur128 v1.1.0[1]
and must be
configured with `--enable-libebur128'. Plea
On Tue, 5 Apr 2016 at 20:39 Michael Niedermayer
wrote:
> On Mon, Apr 04, 2016 at 08:18:47PM +, Kieran Kunhya wrote:
> > 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 Mich
On Wed, Apr 06, 2016 at 01:05:34AM +0200, Clément Bœsch wrote:
> On Fri, Apr 01, 2016 at 01:02:56AM +0200, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > tests/fate/filter-video.mak |9 ++
> > tests/ref/fate/filter-meta-4560-rotate0 | 259
> > +
On Tue, Apr 05, 2016 at 07:17:03PM +0200, Stefano Sabatini wrote:
> On date Saturday 2016-04-02 15:56:55 +0200, Michael Niedermayer encoded:
> > On Sat, Apr 02, 2016 at 12:46:57PM +0200, Stefano Sabatini wrote:
> > > This allows to recognize ID3 packets from the stream type.
> > > ---
> > > libavf
> there are the following build warnings, please fix them
>
> libavcodec/mlpenc.c: In function ‘mlp_encode_init’:
> libavcodec/mlpenc.c:585:5: warning: ‘coded_frame’ is deprecated (declared
> at libavcodec/avcodec.h:2967) [-Wdeprecated-declarations]
> libavcodec/mlpenc.c: In function ‘mlp_encode_fr
> Here's another audio filter. I hinted at this a few months ago, but I found
> out that
> finishing the last 5% took almost as long as the first 95%. This is an EBU
> R128
> dynamic loudness normalization filter. This filter uses libebur128 v1.1.0[1]
> and must be
> configured with `--enable-li
Signed-off-by: James Almer
---
tests/fate/filter-audio.mak | 13 +++--
tests/fate/filter-video.mak | 36 ++--
2 files changed, 25 insertions(+), 24 deletions(-)
diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index b7bc979..b3ed64f 1
Hello Carl,
Thank you for your reply.
>>Did you look at the aresample filter and libswresample?
You mean to say resample filter is required before/after our decoder?
Our audio PCM decoder is expecting signed 16/24 bit. We are getting proper
input to the decoder.
The decoder process the data and f
On Tue, Apr 05, 2016 at 07:01:14PM -0500, Kyle Swanson wrote:
> Here's another audio filter. I hinted at this a few months ago, but I found
> out that
> finishing the last 5% took almost as long as the first 95%. This is an EBU
> R128
> dynamic loudness normalization filter. This filter uses libe
51 matches
Mail list logo
