[FFmpeg-devel] [PATCH] doc/developer: Remove mentioning of sending pull requests

[Timothy Gu]

The _de facto_ policy on patch submission has always been "sending it to
the mailing list."
---
 doc/developer.texi | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 9a901d8..9383b21 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -32,13 +32,11 @@ consult @url{https://ffmpeg.org/legal.html}.
 
 @section Contributing
 
-There are 3 ways by which code gets into ffmpeg.
+There are two ways by which code gets into ffmpeg.
 @itemize @bullet
 @item Submitting Patches to the main developer mailing list
   see @ref{Submitting patches} for details.
 @item Directly committing changes to the main tree.
-@item Committing changes to a git clone, for example on github.com or
-  gitorious.org. And asking us to merge these changes.
 @end itemize
 
 Whichever way, changes should be reviewed by the maintainer of the code
-- 
2.1.4

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

Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files

[Carl Eugen Hoyos]

Hi!

On Saturday 05 December 2015 12:17:56 am Eran Kornblau wrote:
> > Please send the patches to the mailing list. See
> > https://github.com/FFmpeg/FFmpeg/pull/153
>
> Attached, note there are two files, the second commit is just a tiny 
> fix to a bug in the first one, hope that's ok.

No, please merge them (without adding trailing whitespace, it cannot 
be committed to our repository).
While at it, please fix this nit (several times):
> +}
> +else {

should be on one line, there is tools/patcheck that should have told 
you (and also tells you about trailing whitespace).

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

Re: [FFmpeg-devel] [PATCH 3/3] avutil/threadmessage: fix condition broadcasting

[Clément Bœsch]

On Sat, Dec 05, 2015 at 01:19:16PM +0100, Nicolas George wrote:
> Le quintidi 15 frimaire, an CCXXIV, Clement Boesch a écrit :
> > ping, I'd like to apply this fix soon
> 
> I have already answered:
> 
> http://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184285.html
> 

This was before providing the 2 cond version, but OK

> So please go ahead.
> 

I'd like to push the test as well, but it depends on the first patch
(flush func). I clarified a bit the use of the flush in the doxy. Are you
still uncomfortable about this one?

-- 
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 2/2] avfilter: add sidechaingate filter

[Ganesh Ajjanagadde]

On Sat, Dec 5, 2015 at 1:20 AM, Paul B Mahol  wrote:
> On 12/4/15, Ganesh Ajjanagadde  wrote:
>> On Fri, Dec 4, 2015 at 3:49 PM, Paul B Mahol  wrote:
>>> On 12/4/15, Ganesh Ajjanagadde  wrote:
 On Fri, Dec 4, 2015 at 11:36 AM, Paul B Mahol  wrote:
> On 12/4/15, Ganesh Ajjanagadde  wrote:
>> On Wed, Dec 2, 2015 at 1:42 AM, Paul B Mahol  wrote:
>>> On 12/2/15, Paul B Mahol  wrote:
 On 12/2/15, Ganesh Ajjanagadde  wrote:
> On Tue, Dec 1, 2015 at 2:14 PM, Paul B Mahol 
> wrote:
>> On 12/1/15, Nicolas George  wrote:
>>> Le primidi 11 frimaire, an CCXXIV, Paul B Mahol a ecrit :
 Similar how its freed when no longer used.
>>>
>>> Please elaborate. I know the API, I do not see what you suggest.
>>>
>>> (Thanks for trimming.)
>>>
>>> Regards,
>>
>> After carefully looking at this functon, I see no leaking at all.
>
> Care to elaborate on this? My question is: what happens when e.g
> layouts get set and allocated/ref'ed correctly, but while trying to
> allocate formats, ENOMEM occurs? Or in other words, where does the
> formats get deallocated in such a case? And why does Coverity flag
> these things?

 Maybe it is for test program: libavfilter/filtfmts.c

>>>
>>> Also I changed return value of query_formats to always be -1 and run
>>> program under 'valgrind --leak-check=full --show-leak-kinds=all'
>>> I see unrelated leaks from af_aformat and others, and no leaks from
>>> query_formats.
>>
>> You are being ambiguous here, and your testing was likely not thorough
>> enough.
>>
>> Please try the following:
>> diff --git a/libavfilter/af_agate.c b/libavfilter/af_agate.c
>> index 291e803..416b671 100644
>> --- a/libavfilter/af_agate.c
>> +++ b/libavfilter/af_agate.c
>> @@ -188,6 +188,7 @@ static int query_formats(AVFilterContext *ctx)
>>  layouts = ff_all_channel_counts();
>>  if (!layouts)
>>  return AVERROR(ENOMEM);
>> +return AVERROR(ENOMEM);
>
> This is nonsense.

 You have a very bad habit of calling something "nonsense". I can reply
 in kind saying that your original "carefully looking at this function"
 was nonsense, since the leak is demonstrated below. Your test was with
 a return -1, which is also nonsensical.

 I moreover did say it is not a proper illustration, and gave a better
 one with instructions to reproduce below. Please stop your habit of
 selectively replying and thus creating biased perspectives for a
 casual observer of what I point out. Your code was broken wrt
 memleaks, stop defending it, test the example I gave, and work towards
 creating a constructive solution.
>>>
>>> First provide actual sane patch that demonstrate that leak actually does
>>> happen.
>>
>> If you actually bothered to read the message I posted fully instead of
>> posting comments like "nonsense", you would have seen such a patch.
>>
>>>
>>> Allocating something and than returning immediately error and then saying
>>> look your code sucks is very unfriendly.
>>
>> No. What is unfriendly is the following:
>> 1. You not addressing a reviewer at the time when a patch is posted
>> and pushing to master, and the associated hypocrisy wrt the dev policy
>> since you joined the fracas regarding "pushing without review"
>> (https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182511.html)
>> which was not even true while doing so freely yourself for a far more
>> sizable and thus impactful change.
>> 2. Your terse replies that need repeated queries to extract something
>> out of them. This was not for just a newbie like me, but even Nicolas
>> needed clarification.
>> 3. Your repeated refusal to acknowledge that the leak can happen, and
>> when someone (in this case me) spends effort demonstrating said leak,
>> your blunt dismissal of it via a selective reply.
>> 4. Your carefree attitude, falling to things like "it is all low
>> hanging fruit" and claiming that it was "wasted time". This is
>> insulting to the reviewer.
>
> I do not like reviewes from vertical space indent department.

It is very insulting to me to claim that I am from the "vertical space
indent department", and again this goes back to the unfriendliness.
Please refrain from this. I won't actually address this with explicit
links as proof, since it is obviously false from the commit history
which speaks for itself. The reviews also speak for themselves from
the ffmpeg-devel archive.

I personally don't mind at all to stop reviewing filters posted by
you: I only have a finite amount of energy to deal with this kind of

[FFmpeg-devel] [PATCH] probe TrueHD in MPEGTS

[Rodger Combs]

---
 libavformat/utils.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 251b2c6..ae9ae5b 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -284,6 +284,7 @@ static int set_codec_from_probe_data(AVFormatContext *s, 
AVStream *st,
 { "m4v",   AV_CODEC_ID_MPEG4,  AVMEDIA_TYPE_VIDEO },
 { "mp3",   AV_CODEC_ID_MP3,AVMEDIA_TYPE_AUDIO },
 { "mpegvideo", AV_CODEC_ID_MPEG2VIDEO, AVMEDIA_TYPE_VIDEO },
+{ "truehd",AV_CODEC_ID_TRUEHD, AVMEDIA_TYPE_AUDIO },
 { 0 }
 };
 int score;
-- 
2.6.3

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

Re: [FFmpeg-devel] Memory leaks in libavformat/segment.c

[Lvqier]

Ok, I will try av_reallocp

/Best Regards,
lvqier - lvq...@gmail.com 
/

**
青春如烟，唱一首笑忘歌

On 12/5/15 7:27 PM, Hendrik Leppkes wrote:

On Sat, Dec 5, 2015 at 11:02 AM, Qier LU  wrote:

Hi Michael,

The attached is against git master.


The patch is probably fine now. Maybe it would be saner to actually
use av_reallocp on the filename to avoid having to allocate and free
it in different places?

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/golomb: Mask shift amount before use in get_ue_golomb()

[Ganesh Ajjanagadde]

On Fri, Dec 4, 2015 at 9:12 PM, Michael Niedermayer  wrote:
> On Fri, Dec 04, 2015 at 10:28:35PM +0100, Andreas Cadhalpun wrote:
>> On 03.12.2015 23:09, Michael Niedermayer wrote:
>> > From: Michael Niedermayer 
>> >
>> > Fixes undefined behavior
>> > Fixes: mozilla bug 1229208
>> > Fixes: 
>> > fbeb8b2c7c996e9b91c6b1af319d7ebc/asan_heap-oob_195450f_2743_e8856ece4579ea486670be2b236099a0.bit
>> >
>> > Found-by: Tyson Smith
>> > Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
>> > Signed-off-by: Michael Niedermayer 
>> > ---
>> >  libavcodec/golomb.h |2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/libavcodec/golomb.h b/libavcodec/golomb.h
>> > index d30bb6b..323665d 100644
>> > --- a/libavcodec/golomb.h
>> > +++ b/libavcodec/golomb.h
>> > @@ -72,7 +72,7 @@ static inline int get_ue_golomb(GetBitContext *gb)
>> >  av_log(NULL, AV_LOG_ERROR, "Invalid UE golomb code\n");
>> >  return AVERROR_INVALIDDATA;
>> >  }
>> > -buf >>= log;
>> > +buf >>= log & 31;
>> >  buf--;
>> >
>> >  return buf;
>> >
>>
>> While that certainly fixes the undefined behavior, I'm wondering what's the 
>> relation
>> to commit fd165ac. In other words, why not just remove the CONFIG_FTRAPV from
>> the error check above?
>
> the & 31 is a hack really (and choosen because at least clang
> optimizes it out)
> the "correct" way would be to test, print a warning and return an
> error code. That way if a valid (non fuzzed) file triggers it we know
> that the range of get_ue_golomb() is potentially too small.
> With the & 31 no information is shown, before this patch here
> ubsan would show it as well without the normal case being slower
> so its all perfect already ... except ... that its wrong because its
> undefined behavior
>
> maybe someone has a better idea ...
>
>
>>
>> Also, if you are interested in fixing such undefined behavior, I have lots of
>> fuzzed samples triggering ubsan all over the place...
>
> I think my todo list is too long to fix all. Maybe others are
> interrested in helping.
> The really tricky part is to fix some of these issues without causing
> a slowdown in speed relevant code and without making maintaince
> harder
> for example decoding a file from a bug report with ubsan and looking
> for overflows can in rare instances directly point to the problem
> or close to it. One needs to keep this in mind when Fixing/Hiding
> ubsan issues, sometimes a log message and error out is better than
> extending precission or using unsigned sometimes its not ...

Would like to add a comment here: wrt ubsan, I think clang's is
slightly better than gcc's. GCC seems to have some bugs, for instance
it does not work correctly wrt the FFNABS solution for safe absolute
value, while clang's does. I have remarked upon this in the relevant
trac ticket:
https://trac.ffmpeg.org/ticket/4727#comment:8

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Awnsering whenever a program halts or runs forever is
> On a turing machine, in general impossible (turings halting problem).
> On any real computer, always possible as a real computer has a finite number
> of states N, and will either halt in less than N cycles or never halt.
>
> ___
> 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

[FFmpeg-devel] My problem

[Rene Alves]

