Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm

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

Re: [FFmpeg-devel] Thirdparty audio codec integration

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

[FFmpeg-devel] [PATCH] fate: fix sample dependencies for fate-{a, v}filter tests

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

Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm

> 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

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

> 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

Re: [FFmpeg-devel] [PATCH] lavf/mpegts: add 0x15 (metadata) entry to the ISO_types array

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

Re: [FFmpeg-devel] [PATCH] fate: Test for Ticket4560

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

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

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

[FFmpeg-devel] [PATCH] avfilter: add loudnorm

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

Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/tee: Handling slave failure in tee muxer

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

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

> 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

Re: [FFmpeg-devel] [PATCH] fate: Test for Ticket4560

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

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

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 >

Re: [FFmpeg-devel] [PATCH] lavfi: new colorspace conversion filter.

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

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

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

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

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

Re: [FFmpeg-devel] [PATCH] fate: Add test for Ticket 2397

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

Re: [FFmpeg-devel] [PATCH] [WIP] Updated MLP encoder - Qualification Task (TrueHD)

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

Re: [FFmpeg-devel] [PATCH] [WIP] Updated MLP encoder - Qualification Task (TrueHD)

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

Re: [FFmpeg-devel] libavcodec/exr : enable support for mipmap/ripmap tile.

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

Re: [FFmpeg-devel] [PATCH] [WIP] Updated MLP encoder - Qualification Task (TrueHD)

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

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

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

[FFmpeg-devel] [GSoC][Outreachy] mentoring

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

Re: [FFmpeg-devel] [PATCH] [WIP] Updated MLP encoder - Qualification Task (TrueHD)

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

Re: [FFmpeg-devel] libavcodec/exr : enable support for mipmap/ripmap tile.

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

[FFmpeg-devel] [PATCH] avfilter: add remap filter

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

[FFmpeg-devel] [PATCH] avformat: add aix demuxer

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 +

[FFmpeg-devel] libavcodec/exr : enable support for mipmap/ripmap tile.

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

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

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 >

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

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

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

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

Re: [FFmpeg-devel] [PATCH] lavf/mpegts: add 0x15 (metadata) entry to the ISO_types array

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

[FFmpeg-devel] [PATCH] [WIP] Updated MLP encoder - Qualification Task (TrueHD)

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

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

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 ___

Re: [FFmpeg-devel] Thirdparty audio codec integration

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

[FFmpeg-devel] Thirdparty audio codec integration

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

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

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

Re: [FFmpeg-devel] [PATCH]lavf/gsmdec: Add a probe function

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

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

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

Re: [FFmpeg-devel] [PATCH]lavf/gsmdec: Add a probe function

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

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

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

Re: [FFmpeg-devel] [PATCH]lavf/gsmdec: Add a probe function

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

Re: [FFmpeg-devel] [PATCH]lavf/rawenc: Add a gsm muxer

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

Re: [FFmpeg-devel] New filter: remap (usecase is fisheye video)

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

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

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

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

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

Re: [FFmpeg-devel] New filter: remap (usecase is fisheye video)

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

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

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:

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

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