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 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/ uploaded [...] -- 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 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: Nicolas George > Signed-off-by: Derek Buitenhuis > --- > libavcodec/libxvid.c | 40 > 1 file changed, 40 insertions(+) should be ok fro ffmpegs side, i dont know the xvid API thx [..] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 accept more than one input stream instead of file names. 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 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 GPLv2 (which is possibly the most often used license
for FFmpeg but in any case a possible license) is not
compatible with the AGPL.
> +enabled libopenjpeg && { check_lib openjpeg-2.1/openjpeg.h
> opj_version -lopenjp2 -ldl ||
This is unneeded for libopenjpeg and therefore not acceptable
afaict. Is Grok part of any major distribution?
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 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 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 accept more than one input > stream instead of file names. > > Carl Eugen > > ___ > 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]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.
> >
> > Please comment, Carl Eugen
>
> breaks fate-gif-deal somehow
Cool effect, new muxer patch attached.
Thank you, Carl Eugen
diff --git a/libavformat/Makefile b/libavformat/Makefile
index a54e6cb..77b6730 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -180,6 +180,7 @@ OBJS-$(CONFIG_FSB_DEMUXER) += fsb.o
OBJS-$(CONFIG_GIF_MUXER) += gif.o
OBJS-$(CONFIG_GIF_DEMUXER) += gifdec.o
OBJS-$(CONFIG_GSM_DEMUXER) += gsmdec.o
+OBJS-$(CONFIG_GSM_MUXER) += rawenc.o
OBJS-$(CONFIG_GXF_DEMUXER) += gxf.o
OBJS-$(CONFIG_GXF_MUXER) += gxfenc.o audiointerleave.o
OBJS-$(CONFIG_G722_DEMUXER) += g722.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 94f258d..80f6d28 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -138,7 +138,7 @@ void av_register_all(void)
REGISTER_DEMUXER (G729, g729);
REGISTER_DEMUXER (GENH, genh);
REGISTER_MUXDEMUX(GIF, gif);
-REGISTER_DEMUXER (GSM, gsm);
+REGISTER_MUXDEMUX(GSM, gsm);
REGISTER_MUXDEMUX(GXF, gxf);
REGISTER_MUXDEMUX(H261, h261);
REGISTER_MUXDEMUX(H263, h263);
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index 358ee4e..14ba9fb 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -193,6 +193,20 @@ AVOutputFormat ff_g723_1_muxer = {
};
#endif
+#if CONFIG_GSM_MUXER
+AVOutputFormat ff_gsm_muxer = {
+.name = "gsm",
+.long_name = NULL_IF_CONFIG_SMALL("raw GSM"),
+.mime_type = "audio/x-gsm",
+.extensions= "gsm",
+.audio_codec = AV_CODEC_ID_GSM,
+.video_codec = AV_CODEC_ID_NONE,
+.write_header = force_one_stream,
+.write_packet = ff_raw_write_packet,
+.flags = AVFMT_NOTIMESTAMPS,
+};
+#endif
+
#if CONFIG_H261_MUXER
AVOutputFormat ff_h261_muxer = {
.name = "h261",
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 ___ 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
> > 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 just in case? Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 hard or too soft? It seems it breaks fate. > > Carl Eugen > > ___ > 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
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 terrestrial (OTA) broadcast? > Should we just send one to every citizen on earth just in case? Permanently overlay a text rendering of the AGPL over the channel. No really, why do you want your lib to be AGPL? It only causes problems. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 interesting effect. +REGISTER_MUXDEMUX(GSM, gsm); REGISTER_DEMUXER (GENH, genh); REGISTER_MUXDEMUX(GIF, gif); REGISTER_DEMUXER (GSM, gsm); (Note the two gsm demuxers) 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
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 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 just in case? > > Permanently overlay a text rendering of the AGPL over the channel. > > No really, why do you want your lib to be AGPL? It only causes problems. I want to ++ this, because it will get ignored. Aaron: we really encourage you to work on j2k, but we also encourage you to do so with a more liberal license (e.g. GPL, or possibly even LGPL) for the final product. AGPL is a bloody pain. Why do you want AGPL so much? Did the so-called loophole hurt you personally in some way? Or is this all theoretical? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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 AV_SAMPLE_FMT_FLT. But it is not working. Is there any other parameter/flags need to update so that i should get output as float using ffmpeg? Please let me know if you need further info. Regards, Suresh. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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 api.
I have to update it, any pointers for doing this? Should I just look at
other encoders and try to follow how they implement the encode_frame
function?
Also, I still have to make the changes in the mallocs suggested by my
mentor on IRC.
I'll send the updated patches within a week.
Should I squash the commits and send a single patch instead?
Cheers,
Jai Luthra
PS: I noticed Disha Singh is also working on this for outreachy. Is it
fine if two applicants work on the same project through different
programs over the summer?
From 4ed2b13f7b263aaca0aa0caea7153aa64785948a Mon Sep 17 00:00:00 2001
From: Jai Luthra
Date: Wed, 2 Mar 2016 23:08:41 +0530
Subject: [PATCH 1/9] mlpenc: Add ramiro's work
Add the mlp encoder written by Ramiro Polla
https://github.com/ramiropolla/soc/blob/master/mlp/mlpenc.c
Signed-off-by: Jai Luthra
---
libavcodec/mlpenc.c | 2422 +++
1 file changed, 2422 insertions(+)
create mode 100644 libavcodec/mlpenc.c
diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
new file mode 100644
index 000..70cb7d8
--- /dev/null
+++ b/libavcodec/mlpenc.c
@@ -0,0 +1,2422 @@
+/**
+ * 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 "dsputil.h"
+#include "lpc.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 stage.
+
+uint8_t noise_shift; ///< The left shift applied to random noise in 0x31ea substreams.
+uint32_tnoisegen_seed; ///< The current seed value for the pseudorandom noise generator(s).
+
+int data_check_present; ///< Set if the substream contains extra info to check the size of VLC blocks.
+
+int32_t lossless_check_data; ///< XOR of all output samples
+
+uint8_t max_huff_lsbs; ///< largest huff_lsbs
+uint8_t max_output_bits; ///< largest output bit-depth
+} RestartHeader;
+
+typedef struct {
+uint8_t count; ///< number of matrices to apply
+
+uint8_t outch[MAX_MATRICES];///< output channel for each matrix
+int32_t forco[MAX_MATRICES][MAX_CHANNELS+2];///< forward coefficients
+int32_t coeff[MAX_MATRICES][MAX_CHANNELS+2];///< decoding coefficients
+uint8_t fbits[MAX_CHANNELS];///< fraction bits
+
+int8_t shift[MAX_CHANNELS];///< Left shift to apply to decoded PCM values to get final 24-bit output.
+} MatrixParams;
+
+typedef struct {
+uint16_tblocksize; ///< number of PCM samples in current audio block
+uint8_t quant_step_size[MAX_CHANNELS]; ///< left shift to apply to Huffman-decoded residuals
+
+MatrixParamsmatrix_params;
+
+uint8_t param_presence_flags; ///< Bitmask of which parameter sets are conveyed in a decoding parameter block.
+#define PARAM_PRESENCE_FLAGS(1 << 8)
+
+#define PARAMS_DEFAULT (0xFF)
+#define PARAM_BLOCKSIZE (1 << 7)
+#define PARAM_MATRIX(1 << 6)
+#define PARAM_OUTSHIFT (1 << 5)
+#define PARAM_QUANTSTEP (1 << 4)
+#define PARAM_FIR (1 << 3)
+#define PARAM_IIR (1 << 2)
+#define PARAM_HUFFOFFSET(1 << 1)
+#define PARAM_PRESENT (1 << 0)
+
+} DecodingParams;
+
+typedef struct BestOffset {
+int16_t offset;
+int bitcount;
+int lsb_bits;
+int16_t
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 tickets/2579/old_klv_data_stream.mpg Where/how I can find the sample? > "breaks" in the sense of detecting the klv stuff as id3 -- FFmpeg = Fundamental and Fascinating Mastering Ponderous Easy God ___ 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
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 fruitless discussion including the misunderstandings. I wouldn't call it "mistake" but rather a difference in opinion, but otherwise +1. In my view it is "closing a loophole by throwing your users under the bus", and while the license is very vague in any reading of it the effectiveness of closing the loophole seems proportional to the throwing under the bus... ___ 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
> 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 OMX_SKIP64BIT >>> +#include "bcm_host.h" >>> +#include "ilclient.h" >>> +#inclu
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 > > > 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 i think nothing in the fate samples has been compared to any spec [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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 samples, it seems that mipmap and ripmap exr
file, store the full res tiles before subres tiles.
So the actual way of decoding tile, works fine with mipmap and ripmap (only
calc the full res tile count), run decode_block for theses tile.
So i think the patch in attach works fine for mipmap and ripmap.
I also ignore now, the tile round mode, because this value, is only, for
detecting tile count in subres level
This patch decode fine all Multiresolution tile files of the official
libray :
http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz
except : WavyLinesSphere.exr
But this file, is in fact not a Multiresolution file (exrheader information
show that it's a scanline PIZ).
And i suppose the decoding error, is related, to ticket
https://trac.ffmpeg.org/ticket/3932
Comments welcome
Martin
Jokyo Images
From 0418ccbdae5a94867ac2e7805f1311f88c434d8f Mon Sep 17 00:00:00 2001
From: Martin Vignali
Date: Tue, 5 Apr 2016 21:17:51 +0200
Subject: [PATCH] libavcodec/exr : enable mipmap, ripmap decoding
---
libavcodec/exr.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index b542831..2763126 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -73,11 +73,13 @@ enum ExrTileLevelMode {
EXR_TILE_LEVEL_ONE,
EXR_TILE_LEVEL_MIPMAP,
EXR_TILE_LEVEL_RIPMAP,
+EXR_TILE_LEVEL_UNKNOWN,
};
enum ExrTileLevelRound {
EXR_TILE_ROUND_UP,
EXR_TILE_ROUND_DOWN,
+EXR_TILE_ROUND_UNKNOWN,
};
typedef struct EXRChannel {
@@ -1011,9 +1013,9 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
if (data_size <= 0 || data_size > buf_size)
return AVERROR_INVALIDDATA;
-if (tileLevelX || tileLevelY) { /* tile of low resolution (Mipmap, rimmap) */
-av_log(s->avctx, AV_LOG_ERROR, "Wrong Tile level %i / %i.\n", tileLevelX, tileLevelY);
-return AVERROR_INVALIDDATA;
+if (tileLevelX || tileLevelY) { /* tile level, is not the full res level */
+avpriv_report_missing_feature(s->avctx, "Subres tile before full res tile");
+return AVERROR_PATCHWELCOME;
}
line = s->tile_attr.ySize * tileY;
@@ -1490,13 +1492,13 @@ static int decode_header(EXRContext *s)
s->tile_attr.level_mode = tileLevel & 0x0f;
s->tile_attr.level_round = (tileLevel >> 4) & 0x0f;
-if (s->tile_attr.level_mode != EXR_TILE_LEVEL_ONE) {
+if (s->tile_attr.level_mode >= EXR_TILE_LEVEL_UNKNOWN){
avpriv_report_missing_feature(s->avctx, "Tile level mode %d",
s->tile_attr.level_mode);
return AVERROR_PATCHWELCOME;
}
-if (s->tile_attr.level_round != EXR_TILE_ROUND_UP) {
+if (s->tile_attr.level_round >= EXR_TILE_ROUND_UNKNOWN) {
avpriv_report_missing_feature(s->avctx, "Tile level round %d",
s->tile_attr.level_round);
return AVERROR_PATCHWELCOME;
--
1.9.3 (Apple Git-50)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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 +
libavformat/aixdec.c | 129 +++
libavformat/allformats.c | 1 +
3 files changed, 131 insertions(+)
create mode 100644 libavformat/aixdec.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 0b8388d..5515b84 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -82,6 +82,7 @@ OBJS-$(CONFIG_AFC_DEMUXER) += afc.o
OBJS-$(CONFIG_AIFF_DEMUXER) += aiffdec.o pcm.o isom.o \
mov_chan.o
OBJS-$(CONFIG_AIFF_MUXER)+= aiffenc.o isom.o id3v2enc.o
+OBJS-$(CONFIG_AIX_DEMUXER) += aixdec.o
OBJS-$(CONFIG_AMR_DEMUXER) += amr.o
OBJS-$(CONFIG_AMR_MUXER) += amr.o
OBJS-$(CONFIG_ANM_DEMUXER) += anm.o
diff --git a/libavformat/aixdec.c b/libavformat/aixdec.c
new file mode 100644
index 000..83d3dea
--- /dev/null
+++ b/libavformat/aixdec.c
@@ -0,0 +1,129 @@
+/*
+ * AIX demuxer
+ * Copyright (c) 2016 Paul B Mahol
+ *
+ * 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 "libavutil/intreadwrite.h"
+#include "avformat.h"
+#include "internal.h"
+
+typedef struct AIXContext {
+uint64_t segment_offset;
+} AIXContext;
+
+static int aix_probe(AVProbeData *p)
+{
+if (AV_RL32(p->buf) != MKTAG('A','I','X','F') ||
+AV_RB32(p->buf + 8) != 0x0114 ||
+AV_RB32(p->buf + 12) != 0x0800)
+return 0;
+
+return AVPROBE_SCORE_MAX;
+}
+
+static int aix_read_header(AVFormatContext *s)
+{
+AIXContext *aix = s->priv_data;
+unsigned nb_streams, first_offset, segment_count;
+unsigned stream_list_offset;
+unsigned segment_list_offset = 0x20;
+unsigned segment_list_entry_size = 0x10;
+unsigned size;
+int i;
+
+avio_skip(s->pb, 4);
+first_offset = avio_rb32(s->pb) + 8;
+avio_skip(s->pb, 16);
+segment_count = avio_rb16(s->pb);
+if (segment_count == 0)
+return AVERROR_INVALIDDATA;
+avio_seek(s->pb, segment_list_offset, SEEK_SET);
+aix->segment_offset = avio_rb32(s->pb);
+stream_list_offset = segment_list_offset + segment_list_entry_size * segment_count + 0x10;
+if (stream_list_offset >= first_offset)
+return AVERROR_INVALIDDATA;
+avio_seek(s->pb, stream_list_offset, SEEK_SET);
+nb_streams = avio_r8(s->pb);
+if (nb_streams == 0)
+return AVERROR_INVALIDDATA;
+avio_skip(s->pb, 7);
+for (i = 0; i < nb_streams; i++) {
+AVStream *st = avformat_new_stream(s, NULL);
+
+if (!st)
+return AVERROR(ENOMEM);
+st->codec->codec_type = AVMEDIA_TYPE_AUDIO;
+st->codec->codec_id= AV_CODEC_ID_ADPCM_ADX;
+st->codec->sample_rate = avio_rb32(s->pb);
+st->codec->channels= avio_r8(s->pb);
+avpriv_set_pts_info(st, 64, 1, st->codec->sample_rate);
+avio_skip(s->pb, 3);
+}
+
+avio_seek(s->pb, first_offset, SEEK_SET);
+for (i = 0; i < nb_streams; i++) {
+if (avio_rl32(s->pb) != MKTAG('A','I','X','P'))
+return AVERROR_INVALIDDATA;
+size = avio_rb32(s->pb);
+if (size <= 8)
+return AVERROR_INVALIDDATA;
+avio_skip(s->pb, 8);
+ff_get_extradata(s->streams[i]->codec, s->pb, size - 8);
+}
+
+return 0;
+}
+
+static int aix_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+int size, ret, index, duration, chunk;
+int64_t pos;
+
+pos = avio_tell(s->pb);
+chunk = avio_rl32(s->pb);
+if (chunk == MKTAG('A','I','X','E')) {
+return AVERROR_EOF;
+} else if (chunk != MKTAG('A','I','X','P')) {
+return AVERROR_INVALIDDATA;
+}
+size = avio_rb32(s->pb);
+if (size <= 8)
+return AVERROR_INVALIDDATA;
+index = avio_r8(s->pb);
+if (avio_r8(s->pb) != s->nb_streams || index >= s->nb_streams)
+return AVERROR_INVALIDDATA;
+duration = avio_rb16(s->pb);
+avio_skip(s->pb, 4);
+
+ret = av_get_packet(s->pb, pkt, size - 8);
+pkt->s
[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 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_remap.c | 337 +++
4 files changed, 347 insertions(+)
create mode 100644 libavfilter/vf_remap.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 592fc24..8eb683c 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10419,6 +10419,14 @@ less than @code{0}, the filter will try to use a good random seed on a
best effort basis.
@end table
+@section remap
+
+Remap pixels using 2nd: Xmap and 3rd: Ymap input video stream.
+
+Destination pixel at position (X, Y) will be picked from source (x, y) position
+where x = Xmap(X, Y) and y = Ymap(X, Y). If mapping values are out of range zero
+value for pixel will be used for destination pixel.
+
@section removegrain
The removegrain filter is a spatial denoiser for progressive video.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index b6e1999..3a3de48 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -224,6 +224,7 @@ OBJS-$(CONFIG_PULLUP_FILTER) += vf_pullup.o
OBJS-$(CONFIG_QP_FILTER) += vf_qp.o
OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
OBJS-$(CONFIG_REALTIME_FILTER) += f_realtime.o
+OBJS-$(CONFIG_REMAP_FILTER) += vf_remap.o framesync.o
OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o
OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o lavfutils.o vf_removelogo.o
OBJS-$(CONFIG_REPEATFIELDS_FILTER) += vf_repeatfields.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 5c18fd1..b6f4a2c 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -244,6 +244,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(QP, qp, vf);
REGISTER_FILTER(RANDOM, random, vf);
REGISTER_FILTER(REALTIME, realtime, vf);
+REGISTER_FILTER(REMAP, remap, vf);
REGISTER_FILTER(REMOVEGRAIN,removegrain,vf);
REGISTER_FILTER(REMOVELOGO, removelogo, vf);
REGISTER_FILTER(REPEATFIELDS, repeatfields, vf);
diff --git a/libavfilter/vf_remap.c b/libavfilter/vf_remap.c
new file mode 100644
index 000..c6639fe
--- /dev/null
+++ b/libavfilter/vf_remap.c
@@ -0,0 +1,337 @@
+/*
+ * Copyright (c) 2016 Floris Sluiter
+ *
+ * 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
+ * Pixel remap filter
+ * This filter copies pixel by pixel a source frame to a target frame.
+ * It remaps the pixels to a new x,y destination based on two files ymap/xmap.
+ * Map files are passed as a parameter and are in PGM format (P2 or P5),
+ * where the values are y(rows)/x(cols) coordinates of the source_frame.
+ * The *target* frame dimension is based on mapfile dimensions: specified in the
+ * header of the mapfile and reflected in the number of datavalues.
+ * Dimensions of ymap and xmap must be equal. Datavalues must be positive or zero.
+ * Any datavalue in the ymap or xmap which value is higher
+ * then the *source* frame height or width is silently ignored, leaving a
+ * blank/chromakey pixel. This can safely be used as a feature to create overlays.
+ *
+ * Algorithm digest:
+ * Target_frame[y][x] = Source_frame[ ymap[y][x] ][ [xmap[y][x] ];
+ */
+
+#include "libavutil/imgutils.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "framesync.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct RemapContext {
+const AVClass *class;
+int nb_planes;
+int nb_components;
+int step;
+FFFrameSync fs;
+
+void (*remap)(struct RemapContext *s, const AVFrame *in,
+ const AVFrame *xin, const AVFrame *yin,
+ AVFrame *out);
+} RemapContext;
+
+#define OFFSET(x) offsetof(RemapContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption r
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 mainly design to store maps for 3D render. > > After some tests on official samples, it seems that mipmap and ripmap exr > file, store the full res tiles before subres tiles. > So the actual way of decoding tile, works fine with mipmap and ripmap (only > calc the full res tile count), run decode_block for theses tile. > > So i think the patch in attach works fine for mipmap and ripmap. > > I also ignore now, the tile round mode, because this value, is only, for > detecting tile count in subres level > > This patch decode fine all Multiresolution tile files of the official > libray : > http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz > > except : WavyLinesSphere.exr > But this file, is in fact not a Multiresolution file (exrheader information > show that it's a scanline PIZ). > And i suppose the decoding error, is related, to ticket > https://trac.ffmpeg.org/ticket/3932 > > > Comments welcome Shouldn't there be option use lower resolution tiles? > > Martin > Jokyo Images > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 encode2 function prototype has > changed, but the mlp_encode_frame assumes the old api. > > I have to update it, any pointers for doing this? Should I just look at > other encoders and try to follow how they implement the encode_frame > function? > > Also, I still have to make the changes in the mallocs suggested by my > mentor on IRC. > I'll send the updated patches within a week. > > Should I squash the commits and send a single patch instead? a single patch makes more sense for reviewing > > Cheers, > Jai Luthra > > PS: I noticed Disha Singh is also working on this for outreachy. Is it > fine if two applicants work on the same project through different > programs over the summer? It is possible AFAIK, but its unlikely we will accept 2 students doing exactly the same So far noone has passed the qualfication task for this project though [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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 sense
Thanks
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch]Qualification task for TrueHD encoder
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 DecodingParams restart_decoding_params[MAX_SUBSTREAMS];
> +static BestOffset restart_best_offset[NUM_CODEBOOKS] = {{0}};
"non const" statics are not allowed as they break with muliple
encoder instances
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is dangerous to be right in matters on which the established authorities
are wrong. -- 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] 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 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, B
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 for outreachy. Is it
> > fine if two applicants work on the same project through different
> > programs over the summer?
>
> It is possible AFAIK, but its unlikely we will accept 2 students doing
> exactly the same
> So far noone has passed the qualfication task for this project though
I'll complete it and submit for final evaluation within a week.
Sorry for being late, I was busy with college studies but I'll be completely
free during the coding period.
Cheers,
Jai Luthra
From 6190f169d87523af12c9a5187dc3a8019d066c3f Mon Sep 17 00:00:00 2001
From: Jai Luthra
Date: Wed, 2 Mar 2016 23:08:41 +0530
Subject: [PATCH] mlpenc: Add compilable mlp encoder
Signed-off-by: Jai Luthra
---
libavcodec/Makefile|1 +
libavcodec/alacenc.c |4 +-
libavcodec/allcodecs.c |2 +-
libavcodec/flacenc.c |3 +-
libavcodec/lpc.c | 13 +-
libavcodec/lpc.h |2 +-
libavcodec/mlp.c | 14 +
libavcodec/mlp.h | 38 +
libavcodec/mlpenc.c| 2426
libavcodec/ra144enc.c |2 +-
10 files changed, 2495 insertions(+), 10 deletions(-)
create mode 100644 libavcodec/mlpenc.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 8e6563c..e03514a 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
OBJS-$(CONFIG_MMVIDEO_DECODER) += mmvideo.o
OBJS-$(CONFIG_MOTIONPIXELS_DECODER)+= motionpixels.o
OBJS-$(CONFIG_MOVTEXT_DECODER) += movtextdec.o ass.o
diff --git a/libavcodec/alacenc.c b/libavcodec/alacenc.c
index c80c887..303fa26 100644
--- a/libavcodec/alacenc.c
+++ b/libavcodec/alacenc.c
@@ -38,6 +38,7 @@
#define DEFAULT_MAX_PRED_ORDER6
#define DEFAULT_MIN_PRED_ORDER4
#define ALAC_MAX_LPC_PRECISION9
+#define ALAC_MIN_LPC_SHIFT0
#define ALAC_MAX_LPC_SHIFT9
#define ALAC_CHMODE_LEFT_RIGHT0
@@ -171,7 +172,8 @@ static void calc_predictor_params(AlacEncodeContext *s, int ch)
s->max_prediction_order,
ALAC_MAX_LPC_PRECISION, coefs, shift,
FF_LPC_TYPE_LEVINSON, 0,
- ORDER_METHOD_EST, ALAC_MAX_LPC_SHIFT, 1);
+ ORDER_METHOD_EST, ALAC_MIN_LPC_SHIFT,
+ ALAC_MAX_LPC_SHIFT, 1);
s->lpc[ch].lpc_order = opt_order;
s->lpc[ch].lpc_quant = shift[opt_order-1];
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 3214e35..352ffae 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/flacenc.c b/libavcodec/flacenc.c
index a91ed19..e0f0880 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -43,6 +43,7 @@
#define MAX_PARTITION_ORDER 8
#define MAX_PARTITIONS (1 << MAX_PARTITION_ORDER)
#define MAX_LPC_PRECISION 15
+#define MIN_LPC_SHIFT 0
#define MAX_LPC_SHIFT 15
enum CodingMode {
@@ -883,7 +884,7 @@ static int encode_residual_ch(FlacEncodeContext *s, int ch)
opt_order = ff_lpc_calc_coefs(&s->lpc_ctx, smp, n, min_order, max_order,
s->options.lpc_coeff_precision, coefs, shift, s->options.lpc_type,
s->options.lpc_passes, omethod,
- MAX_LPC_SHIFT, 0);
+ MIN_LPC_SHIFT, MAX_LPC_SHIFT, 0);
if (omethod == ORDER_METHOD_2LEVEL ||
omethod == ORDER_METHOD_4LEVEL ||
diff --git a/libavcodec/lpc.c b/libavcodec/lpc.c
index 052aeaa..f8da1e1 100644
--- a/libavcodec/lpc.c
+++ b/libavcodec/lpc.c
@@ -93,7 +93,8 @@ static void lpc_compute_autocorr_c(const double *data, int len, int lag,
* Quantize LPC coefficients
*/
static void quantize_lpc_coefs(double *lpc_in, int order, int precision,
- int32_t *lpc_out, int *shift, int max_shift, int zero_shift)
+
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 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 samples, it seems that mipmap and ripmap exr > > file, store the full res tiles before subres tiles. > > So the actual way of decoding tile, works fine with mipmap and ripmap > (only > > calc the full res tile count), run decode_block for theses tile. > > > > So i think the patch in attach works fine for mipmap and ripmap. > > > > I also ignore now, the tile round mode, because this value, is only, for > > detecting tile count in subres level > > > > This patch decode fine all Multiresolution tile files of the official > > libray : > > > http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz > > > > except : WavyLinesSphere.exr > > But this file, is in fact not a Multiresolution file (exrheader > information > > show that it's a scanline PIZ). > > And i suppose the decoding error, is related, to ticket > > https://trac.ffmpeg.org/ticket/3932 > > > > > > Comments welcome > > Shouldn't there be option use lower resolution tiles? > > It can be a future feature. I prefer for now, focus on adding support for kinds of exr who can't be decode at all. Martin Vignali Jokyo Images ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch]Qualification task for TrueHD encoder
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.
> [...]
>
> > +static ChannelParams restart_channel_params[MAX_CHANNELS];
> > +static DecodingParams restart_decoding_params[MAX_SUBSTREAMS];
> > +static BestOffset restart_best_offset[NUM_CODEBOOKS] = {{0}};
>
> "non const" statics are not allowed as they break with muliple
> encoder instances
that is if they would change, if they do not change they should be
const
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 patch for review.
>
> > > PS: I noticed Disha Singh is also working on this for outreachy. Is it
> > > fine if two applicants work on the same project through different
> > > programs over the summer?
> >
> > It is possible AFAIK, but its unlikely we will accept 2 students doing
> > exactly the same
> > So far noone has passed the qualfication task for this project though
> I'll complete it and submit for final evaluation within a week.
> Sorry for being late, I was busy with college studies but I'll be completely
> free during the coding period.
>
> Cheers,
> Jai Luthra
[...]
> +static ChannelParams restart_channel_params[MAX_CHANNELS];
> +static DecodingParams restart_decoding_params[MAX_SUBSTREAMS];
> +static BestOffset restart_best_offset[NUM_CODEBOOKS] = {{0}};
"non const" statics are not allowed as they break with muliple
encoder instances
that is if they would change, if they do not change they should be
const
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 > --- > tests/fate/filter-video.mak|4 + > tests/filtergraphs/overlay-2397|2 + > tests/ref/fate/filter-overlay-2397 | 848 > > 3 files changed, 854 insertions(+) > create mode 100644 tests/filtergraphs/overlay-2397 > create mode 100644 tests/ref/fate/filter-overlay-2397 > > diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak > index 7fb7677..5fd6ae0 100644 > --- a/tests/fate/filter-video.mak > +++ b/tests/fate/filter-video.mak > @@ -304,6 +304,10 @@ FATE_FILTER-$(call ALLYES, SMJPEG_DEMUXER MJPEG_DECODER > PERMS_FILTER HQDN3D_FILT > fate-filter-hqdn3d-sample: tests/data/filtergraphs/hqdn3d > fate-filter-hqdn3d-sample: CMD = framecrc -idct simple -i > $(TARGET_SAMPLES)/smjpeg/scenwin.mjpg -filter_complex_script > $(TARGET_PATH)/tests/data/filtergraphs/hqdn3d -an > > +FATE_FILTER-$(call ALLYES, MATROSKA_DEMUXER OVERLAY_FILTER H264_DECODER > DVDSUB_DECODER) += fate-filter-overlay-2397 > +fate-filter-overlay-2397: tests/data/filtergraphs/overlay-2397 > +fate-filter-overlay-2397: CMD = framecrc -flags bitexact -i > $(TARGET_SAMPLES)/filter/242_4.mkv -filter_complex_script > $(TARGET_PATH)/tests/data/filtergraphs/overlay-2397 -c:a copy > + is it relevant to include the audio? also i'd better mention "dvdsub" than the ticket id (commit message should still contain the reference to the ticket though). thanks -- 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] [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 patch for review. > > > > PS: I noticed Disha Singh is also working on this for outreachy. Is it > > > fine if two applicants work on the same project through different > > > programs over the summer? > > > > It is possible AFAIK, but its unlikely we will accept 2 students doing > > exactly the same > > So far noone has passed the qualfication task for this project though > I'll complete it and submit for final evaluation within a week. > Sorry for being late, I was busy with college studies but I'll be completely > free during the coding period. > > Cheers, > Jai Luthra > Makefile|1 > alacenc.c |4 > allcodecs.c |2 > flacenc.c |3 > lpc.c | 13 > lpc.h |2 > mlp.c | 14 > mlp.h | 38 > mlpenc.c| 2426 > > ra144enc.c |2 > 10 files changed, 2495 insertions(+), 10 deletions(-) > ab5595eae435284664cd4aea4d2f39adbe72fa8b > 0001-mlpenc-Add-compilable-mlp-encoder.patch > From 6190f169d87523af12c9a5187dc3a8019d066c3f Mon Sep 17 00:00:00 2001 > From: Jai Luthra > Date: Wed, 2 Mar 2016 23:08:41 +0530 > Subject: [PATCH] mlpenc: Add compilable mlp encoder libavcodec/mlpenc.c: In function ‘write_access_unit’: libavcodec/mlpenc.c:1226:14: warning: variable ‘buf2’ set but not used [-Wunused-but-set-variable] libavcodec/mlpenc.c: At top level: libavcodec/mlpenc.c:2422:5: warning: initialization from incompatible pointer type [enabled by default] libavcodec/mlpenc.c:2422:5: warning: (near initialization for ‘ff_mlp_encoder.encode2’) [enabled by default] libavcodec/mlpenc.c:682:21: warning: ‘bitcount_restart_header’ defined but not used [-Wunused-function] libavcodec/mlpenc.c:726:21: warning: ‘bitcount_decoding_params’ defined but not used [-Wunused-function] libavcodec/mlpenc.c: In function ‘analyze_sample_buffer’: libavcodec/mlpenc.c:2110:19: warning: ‘best_codebook’ may be used uninitialized in this function [-Wuninitialized] libavcodec/mlpenc.c:2059:22: note: ‘best_codebook’ was declared here all build warnings should be fixed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 > libavcodec/Makefile|1 > libavcodec/allcodecs.c |2 > libavcodec/mlp.h |4 > libavcodec/mlpenc.c| 2496 > + > 6 files changed, 2504 insertions(+), 1 deletion(-) > 6bf664edf111d3a5b7e4010b30e04bbbf37a715e 0001-MLP-ENCODER.patch > From 9ab9819c2e2bb0759944a69204918fad10102ef1 Mon Sep 17 00:00:00 2001 > From: dinux5 > Date: Mon, 4 Apr 2016 08:41:56 +0530 > Subject: [PATCH] MLP 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 ‘mlp_encode_frame’: libavcodec/mlpenc.c:2369:5: warning: ‘coded_frame’ is deprecated (declared at libavcodec/avcodec.h:2967) [-Wdeprecated-declarations] libavcodec/mlpenc.c: In function ‘mlp_encode_close’: libavcodec/mlpenc.c:2469:5: warning: ‘coded_frame’ is deprecated (declared at libavcodec/avcodec.h:2967) [-Wdeprecated-declarations] libavcodec/mlpenc.c: In function ‘analyze_sample_buffer’: libavcodec/mlpenc.c:2141:19: warning: ‘best_codebook’ may be used uninitialized in this function [-Wuninitialized] libavcodec/mlpenc.c:2089:22: note: ‘best_codebook’ was declared here [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein 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
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 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
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 | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/colorspacedsp.c | 130 +
> libavfilter/colorspacedsp.h | 51 ++
> libavfilter/colorspacedsp_template.c | 256 ++
> libavfilter/vf_colorspace.c | 909
> +++
note: don't forget Changelog and minor lavfi bump
note2: sorry in advance if my comments aren't very deeply related to the
algorithms themselves.
[...]
> +#include "colorspacedsp.h"
> +
> +#define SS_W 0
> +#define SS_H 0
> +
> +#define BIT_DEPTH 8
> +#include "colorspacedsp_template.c"
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 10
> +#include "colorspacedsp_template.c"
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 12
> +#include "colorspacedsp_template.c"
> +
> +#undef SS_W
> +#undef SS_H
> +
> +#define SS_W 1
> +#define SS_H 0
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 8
> +#include "colorspacedsp_template.c"
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 10
> +#include "colorspacedsp_template.c"
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 12
> +#include "colorspacedsp_template.c"
> +
> +#undef SS_W
> +#undef SS_H
> +
> +#define SS_W 1
> +#define SS_H 1
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 8
> +#include "colorspacedsp_template.c"
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 10
> +#include "colorspacedsp_template.c"
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 12
> +#include "colorspacedsp_template.c"
> +
Note: a cleaner way to do this (IMO) is to do put the settings into the
template file, and do something like:
#define TEMPLATE_444
#include "colorspacedsp_template.c"
#undef TEMPLATE_444
#define TEMPLATE_422
#include "colorspacedsp_template.c"
#undef TEMPLATE_422
#define TEMPLATE_420
#include "colorspacedsp_template.c"
#undef TEMPLATE_420
it's simpler for the caller, and in the template you see the exact
settings in use for each "profile".
See libswresample/rematrix{,_template}.c for a complete example.
[...]
> +typedef void (*yuv2rgb_fn)(int16_t *rgb[3], ptrdiff_t rgb_stride,
> + uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
> + int w, int h, const int16_t
> yuv2rgb_coeffs[3][3][8],
> + const int16_t yuv_offset[8]);
> +typedef void (*rgb2yuv_fn)(uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
> + int16_t *rgb[3], ptrdiff_t rgb_stride,
> + int w, int h, const int16_t
> rgb2yuv_coeffs[3][3][8],
> + const int16_t yuv_offset[8]);
> +typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], ptrdiff_t yuv_out_stride[3],
> + uint8_t *yuv_in[3], ptrdiff_t yuv_in_stride[3],
> + int w, int h, const int16_t
> yuv2yuv_coeffs[3][3][8],
> + const int16_t yuv_offset[2][8]);
I suppose you didn't make use of const for the input because of the
pain of the multiple dimensions?
uint8_t * const in[N] doesn't do the trick?
[...]
> +static void fn(yuv2rgb)(int16_t *rgb[3], ptrdiff_t rgb_stride,
> +uint8_t *_yuv[3], ptrdiff_t yuv_stride[3],
> +int w, int h, const int16_t yuv2rgb_coeffs[3][3][8],
> +const int16_t yuv_offset[8])
> +{
> +pixel **yuv = (pixel **) _yuv;
> +const pixel *yuv0 = yuv[0], *yuv1 = yuv[1], *yuv2 = yuv[2];
> +int16_t *rgb0 = rgb[0], *rgb1 = rgb[1], *rgb2 = rgb[2];
> +int y, x;
> +int cy = yuv2rgb_coeffs[0][0][0];
> +int crv = yuv2rgb_coeffs[0][2][0];
> +int cgu = yuv2rgb_coeffs[1][1][0];
> +int cgv = yuv2rgb_coeffs[1][2][0];
> +int cbu = yuv2rgb_coeffs[2][1][0];
> +int sh = BIT_DEPTH - 1;
> +int uv_offset = 128 << (BIT_DEPTH - 8);
nit: if these aren't going to change in this big function, you might want
to set them const. It could help the compilers, and particularly the last
two.
> +
> +av_assert2(yuv2rgb_coeffs[0][1][0] == 0);
> +av_assert2(yuv2rgb_coeffs[2][2][0] == 0);
> +av_assert2(yuv2rgb_coeffs[1][0][0] == cy && yuv2rgb_coeffs[2][0][0] ==
> cy);
> +
> +#if SS_W == 1
> +w = (w + 1) >> 1;
> +#if SS_H == 1
> +h = (h + 1) >> 1;
> +#endif
> +#endif
this should save some ifdefery, still be a noop when SS_X are 0, and
generate the same instruction (if i'm not mistaken) when not 0:
w = AV_CEIL_RSHIFT(w, SS_W);
h = AV_CEIL_RSHIFT(h, SS_H);
but maybe that's not what you want.
> +for (y = 0; y < h; y++) {
> +for (x = 0; x < w; x++) {
> +int y00 = yuv0[x << SS_W] - yuv_offset[0];
> +#if SS_W == 1
> +int y01 = yuv0[2 * x + 1] - yuv_offset[0];
> +#if SS_H == 1
> +
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
> +
> 6 files changed, 440 insertions(+)
> create mode 100644 libavcodec/vc264.c
>
> diff --git a/LICENSE.md b/LICENSE.md
> index a70f486..363e4e4 100644
> --- a/LICENSE.md
> +++ b/LICENSE.md
> @@ -124,3 +124,39 @@ license, requires a proprietary binary blob at run time,
> and is deemed to be
> incompatible with the GPL. We are not certain if it is compatible with the
> LGPL, but we require `--enable-nonfree` even with LGPL configurations in case
> it is not.
> +
> +### libilclient and vc264.c hardware assist h264 encoder
> +If libilclient is enabled and vc264.c compiled , then this copyright
> +notice must accompany any binary which is compiled against
> +the library libavcodec. Additionally, this copyright notice can be viewed
> +against such binary by using the unix shell commands :
> +strings ffmpeg_binary | grep -i copyright
> +
> +--
> +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.
> +--
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a993a67..71a321c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -278,6 +278,7 @@ Codecs:
>vble.cDerek Buitenhuis
>vc1* Kostya Shishkov, Christophe Gisquet
>vc2* Rostislav Pehlivanov
> + vc264.c Amancio Hasty
>vcr1.cMichael Niedermayer
>vda_h264_dec.cXidorn Quan
>videotoolboxenc.c Rick Kern
> diff --git a/configure b/configure
> index e8c4a7b..cd6563a 100755
> --- a/configure
> +++ b/configure
> @@ -277,6 +277,7 @@ External library support:
>--disable-lzma disable lzma [autodetect]
>--enable-decklinkenable Blackmagic DeckLink I/O support [no]
>--enable-mediacodec enable Android MediaCodec support [no]
> + --enable-libilclient enable h264 encoding via ilclient [no]
>--enable-mmalenable decoding via MMAL [no]
>--enable-netcdf enable NetCDF, needed for sofalizer filter [no]
>--enable-nvenc enable NVIDIA NVENC support [no]
> @@ -1477,6 +1478,7 @@ EXTERNAL_LIBRARY_LIST="
> libgsm
> libiec61883
> libilbc
> +libilclient
> libkvazaar
> libmfx
> libmodplug
> @@ -2533,6 +2535,9 @@ h264_d3d11va_hwaccel_deps="d3d11va"
> h264_d3d11va_hwaccel_select="h264_decoder"
> h264_dxva2_hwaccel_deps="dxva2"
> h264_dxva2_hwaccel_select="h264_decoder"
> +h264_libilclient_encoder_deps="libilclient"
> +h264_libilclient_encoder_select="libilclient"
> +h264_libilclient_hwaccel_deps="libilclient"
I think you're a little confused about what a hwaccel is here - a hwaccel is a
decode acceleration tool, not anything to do with encode. Remove all the
references to hwaccels, they aren't relevant at all to the patch.
> h264_mediacodec_decoder_deps="mediacodec"
> h264_mediacodec_decoder_select="h264_mp4toannexb_bsf h264_parser"
> h264_mmal_decoder_deps="mmal"
> @@ -5548,6 +5553,12 @@ enabled libgsm&& { for gsm_hdr in "gsm.h"
> "gsm/gsm.h"; do
>
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 insertions(+) > create mode 100644 tests/ref/fate/filter-meta-4560-rotate0 > It looks like this test is failing for aarch64... [...] -- 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] 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 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 >>>
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 other slave outputs can continue.
Signed-off-by: Jan Sebechlebsky
---
I've just added topic to commit message title as Marton Balint suggested.
doc/muxers.texi | 14
libavformat/tee.c | 96 +--
2 files changed, 100 insertions(+), 10 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 2aafbad..2d63083 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1372,6 +1372,12 @@ Select the streams that should be mapped to the slave
output,
specified by a stream specifier. If not specified, this defaults to
all the input streams. You may use multiple stream specifiers
separated by commas (@code{,}) e.g.: @code{a:0,v}
+
+@item onfail
+Specify behaviour on output failure. This can be set to either @code{abort}
(which is
+default) or @code{ignore}. @code{abort} will cause whole process to fail in
case of failure
+on this slave output. @code{ignore} will ignore failure on this output, so
other outputs
+will continue without being affected.
@end table
@subsection Examples
@@ -1386,6 +1392,14 @@ ffmpeg -i ... -c:v libx264 -c:a mp2 -f tee -map 0:v -map
0:a
@end example
@item
+As above, but continue streaming even if output to local file fails
+(for example local drive fills up):
+@example
+ffmpeg -i ... -c:v libx264 -c:a mp2 -f tee -map 0:v -map 0:a
+ "[onfail=ignore]archive-20121107.mkv|[f=mpegts]udp://10.0.1.255:1234/"
+@end example
+
+@item
Use @command{ffmpeg} to encode the input, and send the output
to three different destinations. The @code{dump_extra} bitstream
filter is used to add extradata information to all the output video
diff --git a/libavformat/tee.c b/libavformat/tee.c
index d823805..50aaf9f 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -29,10 +29,20 @@
#define MAX_SLAVES 16
+typedef enum {
+ON_SLAVE_FAILURE_ABORT = 1,
+ON_SLAVE_FAILURE_IGNORE = 2
+} SlaveFailurePolicy;
+
+#define DEFAULT_SLAVE_FAILURE_POLICY ON_SLAVE_FAILURE_ABORT
+
typedef struct {
AVFormatContext *avf;
AVBitStreamFilterContext **bsfs; ///< bitstream filters per stream
+SlaveFailurePolicy on_fail;
+unsigned char is_alive;
+
/** map from input to output streams indexes,
* disabled output streams are set to -1 */
int *stream_map;
@@ -41,6 +51,7 @@ typedef struct {
typedef struct TeeContext {
const AVClass *class;
unsigned nb_slaves;
+unsigned nb_alive;
TeeSlave slaves[MAX_SLAVES];
} TeeContext;
@@ -135,6 +146,18 @@ end:
return ret;
}
+static inline int parse_slave_failure_policy_option(const char *opt)
+{
+if (!opt) {
+return DEFAULT_SLAVE_FAILURE_POLICY;
+} else if (!av_strcasecmp("abort", opt)) {
+return ON_SLAVE_FAILURE_ABORT;
+} else if (!av_strcasecmp("ignore", opt)) {
+return ON_SLAVE_FAILURE_IGNORE;
+}
+return 0;
+}
+
static void close_slave(TeeSlave *tee_slave)
{
AVFormatContext *avf;
@@ -165,7 +188,8 @@ static void close_slaves(AVFormatContext *avf)
unsigned i;
for (i = 0; i < tee->nb_slaves; i++) {
-close_slave(&tee->slaves[i]);
+if (tee->slaves[i].is_alive)
+close_slave(&tee->slaves[i]);
}
}
@@ -175,7 +199,7 @@ static int open_slave(AVFormatContext *avf, char *slave, TeeSlave *tee_slave)
AVDictionary *options = NULL;
AVDictionaryEntry *entry;
char *filename;
-char *format = NULL, *select = NULL;
+char *format = NULL, *select = NULL, *on_fail = NULL;
AVFormatContext *avf2 = NULL;
AVStream *st, *st2;
int stream_count;
@@ -195,6 +219,17 @@ static int open_slave(AVFormatContext *avf, char *slave,
TeeSlave *tee_slave)
STEAL_OPTION("f", format);
STEAL_OPTION("select", select);
+STEAL_OPTION("onfail", on_fail);
+
+tee_slave->on_fail = parse_slave_failure_policy_option(on_fail);
+if (!tee_slave->on_fail) {
+av_log(avf, AV_LOG_ERROR,
+ "Invalid onfail option value, valid options are 'abort' and
'ignore'\n");
+ret = AVERROR(EINVAL);
+/* Set failure behaviour to abort, so invalid option error will not be
ignored */
+tee_slave->on_fail = ON_SLAVE_FAILURE_ABORT;
+goto end;
+}
ret = avformat_alloc_output_context2(&avf2, NULL, format, filename);
if (ret < 0)
@@ -339,8 +374,11 @@ static int open_slave(AVFormatContext *avf, char *slave,
TeeSlave *tee_slave)
}
end:
+if (ret < 0)
+close_slave(tee_slave);
av_free(format);
av_free(select);
+av_free(on_fail);
av_dict_free(&options);
av_freep(&tmp_select);
return ret;
@@ -370,6 +408,31 @@
[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'. Please also see the accompanying blog
post[2]
which has an algorithm description, as well as some usage instructions.
[1] https://github.com/jiixyj/libebur128
[2] http://k.ylo.ph/2016/04/04/loudnorm.html
Thanks!
Kyle
Signed-off-by: Kyle Swanson
---
Changelog | 1 +
MAINTAINERS | 1 +
configure | 5 +
doc/filters.texi | 42 +++
libavfilter/Makefile | 1 +
libavfilter/af_loudnorm.c | 905 ++
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 4 +-
8 files changed, 958 insertions(+), 2 deletions(-)
create mode 100644 libavfilter/af_loudnorm.c
diff --git a/Changelog b/Changelog
index fa4edd4..602f6a2 100644
--- a/Changelog
+++ b/Changelog
@@ -20,6 +20,7 @@ version :
- bitstream filter for extracting DTS core
- ADPCM IMA DAT4 decoder
- musx demuxer
+- loudnorm filter
version 3.0:
- Common Encryption (CENC) MP4 encoding and decoding support
diff --git a/MAINTAINERS b/MAINTAINERS
index a993a67..fb4b8fd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -358,6 +358,7 @@ Filters:
af_compand.c Paul B Mahol
af_firequalizer.c Muhammad Faiz
af_ladspa.c Paul B Mahol
+ af_loudnorm.c Kyle Swanson
af_pan.c Nicolas George
af_sidechaincompress.cPaul B Mahol
af_silenceremove.cPaul B Mahol
diff --git a/configure b/configure
index 94a66d8..024568a 100755
--- a/configure
+++ b/configure
@@ -219,6 +219,8 @@ External library support:
--enable-libcdio enable audio CD grabbing with libcdio [no]
--enable-libdc1394 enable IIDC-1394 grabbing using libdc1394
and libraw1394 [no]
+ --enable-libebur128 enable libebur128 for EBU R128 measurement,
+ needed for loudnorm filter [no]
--enable-libfaac enable AAC encoding via libfaac [no]
--enable-libfdk-aac enable AAC de/encoding via libfdk-aac [no]
--enable-libfliteenable flite (voice synthesis) support via libflite
[no]
@@ -1467,6 +1469,7 @@ EXTERNAL_LIBRARY_LIST="
libcdio
libcelt
libdc1394
+libebur128
libfaac
libfdk_aac
libflite
@@ -2948,6 +2951,7 @@ hwupload_cuda_filter_deps="cuda"
interlace_filter_deps="gpl"
kerndeint_filter_deps="gpl"
ladspa_filter_deps="ladspa dlopen"
+loudnorm_filter_deps="libebur128"
mcdeint_filter_deps="avcodec gpl"
movie_filter_deps="avcodec avformat"
mpdecimate_filter_deps="gpl"
@@ -5534,6 +5538,7 @@ enabled libcelt && require libcelt celt/celt.h
celt_decode -lcelt0 &&
{ check_lib celt/celt.h
celt_decoder_create_custom -lcelt0 ||
die "ERROR: libcelt must be installed and
version must be >= 0.11.0."; }
enabled libcaca && require_pkg_config caca caca.h caca_create_canvas
+enabled libebur128&& require ebur128 ebur128.h
ebur128_relative_threshold -lebur128
enabled libfaac && require2 libfaac "stdint.h faac.h"
faacEncGetVersion -lfaac
enabled libfdk_aac&& { use_pkg_config fdk-aac "fdk-aac/aacenc_lib.h"
aacEncOpen ||
{ require libfdk_aac fdk-aac/aacenc_lib.h
aacEncOpen -lfdk-aac &&
diff --git a/doc/filters.texi b/doc/filters.texi
index 592fc24..6c563d9 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2711,6 +2711,48 @@ Modify the @var{N}-th control value.
If the specified value is not valid, it is ignored and prior one is kept.
@end table
+@section loudnorm
+
+EBU R128 loudness normalization. Includes both dynamic and linear
normalization modes.
+Support for both single pass (livestreams, files) and double pass (files)
modes.
+This algorithm can target IL, LRA, and maximum true peak. Requires libebur128.
+
+The filter accepts the following options:
+
+@table @option
+@item I, i
+Set integrated loudness target
+
+@item LRA, lra
+Set loudness range target
+
+@item TP, tp
+Set maximum true peak
+
+@item measured_I, measured_i
+Measured IL of input file
+
+@item measured_LRA, measured_lra
+Measured LRA of input file
+
+@item measured_TP, measured_tp
+Measured true peak of input file
+
+@item measured_thresh
+Measured threshold of input file
+
+@item offset
+Set offset gain. Gain is applied before the true-peak limiter.
+
+@item linear
+Normalize linearly if possible.
+measured_I, measured_LRA, measured_TP, and measured_thresh also need
+to be specified to use this mode.
+
+@item print_format
+Set print format for stats. Options are summary, json, or none.
+@end table
+
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 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 > > i think nothing in the fate samples has been compared to any spec > > That doesn't answer the question. *We wrote the spec* so it would be stupid to take this file and assume it's correct when it was made during spec development. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 ++ > > tests/ref/fate/filter-meta-4560-rotate0 | 259 > > +++ > > 2 files changed, 268 insertions(+) > > create mode 100644 tests/ref/fate/filter-meta-4560-rotate0 > > > > It looks like this test is failing for aarch64... fixed i hope [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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. > > > --- > > > libavformat/mpegts.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > breaks tickets/2579/old_klv_data_stream.mpg > > Where/how I can find the sample? i assume its (didnt download and double check) http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2579/old_klv_data_stream.mpg [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 ‘mlp_encode_frame’: > libavcodec/mlpenc.c:2369:5: warning: ‘coded_frame’ is deprecated (declared > at libavcodec/avcodec.h:2967) [-Wdeprecated-declarations] > libavcodec/mlpenc.c: In function ‘mlp_encode_close’: > libavcodec/mlpenc.c:2469:5: warning: ‘coded_frame’ is deprecated (declared > at libavcodec/avcodec.h:2967) [-Wdeprecated-declarations] > During build other encoders too give this warning (deprecation of coded->frame), so I could not figure out how to fix it. Please give some clue regarding what to be used instead of "coded->frame". :) -Disha ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 `--enable-libebur128'. Please also see the accompanying blog > post[2] > which has an algorithm description, as well as some usage instructions. > > [1] https://github.com/jiixyj/libebur128 > [2] http://k.ylo.ph/2016/04/04/loudnorm.html > > Thanks! > Kyle Hi, First version had a couple of messed up tabs. New patch attached. 0001-avfilter-add-loudnorm.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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 index b7bc979..b3ed64f 100644 --- a/tests/fate/filter-audio.mak +++ b/tests/fate/filter-audio.mak @@ -27,20 +27,20 @@ fate-filter-amix-transition: SRC2 = $(TARGET_PATH)/tests/data/asynth-44100-2-3.w fate-filter-amix-transition: CMD = ffmpeg -filter_complex amix=inputs=3:dropout_transition=0.5 -i $(SRC) -ss 2 -i $(SRC1) -ss 4 -i $(SRC2) -f f32le - fate-filter-amix-transition: REF = $(SAMPLES)/filter/amix_transition.pcm -FATE_AFILTER-$(call FILTERDEMDECENCMUX, AMIX, WAV, PCM_S16LE, PCM_F32LE, PCM_F32LE) += $(FATE_AMIX) +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, AMIX, WAV, PCM_S16LE, PCM_F32LE, PCM_F32LE) += $(FATE_AMIX) $(FATE_AMIX): tests/data/asynth-44100-2.wav tests/data/asynth-44100-2-2.wav $(FATE_AMIX): SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav $(FATE_AMIX): SRC1 = $(TARGET_PATH)/tests/data/asynth-44100-2-2.wav $(FATE_AMIX): CMP = oneoff $(FATE_AMIX): CMP_UNIT = f32 -FATE_AFILTER-$(call FILTERDEMDECMUX, ASYNCTS, FLV, NELLYMOSER, PCM_S16LE) += fate-filter-asyncts +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECMUX, ASYNCTS, FLV, NELLYMOSER, PCM_S16LE) += fate-filter-asyncts fate-filter-asyncts: SRC = $(TARGET_SAMPLES)/nellymoser/nellymoser-discont.flv fate-filter-asyncts: CMD = pcm -analyzeduration 1000 -i $(SRC) -af asyncts fate-filter-asyncts: CMP = oneoff fate-filter-asyncts: REF = $(SAMPLES)/nellymoser/nellymoser-discont-async-v3.pcm -FATE_FILTER-$(CONFIG_ARESAMPLE_FILTER) += fate-filter-aresample +FATE_AFILTER_SAMPLES-$(CONFIG_ARESAMPLE_FILTER) += fate-filter-aresample fate-filter-aresample: SRC = $(TARGET_SAMPLES)/nellymoser/nellymoser-discont.flv fate-filter-aresample: CMD = pcm -analyzeduration 1000 -i $(SRC) -af aresample=min_comp=0.001:min_hard_comp=0.1:first_pts=0 fate-filter-aresample: CMP = oneoff @@ -60,7 +60,7 @@ fate-filter-atrim-time: CMD = framecrc -i $(SRC) -af atrim=0.1:0.2 $(FATE_ATRIM): tests/data/asynth-44100-2.wav $(FATE_ATRIM): SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav -FATE_FILTER-$(call FILTERDEMDECENCMUX, ATRIM, WAV, PCM_S16LE, PCM_S16LE, WAV) += $(FATE_ATRIM) +FATE_AFILTER-$(call FILTERDEMDECENCMUX, ATRIM, WAV, PCM_S16LE, PCM_S16LE, WAV) += $(FATE_ATRIM) FATE_FILTER_CHANNELMAP += fate-filter-channelmap-one-int fate-filter-channelmap-one-int: tests/data/filtergraphs/channelmap_one_int @@ -106,5 +106,6 @@ FATE_AFILTER-yes += fate-filter-formats fate-filter-formats: libavfilter/formats-test$(EXESUF) fate-filter-formats: CMD = run libavfilter/formats-test -FATE_SAMPLES_AVCONV += $(FATE_AFILTER-yes) -fate-afilter: $(FATE_AFILTER-yes) +FATE_SAMPLES_AVCONV += $(FATE_AFILTER_SAMPLES-yes) +FATE_FFMPEG += $(FATE_AFILTER-yes) +fate-afilter: $(FATE_AFILTER-yes) $(FATE_AFILTER_SAMPLES-yes) diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index ef266c0..4942279 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -1,4 +1,4 @@ -FATE_FILTER-$(call ALLYES, PERMS_FILTER DELOGO_FILTER RM_DEMUXER RV30_DECODER) += fate-filter-delogo +FATE_FILTER_SAMPLES-$(call ALLYES, PERMS_FILTER DELOGO_FILTER RM_DEMUXER RV30_DECODER) += fate-filter-delogo fate-filter-delogo: CMD = framecrc -i $(TARGET_SAMPLES)/real/rv30.rm -vf perms=random,delogo=show=0:x=290:y=25:w=26:h=16 -an FATE_YADIF += fate-filter-yadif-mode0 @@ -13,7 +13,7 @@ fate-filter-yadif10: CMD = framecrc -flags bitexact -idct simple -i $(TARGET_SAM FATE_YADIF += fate-filter-yadif16 fate-filter-yadif16: CMD = framecrc -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -pix_fmt yuv420p16le -vframes 30 -vf yadif=0 -FATE_FILTER-$(call FILTERDEMDEC, YADIF, MPEGTS, MPEG2VIDEO) += $(FATE_YADIF) +FATE_FILTER_SAMPLES-$(call FILTERDEMDEC, YADIF, MPEGTS, MPEG2VIDEO) += $(FATE_YADIF) FATE_W3FDIF += fate-filter-w3fdif-simple fate-filter-w3fdif-simple: CMD = framecrc -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -vframes 30 -vf w3fdif=0 @@ -21,7 +21,7 @@ fate-filter-w3fdif-simple: CMD = framecrc -flags bitexact -idct simple -i $(TARG FATE_W3FDIF += fate-filter-w3fdif-complex fate-filter-w3fdif-complex: CMD = framecrc -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -vframes 30 -vf w3fdif=1 -FATE_FILTER-$(call FILTERDEMDEC, W3FDIF, MPEGTS, MPEG2VIDEO) += $(FATE_W3FDIF) +FATE_FILTER_SAMPLES-$(call FILTERDEMDEC, W3FDIF, MPEGTS, MPEG2VIDEO) += $(FATE_W3FDIF) FATE_MCDEINT += fate-filter-mcdeint-fast fate-filter-mcdeint-fast: CMD = framecrc -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -vframes 30 -vf mcdeint=fast @@ -29,12 +29,12 @@ fate-filter-mcdeint-fast: CMD = framecrc -flags bitexact -idct simple -i $
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 fill with "float" values, which will be required to use by rendering as float data. My query is, what flags need to set from the decoder level so that the rendering will understand the data is float. Regards, Suresh. On Tue, Apr 5, 2016 at 7:14 PM, Carl Eugen Hoyos wrote: > 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 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] 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 libebur128 v1.1.0[1] > and must be > configured with `--enable-libebur128'. Please also see the accompanying blog > post[2] > which has an algorithm description, as well as some usage instructions. > > [1] https://github.com/jiixyj/libebur128 > [2] http://k.ylo.ph/2016/04/04/loudnorm.html > > Thanks! > Kyle > > Signed-off-by: Kyle Swanson > --- > Changelog | 1 + > MAINTAINERS | 1 + > configure | 5 + > doc/filters.texi | 42 +++ > libavfilter/Makefile | 1 + > libavfilter/af_loudnorm.c | 905 > ++ > libavfilter/allfilters.c | 1 + > libavfilter/version.h | 4 +- > 8 files changed, 958 insertions(+), 2 deletions(-) > create mode 100644 libavfilter/af_loudnorm.c > Mmh. That's nice and all but... why not use/adjust the native ebur128 filter we have instead of relying on an external library? [...] -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