http://pastebin.com/NrwLsu6J
[C++] #include "RawVideoReader.h" #include  #include 
#define AV_OU - Pastebin.com
pastebin.com

This is my code, I followed some steps I´ve found on line
But the av_encode_video2 function doesn´t wor k:(
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avutil/threadmessage: fix condition broadcasting

[Nicolas George]

Le quintidi 15 frimaire, an CCXXIV, Clement Boesch a écrit :
> ping, I'd like to apply this fix soon

I have already answered:

http://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184285.html

So please go ahead.

Regards,

-- 
  Nicolas George


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

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

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_panorama.c | 437 ++
 3 files changed, 439 insertions(+)
 create mode 100644 libavfilter/vf_panorama.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 8884d1d..5e0321f 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -193,6 +193,7 @@ OBJS-$(CONFIG_OWDENOISE_FILTER)  += 
vf_owdenoise.o
 OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
 OBJS-$(CONFIG_PALETTEGEN_FILTER) += vf_palettegen.o
 OBJS-$(CONFIG_PALETTEUSE_FILTER) += vf_paletteuse.o dualinput.o 
framesync.o
+OBJS-$(CONFIG_PANORAMA_FILTER)   += vf_panorama.o
 OBJS-$(CONFIG_PERMS_FILTER)  += f_perms.o
 OBJS-$(CONFIG_PERSPECTIVE_FILTER)+= vf_perspective.o
 OBJS-$(CONFIG_PHASE_FILTER)  += vf_phase.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 0eeef53..952bddf 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -214,6 +214,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(PAD,pad,vf);
 REGISTER_FILTER(PALETTEGEN, palettegen, vf);
 REGISTER_FILTER(PALETTEUSE, paletteuse, vf);
+REGISTER_FILTER(PANORAMA,   panorama,   vf);
 REGISTER_FILTER(PERMS,  perms,  vf);
 REGISTER_FILTER(PERSPECTIVE,perspective,vf);
 REGISTER_FILTER(PHASE,  phase,  vf);
diff --git a/libavfilter/vf_panorama.c b/libavfilter/vf_panorama.c
new file mode 100644
index 000..b6bba64
--- /dev/null
+++ b/libavfilter/vf_panorama.c
@@ -0,0 +1,437 @@
+/*
+ * 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/avassert.h"
+#include "libavutil/eval.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+enum Projections {
+SPHERE,
+CUBE,
+NB_PROJECTIONS,
+};
+
+enum Faces {
+LEFT,
+FRONT,
+RIGHT,
+TOP,
+BACK,
+DOWN,
+};
+
+struct XYRemap {
+int vi, ui;
+int v2, u2;
+double a, b, c, d;
+};
+
+typedef struct PanoramaContext {
+const AVClass *class;
+int in, out;
+
+int planewidth[4], planeheight[4];
+int inplanewidth[4], inplaneheight[4];
+int nb_planes;
+
+struct XYRemap *remap[4];
+
+int (*panorama)(struct PanoramaContext *s,
+const uint8_t *src, uint8_t *dst,
+int width, int height,
+int in_linesize, int out_linesize,
+struct XYRemap *remap);
+} PanoramaContext;
+
+#define OFFSET(x) offsetof(PanoramaContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption panorama_options[] = {
+{ "input",  "set input projection",   OFFSET(in), AV_OPT_TYPE_INT,   
{.i64=SPHERE}, 0, NB_PROJECTIONS-1, FLAGS, "in" },
+{ "s", "spheric",  0, AV_OPT_TYPE_CONST, 
{.i64=SPHERE}, 0,0, FLAGS, "in" },
+{ "c", "cubic",0, AV_OPT_TYPE_CONST, 
{.i64=CUBE},   0,0, FLAGS, "in" },
+{ "output", "set output projection", OFFSET(out), AV_OPT_TYPE_INT,   
{.i64=CUBE},   0, NB_PROJECTIONS-1, FLAGS, "out" },
+{ "s", "spheric",  0, AV_OPT_TYPE_CONST, 
{.i64=SPHERE}, 0,0, FLAGS, "out" },
+{ "c", "cubic",0, AV_OPT_TYPE_CONST, 
{.i64=CUBE},   0,0, FLAGS, "out" },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(panorama);
+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat pix_fmts[] = {
+AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA420P,
+AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ440P, 
AV_PIX_FMT_YUVJ422P,AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ411P,
+AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV422P, 
AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV411P, AV_PIX_FMT_YUV410P,
+AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP, AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE
+

Re: [FFmpeg-devel] [PATCH] avfilter: add panorama filter

[Clément Bœsch]

On Sat, Dec 05, 2015 at 06:38:47PM +0100, Paul B Mahol wrote:
[...]
> +{ "input",  "set input projection",   OFFSET(in), AV_OPT_TYPE_INT,   
> {.i64=SPHERE}, 0, NB_PROJECTIONS-1, FLAGS, "in" },
> +{ "s", "spheric",  0, AV_OPT_TYPE_CONST, 
> {.i64=SPHERE}, 0,0, FLAGS, "in" },
> +{ "c", "cubic",0, AV_OPT_TYPE_CONST, 
> {.i64=CUBE},   0,0, FLAGS, "in" },
> +{ "output", "set output projection", OFFSET(out), AV_OPT_TYPE_INT,   
> {.i64=CUBE},   0, NB_PROJECTIONS-1, FLAGS, "out" },
> +{ "s", "spheric",  0, AV_OPT_TYPE_CONST, 
> {.i64=SPHERE}, 0,0, FLAGS, "out" },
> +{ "c", "cubic",0, AV_OPT_TYPE_CONST, 
> {.i64=CUBE},   0,0, FLAGS, "out" },

i think you can use something like "projection" as unit, and define the
const list only once.

> +{ NULL }
> +};
> +
> +AVFILTER_DEFINE_CLASS(panorama);
> +
> +static int query_formats(AVFilterContext *ctx)
> +{
> +static const enum AVPixelFormat pix_fmts[] = {
> +AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA420P,
> +AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ440P, 
> AV_PIX_FMT_YUVJ422P,AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ411P,
> +AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV422P, 
> AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV411P, AV_PIX_FMT_YUV410P,
> +AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP, AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE
> +};
> +
> +AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts);
> +if (!fmts_list)
> +return AVERROR(ENOMEM);
> +return ff_set_common_formats(ctx, fmts_list);
> +}
> +
> +static int bilinear(PanoramaContext *s,
> +const uint8_t *src, uint8_t *dst,
> +int width, int height,
> +int in_linesize, int out_linesize,

> +struct XYRemap *remap)

remap doesn't seem altered here

> +{
> +double A, B, C, D;
> +int x, y;
> +
> +for (y = 0; y < height; y++) {
> +uint8_t *d = dst + y * out_linesize;
> +for (x = 0; x < width; x++) {
> +struct XYRemap *r = [y * width + x];
> +
> +A = src[r->vi * in_linesize + r->ui];
> +B = src[r->vi * in_linesize + r->u2];
> +C = src[r->v2 * in_linesize + r->ui];
> +D = src[r->v2 * in_linesize + r->u2];

nit: you can declare A,B,C,D as local const double in this scope

> +*d++ = round(A * r->a + B * r->b + C * r->c + D * r->d);
> +}
> +}
> +
> +return 0;
> +}
> +

looks threadable btw

[...]

-- 
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] libavtuil: add version component accessor macros

[Reynaldo H. Verdejo Pinochet]

On 12/05/2015 10:31 AM, Reynaldo H. Verdejo Pinochet wrote:
> Pretty standard macros, these should help libav*
> users avoid repeating ver.si.on parsing code,
> which aids in compatibility-checking tasks like
> identifying FFmpeg from Libav (_MICRO >= 100 check).

Actually ran into this while working on the GStreamer issue
here:

https://bugzilla.gnome.org/show_bug.cgi?id=758183

Bests,


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

Re: [FFmpeg-devel] [PATCH] libavtuil: add version component accessor macros

[Michael Niedermayer]

On Sat, Dec 05, 2015 at 10:31:33AM -0800, Reynaldo H. Verdejo Pinochet wrote:
> Pretty standard macros, these should help libav*
> users avoid repeating ver.si.on parsing code,
> which aids in compatibility-checking tasks like
> identifying FFmpeg from Libav (_MICRO >= 100 check).
> Something many are doing since we are not
> intercompatible anymore.
> 
> Signed-off-by: Reynaldo H. Verdejo Pinochet 
> ---
>  libavutil/version.h | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)

LGTM

thx

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

[FFmpeg-devel] [PATCH] libavtuil: add version component accessor macros

[Reynaldo H. Verdejo Pinochet]

Pretty standard macros, these should help libav*
users avoid repeating ver.si.on parsing code,
which aids in compatibility-checking tasks like
identifying FFmpeg from Libav (_MICRO >= 100 check).
Something many are doing since we are not
intercompatible anymore.

Signed-off-by: Reynaldo H. Verdejo Pinochet 
---
 libavutil/version.h | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/libavutil/version.h b/libavutil/version.h
index e0ddfd2..22b67d1 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -37,6 +37,14 @@
 #define AV_VERSION(a, b, c) AV_VERSION_DOT(a, b, c)
 
 /**
+ * Extract version components from the full ::AV_VERSION_INT int as returned
+ * by functions like ::avformat_version() and ::avcodec_version()
+ */
+#define AV_VERSION_MAJOR(a) ((a) >> 16)
+#define AV_VERSION_MINOR(a) (((a) & 0x00FF00) >> 8)
+#define AV_VERSION_MICRO(a) ((a) & 0xFF)
+
+/**
  * @}
  */
 
@@ -56,7 +64,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  55
-#define LIBAVUTIL_VERSION_MINOR   9
+#define LIBAVUTIL_VERSION_MINOR  10
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.6.2

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

[FFmpeg-devel] [PATCH] news: add a news entry for the AAC encoder experimental flag removal

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 src/index | 21 +
 1 file changed, 21 insertions(+)

diff --git a/src/index b/src/index
index d1d4a58..0c54046 100644
--- a/src/index
+++ b/src/index
@@ -37,6 +37,27 @@
 News
   
 
+  The native FFmpeg encoder is out of 
experimental!
+  
+After seven years the native FFmpeg AAC encoder has had its experimental 
flag
+removed and declared as ready for use. Subjective quality tests put the
+encoder to be of equal or greater quality than most of the other encoders
+available to the public.
+  
+Licensing has always been an issue with encoding AAC audio as most of the
+encoders have had a license making FFmpeg indistributable if compiled with
+support for them. The fact that there now exists a fully open and truly
+free AAC encoder integrated directly within the project means a lot to 
those
+who wish to use accepted and widespread standards.
+  
+The majority of the work done to bring the encoder up to quality was
+done by Claudio Freire and Rostislav Pehlivanov. Also thanks to
+http://d.hatena.ne.jp/kamedo2/;>Kamedo2 who does comparisons
+and tests, the original authors and all past and current contributors to 
the
+encoder. Users are suggested and encouraged to use the encoder and provide
+feedback or breakage reports through our https://trac.ffmpeg.org/;>bug tracker.
+  
+
   Telepoint & MediaHub are now supporting 
our project
   
 A big thank you note goes to our newest supporters: MediaHub and Telepoint.
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] libavtuil: add version component accessor macros

[Ganesh Ajjanagadde]

On Sat, Dec 5, 2015 at 1:56 PM, Michael Niedermayer  wrote:
> On Sat, Dec 05, 2015 at 10:31:33AM -0800, Reynaldo H. Verdejo Pinochet wrote:
>> Pretty standard macros, these should help libav*
>> users avoid repeating ver.si.on parsing code,
>> which aids in compatibility-checking tasks like
>> identifying FFmpeg from Libav (_MICRO >= 100 check).
>> Something many are doing since we are not
>> intercompatible anymore.
>>
>> Signed-off-by: Reynaldo H. Verdejo Pinochet 
>> ---
>>  libavutil/version.h | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> LGTM
>
> thx

minor nit: commit message typo (libavtuil -> libavutil).

>
> [...]
> --
> 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"
>
> ___
> 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 panorama filter

[Clément Bœsch]

On Sat, Dec 05, 2015 at 01:20:40PM -0500, Ganesh Ajjanagadde wrote:
[...]
> >> +
> >> +AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts);
> >> +if (!fmts_list)
> >> +return AVERROR(ENOMEM);
> >> +return ff_set_common_formats(ctx, fmts_list);
> 
> still leaky - when fmts_list is allocated correctly, and
> ff_set_common_formats fails. Proof: use the patch used for the proof
> regarding af_agate.
> 
> @Clement: found this while examining avfilter/vf_curves. Can you
> please do the needful there?
> 

i lost track of what's happening here, but isn't ff_set_common_formats()
freeing the list in case of failure?

That pattern is likely used in many places.

-- 
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] avfilter: add panorama filter

[Ganesh Ajjanagadde]

> On Sat, Dec 05, 2015 at 06:38:47PM +0100, Paul B Mahol wrote:
[...]
>> +AVFILTER_DEFINE_CLASS(panorama);
>> +
>> +static int query_formats(AVFilterContext *ctx)
>> +{
>> +static const enum AVPixelFormat pix_fmts[] = {
>> +AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA420P,
>> +AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ440P, 
>> AV_PIX_FMT_YUVJ422P,AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ411P,
>> +AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV422P, 
>> AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV411P, AV_PIX_FMT_YUV410P,
>> +AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP, AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE
>> +};

Seems a rather long list that is quite arbitrary. Any reason not to
use some "all" API provided in formats.h?

>> +
>> +AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts);
>> +if (!fmts_list)
>> +return AVERROR(ENOMEM);
>> +return ff_set_common_formats(ctx, fmts_list);

still leaky - when fmts_list is allocated correctly, and
ff_set_common_formats fails. Proof: use the patch used for the proof
regarding af_agate.

@Clement: found this while examining avfilter/vf_curves. Can you
please do the needful there?

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

Re: [FFmpeg-devel] [PATCH] avfilter: add panorama filter

[Ganesh Ajjanagadde]

On Sat, Dec 5, 2015 at 1:40 PM, Clément Bœsch  wrote:
> On Sat, Dec 05, 2015 at 01:20:40PM -0500, Ganesh Ajjanagadde wrote:
> [...]
>> >> +
>> >> +AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts);
>> >> +if (!fmts_list)
>> >> +return AVERROR(ENOMEM);
>> >> +return ff_set_common_formats(ctx, fmts_list);
>>
>> still leaky - when fmts_list is allocated correctly, and
>> ff_set_common_formats fails. Proof: use the patch used for the proof
>> regarding af_agate.
>>
>> @Clement: found this while examining avfilter/vf_curves. Can you
>> please do the needful there?
>>
>
> i lost track of what's happening here, but isn't ff_set_common_formats()
> freeing the list in case of failure?

Unfortunately not, it only unref's and does not free:
==25616== 40 bytes in 1 blocks are indirectly lost in loss record 7 of 14
==25616==at 0x4C2AD45: memalign (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25616==by 0x4C2AE0D: posix_memalign (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25616==by 0x77978C6: av_malloc (mem.c:97)
==25616==by 0x50DF1D7: av_malloc_array (mem.h:97)
==25616==by 0x50DF1D7: ff_make_format_list (formats.c:285)
==25616==by 0x511770F: query_formats (vf_curves.c:469)
==25616==by 0x50D33F5: filter_query_formats (avfiltergraph.c:307)
==25616==by 0x50D3BEB: query_formats (avfiltergraph.c:435)
==25616==by 0x50D48C2: graph_config_formats (avfiltergraph.c:1139)
==25616==by 0x50D48C2: avfilter_graph_config (avfiltergraph.c:1250)
==25616==by 0x419424: configure_filtergraph (ffmpeg_filter.c:1042)
==25616==by 0x423072: transcode_init (ffmpeg.c:3035)
==25616==by 0x424895: transcode (ffmpeg.c:4092)
==25616==by 0x407B53: main (ffmpeg.c:4314)

>
> That pattern is likely used in many places.

In that case a more sustainable solution may be useful. I don't know
and have no opinions on whether anything useful can be done in
formats.c/formats.h for helping here.
@Nicolas: any ideas?

One can argue that we do not need to address these leaks as they are
mostly "theoretical", but I personally am strongly against it unless
someone convinces me otherwise.

>
> --
> Clément B.
>
> ___
> 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] news: add a news entry for the AAC encoder experimental flag removal

[Ganesh Ajjanagadde]

On Sat, Dec 5, 2015 at 2:14 PM, Rostislav Pehlivanov
 wrote:
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  src/index | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/src/index b/src/index
> index d1d4a58..0c54046 100644
> --- a/src/index
> +++ b/src/index
> @@ -37,6 +37,27 @@
>  News
>
>
> +  The native FFmpeg encoder is out of 
> experimental!
> +  
> +After seven years the native FFmpeg AAC encoder has had its experimental 
> flag
> +removed and declared as ready for use. Subjective quality tests put the
> +encoder to be of equal or greater quality than most of the other encoders
> +available to the public.

Consider adding a link to such tests/how to verify this. Also list
what you are comparing to. Maybe even a pic with performance/quality
benchmarks.

In short, please add some more detail at your discretion.

> +  
> +Licensing has always been an issue with encoding AAC audio as most of the
> +encoders have had a license making FFmpeg indistributable if compiled 
> with
> +support for them. The fact that there now exists a fully open and truly
> +free AAC encoder integrated directly within the project means a lot to 
> those
> +who wish to use accepted and widespread standards.
> +  
> +The majority of the work done to bring the encoder up to quality was
> +done by Claudio Freire and Rostislav Pehlivanov. Also thanks to
> +http://d.hatena.ne.jp/kamedo2/;>Kamedo2 who does comparisons
> +and tests, the original authors and all past and current contributors to 
> the
> +encoder. Users are suggested and encouraged to use the encoder and 
> provide
> +feedback or breakage reports through our  href="https://trac.ffmpeg.org/;>bug tracker.

Did not know feedback also goes on the bug tracker. I don't really
know, maybe "feedback via IRC/ffmpeg-devel/private email" (pick
whatever subset you want)?

Consider refining the Changelog entry from "- extensive native AAC
encoder improvements" to "extensive native AAC encoder improvements
and removal of its experimental flag".

Anyway, great work, thanks!

> +  
> +
>Telepoint & MediaHub are now 
> supporting our project
>
>  A big thank you note goes to our newest supporters: MediaHub and 
> Telepoint.
> --
> 2.6.2
>
> ___
> 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] news: add a news entry for the AAC encoder experimental flag removal

[Timothy Gu]

On Sat, Dec 05, 2015 at 07:14:43PM +, Rostislav Pehlivanov wrote:
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  src/index | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/src/index b/src/index
> index d1d4a58..0c54046 100644
> --- a/src/index
> +++ b/src/index
> @@ -37,6 +37,27 @@
>  News
>
>  
> +  The native FFmpeg encoder is out of 
> experimental!

The native FFmpeg AAC encoder

The id could be a bit more descriptive. `aac_encoder_stable` sounds good
to me.

> +  
> +After seven years the native FFmpeg AAC encoder has had its experimental 
> flag
> +removed and declared as ready for use. Subjective quality tests put the

IMO, "ready for general use" is slightly more precise.

> +encoder to be of equal or greater quality than most of the other encoders
> +available to the public.
> +  

Open a new  here.

> +Licensing has always been an issue with encoding AAC audio as most of the
> +encoders have had a license making FFmpeg indistributable if compiled 
> with

configure outputs "unredistributable." Not sure which one is better from
a legal POV.

> +support for them. The fact that there now exists a fully open and truly
> +free AAC encoder integrated directly within the project means a lot to 
> those
> +who wish to use accepted and widespread standards.
> +  

Ditto.

> +The majority of the work done to bring the encoder up to quality was
> +done by Claudio Freire and Rostislav Pehlivanov. Also thanks to
> +http://d.hatena.ne.jp/kamedo2/;>Kamedo2 who does comparisons
> +and tests, the original authors and all past and current contributors to 
> the
> +encoder. Users are suggested and encouraged to use the encoder and 
> provide
> +feedback or breakage reports through our  href="https://trac.ffmpeg.org/;>bug tracker.
> +  

You could also mention GSoC's role in getting you started in
contributing to the encoder.

> +
>Telepoint & MediaHub are now 
> supporting our project
>
>  A big thank you note goes to our newest supporters: MediaHub and 
> Telepoint.

Rostislav and Claudio, thanks for all your work on the AAC encoder!

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

Re: [FFmpeg-devel] [PATCH] avfilter: add panorama filter

[Michael Niedermayer]

On Sat, Dec 05, 2015 at 06:38:47PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/vf_panorama.c | 437 
> ++
>  3 files changed, 439 insertions(+)
>  create mode 100644 libavfilter/vf_panorama.c
> 
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 8884d1d..5e0321f 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -193,6 +193,7 @@ OBJS-$(CONFIG_OWDENOISE_FILTER)  += 
> vf_owdenoise.o
>  OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
>  OBJS-$(CONFIG_PALETTEGEN_FILTER) += vf_palettegen.o
>  OBJS-$(CONFIG_PALETTEUSE_FILTER) += vf_paletteuse.o dualinput.o 
> framesync.o
> +OBJS-$(CONFIG_PANORAMA_FILTER)   += vf_panorama.o
>  OBJS-$(CONFIG_PERMS_FILTER)  += f_perms.o
>  OBJS-$(CONFIG_PERSPECTIVE_FILTER)+= vf_perspective.o
>  OBJS-$(CONFIG_PHASE_FILTER)  += vf_phase.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 0eeef53..952bddf 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -214,6 +214,7 @@ void avfilter_register_all(void)
>  REGISTER_FILTER(PAD,pad,vf);
>  REGISTER_FILTER(PALETTEGEN, palettegen, vf);
>  REGISTER_FILTER(PALETTEUSE, paletteuse, vf);
> +REGISTER_FILTER(PANORAMA,   panorama,   vf);
>  REGISTER_FILTER(PERMS,  perms,  vf);
>  REGISTER_FILTER(PERSPECTIVE,perspective,vf);
>  REGISTER_FILTER(PHASE,  phase,  vf);
> diff --git a/libavfilter/vf_panorama.c b/libavfilter/vf_panorama.c
> new file mode 100644
> index 000..b6bba64
> --- /dev/null
> +++ b/libavfilter/vf_panorama.c
> @@ -0,0 +1,437 @@
> +/*
> + * 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/avassert.h"
> +#include "libavutil/eval.h"
> +#include "libavutil/imgutils.h"
> +#include "libavutil/pixdesc.h"
> +#include "libavutil/opt.h"
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "internal.h"
> +#include "video.h"
> +
> +enum Projections {
> +SPHERE,
> +CUBE,
> +NB_PROJECTIONS,
> +};
> +
> +enum Faces {
> +LEFT,
> +FRONT,
> +RIGHT,
> +TOP,
> +BACK,
> +DOWN,
> +};
> +
> +struct XYRemap {
> +int vi, ui;
> +int v2, u2;
> +double a, b, c, d;
> +};
> +
> +typedef struct PanoramaContext {
> +const AVClass *class;
> +int in, out;
> +
> +int planewidth[4], planeheight[4];
> +int inplanewidth[4], inplaneheight[4];
> +int nb_planes;
> +
> +struct XYRemap *remap[4];
> +
> +int (*panorama)(struct PanoramaContext *s,
> +const uint8_t *src, uint8_t *dst,
> +int width, int height,
> +int in_linesize, int out_linesize,
> +struct XYRemap *remap);
> +} PanoramaContext;
> +
> +#define OFFSET(x) offsetof(PanoramaContext, x)
> +#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
> +
> +static const AVOption panorama_options[] = {
> +{ "input",  "set input projection",   OFFSET(in), AV_OPT_TYPE_INT,   
> {.i64=SPHERE}, 0, NB_PROJECTIONS-1, FLAGS, "in" },
> +{ "s", "spheric",  0, AV_OPT_TYPE_CONST, 
> {.i64=SPHERE}, 0,0, FLAGS, "in" },
> +{ "c", "cubic",0, AV_OPT_TYPE_CONST, 
> {.i64=CUBE},   0,0, FLAGS, "in" },
> +{ "output", "set output projection", OFFSET(out), AV_OPT_TYPE_INT,   
> {.i64=CUBE},   0, NB_PROJECTIONS-1, FLAGS, "out" },
> +{ "s", "spheric",  0, AV_OPT_TYPE_CONST, 
> {.i64=SPHERE}, 0,0, FLAGS, "out" },
> +{ "c", "cubic",0, AV_OPT_TYPE_CONST, 
> {.i64=CUBE},   0,0, FLAGS, "out" },
> +{ NULL }
> +};
> +
> +AVFILTER_DEFINE_CLASS(panorama);
> +
> +static int query_formats(AVFilterContext *ctx)
> +{
> +static const enum AVPixelFormat pix_fmts[] = {
> +AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUVA422P, 

Re: [FFmpeg-devel] [PATCH] probe TrueHD in MPEGTS

[Michael Niedermayer]

On Sat, Dec 05, 2015 at 08:19:51AM -0600, Rodger Combs wrote:
> ---
>  libavformat/utils.c | 1 +
>  1 file changed, 1 insertion(+)

LGTM

thx

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

[FFmpeg-devel] [PATCH] avfilter/formats: fix segfault when allocation fails

[Ganesh Ajjanagadde]

This is a somewhat subtle failure that can occur when the realloc_array
fails in FORMATS_REF.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/formats.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index 2b13cbf..95a6b11 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -445,7 +445,7 @@ do {\
 do {   \
 int idx = -1;  \
\
-if (!*ref) \
+if (!*ref || !(*ref)->refs)\
 return;\
\
 FIND_REF_INDEX(ref, idx);  \
-- 
2.6.3

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

Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add sidechaingate filter

[Clément Bœsch]

On Sat, Dec 05, 2015 at 06:20:29AM +, Paul B Mahol wrote:
[...]
> Yes, it was and still is wasted time, to find out that there is no
> leaking at all.

There is an allocation, so it could fail under certain context/system
conditions. There is also branching in that code assuming it could fail,
so we have to assume it can happen (or consider it will never and drop
many allocation checks altogether).  This branching is broken as
demonstrated by Ganesh (because if it is triggered, it will crash). So
while in practice this is not that important (because this allocation is
unlikely to happen), there is indeed a bug that need to be addressed.

-- 
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 6/8] avfilter/show_palette: fix memory leak

[Clément Bœsch]

On Fri, Dec 04, 2015 at 05:56:12PM -0500, Ganesh Ajjanagadde wrote:
> On Fri, Dec 4, 2015 at 5:29 PM, Marton Balint  wrote:
>   if ((ret = ff_formats_ref(in , >inputs[0]->out_formats)) < 0
>  ||
>   (ret = ff_formats_ref(out, >outputs[0]->in_formats)) < 0)
>  -return ret;
>  +goto fail;
>   return 0;
>  +fail:
> >>>
> >>>
>  +av_freep(>formats);
> >>>
> >>>
> >>> what if in==NULL?
> >>>
>  +av_freep();
> >>>
> >>>
>  +av_freep(>formats);
> >>>
> >>>
> >>> ditto
> >>>
>  +av_freep();
>  +return ret;
>   }
> >>
> >>
> >> Fixed locally with an if(in) and similar checks. Also applies to other
> >> patches I sent.
> >
> >
> > Maybe it's just me, but don't we usually use two labels for such cases?
> >
> > E.g.
> >
> > fail1:
> >av_freep(>xxx);
> > fail2:
> >av_freep();
> >return ret;
> 
> I don't really mind, I personally prefer a single goto as I find it
> logically simpler to analyze.
> 

I also prefer a if branching here.

-- 
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 3/3] avutil/threadmessage: fix condition broadcasting

[Clément Bœsch]

On Wed, Dec 02, 2015 at 03:57:31PM +0100, Clément Bœsch wrote:
[...]
> This second solution replaces the condition with two: one to notify the
> senders, and one to notify the receivers. This prevents senders from
> notifying other senders instead of a reader, and the other way around.
> It also avoid broadcasting to everyone like the first solution, and is,
> as a result in theory more optimized.
> ---
>  libavutil/threadmessage.c | 35 ---
>  1 file changed, 24 insertions(+), 11 deletions(-)
> 

ping, I'd like to apply this fix soon

[...]

-- 
Clément B.


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

[FFmpeg-devel] [PATCH] diracdec: Move strides to bytes, and pointer types to uint8_t.

[Kieran Kunhya]

Start templating functions for move to support 10-bit
Parts of this patch were written by Rostislav Pehlivanov
---
 libavcodec/dirac.c  |  10 +-
 libavcodec/dirac.h  |   3 +-
 libavcodec/diracdec.c   | 229 ++--
 libavformat/oggparsedirac.c |   4 +-
 4 files changed, 147 insertions(+), 99 deletions(-)

diff --git a/libavcodec/dirac.c b/libavcodec/dirac.c
index 07db919..aa82dd9 100644
--- a/libavcodec/dirac.c
+++ b/libavcodec/dirac.c
@@ -118,7 +118,7 @@ static const enum AVPixelFormat dirac_pix_fmt[2][3] = {
 /* [DIRAC_STD] 10.3 Parse Source Parameters.
  * source_parameters(base_video_format) */
 static int parse_source_parameters(AVCodecContext *avctx, GetBitContext *gb,
-   dirac_source_params *source)
+   dirac_source_params *source, int *bit_depth)
 {
 AVRational frame_rate = { 0, 0 };
 unsigned luma_depth = 8, luma_offset = 16;
@@ -239,6 +239,9 @@ static int parse_source_parameters(AVCodecContext *avctx, 
GetBitContext *gb,
 if (luma_depth > 8)
 av_log(avctx, AV_LOG_WARNING, "Bitdepth greater than 8\n");
 
+
+*bit_depth = luma_depth;
+
 avctx->pix_fmt = dirac_pix_fmt[!luma_offset][source->chroma_format];
 avcodec_get_chroma_sub_sample(avctx->pix_fmt, _x_shift, 
_y_shift);
 if ((source->width % (1<height % 
(1<width, source->height);
diff --git a/libavcodec/dirac.h b/libavcodec/dirac.h
index b0f955b..14653f1 100644
--- a/libavcodec/dirac.h
+++ b/libavcodec/dirac.h
@@ -55,6 +55,7 @@ typedef struct dirac_source_params {
 } dirac_source_params;
 
 int avpriv_dirac_parse_sequence_header(AVCodecContext *avctx, GetBitContext 
*gb,
-   dirac_source_params *source);
+   dirac_source_params *source,
+   int *bit_depth);
 
 #endif /* AVCODEC_DIRAC_H */
diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index ea16007..274f574 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -97,11 +97,12 @@ typedef struct {
 typedef struct SubBand {
 int level;
 int orientation;
-int stride;
+int stride; /* in bytes */
 int width;
 int height;
+int pshift;
 int quant;
-IDWTELEM *ibuf;
+uint8_t *ibuf;
 struct SubBand *parent;
 
 /* for low delay */
@@ -117,9 +118,9 @@ typedef struct Plane {
 int idwt_width;
 int idwt_height;
 int idwt_stride;
-IDWTELEM *idwt_buf;
-IDWTELEM *idwt_buf_base;
-IDWTELEM *idwt_tmp;
+uint8_t *idwt_buf;
+uint8_t *idwt_buf_base;
+uint8_t *idwt_tmp;
 
 /* block length */
 uint8_t xblen;
@@ -147,6 +148,9 @@ typedef struct DiracContext {
 int chroma_x_shift;
 int chroma_y_shift;
 
+int bit_depth;  /* bit depth */
+int pshift; /* pixel shift = bit_depth > 8   */
+
 int zero_res;   /* zero residue flag */
 int is_arith;   /* whether coeffs use arith or golomb coding */
 int low_delay;  /* use the low delay syntax  */
@@ -339,9 +343,9 @@ static int alloc_sequence_buffers(DiracContext *s)
 w = FFALIGN(CALC_PADDING(w, MAX_DWT_LEVELS), 8); /* FIXME: Should this 
be 16 for SSE??? */
 h = top_padding + CALC_PADDING(h, MAX_DWT_LEVELS) + max_yblen/2;
 
-s->plane[i].idwt_buf_base = av_mallocz_array((w+max_xblen), h * 
sizeof(IDWTELEM));
-s->plane[i].idwt_tmp  = av_malloc_array((w+16), sizeof(IDWTELEM));
-s->plane[i].idwt_buf  = s->plane[i].idwt_buf_base + top_padding*w;
+s->plane[i].idwt_buf_base = av_mallocz_array((w+max_xblen), h * (2 << 
s->pshift));
+s->plane[i].idwt_tmp  = av_malloc_array((w+16), 2 << s->pshift);
+s->plane[i].idwt_buf  = s->plane[i].idwt_buf_base + 
(top_padding*w)*(2 << s->pshift);
 if (!s->plane[i].idwt_buf_base || 

Re: [FFmpeg-devel] Memory leaks in libavformat/segment.c

[Hendrik Leppkes]

On Sat, Dec 5, 2015 at 11:02 AM, Qier LU  wrote:
> Hi Michael,
>
> The attached is against git master.
>

The patch is probably fine now. Maybe it would be saner to actually
use av_reallocp on the filename to avoid having to allocate and free
it in different places?

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

Re: [FFmpeg-devel] [PATCH] avfilter/codecview/WIP: add QP support

[Clément Bœsch]

On Sat, Dec 05, 2015 at 03:52:42AM +0100, Michael Niedermayer wrote:
> On Fri, Dec 04, 2015 at 05:06:34PM +0100, Clément Bœsch wrote:
> > On Mon, Aug 31, 2015 at 04:43:15PM +0200, Michael Niedermayer wrote:
> > > On Mon, Aug 31, 2015 at 03:29:03PM +0200, Clément Bœsch wrote:
> > > > From: Clément Bœsch 
> > > > 
> > > > ---
> > > > I'm not sure I'm doing the correct thing here, but maybe that's just 
> > > > because my
> > > > samples aren't relevant.
> > > 
> > > i tried
> > > ./ffplay tests/data/fate/vsynth1-mpeg4-qprd.avi -debug 8192
> > > ./ffplay tests/data/fate/vsynth1-mpeg4-qprd.avi -flags2 +export_mvs -vf 
> > > codecview=qp=1
> > > 
> > > the output looks quite different
> > 
> > Ah, indeed. The normalized QP is scaled in [0;63] so I fixed the filter to
> > rescale the value the same way as in mpeg video debug code. New patch
> > attached.
> > 
> > -- 
> > Clément B.
> 
> >  doc/filters.texi   |3 +++
> >  libavfilter/vf_codecview.c |   43 
> > ++-
> >  2 files changed, 45 insertions(+), 1 deletion(-)
> > 5a4fd233be3115808f47ddf06db52f210053b56d  
> > 0001-avfilter-codecview-add-QP-support.patch
> > From 6fc6784793adb65b7e149d7d037460de411f9b39 Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?= 
> > Date: Mon, 31 Aug 2015 15:18:34 +0200
> > Subject: [PATCH] avfilter/codecview: add QP support
> 
> should be ok if tested
> 

applied, thanks

-- 
Clément B.


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

[FFmpeg-devel] [PATCHv2] avcodec/aacsbr_tablegen: always initialize tables at runtime

[Ganesh Ajjanagadde]

This gets rid of virtually useless hardcoded tables hackery. The reason
it is useless is that a 320 element lut is anyway placed regardless of
--enable-hardcoded-tables, from which all necessary tables are trivially
derived at runtime at very low cost:

sample benchmark (x86-64, Haswell, GNU/Linux, single run is really
what is relevant here since looping drastically changes the bench). Fluctuations
are on the order of 10% for the single run test:
39400 decicycles in aacsbr_tableinit,   1 runs,  0 skips
25325 decicycles in aacsbr_tableinit,   2 runs,  0 skips
18475 decicycles in aacsbr_tableinit,   4 runs,  0 skips
15008 decicycles in aacsbr_tableinit,   8 runs,  0 skips
13016 decicycles in aacsbr_tableinit,  16 runs,  0 skips
12005 decicycles in aacsbr_tableinit,  32 runs,  0 skips
11546 decicycles in aacsbr_tableinit,  64 runs,  0 skips
11506 decicycles in aacsbr_tableinit, 128 runs,  0 skips
11500 decicycles in aacsbr_tableinit, 256 runs,  0 skips
11183 decicycles in aacsbr_tableinit, 509 runs,  3 skips

Tested with FATE with/without --enable-hardcoded-tables.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/Makefile |  8 ++--
 libavcodec/aacsbr_fixed_tablegen.c  | 39 -
 libavcodec/aacsbr_fixed_tablegen.h  |  4 
 libavcodec/aacsbr_tablegen.c| 39 -
 libavcodec/aacsbr_tablegen.h|  4 
 libavcodec/aacsbr_tablegen_common.h |  4 
 6 files changed, 2 insertions(+), 96 deletions(-)
 delete mode 100644 libavcodec/aacsbr_fixed_tablegen.c
 delete mode 100644 libavcodec/aacsbr_tablegen.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index d85215d..a4c35b9 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -965,8 +965,6 @@ TOOLS = fourcc2pixfmt
 
 HOSTPROGS = aacps_tablegen  \
 aacps_fixed_tablegen\
-aacsbr_tablegen \
-aacsbr_fixed_tablegen   \
 cbrt_tablegen   \
 cbrt_fixed_tablegen \
 cos_tablegen\
@@ -996,8 +994,8 @@ else
 $(SUBDIR)%_tablegen$(HOSTEXESUF): HOSTCFLAGS += -DCONFIG_SMALL=0
 endif
 
-GEN_HEADERS = cbrt_tables.h cbrt_fixed_tables.h aacps_tables.h 
aacps_fixed_tables.h aacsbr_tables.h \
-  aacsbr_fixed_tables.h dsd_tables.h dv_tables.h \
+GEN_HEADERS = cbrt_tables.h cbrt_fixed_tables.h aacps_tables.h 
aacps_fixed_tables.h \
+  dsd_tables.h dv_tables.h \
   sinewin_tables.h sinewin_fixed_tables.h mpegaudio_tables.h 
motionpixels_tables.h \
   pcm_tables.h qdm2_tables.h
 GEN_HEADERS := $(addprefix $(SUBDIR), $(GEN_HEADERS))
@@ -1010,8 +1008,6 @@ $(SUBDIR)aacdec.o: $(SUBDIR)cbrt_tables.h
 $(SUBDIR)aacdec_fixed.o: $(SUBDIR)cbrt_fixed_tables.h
 $(SUBDIR)aacps_float.o: $(SUBDIR)aacps_tables.h
 $(SUBDIR)aacps_fixed.o: $(SUBDIR)aacps_fixed_tables.h
-$(SUBDIR)aacsbr.o: $(SUBDIR)aacsbr_tables.h
-$(SUBDIR)aacsbr_fixed.o: $(SUBDIR)aacsbr_fixed_tables.h
 $(SUBDIR)aactab_fixed.o: $(SUBDIR)aac_fixed_tables.h
 $(SUBDIR)dsddec.o: $(SUBDIR)dsd_tables.h
 $(SUBDIR)dvenc.o: $(SUBDIR)dv_tables.h
diff --git a/libavcodec/aacsbr_fixed_tablegen.c 
b/libavcodec/aacsbr_fixed_tablegen.c
deleted file mode 100644
index 832fcb7..000
--- a/libavcodec/aacsbr_fixed_tablegen.c
+++ /dev/null
@@ -1,39 +0,0 @@
-/*
- * Header file for hardcoded AAC SBR windows
- *
- * Copyright (c) 2014 Reimar Döffinger 
- *
- * 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 
-#define CONFIG_HARDCODED_TABLES 0
-#define USE_FIXED 1
-#include "aacsbr_fixed_tablegen.h"
-#include "tableprint.h"
-
-int main(void)
-{
-aacsbr_tableinit();
-
-write_fileheader();
-
-WRITE_ARRAY_ALIGNED("static const", 32, int32_t, sbr_qmf_window_ds);
-WRITE_ARRAY_ALIGNED("static const", 32, int32_t, sbr_qmf_window_us);
-
-return 0;
-}
diff --git 

Re: [FFmpeg-devel] [PATCH] avcodec/aacsbr_tablegen: always initialize tables at runtime

[Ganesh Ajjanagadde]

On Thu, Dec 3, 2015 at 8:13 PM, Ganesh Ajjanagadde
 wrote:
> On Sun, Nov 29, 2015 at 10:58 PM, Ganesh Ajjanagadde
>  wrote:
>> This gets rid of virtually useless hardcoded tables hackery. The reason
>> it is useless is that a 320 element lut is anyway placed regardless of
>> --enable-hardcoded-tables, from which all necessary tables are trivially
>> derived at runtime at very low cost:
>>
>> sample benchmark (x86-64, Haswell, GNU/Linux, single run is really
>> what is relevant here since looping drastically changes the bench). 
>> Fluctuations
>> are on the order of 10% for the single run test:
>> 39400 decicycles in aacsbr_tableinit,   1 runs,  0 skips
>> 25325 decicycles in aacsbr_tableinit,   2 runs,  0 skips
>> 18475 decicycles in aacsbr_tableinit,   4 runs,  0 skips
>> 15008 decicycles in aacsbr_tableinit,   8 runs,  0 skips
>> 13016 decicycles in aacsbr_tableinit,  16 runs,  0 skips
>> 12005 decicycles in aacsbr_tableinit,  32 runs,  0 skips
>> 11546 decicycles in aacsbr_tableinit,  64 runs,  0 skips
>> 11506 decicycles in aacsbr_tableinit, 128 runs,  0 skips
>> 11500 decicycles in aacsbr_tableinit, 256 runs,  0 skips
>> 11183 decicycles in aacsbr_tableinit, 509 runs,  3 skips
>>
>> Tested with FATE with/without --enable-hardcoded-tables.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavcodec/Makefile |  8 ++-
>>  libavcodec/aacsbr_fixed_tablegen.c  | 42 
>> -
>>  libavcodec/aacsbr_fixed_tablegen.h  |  4 
>>  libavcodec/aacsbr_tablegen.c| 42 
>> -
>>  libavcodec/aacsbr_tablegen.h|  4 
>>  libavcodec/aacsbr_tablegen_common.h |  4 
>>  6 files changed, 2 insertions(+), 102 deletions(-)
>>  delete mode 100644 libavcodec/aacsbr_fixed_tablegen.c
>>  delete mode 100644 libavcodec/aacsbr_tablegen.c
[...]
> ping for AAC people or anyone else interested.

rebased on master, posted v2 that is essentially identical.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] news: add a news entry for the AAC encoder experimental flag removal

[Ganesh Ajjanagadde]

On Sat, Dec 5, 2015 at 3:27 PM, Rostislav Pehlivanov
 wrote:
> Sorry, sent out this email to Ganesh only at first. Posting it to the ML
> now.
>
>>Consider adding a link to such tests/how to verify this.
> Subjective tests. I did try to compare them using an SSIM audio filter
> (based on a journal paper) I wrote for lavfi a few months ago but I gave up.
> Spoke with the Opus guys who outright told me that it makes no sense to use
> SSIM and that basically all of the tests done while developing Opus were
> subjective. So I never got the filter merged because it would have been a
> pointless statistic.

Thanks for the clarification.

Frankly, I never buy PSNR/SSIM for audio and video myself: it is very
clear that they were designed as mathematically convenient due to
relations to Euclidean norms and hence to allow possible integration
into the standard L_2 theory. Users may or may not care depending on
their background or personal taste. Of course, it does not mean they
are useless, since they can give automated, reproducible tests for
regression like FATE, and in the absence of anything better, they
stand. Or in other words, the actual choice I find arbitrary.

>
>>Also list
>>what you are comparing to.
> Speaking in general and for libfdk_aac in specific. I am not going to
> mention its name in the blog post.
>
>>Maybe even a pic with performance/quality
>>benchmarks.
> I don't see pictures in any news and I wouldn't want to break that
> tradition.
> Encoding performance is twice as slow compared to libfdk_aac. Which is still
> 12x realtime on my poor Celeron B820. In the grand scheme of things this is
> insignificant.

Maybe, maybe not. I can't judge if that perf number is important.
Nevertheless, I personally always highly value complete honesty wrt to
public facing announcements, academic papers, etc. That honesty
includes listing pros and cons.

As for the pic: I don't see why we can't break with tradition :).
FFmpeg is after all a multimedia framework. According to your claim
above, such a pic is not easy due to subjective nature, so ok.

>
>>In short, please add some more detail at your discretion.
> As I said earlier, this is not something I or anyone else can show nor prove
> to be valid in general for all people for all audio files. There is just a
> general agreement among the encoder developers that yes, for some samples
> the encoder sounds better at 128kbps and yes, for some samples it sounds
> worse. But the prevalent idea is that the encoder is transparent for most
> files encoded at 128kbps, which is the de-facto standard CBR bitrate for
> AAC.
> But don't take my word for it. Test it yourself.

No problem, I trust you :) - I don't use AAC myself, and am not an
audiophile to really judge.

>
>>Did not know feedback also goes on the bug tracker. I don't really
>>know, maybe "feedback via IRC/ffmpeg-devel/private email" (pick
>>whatever subset you want)?
> There's a large trac ticket with over 450 replies. That's where the main
> source of external feedback comes from. Mainly from Kamedo2 whom I credited.
>
>>Consider refining the Changelog entry from "- extensive native AAC
>>encoder improvements" to "extensive native AAC encoder improvements
>>and removal of its experimental flag".
> Did that slightly before I sent the mail.
>
>>Anyway, great work, thanks!
>
> On 5 December 2015 at 19:29, Ganesh Ajjanagadde  wrote:
>>
>> On Sat, Dec 5, 2015 at 2:14 PM, Rostislav Pehlivanov
>>  wrote:
>> > Signed-off-by: Rostislav Pehlivanov 
>> > ---
>> >  src/index | 21 +
>> >  1 file changed, 21 insertions(+)
>> >
>> > diff --git a/src/index b/src/index
>> > index d1d4a58..0c54046 100644
>> > --- a/src/index
>> > +++ b/src/index
>> > @@ -37,6 +37,27 @@
>> >  News
>> >
>> >
>> > +  The native FFmpeg encoder is out of
>> > experimental!
>> > +  
>> > +After seven years the native FFmpeg AAC encoder has had its
>> > experimental flag
>> > +removed and declared as ready for use. Subjective quality tests put
>> > the
>> > +encoder to be of equal or greater quality than most of the other
>> > encoders
>> > +available to the public.
>>
>> Consider adding a link to such tests/how to verify this. Also list
>> what you are comparing to. Maybe even a pic with performance/quality
>> benchmarks.
>>
>> In short, please add some more detail at your discretion.
>>
>> > +  
>> > +Licensing has always been an issue with encoding AAC audio as most
>> > of the
>> > +encoders have had a license making FFmpeg indistributable if
>> > compiled with
>> > +support for them. The fact that there now exists a fully open and
>> > truly
>> > +free AAC encoder integrated directly within the project means a lot
>> > to those
>> > +who wish to use accepted and widespread standards.
>> > +  
>> > +The majority of the work done to bring the encoder up to quality
>> > was
>> > +done by 

Re: [FFmpeg-devel] [PATCH 3/8] avfilter/af_channelmap: fix memory leak

[Paul B Mahol]

On 12/4/15, Ganesh Ajjanagadde  wrote:
> Recent commits 6aaac24d72a7da631173209841a3944fcb4a3309 and
> 3835554bf8ed78539a3492c239f979c0ab03a15f made progress towards cleaning
> up usage of the formats API, and in particular fixed possible NULL pointer
> dereferences.
>
> This commit addresses the issue of possible resource leaks when some
> intermediate
> call fails.
>
> Tested with valgrind --leak-check=full --show-leak-kinds=all, and manual
> simulation
> of malloc/realloc failures.
>
> Fixes: CID 1338330.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavfilter/af_channelmap.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/af_channelmap.c b/libavfilter/af_channelmap.c
> index 9e95a98..dfe3d48 100644
> --- a/libavfilter/af_channelmap.c
> +++ b/libavfilter/af_channelmap.c
> @@ -292,14 +292,22 @@ static int channelmap_query_formats(AVFilterContext
> *ctx)
>  int ret;
>
>  layouts = ff_all_channel_layouts();
> +if (!layouts) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
>  if ((ret = ff_add_channel_layout (_layouts,
> s->output_layout)) < 0 ||
>  (ret = ff_set_common_formats (ctx ,
> ff_planar_sample_fmts() )) < 0 ||
>  (ret = ff_set_common_samplerates (ctx ,
> ff_all_samplerates())) < 0 ||
>  (ret = ff_channel_layouts_ref(layouts ,
> >inputs[0]->out_channel_layouts)) < 0 ||
>  (ret = ff_channel_layouts_ref(channel_layouts ,
> >outputs[0]->in_channel_layouts)) < 0)
> -return ret;
> +goto fail;
>
>  return 0;
> +fail:
> +av_freep(>channel_layouts);
> +av_freep();
> +return ret;
>  }
>
>  static int channelmap_filter_frame(AVFilterLink *inlink, AVFrame *buf)
> --
> 2.6.3
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH v2] news: add a news entry for the AAC encoder experimental flag removal

[Rostislav Pehlivanov]

Feel free to edit the part about the GSoC or anything you think isn't
enough. I know why it's important, so if you think it's not enough just add
whatever you think sounds right. After all I'm not the best person to write
about myself, I'm too biased :)

On 5 December 2015 at 20:49, Rostislav Pehlivanov 
wrote:

> Signed-off-by: Rostislav Pehlivanov 
> ---
>  src/index | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/src/index b/src/index
> index d1d4a58..ea2ca7e 100644
> --- a/src/index
> +++ b/src/index
> @@ -37,6 +37,32 @@
>  News
>
>
> +  The native FFmpeg encoder is now
> stable!
> +  
> +After seven years the native FFmpeg AAC encoder has had its
> experimental flag
> +removed and declared as ready for general use. The encoder is
> transparent
> +at 128kbps for most samples tested with artifacts only appearing in
> extreme
> +cases. Subjective quality tests put the encoder to be of equal or
> greater
> +quality than most of the other encoders available to the public.
> +  
> +  
> +Licensing has always been an issue with encoding AAC audio as most of
> the
> +encoders have had a license making FFmpeg unredistributable if
> compiled with
> +support for them. The fact that there now exists a fully open and
> truly
> +free AAC encoder integrated directly within the project means a lot
> to those
> +who wish to use accepted and widespread standards.
> +  
> +  
> +The majority of the work done to bring the encoder up to quality was
> started
> +duing this year's GSoC by developer Claudio Freire and Rostislav
> Pehlivanov.
> +Both continued to work on the encoder with the latter joining as a
> developer
> +and mainainer, working on other parts of the project as well. Also,
> thanks
> +to http://d.hatena.ne.jp/kamedo2/;>Kamedo2 who does
> comparisons
> +and tests, the original authors and all past and current contributors
> to the
> +encoder. Users are suggested and encouraged to use the encoder and
> provide
> +feedback or breakage reports through our https://trac.ffmpeg.org/;>bug tracker.
> +  
> +
>Telepoint & MediaHub are now
> supporting our project
>
>  A big thank you note goes to our newest supporters: MediaHub and
> Telepoint.
> --
> 2.6.2
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 02/10] ffplay: use hypot()

[Ganesh Ajjanagadde]

On Sun, Nov 22, 2015 at 12:05 PM, Ganesh Ajjanagadde
 wrote:
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  ffplay.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/ffplay.c b/ffplay.c
> index 2c1817e..36da8a5 100644
> --- a/ffplay.c
> +++ b/ffplay.c
> @@ -1115,9 +1115,9 @@ static void video_audio_display(VideoState *s)
>   * directly access it but it is more than fast enough. */
>  for (y = 0; y < s->height; y++) {
>  double w = 1 / sqrt(nb_freq);
> -int a = sqrt(w * sqrt(data[0][2 * y + 0] * data[0][2 * y + 
> 0] + data[0][2 * y + 1] * data[0][2 * y + 1]));
> -int b = (nb_display_channels == 2 ) ? sqrt(w * 
> sqrt(data[1][2 * y + 0] * data[1][2 * y + 0]
> -   + data[1][2 * y + 1] * data[1][2 * y + 1])) : a;
> +int a = sqrt(w * hypot(data[0][2 * y + 0], data[0][2 * y + 
> 1]));
> +int b = (nb_display_channels == 2 ) ? sqrt(w * 
> hypot(data[1][2 * y + 0], data[1][2 * y + 1]))
> +: a;
>  a = FFMIN(a, 255);
>  b = FFMIN(b, 255);
>  fgcolor = SDL_MapRGB(screen->format, a, b, (a + b) / 2);
> --
> 2.6.2
>

@Marton: are you fine with this? I think it improves readability;
accuracy benefits are likely irrelevant here.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] news: add a news entry for the AAC encoder experimental flag removal

[Lou Logan]

On Sat, Dec 5, 2015, at 12:59 PM, Lou Logan wrote:

> Rest LGTM. I'm unable to commit at the moment, but I'll do that within 5
> hrs, including the typo Ganesh noticed, unless someone else does first.

Pushed and I'll mention on Twitter.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/libvo-aac: Mark the encoder as experimental

[Carl Eugen Hoyos]

Hi!

I prefer attached patch over removing the encoder immediately.

Carl Eugen
diff --git a/Changelog b/Changelog
index ad13d88..6555351 100644
--- a/Changelog
+++ b/Changelog
@@ -42,6 +42,7 @@ version :
 - mipsdspr1 option has been renamed to mipsdsp
 - aemphasis filter
 - mips32r5 option has been removed
+- add experimental flag to the libvo-aac encoder
 
 
 version 2.8:
diff --git a/libavcodec/libvo-aacenc.c b/libavcodec/libvo-aacenc.c
index 7f21ad2..7b983b7 100644
--- a/libavcodec/libvo-aacenc.c
+++ b/libavcodec/libvo-aacenc.c
@@ -194,7 +194,8 @@ AVCodec ff_libvo_aacenc_encoder = {
 .encode2= aac_encode_frame,
 .close  = aac_encode_close,
 .supported_samplerates = mpeg4audio_sample_rates,
-.capabilities   = AV_CODEC_CAP_SMALL_LAST_FRAME | AV_CODEC_CAP_DELAY,
+.capabilities   = AV_CODEC_CAP_SMALL_LAST_FRAME | AV_CODEC_CAP_DELAY |
+  AV_CODEC_CAP_EXPERIMENTAL,
 .sample_fmts= (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_S16,
  AV_SAMPLE_FMT_NONE },
 };
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: implement vp9 dxva2 hwaccel

[Hendrik Leppkes]

On Fri, Dec 4, 2015 at 3:24 PM, Hendrik Leppkes  wrote:
> On Fri, Dec 4, 2015 at 2:55 PM, Ronald S. Bultje  wrote:
>> Hi,
>>
>> On Thu, Dec 3, 2015 at 5:13 AM, Hendrik Leppkes  wrote:
>>
>>> +/* Create an annex B bitstream buffer with only slice NAL and
>>> finalize slice */
>>>
>>
>> What does this comment mean? I suppose it's copy-pasted from someplace else
>> and doesn't really belong here?
>>
>> I can't really review the changes themselves, it's fairly HW specific, so
>> I'd say it's probably OK but I'm probably also not the right person to
>> review it :).
>>
>
> Oh yeah that comment is copied, should just get rid of it since its
> not even accurate, the VP9 bitstream buffer contains everything,
> including frame headers and whatnot, while for h264 its only slices.

Last call for anyone to review it. History has shown that reviews for
dxva2 patches are hard to come by, but since I'm the maintainer of
these things, either speak up now or it'll just get pushed. :)

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

Re: [FFmpeg-devel] Memory leaks in libavformat/segment.c

[Qier LU]

Hi Michael,

The attached is against git master.

On Sat, Dec 5, 2015 at 5:34 AM, Michael Niedermayer 
wrote:

> On Fri, Dec 04, 2015 at 11:20:17AM +0800, Lvqier wrote:
> > Hi,
> >
> > I am using FFmpeg to generate mpegts segments. FFmpeg has memory
> > leaks, see the valgrind output in the attachment.
> >
> > Command line to reproduce:
> > > valgrind --tool=memcheck --leak-check=full ./ffmpeg_g -f decklink
> > -i 'DeckLink Mini Recorder@14' -map 0 -acodec libvo_aacenc -vcodec
> > libx264 -pix_fmt yuv420p -vprofile baseline -q 2 -r 25 -g 25 -dn -f
> > stream_segment -segment_format mpegts -segment_time 10
> > /dev/shm/capture/libav-%010d.ts
> >
> > I have read the source code of libavformat/segment.c and make a
> > patch which is attached as well to fix it.
> >
> > --
> > /Best Regards,
> > lvqier - lvq...@gmail.com 
> > /
> >
> > **
> > 青春如烟，唱一首笑忘歌
> >
>
> >  segment.c |3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > ecd80dc49306e15e9eff71f9192d7a861e53c4e5  patch.diff
> > --- ../ffmpeg-2.8.1/libavformat/segment.c 2015-09-09
> 09:17:47.0 +0800
>
> patches should be against git master
>
>
> > +++ libavformat/segment.c 2015-12-03 14:37:45.0 +0800
> > @@ -388,6 +388,7 @@
> >
> >  end:
> >  avio_closep(>pb);
> > +av_freep(>cur_entry.filename);
> >
> >  return ret;
> >  }
> > @@ -887,7 +888,7 @@
> >  av_opt_free(seg);
> >  av_freep(>times);
> >  av_freep(>frames);
> > -av_freep(>cur_entry.filename);
>
> > +//av_freep(>cur_entry.filename);
>
> outcommented code like this doesnt belong in git master
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Opposition brings concord. Out of discord comes the fairest harmony.
> -- Heraclitus
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>


-- 
牛奶糖有着让人幸福的味道
尝一下的话就会在嘴里像花儿绽放一样
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 8432d0f..b5ee207 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -388,6 +388,7 @@ static int segment_end(AVFormatContext *s, int 
write_trailer, int is_last)
 
 end:
 avio_closep(>pb);
+av_freep(>cur_entry.filename);
 
 return ret;
 }
@@ -887,7 +888,6 @@ fail:
 av_opt_free(seg);
 av_freep(>times);
 av_freep(>frames);
-av_freep(>cur_entry.filename);
 
 cur = seg->segment_list_entries;
 while (cur) {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] news: add a news entry for the AAC encoder experimental flag removal

[Rostislav Pehlivanov]

Sorry, sent out this email to Ganesh only at first. Posting it to the ML
now.

>Consider adding a link to such tests/how to verify this.
Subjective tests. I did try to compare them using an SSIM audio filter
(based on a journal paper) I wrote for lavfi a few months ago but I gave
up. Spoke with the Opus guys who outright told me that it makes no sense to
use SSIM and that basically all of the tests done while developing Opus
were subjective. So I never got the filter merged because it would have
been a pointless statistic.

>Also list
>what you are comparing to.
Speaking in general and for libfdk_aac in specific. I am not going to
mention its name in the blog post.

>Maybe even a pic with performance/quality
>benchmarks.
I don't see pictures in any news and I wouldn't want to break that
tradition.
Encoding performance is twice as slow compared to libfdk_aac. Which is
still 12x realtime on my poor Celeron B820. In the grand scheme of things
this is insignificant.

>In short, please add some more detail at your discretion.
As I said earlier, this is not something I or anyone else can show nor
prove to be valid in general for all people for all audio files. There is
just a general agreement among the encoder developers that yes, for some
samples the encoder sounds better at 128kbps and yes, for some samples it
sounds worse. But the prevalent idea is that the encoder is transparent for
most files encoded at 128kbps, which is the de-facto standard CBR bitrate
for AAC.
But don't take my word for it. Test it yourself.

>Did not know feedback also goes on the bug tracker. I don't really
>know, maybe "feedback via IRC/ffmpeg-devel/private email" (pick
>whatever subset you want)?
There's a large trac ticket with over 450 replies. That's where the main
source of external feedback comes from. Mainly from Kamedo2 whom I credited.

>Consider refining the Changelog entry from "- extensive native AAC
>encoder improvements" to "extensive native AAC encoder improvements
>and removal of its experimental flag".
Did that slightly before I sent the mail.

>Anyway, great work, thanks!

On 5 December 2015 at 19:29, Ganesh Ajjanagadde  wrote:

> On Sat, Dec 5, 2015 at 2:14 PM, Rostislav Pehlivanov
>  wrote:
> > Signed-off-by: Rostislav Pehlivanov 
> > ---
> >  src/index | 21 +
> >  1 file changed, 21 insertions(+)
> >
> > diff --git a/src/index b/src/index
> > index d1d4a58..0c54046 100644
> > --- a/src/index
> > +++ b/src/index
> > @@ -37,6 +37,27 @@
> >  News
> >
> >
> > +  The native FFmpeg encoder is out of
> experimental!
> > +  
> > +After seven years the native FFmpeg AAC encoder has had its
> experimental flag
> > +removed and declared as ready for use. Subjective quality tests put
> the
> > +encoder to be of equal or greater quality than most of the other
> encoders
> > +available to the public.
>
> Consider adding a link to such tests/how to verify this. Also list
> what you are comparing to. Maybe even a pic with performance/quality
> benchmarks.
>
> In short, please add some more detail at your discretion.
>
> > +  
> > +Licensing has always been an issue with encoding AAC audio as most
> of the
> > +encoders have had a license making FFmpeg indistributable if
> compiled with
> > +support for them. The fact that there now exists a fully open and
> truly
> > +free AAC encoder integrated directly within the project means a lot
> to those
> > +who wish to use accepted and widespread standards.
> > +  
> > +The majority of the work done to bring the encoder up to quality was
> > +done by Claudio Freire and Rostislav Pehlivanov. Also thanks to
> > +http://d.hatena.ne.jp/kamedo2/;>Kamedo2 who does
> comparisons
> > +and tests, the original authors and all past and current
> contributors to the
> > +encoder. Users are suggested and encouraged to use the encoder and
> provide
> > +feedback or breakage reports through our https://trac.ffmpeg.org/;>bug tracker.
>
> Did not know feedback also goes on the bug tracker. I don't really
> know, maybe "feedback via IRC/ffmpeg-devel/private email" (pick
> whatever subset you want)?
>
> Consider refining the Changelog entry from "- extensive native AAC
> encoder improvements" to "extensive native AAC encoder improvements
> and removal of its experimental flag".
>
> Anyway, great work, thanks!
>
> > +  
> > +
> >Telepoint & MediaHub are now
> supporting our project
> >
> >  A big thank you note goes to our newest supporters: MediaHub and
> Telepoint.
> > --
> > 2.6.2
> >
> > ___
> > 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 v2] news: add a news entry for the AAC encoder experimental flag removal

[Lou Logan]

On Sat, Dec 5, 2015, at 11:49 AM, Rostislav Pehlivanov wrote:
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  src/index | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/src/index b/src/index
> index d1d4a58..ea2ca7e 100644
> --- a/src/index
> +++ b/src/index
> @@ -37,6 +37,32 @@
>  News
>
>  
> +  The native FFmpeg encoder is now
> stable!

Missing "AAC" in the title.

Rest LGTM. I'm unable to commit at the moment, but I'll do that within 5
hrs, including the typo Ganesh noticed, unless someone else does first.

Thanks to everyone who worked on this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/8] avfilter/af_channelmap: fix memory leak

[Ganesh Ajjanagadde]

On Sat, Dec 5, 2015 at 3:50 PM, Paul B Mahol  wrote:
> On 12/4/15, Ganesh Ajjanagadde  wrote:
>> Recent commits 6aaac24d72a7da631173209841a3944fcb4a3309 and
>> 3835554bf8ed78539a3492c239f979c0ab03a15f made progress towards cleaning
>> up usage of the formats API, and in particular fixed possible NULL pointer
>> dereferences.
>>
>> This commit addresses the issue of possible resource leaks when some
>> intermediate
>> call fails.
>>
>> Tested with valgrind --leak-check=full --show-leak-kinds=all, and manual
>> simulation
>> of malloc/realloc failures.
>>
>> Fixes: CID 1338330.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavfilter/af_channelmap.c | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavfilter/af_channelmap.c b/libavfilter/af_channelmap.c
>> index 9e95a98..dfe3d48 100644
>> --- a/libavfilter/af_channelmap.c
>> +++ b/libavfilter/af_channelmap.c
>> @@ -292,14 +292,22 @@ static int channelmap_query_formats(AVFilterContext
>> *ctx)
>>  int ret;
>>
>>  layouts = ff_all_channel_layouts();
>> +if (!layouts) {
>> +ret = AVERROR(ENOMEM);
>
> Consider this: ff_all_channel_layouts returns NULL.
>
>> +goto fail;
>
> Ok, we do not return immediately but use gotos, whatever...
>
>> +}
>>  if ((ret = ff_add_channel_layout (_layouts,
>> s->output_layout)) < 0 ||
>>  (ret = ff_set_common_formats (ctx ,
>> ff_planar_sample_fmts() )) < 0 ||
>>  (ret = ff_set_common_samplerates (ctx ,
>> ff_all_samplerates())) < 0 ||
>>  (ret = ff_channel_layouts_ref(layouts ,
>> >inputs[0]->out_channel_layouts)) < 0 ||
>>  (ret = ff_channel_layouts_ref(channel_layouts ,
>> >outputs[0]->in_channel_layouts)) < 0)
>> -return ret;
>> +goto fail;
>>
>>  return 0;
>> +fail:
>> +av_freep(>channel_layouts);
>
> What happens here if layouts is NULL ?

Clement has asked this for another one of these, and I replied there
saying that I fixed it locally, and that such a remark applies to all
other patches sent in the set. I did not want to ping all the other
patches. Nevertheless, thanks for pointing it out.

>
>> +av_freep();
>> +return ret;
>>  }
>>
>>  static int channelmap_filter_frame(AVFilterLink *inlink, AVFrame *buf)
>> --
>> 2.6.3
>>
>> ___
>> 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] news: add a news entry for the AAC encoder experimental flag removal

[Rostislav Pehlivanov]

Sorry, sent out this email to Ganesh only at first. Posting it to the ML
now.

>Consider adding a link to such tests/how to verify this.
Subjective tests. I did try to compare them using an SSIM audio filter
(based on a journal paper) I wrote for lavfi a few months ago but I gave
up. Spoke with the Opus guys who outright told me that it makes no sense to
use SSIM and that basically all of the tests done while developing Opus
were subjective. So I never got the filter merged because it would have
been a pointless statistic.

>Also list
>what you are comparing to.
Speaking in general and for libfdk_aac in specific. I am not going to
mention its name in the blog post.

>Maybe even a pic with performance/quality
>benchmarks.
I don't see pictures in any news and I wouldn't want to break that
tradition.
Encoding performance is twice as slow compared to libfdk_aac. Which is
still 12x realtime on my poor Celeron B820. In the grand scheme of things
this is insignificant.

>In short, please add some more detail at your discretion.
As I said earlier, this is not something I or anyone else can show nor
prove to be valid in general for all people for all audio files. There is
just a general agreement among the encoder developers that yes, for some
samples the encoder sounds better at 128kbps and yes, for some samples it
sounds worse. But the prevalent idea is that the encoder is transparent for
most files encoded at 128kbps, which is the de-facto standard CBR bitrate
for AAC.
But don't take my word for it. Test it yourself.

>Did not know feedback also goes on the bug tracker. I don't really
>know, maybe "feedback via IRC/ffmpeg-devel/private email" (pick
>whatever subset you want)?
There's a large trac ticket with over 450 replies. That's where the main
source of external feedback comes from. Mainly from Kamedo2 whom I credited.

>Consider refining the Changelog entry from "- extensive native AAC
>encoder improvements" to "extensive native AAC encoder improvements
>and removal of its experimental flag".
Did that slightly before I sent the mail.

>Anyway, great work, thanks!

On 5 December 2015 at 19:29, Ganesh Ajjanagadde  wrote:

> On Sat, Dec 5, 2015 at 2:14 PM, Rostislav Pehlivanov
>  wrote:
> > Signed-off-by: Rostislav Pehlivanov 
> > ---
> >  src/index | 21 +
> >  1 file changed, 21 insertions(+)
> >
> > diff --git a/src/index b/src/index
> > index d1d4a58..0c54046 100644
> > --- a/src/index
> > +++ b/src/index
> > @@ -37,6 +37,27 @@
> >  News
> >
> >
> > +  The native FFmpeg encoder is out of
> experimental!
> > +  
> > +After seven years the native FFmpeg AAC encoder has had its
> experimental flag
> > +removed and declared as ready for use. Subjective quality tests put
> the
> > +encoder to be of equal or greater quality than most of the other
> encoders
> > +available to the public.
>
> Consider adding a link to such tests/how to verify this. Also list
> what you are comparing to. Maybe even a pic with performance/quality
> benchmarks.
>
> In short, please add some more detail at your discretion.
>
> > +  
> > +Licensing has always been an issue with encoding AAC audio as most
> of the
> > +encoders have had a license making FFmpeg indistributable if
> compiled with
> > +support for them. The fact that there now exists a fully open and
> truly
> > +free AAC encoder integrated directly within the project means a lot
> to those
> > +who wish to use accepted and widespread standards.
> > +  
> > +The majority of the work done to bring the encoder up to quality was
> > +done by Claudio Freire and Rostislav Pehlivanov. Also thanks to
> > +http://d.hatena.ne.jp/kamedo2/;>Kamedo2 who does
> comparisons
> > +and tests, the original authors and all past and current
> contributors to the
> > +encoder. Users are suggested and encouraged to use the encoder and
> provide
> > +feedback or breakage reports through our https://trac.ffmpeg.org/;>bug tracker.
>
> Did not know feedback also goes on the bug tracker. I don't really
> know, maybe "feedback via IRC/ffmpeg-devel/private email" (pick
> whatever subset you want)?
>
> Consider refining the Changelog entry from "- extensive native AAC
> encoder improvements" to "extensive native AAC encoder improvements
> and removal of its experimental flag".
>
> Anyway, great work, thanks!
>
> > +  
> > +
> >Telepoint & MediaHub are now
> supporting our project
> >
> >  A big thank you note goes to our newest supporters: MediaHub and
> Telepoint.
> > --
> > 2.6.2
> >
> > ___
> > 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 3/8] avfilter/af_channelmap: fix memory leak

[Paul B Mahol]

On 12/4/15, Ganesh Ajjanagadde  wrote:
> Recent commits 6aaac24d72a7da631173209841a3944fcb4a3309 and
> 3835554bf8ed78539a3492c239f979c0ab03a15f made progress towards cleaning
> up usage of the formats API, and in particular fixed possible NULL pointer
> dereferences.
>
> This commit addresses the issue of possible resource leaks when some
> intermediate
> call fails.
>
> Tested with valgrind --leak-check=full --show-leak-kinds=all, and manual
> simulation
> of malloc/realloc failures.
>
> Fixes: CID 1338330.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavfilter/af_channelmap.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/af_channelmap.c b/libavfilter/af_channelmap.c
> index 9e95a98..dfe3d48 100644
> --- a/libavfilter/af_channelmap.c
> +++ b/libavfilter/af_channelmap.c
> @@ -292,14 +292,22 @@ static int channelmap_query_formats(AVFilterContext
> *ctx)
>  int ret;
>
>  layouts = ff_all_channel_layouts();
> +if (!layouts) {
> +ret = AVERROR(ENOMEM);

Consider this: ff_all_channel_layouts returns NULL.

> +goto fail;

Ok, we do not return immediately but use gotos, whatever...

> +}
>  if ((ret = ff_add_channel_layout (_layouts,
> s->output_layout)) < 0 ||
>  (ret = ff_set_common_formats (ctx ,
> ff_planar_sample_fmts() )) < 0 ||
>  (ret = ff_set_common_samplerates (ctx ,
> ff_all_samplerates())) < 0 ||
>  (ret = ff_channel_layouts_ref(layouts ,
> >inputs[0]->out_channel_layouts)) < 0 ||
>  (ret = ff_channel_layouts_ref(channel_layouts ,
> >outputs[0]->in_channel_layouts)) < 0)
> -return ret;
> +goto fail;
>
>  return 0;
> +fail:
> +av_freep(>channel_layouts);

What happens here if layouts is NULL ?

> +av_freep();
> +return ret;
>  }
>
>  static int channelmap_filter_frame(AVFilterLink *inlink, AVFrame *buf)
> --
> 2.6.3
>
> ___
> 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

[FFmpeg-devel] [PATCH v2] news: add a news entry for the AAC encoder experimental flag removal

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 src/index | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/src/index b/src/index
index d1d4a58..ea2ca7e 100644
--- a/src/index
+++ b/src/index
@@ -37,6 +37,32 @@
 News
   
 
+  The native FFmpeg encoder is now 
stable!
+  
+After seven years the native FFmpeg AAC encoder has had its experimental 
flag
+removed and declared as ready for general use. The encoder is transparent
+at 128kbps for most samples tested with artifacts only appearing in extreme
+cases. Subjective quality tests put the encoder to be of equal or greater
+quality than most of the other encoders available to the public.
+  
+  
+Licensing has always been an issue with encoding AAC audio as most of the
+encoders have had a license making FFmpeg unredistributable if compiled 
with
+support for them. The fact that there now exists a fully open and truly
+free AAC encoder integrated directly within the project means a lot to 
those
+who wish to use accepted and widespread standards.
+  
+  
+The majority of the work done to bring the encoder up to quality was 
started
+duing this year's GSoC by developer Claudio Freire and Rostislav 
Pehlivanov.
+Both continued to work on the encoder with the latter joining as a 
developer
+and mainainer, working on other parts of the project as well. Also, thanks
+to http://d.hatena.ne.jp/kamedo2/;>Kamedo2 who does 
comparisons
+and tests, the original authors and all past and current contributors to 
the
+encoder. Users are suggested and encouraged to use the encoder and provide
+feedback or breakage reports through our https://trac.ffmpeg.org/;>bug tracker.
+  
+
   Telepoint & MediaHub are now supporting 
our project
   
 A big thank you note goes to our newest supporters: MediaHub and Telepoint.
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH v2] news: add a news entry for the AAC encoder experimental flag removal

[Ganesh Ajjanagadde]

On Sat, Dec 5, 2015 at 3:49 PM, Rostislav Pehlivanov
 wrote:
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  src/index | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/src/index b/src/index
> index d1d4a58..ea2ca7e 100644
> --- a/src/index
> +++ b/src/index
> @@ -37,6 +37,32 @@
>  News
>
>
> +  The native FFmpeg encoder is now 
> stable!
> +  
> +After seven years the native FFmpeg AAC encoder has had its experimental 
> flag
> +removed and declared as ready for general use. The encoder is transparent
> +at 128kbps for most samples tested with artifacts only appearing in 
> extreme
> +cases. Subjective quality tests put the encoder to be of equal or greater
> +quality than most of the other encoders available to the public.
> +  
> +  
> +Licensing has always been an issue with encoding AAC audio as most of the
> +encoders have had a license making FFmpeg unredistributable if compiled 
> with
> +support for them. The fact that there now exists a fully open and truly
> +free AAC encoder integrated directly within the project means a lot to 
> those
> +who wish to use accepted and widespread standards.
> +  
> +  
> +The majority of the work done to bring the encoder up to quality was 
> started
> +duing this year's GSoC by developer Claudio Freire and Rostislav 
> Pehlivanov.

duing -> during

> +Both continued to work on the encoder with the latter joining as a 
> developer
> +and mainainer, working on other parts of the project as well. Also, 
> thanks
> +to http://d.hatena.ne.jp/kamedo2/;>Kamedo2 who does 
> comparisons
> +and tests, the original authors and all past and current contributors to 
> the
> +encoder. Users are suggested and encouraged to use the encoder and 
> provide
> +feedback or breakage reports through our  href="https://trac.ffmpeg.org/;>bug tracker.
> +  
> +

else LGTM.

>Telepoint & MediaHub are now 
> supporting our project
>
>  A big thank you note goes to our newest supporters: MediaHub and 
> Telepoint.
> --
> 2.6.2
>
> ___
> 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 for reading / writing encrypted MP4 files

[Eran Kornblau]

Hi

> No, please merge them (without adding trailing whitespace, it cannot 
> be committed to our repository).
> While at it, please fix this nit (several times):
> > +}
> > +else {
> 
> should be on one line, there is tools/patcheck that should have told 
> you (and also tells you about trailing whitespace).
> 
Fixed the else convention and squashed all commits into one, the updated patch 
is attached.

Other than that, would it be possible to add me to the mailing list ? I 
submitted my request
to join a couple of days ago, and since was not accepted yet, I'm not getting 
back your emails.

> Carl Eugen

Thanks,

Eran



0001-movenc-support-cenc-common-encryption.patch
Description: 0001-movenc-support-cenc-common-encryption.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] fate: add limited_input_seek tests

[Simon Thelen]

Signed-off-by: Simon Thelen 
---
 tests/fate/ffmpeg.mak| 6 ++
 tests/ref/fate/limited_input_seek| 1 +
 tests/ref/fate/limited_input_seek-copyts | 1 +
 3 files changed, 8 insertions(+)
 create mode 100644 tests/ref/fate/limited_input_seek
 create mode 100644 tests/ref/fate/limited_input_seek-copyts

diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
index 551d8e7..2061cd7 100644
--- a/tests/fate/ffmpeg.mak
+++ b/tests/fate/ffmpeg.mak
@@ -46,3 +46,9 @@ fate-unknown_layout-ac3: $(AREF)
 fate-unknown_layout-ac3: CMD = md5 \
   -guess_layout_max 0 -f s16le -ac 1 -ar 44100 -i $(TARGET_PATH)/$(AREF) \
   -f ac3 -flags +bitexact -c ac3_fixed
+
+FATE_SAMPLES_FFMPEG-$(call DEMMUX, OGG, OGG) += fate-limited_input_seek 
fate-limited_input_seek-copyts
+fate-limited_input_seek: $(TARGET_SAMPLES)/vorbis/moog_small.ogg
+fate-limited_input_seek: CMD = md5 -ss 1.5 -t 1.3 -i 
$(TARGET_SAMPLES)/vorbis/moog_small.ogg -c:a copy -fflags +bitexact -f ogg
+fate-limited_input_seek-copyts: $(TARGET_SAMPLES)/vorbis/moog_small.ogg
+fate-limited_input_seek-copyts: CMD = md5 -ss 1.5 -t 1.3 -i 
$(TARGET_SAMPLES)/vorbis/moog_small.ogg -c:a copy -copyts -fflags +bitexact -f 
ogg
diff --git a/tests/ref/fate/limited_input_seek 
b/tests/ref/fate/limited_input_seek
new file mode 100644
index 000..e0c4bf1
--- /dev/null
+++ b/tests/ref/fate/limited_input_seek
@@ -0,0 +1 @@
+20a1bb9a1cfb23c1fe86f14e6065cd95
diff --git a/tests/ref/fate/limited_input_seek-copyts 
b/tests/ref/fate/limited_input_seek-copyts
new file mode 100644
index 000..92790a8
--- /dev/null
+++ b/tests/ref/fate/limited_input_seek-copyts
@@ -0,0 +1 @@
+ec3604b1954ed80de364b8ef491771ce
-- 
2.6.3

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