Re: [FFmpeg-devel] License consent (cinepakenc.c)

[James Almer]

On 5/16/2017 5:12 PM, Tomas Härdin wrote:
> On Tue, 2017-05-16 at 15:42 -0300, James Almer wrote:
>> On 5/16/2017 3:13 PM, Tomas Härdin wrote:
>>>
>>> Hi
>>>
>>> I got a question from Diego via IRC about what license cinepakenc.c
>>> actually has, since the first commit message just has a message
>>> by"Rl"
>>> saying that I said it was OK but with no appropriately signed
>>> message
>>> from me. So I'm posting this just to clarify things:
>>>
>>> I consent to the original license placed on cinepakenc.c on Wed Jan
>>> 22
>>> 11:12:11 2014 +0100 (commit
>>> 59dbc36f49db5cfd9d2ad4b00ef2e3336173ee8d).
>>>
>>> Just for fun I gave the encoder a try, and the output plays just
>>> fine
>>> on Windows 3.1 in dosbox-x :)
>> Nice, i guess :p
>>
>>>
>>>
>>> My e-mail address changed a while back since I've changed employer,
>>> so
>>> MAINTAINERS should be updated to point to this one. I also don't
>>> work
>>> with MXF any longer, so a new maintainer may be needed for that
>> MAINTAINERS doesn't list email addresses, just GPG fingerprints, and
>> the
>> one listed for you matches the one you're still using today.
>> If you have push access you can remove the mxfdec mention, otherwise
>> i
>> can do that for you.
> 
> Sure. I see I'm listed for lxfdec too, but I think I can still manage
> that. And the cinepak encoder has Rl listed so that's covered
> 
> /Tomas

Ok, done then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed

[James Almer]

On 5/16/2017 11:28 PM, Ronald S. Bultje wrote:
> Hi,
> 
> On Tue, May 16, 2017 at 7:43 PM, Muhammad Faiz  wrote:
> 
>> On Wed, May 17, 2017 at 6:33 AM, Ronald S. Bultje 
>> wrote:
>>> Hi,
>>>
>>> On Tue, May 16, 2017 at 7:23 PM, Muhammad Faiz  wrote:
>>>
 On Sun, May 7, 2017 at 8:18 PM, Nicolas George  wrote:
> L'octidi 18 floréal, an CCXXV, James Almer a écrit :
>> Will that complete fix be ready and be backport-enabled (AKA, no new
>> API) in the coming days?
>
> It can. Right now, I am waiting for a comment from Hendrik, who seemed
> to have objections on the principle but that I hope to have convinced.
> After that, the coding is quite straightforward.

 I will push soon if there is no progress in that complete fix.
>>>
>>>
>>> Push what patch exactly?
>>
>> Push my patch (avfilter: align data frame when needed).
> 
> 
> Wasn't consensus that you should backport the new API, possibly with ff
> prefix, and call it in relevant places, to make sure that the code in new
> and old branch is identical?
> 
> Ronald

Yes, but as he said, if there's no progress in that complete fix, then
this partial fix should be pushed instead, at least for one point
release in the 3.3 branch before being replaced.
For that matter, it should have happened for 3.3.1, seeing the complete
fix couldn't be done in time even though it was supposed to.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed

[Ronald S. Bultje]

Hi,

On Tue, May 16, 2017 at 7:43 PM, Muhammad Faiz  wrote:

> On Wed, May 17, 2017 at 6:33 AM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Tue, May 16, 2017 at 7:23 PM, Muhammad Faiz  wrote:
> >
> >> On Sun, May 7, 2017 at 8:18 PM, Nicolas George  wrote:
> >> > L'octidi 18 floréal, an CCXXV, James Almer a écrit :
> >> >> Will that complete fix be ready and be backport-enabled (AKA, no new
> >> >> API) in the coming days?
> >> >
> >> > It can. Right now, I am waiting for a comment from Hendrik, who seemed
> >> > to have objections on the principle but that I hope to have convinced.
> >> > After that, the coding is quite straightforward.
> >>
> >> I will push soon if there is no progress in that complete fix.
> >
> >
> > Push what patch exactly?
>
> Push my patch (avfilter: align data frame when needed).


Wasn't consensus that you should backport the new API, possibly with ff
prefix, and call it in relevant places, to make sure that the code in new
and old branch is identical?

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

Re: [FFmpeg-devel] [PATCH] libavformat/hls: Observe Set-Cookie headers

[Micah Galizia]

On 2017-05-16 04:57 PM, Michael Niedermayer wrote:

On Sat, May 06, 2017 at 02:28:10PM -0400, Micah Galizia wrote:

On 2017-05-05 09:28 PM, wm4 wrote:


Did you mean & instead of ^?

No, the original code was structured to set *u to null (and thus did
not copy cookies) iff AVFMT_FLAG_CUSTOM_IO was set in the flags.  So
using ^ is logically equivalent -- cookies are copied only if
AVFMT_FLAG_CUSTOM_IO is not set.

it would also copy if another flag is set, is that intended ?


... I think that is what wm4 was getting at too. That is wrong and not 
intended. I'll resubmit with !(a) which is the proper logic.


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

[FFmpeg-devel] [PATCH] libavformat/hls: Observe Set-Cookie headers

[Micah Galizia]

Signed-off-by: Micah Galizia 
---
 libavformat/hls.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index bac53a4350..42022690f1 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -630,8 +630,16 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
 ret = s->io_open(s, pb, url, AVIO_FLAG_READ, );
 if (ret >= 0) {
 // update cookies on http response with setcookies.
-void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
-update_options(>cookies, "cookies", u);
+char *new_cookies = NULL;
+
+if (!(s->flags & AVFMT_FLAG_CUSTOM_IO))
+av_opt_get(*pb, "cookies", AV_OPT_SEARCH_CHILDREN, 
(uint8_t**)_cookies);
+
+if (new_cookies) {
+av_free(c->cookies);
+c->cookies = new_cookies;
+}
+
 av_dict_set(, "cookies", c->cookies, 0);
 }
 
-- 
2.11.0

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

Re: [FFmpeg-devel] Decoding issue with AAC SBR from flv

[Carl Eugen Hoyos]

2017-05-16 16:11 GMT+02:00 Thomas Jammet :

> Can someone help me for this problem?

I opened ticket #6398, thank you for the sample!

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

Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed

[Muhammad Faiz]

On Wed, May 17, 2017 at 6:33 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Tue, May 16, 2017 at 7:23 PM, Muhammad Faiz  wrote:
>
>> On Sun, May 7, 2017 at 8:18 PM, Nicolas George  wrote:
>> > L'octidi 18 floréal, an CCXXV, James Almer a écrit :
>> >> Will that complete fix be ready and be backport-enabled (AKA, no new
>> >> API) in the coming days?
>> >
>> > It can. Right now, I am waiting for a comment from Hendrik, who seemed
>> > to have objections on the principle but that I hope to have convinced.
>> > After that, the coding is quite straightforward.
>>
>> I will push soon if there is no progress in that complete fix.
>
>
> Push what patch exactly?

Push my patch (avfilter: align data frame when needed).

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

Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed

[Ronald S. Bultje]

Hi,

On Tue, May 16, 2017 at 7:23 PM, Muhammad Faiz  wrote:

> On Sun, May 7, 2017 at 8:18 PM, Nicolas George  wrote:
> > L'octidi 18 floréal, an CCXXV, James Almer a écrit :
> >> Will that complete fix be ready and be backport-enabled (AKA, no new
> >> API) in the coming days?
> >
> > It can. Right now, I am waiting for a comment from Hendrik, who seemed
> > to have objections on the principle but that I hope to have convinced.
> > After that, the coding is quite straightforward.
>
> I will push soon if there is no progress in that complete fix.


Push what patch exactly?

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

Re: [FFmpeg-devel] [PATCH] configure: If vfwcap_indev disabled, don't do vfw32 checks; if enabled, require vfw32

[Aaron Levinson]

On 5/16/2017 4:23 PM, Steven Liu wrote:

2017-05-17 6:38 GMT+08:00 Aaron Levinson :


Signed-off-by: Aaron Levinson 
---
 configure | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 7980d92..49f91ac 100755
--- a/configure
+++ b/configure
@@ -6013,10 +6013,10 @@ check_header sys/videoio.h
 check_code cc sys/videoio.h "struct v4l2_frmsizeenum vfse;
vfse.discrete.width = 0;" && enable_safe struct_v4l2_frmivalenum_discrete

 check_lib user32 "windows.h winuser.h" GetShellWindow -luser32
-check_lib vfw32 "windows.h vfw.h" capCreateCaptureWindow -lvfw32
+disabled vfwcap_indev || { require vfw32 "windows.h vfw.h"
capCreateCaptureWindow -lvfw32 &&
 # check that WM_CAP_DRIVER_CONNECT is defined to the proper value
 # w32api 3.12 had it defined wrong
-check_cpp_condition vfw.h "WM_CAP_DRIVER_CONNECT > WM_USER" && enable
vfwcap_defines
+   check_cpp_condition vfw.h
"WM_CAP_DRIVER_CONNECT > WM_USER" && enable vfwcap_defines; }



indent problem?


It's not--it is aligned with "require" on the earlier line, and that 
alignment is consistent with similar things in other parts of the file. 
I decided to leave the comment alone though, but I could indent the 
comment with the other lines if that makes more sense.


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

Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed

[Muhammad Faiz]

On Sun, May 7, 2017 at 8:18 PM, Nicolas George  wrote:
> L'octidi 18 floréal, an CCXXV, James Almer a écrit :
>> Will that complete fix be ready and be backport-enabled (AKA, no new
>> API) in the coming days?
>
> It can. Right now, I am waiting for a comment from Hendrik, who seemed
> to have objections on the principle but that I hope to have convinced.
> After that, the coding is quite straightforward.

I will push soon if there is no progress in that complete fix.

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

Re: [FFmpeg-devel] [PATCH] configure: If vfwcap_indev disabled, don't do vfw32 checks; if enabled, require vfw32

[Steven Liu]

2017-05-17 6:38 GMT+08:00 Aaron Levinson :

> Signed-off-by: Aaron Levinson 
> ---
>  configure | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index 7980d92..49f91ac 100755
> --- a/configure
> +++ b/configure
> @@ -6013,10 +6013,10 @@ check_header sys/videoio.h
>  check_code cc sys/videoio.h "struct v4l2_frmsizeenum vfse;
> vfse.discrete.width = 0;" && enable_safe struct_v4l2_frmivalenum_discrete
>
>  check_lib user32 "windows.h winuser.h" GetShellWindow -luser32
> -check_lib vfw32 "windows.h vfw.h" capCreateCaptureWindow -lvfw32
> +disabled vfwcap_indev || { require vfw32 "windows.h vfw.h"
> capCreateCaptureWindow -lvfw32 &&
>  # check that WM_CAP_DRIVER_CONNECT is defined to the proper value
>  # w32api 3.12 had it defined wrong
> -check_cpp_condition vfw.h "WM_CAP_DRIVER_CONNECT > WM_USER" && enable
> vfwcap_defines
> +   check_cpp_condition vfw.h
> "WM_CAP_DRIVER_CONNECT > WM_USER" && enable vfwcap_defines; }
>

indent problem?

>
>  check_type "dshow.h" IBaseFilter
>
> --
> 2.10.1.windows.1
>
> ___
> 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] configure: If vfwcap_indev disabled, don't do vfw32 checks; if enabled, require vfw32

[Aaron Levinson]

Signed-off-by: Aaron Levinson 
---
 configure | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 7980d92..49f91ac 100755
--- a/configure
+++ b/configure
@@ -6013,10 +6013,10 @@ check_header sys/videoio.h
 check_code cc sys/videoio.h "struct v4l2_frmsizeenum vfse; vfse.discrete.width 
= 0;" && enable_safe struct_v4l2_frmivalenum_discrete
 
 check_lib user32 "windows.h winuser.h" GetShellWindow -luser32
-check_lib vfw32 "windows.h vfw.h" capCreateCaptureWindow -lvfw32
+disabled vfwcap_indev || { require vfw32 "windows.h vfw.h" 
capCreateCaptureWindow -lvfw32 &&
 # check that WM_CAP_DRIVER_CONNECT is defined to the proper value
 # w32api 3.12 had it defined wrong
-check_cpp_condition vfw.h "WM_CAP_DRIVER_CONNECT > WM_USER" && enable 
vfwcap_defines
+   check_cpp_condition vfw.h "WM_CAP_DRIVER_CONNECT > 
WM_USER" && enable vfwcap_defines; }
 
 check_type "dshow.h" IBaseFilter
 
-- 
2.10.1.windows.1

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

[FFmpeg-devel] [PATCH] avcodec/takdec: Fix runtime error: signed integer overflow: 8192 * 524308 cannot be represented in type 'int'

[Michael Niedermayer]

Fixes: 1630/clusterfuzz-testcase-minimized-6326111917047808

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/takdec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/takdec.c b/libavcodec/takdec.c
index 42939b4058..4cfb95a893 100644
--- a/libavcodec/takdec.c
+++ b/libavcodec/takdec.c
@@ -267,11 +267,11 @@ static int decode_segment(TAKDecContext *s, int8_t mode, 
int32_t *decoded, int l
 code = xcodes[mode - 1];
 
 for (i = 0; i < len; i++) {
-int x = get_bits_long(gb, code.init);
+unsigned x = get_bits_long(gb, code.init);
 if (x >= code.escape && get_bits1(gb)) {
 x |= 1 << code.init;
 if (x >= code.aescape) {
-int scale = get_unary(gb, 1, 9);
+unsigned scale = get_unary(gb, 1, 9);
 if (scale == 9) {
 int scale_bits = get_bits(gb, 3);
 if (scale_bits > 0) {
-- 
2.13.0

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

Re: [FFmpeg-devel] [PATCH] libavformat/hls: Observe Set-Cookie headers

[Michael Niedermayer]

On Sat, May 06, 2017 at 02:28:10PM -0400, Micah Galizia wrote:
> On 2017-05-05 09:28 PM, wm4 wrote:
> >On Fri,  5 May 2017 20:55:05 -0400
> >Micah Galizia  wrote:
> >
> >>Signed-off-by: Micah Galizia 
> >>---
> >>  libavformat/hls.c | 12 ++--
> >>  1 file changed, 10 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/libavformat/hls.c b/libavformat/hls.c
> >>index bac53a4350..bda9abecfa 100644
> >>--- a/libavformat/hls.c
> >>+++ b/libavformat/hls.c
> >>@@ -630,8 +630,16 @@ static int open_url(AVFormatContext *s, AVIOContext 
> >>**pb, const char *url,
> >>  ret = s->io_open(s, pb, url, AVIO_FLAG_READ, );
> >>  if (ret >= 0) {
> >>  // update cookies on http response with setcookies.
> >>-void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
> >>-update_options(>cookies, "cookies", u);
> >>+char *new_cookies = NULL;
> >>+
> >>+if (s->flags ^ AVFMT_FLAG_CUSTOM_IO)
> >>+av_opt_get(*pb, "cookies", AV_OPT_SEARCH_CHILDREN, 
> >>(uint8_t**)_cookies);
> >Did you mean & instead of ^?
> 
> No, the original code was structured to set *u to null (and thus did
> not copy cookies) iff AVFMT_FLAG_CUSTOM_IO was set in the flags.  So
> using ^ is logically equivalent -- cookies are copied only if
> AVFMT_FLAG_CUSTOM_IO is not set.

it would also copy if another flag is set, is that intended ?


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

It is what and why we do it that matters, not just one of them.


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 audio crossfeed filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi   |  16 +
 libavfilter/Makefile   |   1 +
 libavfilter/af_crossfeed.c | 161 +
 libavfilter/allfilters.c   |   1 +
 4 files changed, 179 insertions(+)
 create mode 100644 libavfilter/af_crossfeed.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 9611a41..2e7caf3 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2248,6 +2248,22 @@ Set temperature degree in Celsius. This is the 
temperature of the environment.
 Default is 20.
 @end table
 
+@section crossfeed
+Apply headphone crossfeed filter.
+
+The filter accepts the following options:
+
+@table @option
+@item strength
+Set strength of crossfeed. Default is 0.1. Allowed range is from 0 to 1.
+
+@item level_in
+Set input gain. Default is 0.9.
+
+@item level_out
+Set output gain. Default is 1.
+@end table
+
 @section crystalizer
 Simple algorithm to expand audio dynamic range.
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f177fdb..434a989 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -81,6 +81,7 @@ OBJS-$(CONFIG_CHANNELSPLIT_FILTER)   += 
af_channelsplit.o
 OBJS-$(CONFIG_CHORUS_FILTER) += af_chorus.o 
generate_wave_table.o
 OBJS-$(CONFIG_COMPAND_FILTER)+= af_compand.o
 OBJS-$(CONFIG_COMPENSATIONDELAY_FILTER)  += af_compensationdelay.o
+OBJS-$(CONFIG_CROSSFEED_FILTER)  += af_crossfeed.o
 OBJS-$(CONFIG_CRYSTALIZER_FILTER)+= af_crystalizer.o
 OBJS-$(CONFIG_DCSHIFT_FILTER)+= af_dcshift.o
 OBJS-$(CONFIG_DYNAUDNORM_FILTER) += af_dynaudnorm.o
diff --git a/libavfilter/af_crossfeed.c b/libavfilter/af_crossfeed.c
new file mode 100644
index 000..8a9ecad
--- /dev/null
+++ b/libavfilter/af_crossfeed.c
@@ -0,0 +1,161 @@
+/*
+ * 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/channel_layout.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "audio.h"
+#include "formats.h"
+
+typedef struct CrossfeedContext {
+const AVClass *class;
+
+double strength;
+double level_in;
+double level_out;
+
+double a0, a1, a2;
+double b0, b1, b2;
+
+double i1, i2;
+double o1, o2;
+} CrossfeedContext;
+
+static int query_formats(AVFilterContext *ctx)
+{
+AVFilterFormats *formats = NULL;
+AVFilterChannelLayouts *layout = NULL;
+int ret;
+
+if ((ret = ff_add_format (, AV_SAMPLE_FMT_DBL  )) 
< 0 ||
+(ret = ff_set_common_formats (ctx , formats)) 
< 0 ||
+(ret = ff_add_channel_layout ( , AV_CH_LAYOUT_STEREO)) 
< 0 ||
+(ret = ff_set_common_channel_layouts (ctx , layout )) 
< 0 ||
+(ret = ff_set_common_samplerates (ctx , ff_all_samplerates())) 
< 0)
+return ret;
+
+return 0;
+}
+
+static int config_input(AVFilterLink *inlink)
+{
+AVFilterContext *ctx = inlink->dst;
+CrossfeedContext *s = ctx->priv;
+double w0 = 2 * M_PI * s->strength * 1000 / inlink->sample_rate;
+double alpha;
+
+alpha = sin(w0) / 2 * sqrt(2 * (1 / 0.707 - 1) + 2);
+
+s->a0 =   1 + alpha;
+s->a1 =  -2 * cos(w0);
+s->a2 =   1 - alpha;
+s->b0 =  (1 + cos(w0)) / 2;
+s->b1 = -(1 + cos(w0));
+s->b2 =  (1 + cos(w0)) / 2;
+
+s->a1 /= s->a0;
+s->a2 /= s->a0;
+s->b0 /= s->a0;
+s->b1 /= s->a0;
+s->b2 /= s->a0;
+
+return 0;
+}
+
+static int filter_frame(AVFilterLink *inlink, AVFrame *in)
+{
+AVFilterContext *ctx = inlink->dst;
+AVFilterLink *outlink = ctx->outputs[0];
+CrossfeedContext *s = ctx->priv;
+const double *src = (const double *)in->data[0];
+const double level_in = s->level_in;
+const double level_out = s->level_out;
+AVFrame *out;
+double *dst;
+int n;
+
+if (av_frame_is_writable(in)) {
+out = in;
+} else {
+out = ff_get_audio_buffer(inlink, in->nb_samples);
+if (!out) {
+av_frame_free();
+return AVERROR(ENOMEM);
+}
+av_frame_copy_props(out, in);
+}
+dst = (double *)out->data[0];
+
+for (n = 0; n < out->nb_samples; n++, src += 2, dst += 2) {
+double mid = 

Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects

[Mark Thompson]

On 16/05/17 13:04, Aaron Levinson wrote:
> Add dxva2_pool_release_dummy() and use it in call to
> av_buffer_create() in dxva2_pool_alloc().
> 
> Prior to this change, av_buffer_create() was called with NULL for the
> third argument, which indicates that av_buffer_default_free() should
> be used to free the buffer's data.  Eventually, it gets to
> buffer_pool_free() and calls buf->free() on a surface object (which is
> av_buffer_default_free()).
> 
> This can result in a crash when the debug version of the C-runtime is
> used on Windows.  While it doesn't appear to result in a crash when
> the release version of the C-runtime is used on Windows, it likely
> results in memory corruption, since av_free() is being called on
> memory that was allocated using
> IDirectXVideoAccelerationService::CreateSurface().
> 
> Signed-off-by: Aaron Levinson 
> ---
>  libavutil/hwcontext_dxva2.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)

Applied.

Thanks for finding this - I'm rather surprised we haven't seen more serious 
problems because of it.

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

Re: [FFmpeg-devel] [PATCH] fix GetBitContext index when SPS bitstream_restriction_flag=1 but can't be parsed, because index is out of bit-stream size. Need return index value continue H.264 parsing

[Michael Niedermayer]

On Tue, May 16, 2017 at 03:13:36PM +0300, Ivan Shmakov wrote:
> ---
>  libavcodec/h264_ps.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> index 7858361..09e2290 100644
> --- a/libavcodec/h264_ps.c
> +++ b/libavcodec/h264_ps.c
> @@ -136,6 +136,7 @@ static inline int decode_vui_parameters(GetBitContext
> *gb, AVCodecContext *avctx
>  {
>  int aspect_ratio_info_present_flag;
>  unsigned int aspect_ratio_idc;
> +int idx;
>  
>  aspect_ratio_info_present_flag = get_bits1(gb);
>  
> @@ -221,8 +222,10 @@ static inline int decode_vui_parameters(GetBitContext
> *gb, AVCodecContext *avctx
>  sps->pic_struct_present_flag = get_bits1(gb);
>  if (!get_bits_left(gb))
>  return 0;
> +
>  sps->bitstream_restriction_flag = get_bits1(gb);
>  if (sps->bitstream_restriction_flag) {
> +idx = gb->index;
>  get_bits1(gb); /* motion_vectors_over_pic_boundaries_flag */
>  get_ue_golomb(gb); /* max_bytes_per_pic_denom */
>  get_ue_golomb(gb); /* max_bits_per_mb_denom */
> @@ -234,6 +237,7 @@ static inline int decode_vui_parameters(GetBitContext
> *gb, AVCodecContext *avctx
>  if (get_bits_left(gb) < 0) {
>  sps->num_reorder_frames = 0;
>  sps->bitstream_restriction_flag = 0;
> +gb->index = idx;

Direct access to gb->index is not ok
all code directly accssing GetBitContext internals belongs in the
bitstream / get bits code.
Normally to "unread" we just duplicate the GetBitContext before


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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] libavformat: data loss in message accumulation in fill_buffer()

[Michael Niedermayer]

On Tue, May 16, 2017 at 09:05:49AM -0700, Rob Meyers wrote:
> We noticed when reading data from a named pipe the first 10 bytes
> would get dropped. I traced this to the affected code in
> fill_buffer(). The assignment of "dst" was always set to the beginning
> of the buffer, and if it hadn't been consumed yet the data would be
> overwritten. We could reproduce this by setting up a server that
> writes to the named pipe in two small (6 byte) messages with a 1
> second gap between. Without the gap, or if the data is sent as one
> message, there's no problem. It's in the accumulation of data between
> messages to fulfill a read that this bug is triggered.
> 
> ---
>  libavformat/aviobuf.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

as just explained in the previous thread, this is not the correct
change to fix the issue
(just saying so this isnt applied by mistake)

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

Re: [FFmpeg-devel] Decoding issue with AAC SBR from flv

[James Almer]

On 5/16/2017 11:11 AM, Thomas Jammet wrote:
> Hi,
> 
> I think to have found a regression into ffmpeg 3.x versions.
> 
> When I try to play the file in attachment it gives inaudible output and a
> lot of errors from ffplay (see example below). I have tested it with ffmpeg
> 3.3.git and stable release 3.2.3 on Linux and Windows and it gives the same
> result.
> 
> Though if I play it from ffmpeg version 2.8 the output is playing fine (but
> there are 2 errors in the logs).
> 
> For information the file is extracted from a live stream. I think that the
> problem comes from the fact that the first packet is not a "key frame" or
> something like this so the decoder cannot handle it.
> 
> My command is just :
> *ffplay aac_decoding_error.flv*
> 
> And here are the error logs :
> [aac @ 0x9fb08820] channel element 0.3 is not allocated
> [aac @ 0x9fb08820] channel element 0.14 is not allocated
> [aac @ 0x9fb08820] Input buffer exhausted before END element found
> Last message repeated 1 times
> [aac @ 0x9fb08820] channel element 2.10 is not allocated
> [aac @ 0x9fb08820] Input buffer exhausted before END element found
> [aac @ 0x9fb08820] Sample rate index in program config element does not
> match the sample rate index configured by the container.
> [aac @ 0x9fb08820] decode_pce: Input buffer exhausted before END element
> found
> [aac @ 0x9fb08820] Input buffer exhausted before END element found
> [aac @ 0x9fb08820] Sample rate index in program config element does not
> match the sample rate index configured by the container.
> [aac @ 0x9fb08820] decode_pce: Input buffer exhausted before END element
> found
> [aac @ 0x9fb08820] Multiple frames in a packet.
> [aac @ 0x9fb08820] decode_pce: Input buffer exhausted before END element
> found
> [aac @ 0x9fb08820] Input buffer exhausted before END element found
> [aac @ 0x9fb08820] channel element 1.12 is not allocated
> [aac @ 0x9fb08820] Input buffer exhausted before END element found
> [aac @ 0x9fb08820] channel element 3.14 is not allocated
> [aac @ 0x9fb08820] channel element 0.3 is not allocated
> [aac @ 0x9fb08820] skip_data_stream_element: Input buffer exhausted before
> END element found
> [aac @ 0x9fb08820] Input buffer exhausted before END element found
> [aac @ 0x9fb08820] channel element 0.7 is not allocated
> [aac @ 0x9fb08820] Input buffer exhausted before END element found
> ...
> 
> Can someone help me for this problem?
> 
> Regards
> 
> *--*
> 
> *Thomas JAMMET*

Could you open a ticket in http://trac.ffmpeg.org/ with this same
information and sample? See https://ffmpeg.org/bugreports.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat aviobuf: Fixed dst pointer initialization in fill_buffer

[Michael Niedermayer]

On Tue, May 16, 2017 at 04:17:45PM +, Rob Meyers wrote:
> Here's a simple server we used to reproduce the problem:
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #define INGOING "/tmp/audio.fifo"
> 
> ssize_t write_fifo(int fd, char* msg, int size) {
>   ssize_t write_rc;
> 
>   write_rc = write(fd, msg, size);
>   printf("msg '%s' write_rc = %ld\n", msg, write_rc);
>   if (write_rc != size) {
> perror("write sent fewer bytes than expected");
>   }
>   if (write_rc == -1) {
> perror("write error");
>   }
> 
>   return write_rc;
> }
> 
> int main(int argc, char *argv[]) {
>   mkfifo(INGOING, 0666);
> 
>   printf("Welcome to server.\n");
>   printf("channel for reading messages to server is %s\n", INGOING);
> 
>   int in_fd = open(INGOING, O_WRONLY);
>   if (in_fd == -1) {
> perror("open error");
> return 1;
>   }
> 
>   int argi = 1;
>   while (argi < argc) {
> char *msg = argv[argi];
> int len = strlen(msg);
> ++argi;
> 
> write_fifo(in_fd, msg, len);
> sleep(1);
>   }
> 
>   return 0;
> }
> 
> --
> 
> The command line arguments are sent as individual messages. To demonstrate
> the problem I run with "abcdef ghijkl" as the args. This sends two 6 byte
> messages with a short gap between.
> 
> I run ffmpeg like so:
> ffmpeg -ar 1000 -ac 1 -acodec pcm_s16le -f s16le -probesize 500 -i
>  /tmp/audio.fifo -map_metadata -1 -vn -ac:a:0 1 -ar:a:0 1000 -codec:a:0
> pcm_s16le -sn -f s16le -y  -
> 

> Without my patch, you won't see all 12 bytes output, just "kl". My patch
> fixes this.

The patch makes it output all 12 bytes but this is more by luck than
by fixing the issue.

The issue is, well there are at least 2 issues
First the ff_id3v2_read_dict() Tries to read 10 bytes and failing to
find a id3 header seeks back.
This is buggy, it must call ffio_ensure_seekback() before it starts
any reading that it intends to seek back over.

the 2nd issue seems to be that fill_buffer() throws the larger
buffer ffio_ensure_seekback() created out too early.
I didnt investigate this deeply but something goes wrong there

and with ffio_ensure_seekback() and with the downallocation commented
the whole works and returns the 12 bytes



> 
> The buffer is in AVIOContext. The problem with the original code was that
> max_buffer_size is added to the request, to see if it's larger than another
> value that is also max_buffer_size. Like, "if (A + B) < B".

It may be that the buffer size and the maximum packet size are often
the same.  But they are not always the same, for example
ffio_ensure_seekback() makes them different

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

Re: [FFmpeg-devel] License consent (cinepakenc.c)

[Tomas Härdin]

On Tue, 2017-05-16 at 15:42 -0300, James Almer wrote:
> On 5/16/2017 3:13 PM, Tomas Härdin wrote:
> > 
> > Hi
> > 
> > I got a question from Diego via IRC about what license cinepakenc.c
> > actually has, since the first commit message just has a message
> > by"Rl"
> > saying that I said it was OK but with no appropriately signed
> > message
> > from me. So I'm posting this just to clarify things:
> > 
> > I consent to the original license placed on cinepakenc.c on Wed Jan
> > 22
> > 11:12:11 2014 +0100 (commit
> > 59dbc36f49db5cfd9d2ad4b00ef2e3336173ee8d).
> > 
> > Just for fun I gave the encoder a try, and the output plays just
> > fine
> > on Windows 3.1 in dosbox-x :)
> Nice, i guess :p
> 
> > 
> > 
> > My e-mail address changed a while back since I've changed employer,
> > so
> > MAINTAINERS should be updated to point to this one. I also don't
> > work
> > with MXF any longer, so a new maintainer may be needed for that
> MAINTAINERS doesn't list email addresses, just GPG fingerprints, and
> the
> one listed for you matches the one you're still using today.
> If you have push access you can remove the mxfdec mention, otherwise
> i
> can do that for you.

Sure. I see I'm listed for lxfdec too, but I think I can still manage
that. And the cinepak encoder has Rl listed so that's covered

/Tomas

signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fix GetBitContext index when SPS bitstream_restriction_flag=1 but can't be parsed, because index is out of bit-stream size. Need return index value continue H.264 parsing

[Hendrik Leppkes]

On Tue, May 16, 2017 at 2:13 PM, Ivan Shmakov  wrote:
> ---
>  libavcodec/h264_ps.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> index 7858361..09e2290 100644
> --- a/libavcodec/h264_ps.c
> +++ b/libavcodec/h264_ps.c
> @@ -136,6 +136,7 @@ static inline int decode_vui_parameters(GetBitContext
> *gb, AVCodecContext *avctx
>  {
>  int aspect_ratio_info_present_flag;
>  unsigned int aspect_ratio_idc;
> +int idx;
>
>  aspect_ratio_info_present_flag = get_bits1(gb);
>
> @@ -221,8 +222,10 @@ static inline int decode_vui_parameters(GetBitContext
> *gb, AVCodecContext *avctx
>  sps->pic_struct_present_flag = get_bits1(gb);
>  if (!get_bits_left(gb))
>  return 0;
> +
>  sps->bitstream_restriction_flag = get_bits1(gb);
>  if (sps->bitstream_restriction_flag) {
> +idx = gb->index;
>  get_bits1(gb); /* motion_vectors_over_pic_boundaries_flag */
>  get_ue_golomb(gb); /* max_bytes_per_pic_denom */
>  get_ue_golomb(gb); /* max_bits_per_mb_denom */
> @@ -234,6 +237,7 @@ static inline int decode_vui_parameters(GetBitContext
> *gb, AVCodecContext *avctx
>  if (get_bits_left(gb) < 0) {
>  sps->num_reorder_frames = 0;
>  sps->bitstream_restriction_flag = 0;
> +gb->index = idx;
>  }
>
>  if (sps->num_reorder_frames > 16U

This doesn't seem right. What guarantees are that when one element
can't be parsed, anything else can?

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

[FFmpeg-devel] Decoding issue with AAC SBR from flv

[Thomas Jammet]

Hi,

I think to have found a regression into ffmpeg 3.x versions.

When I try to play the file in attachment it gives inaudible output and a
lot of errors from ffplay (see example below). I have tested it with ffmpeg
3.3.git and stable release 3.2.3 on Linux and Windows and it gives the same
result.

Though if I play it from ffmpeg version 2.8 the output is playing fine (but
there are 2 errors in the logs).

For information the file is extracted from a live stream. I think that the
problem comes from the fact that the first packet is not a "key frame" or
something like this so the decoder cannot handle it.

My command is just :
*ffplay aac_decoding_error.flv*

And here are the error logs :
[aac @ 0x9fb08820] channel element 0.3 is not allocated
[aac @ 0x9fb08820] channel element 0.14 is not allocated
[aac @ 0x9fb08820] Input buffer exhausted before END element found
Last message repeated 1 times
[aac @ 0x9fb08820] channel element 2.10 is not allocated
[aac @ 0x9fb08820] Input buffer exhausted before END element found
[aac @ 0x9fb08820] Sample rate index in program config element does not
match the sample rate index configured by the container.
[aac @ 0x9fb08820] decode_pce: Input buffer exhausted before END element
found
[aac @ 0x9fb08820] Input buffer exhausted before END element found
[aac @ 0x9fb08820] Sample rate index in program config element does not
match the sample rate index configured by the container.
[aac @ 0x9fb08820] decode_pce: Input buffer exhausted before END element
found
[aac @ 0x9fb08820] Multiple frames in a packet.
[aac @ 0x9fb08820] decode_pce: Input buffer exhausted before END element
found
[aac @ 0x9fb08820] Input buffer exhausted before END element found
[aac @ 0x9fb08820] channel element 1.12 is not allocated
[aac @ 0x9fb08820] Input buffer exhausted before END element found
[aac @ 0x9fb08820] channel element 3.14 is not allocated
[aac @ 0x9fb08820] channel element 0.3 is not allocated
[aac @ 0x9fb08820] skip_data_stream_element: Input buffer exhausted before
END element found
[aac @ 0x9fb08820] Input buffer exhausted before END element found
[aac @ 0x9fb08820] channel element 0.7 is not allocated
[aac @ 0x9fb08820] Input buffer exhausted before END element found
...

Can someone help me for this problem?

Regards

*--*

*Thomas JAMMET*


aac_decoding_error.flv
Description: video/flv
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] fix GetBitContext index when SPS bitstream_restriction_flag=1 but can't be parsed, because index is out of bit-stream size. Need return index value continue H.264 parsing

[Ivan Shmakov]

---
 libavcodec/h264_ps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 7858361..09e2290 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -136,6 +136,7 @@ static inline int decode_vui_parameters(GetBitContext
*gb, AVCodecContext *avctx
 {
 int aspect_ratio_info_present_flag;
 unsigned int aspect_ratio_idc;
+int idx;
 
 aspect_ratio_info_present_flag = get_bits1(gb);
 
@@ -221,8 +222,10 @@ static inline int decode_vui_parameters(GetBitContext
*gb, AVCodecContext *avctx
 sps->pic_struct_present_flag = get_bits1(gb);
 if (!get_bits_left(gb))
 return 0;
+
 sps->bitstream_restriction_flag = get_bits1(gb);
 if (sps->bitstream_restriction_flag) {
+idx = gb->index;
 get_bits1(gb); /* motion_vectors_over_pic_boundaries_flag */
 get_ue_golomb(gb); /* max_bytes_per_pic_denom */
 get_ue_golomb(gb); /* max_bits_per_mb_denom */
@@ -234,6 +237,7 @@ static inline int decode_vui_parameters(GetBitContext
*gb, AVCodecContext *avctx
 if (get_bits_left(gb) < 0) {
 sps->num_reorder_frames = 0;
 sps->bitstream_restriction_flag = 0;
+gb->index = idx;
 }
 
 if (sps->num_reorder_frames > 16U
-- 
2.10.2.windows.1


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

Re: [FFmpeg-devel] [PATCH] configure: use -x instead of -wN ..@ to strip assembly files

[James Darnley]

On 2017-05-16 13:08, Rostislav Pehlivanov wrote:
> Reduces the amount of debugging information of external asm from
> uselessly verbose to informative enough.
> ---
>  configure | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/configure b/configure
> index e4862f6a35..df849df14f 100755
> --- a/configure
> +++ b/configure
> @@ -6185,8 +6185,7 @@ enabled rpath && add_ldlibflags -Wl,-rpath,$libdir
>  test_ldflags -Wl,-Bsymbolic && append SHFLAGS -Wl,-Bsymbolic
>  
>  # add some strip flags
> -# -wN '..@*' is more selective than -x, but not available everywhere.
> -check_stripflags -wN \'..@*\' || check_stripflags -x
> +check_stripflags -x
>  
>  enabled neon_clobber_test &&
>  check_ldflags -Wl,--wrap,avcodec_open2  \
> 

Look good.  I'm in favour of this change.  It does exactly what I was
(partly) advocating for in my email on Friday.




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

Re: [FFmpeg-devel] License consent (cinepakenc.c)

[James Almer]

On 5/16/2017 3:13 PM, Tomas Härdin wrote:
> Hi
> 
> I got a question from Diego via IRC about what license cinepakenc.c
> actually has, since the first commit message just has a message by"Rl"
> saying that I said it was OK but with no appropriately signed message
> from me. So I'm posting this just to clarify things:
> 
> I consent to the original license placed on cinepakenc.c on Wed Jan 22
> 11:12:11 2014 +0100 (commit 59dbc36f49db5cfd9d2ad4b00ef2e3336173ee8d).
> 
> Just for fun I gave the encoder a try, and the output plays just fine
> on Windows 3.1 in dosbox-x :)

Nice, i guess :p

> 
> My e-mail address changed a while back since I've changed employer, so
> MAINTAINERS should be updated to point to this one. I also don't work
> with MXF any longer, so a new maintainer may be needed for that

MAINTAINERS doesn't list email addresses, just GPG fingerprints, and the
one listed for you matches the one you're still using today.
If you have push access you can remove the mxfdec mention, otherwise i
can do that for you.

> 
> /Tomas
> 
> 
> 
> ___
> 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] License consent (cinepakenc.c)

[Tomas Härdin]

Hi

I got a question from Diego via IRC about what license cinepakenc.c
actually has, since the first commit message just has a message by"Rl"
saying that I said it was OK but with no appropriately signed message
from me. So I'm posting this just to clarify things:

I consent to the original license placed on cinepakenc.c on Wed Jan 22
11:12:11 2014 +0100 (commit 59dbc36f49db5cfd9d2ad4b00ef2e3336173ee8d).

Just for fun I gave the encoder a try, and the output plays just fine
on Windows 3.1 in dosbox-x :)

My e-mail address changed a while back since I've changed employer, so
MAINTAINERS should be updated to point to this one. I also don't work
with MXF any longer, so a new maintainer may be needed for that

/Tomas

signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat aviobuf: Fixed dst pointer initialization in fill_buffer

[Rob Meyers]

Here's a simple server we used to reproduce the problem:

#include 
#include 
#include 
#include 
#include 

#define INGOING "/tmp/audio.fifo"

ssize_t write_fifo(int fd, char* msg, int size) {
  ssize_t write_rc;

  write_rc = write(fd, msg, size);
  printf("msg '%s' write_rc = %ld\n", msg, write_rc);
  if (write_rc != size) {
perror("write sent fewer bytes than expected");
  }
  if (write_rc == -1) {
perror("write error");
  }

  return write_rc;
}

int main(int argc, char *argv[]) {
  mkfifo(INGOING, 0666);

  printf("Welcome to server.\n");
  printf("channel for reading messages to server is %s\n", INGOING);

  int in_fd = open(INGOING, O_WRONLY);
  if (in_fd == -1) {
perror("open error");
return 1;
  }

  int argi = 1;
  while (argi < argc) {
char *msg = argv[argi];
int len = strlen(msg);
++argi;

write_fifo(in_fd, msg, len);
sleep(1);
  }

  return 0;
}

--

The command line arguments are sent as individual messages. To demonstrate
the problem I run with "abcdef ghijkl" as the args. This sends two 6 byte
messages with a short gap between.

I run ffmpeg like so:
ffmpeg -ar 1000 -ac 1 -acodec pcm_s16le -f s16le -probesize 500 -i
 /tmp/audio.fifo -map_metadata -1 -vn -ac:a:0 1 -ar:a:0 1000 -codec:a:0
pcm_s16le -sn -f s16le -y  -

Without my patch, you won't see all 12 bytes output, just "kl". My patch
fixes this.

The buffer is in AVIOContext. The problem with the original code was that
max_buffer_size is added to the request, to see if it's larger than another
value that is also max_buffer_size. Like, "if (A + B) < B".


On Tue, May 16, 2017 at 9:06 AM Michael Niedermayer 
wrote:

> On Mon, May 15, 2017 at 05:55:28PM +, Rob Meyers wrote:
> > Of course.
> >
> > We noticed when reading data from a named pipe the first 10 bytes would
> get
> > dropped.
>
> from were are bytes droped ?
> this is the internal buffer, not something a user should touch
> directly.
>
>
> > I traced this to the affected code in fill_buffer(). The
> > assignment of "dst" was always set to the beginning of the buffer, and if
>
> The buffer pointer resets to the start if there is not enough space
> available to hold another packet.
> with your patch it resets either always or when the buffer is filled
> to the last byte randomly truncating a read.
> If the read function is incapable to fullfill the partial packet read
> that will not work out i think
> But i may be missing something of course
>
>
>
> > it hadn't been consumed yet the data would be overwritten. We could
> > reproduce this by setting up a server that writes to the named pipe in
> two
> > small (6 byte) messages with a 1 second gap between. Without the gap, or
> if
> > the data is sent as one message, there's no problem. It's in the
> > accumulation of data between messages to fulfill a read that this bug is
> > triggered.
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are best at talking, realize last or never when they are wrong.
> ___
> 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] libavformat: data loss in message accumulation in fill_buffer()

[Rob Meyers]

We noticed when reading data from a named pipe the first 10 bytes
would get dropped. I traced this to the affected code in
fill_buffer(). The assignment of "dst" was always set to the beginning
of the buffer, and if it hadn't been consumed yet the data would be
overwritten. We could reproduce this by setting up a server that
writes to the named pipe in two small (6 byte) messages with a 1
second gap between. Without the gap, or if the data is sent as one
message, there's no problem. It's in the accumulation of data between
messages to fulfill a read that this bug is triggered.

---
 libavformat/aviobuf.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 0a7c39eacd..4e04cb79e0 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -519,9 +519,7 @@ void avio_write_marker(AVIOContext *s, int64_t time, enum 
AVIODataMarkerType typ
 
 static void fill_buffer(AVIOContext *s)
 {
-int max_buffer_size = s->max_packet_size ?
-  s->max_packet_size : IO_BUFFER_SIZE;
-uint8_t *dst= s->buf_end - s->buffer + max_buffer_size < 
s->buffer_size ?
+uint8_t *dst= !s->max_packet_size && s->buf_end - s->buffer < 
s->buffer_size ?
   s->buf_end : s->buffer;
 int len = s->buffer_size - (dst - s->buffer);
 
-- 
2.13.0.rc2.291.g57267f2277-goog

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

Re: [FFmpeg-devel] [PATCH] libavformat aviobuf: Fixed dst pointer initialization in fill_buffer

[Michael Niedermayer]

On Mon, May 15, 2017 at 05:55:28PM +, Rob Meyers wrote:
> Of course.
> 
> We noticed when reading data from a named pipe the first 10 bytes would get
> dropped.

from were are bytes droped ?
this is the internal buffer, not something a user should touch
directly.


> I traced this to the affected code in fill_buffer(). The
> assignment of "dst" was always set to the beginning of the buffer, and if

The buffer pointer resets to the start if there is not enough space
available to hold another packet.
with your patch it resets either always or when the buffer is filled
to the last byte randomly truncating a read.
If the read function is incapable to fullfill the partial packet read
that will not work out i think
But i may be missing something of course



> it hadn't been consumed yet the data would be overwritten. We could
> reproduce this by setting up a server that writes to the named pipe in two
> small (6 byte) messages with a 1 second gap between. Without the gap, or if
> the data is sent as one message, there's no problem. It's in the
> accumulation of data between messages to fulfill a read that this bug is
> triggered.

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

Those who are best at talking, realize last or never when they are wrong.


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

Re: [FFmpeg-devel] [PATCH] libavformat aviobuf: Fixed dst pointer initialization in fill_buffer

[Rob Meyers]

No problem. I'll resubmit the patch request.

On Mon, May 15, 2017 at 9:47 PM wm4  wrote:

> On Mon, 15 May 2017 17:55:28 +
> Rob Meyers  wrote:
>
> > Of course.
> >
> > We noticed when reading data from a named pipe the first 10 bytes would
> get
> > dropped. I traced this to the affected code in fill_buffer(). The
> > assignment of "dst" was always set to the beginning of the buffer, and if
> > it hadn't been consumed yet the data would be overwritten. We could
> > reproduce this by setting up a server that writes to the named pipe in
> two
> > small (6 byte) messages with a 1 second gap between. Without the gap, or
> if
> > the data is sent as one message, there's no problem. It's in the
> > accumulation of data between messages to fulfill a read that this bug is
> > triggered.
>
> Well, that explanation should be in the commit message (with a short 70
> char summary as subject line). Not just "fixed $thing".
> ___
> 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] Disable MSA optimization for big endian arch

[Michael Niedermayer]

On Mon, Apr 24, 2017 at 05:33:22PM +0530, shivraj.pa...@imgtec.com wrote:
> From: Shivraj Patil 
> 
> Signed-off-by: Shivraj Patil 
> ---
>  configure |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/configure b/configure
> index 1e3463c..c63a48a 100755
> --- a/configure
> +++ b/configure
> @@ -5357,6 +5357,10 @@ elif enabled mips; then
>  enabled mipsdsp && check_inline_asm_flags mipsdsp '"addu.qb $t0, $t1, 
> $t2"' '-mdsp'
>  enabled mipsdspr2 && check_inline_asm_flags mipsdspr2 '"absq_s.qb $t0, 
> $t1"' '-mdspr2'
>  
> +if enabled bigendian && enabled msa; then
> +disable msa
> +fi


the order of this looks a bit odd
for example there is above:
enabled mipsfpu && enabled msa && check_inline_asm_flags msa '"addvi.b $w0, 
$w1, 1"' '-mmsa' && check_header msa.h || disable msa

I think this would add -mmsa to the flags or disable msa already

with the code you add msa is disabled but -mmsa is left in the flags

Please correct me if iam wrong.

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

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/cuvid: Use a dummy packet to flush cuvid.

[Hendrik Leppkes]

On Tue, May 16, 2017 at 3:41 PM, Philip Langdale  wrote:
> On May 16, 2017, at 01:32, Timo Rothenpieler  wrote:
>>
>>> Am 16.05.2017 um 10:27 schrieb Wiki Wang:
>>> ---
>>> libavcodec/cuvid.c | 13 +++--
>>> 1 file changed, 3 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
>>> index 218be8495d..0b1710bd46 100644
>>> --- a/libavcodec/cuvid.c
>>> +++ b/libavcodec/cuvid.c
>>> @@ -1029,20 +1029,13 @@ static void cuvid_flush(AVCodecContext *avctx)
>>> return;
>>> }
>>>
>>> -if (ctx->cudecoder) {
>>> -ctx->cvdl->cuvidDestroyDecoder(ctx->cudecoder);
>>> -ctx->cudecoder = NULL;
>>> -}
>>> +seq_pkt.flags = CUVID_PKT_ENDOFSTREAM;
>>>
>>> -if (ctx->cuparser) {
>>> -ctx->cvdl->cuvidDestroyVideoParser(ctx->cuparser);
>>> -ctx->cuparser = NULL;
>>> -}
>>> -
>>> -ret = CHECK_CU(ctx->cvdl->cuvidCreateVideoParser(>cuparser, 
>>> >cuparseinfo));
>>> +ret = CHECK_CU(ctx->cvdl->cuvidParseVideoData(ctx->cuparser, 
>>> _pkt));
>>> if (ret < 0)
>>> goto error;
>>>
>>> +seq_pkt.flags = 0;
>>> seq_pkt.payload = ctx->cuparse_ext.raw_seqhdr_data;
>>> seq_pkt.payload_size = ctx->cuparse_ext.format.seqhdr_data_length;
>>>
>>>
>>
>> I'm not exactly sure what was the issue for this to be done this way,
>> but I remember there being some issue with just flushing the decoder,
>> hence the re-creation.
>>
> The issue is that when flushing for a media player, you need to drop all
> frames in the pipeline too. Inserting EOS means you still have n frames
> that will come out after the flush which breaks interactive seeking.
>

Indeed, flush should be an actual flush - discard all data and start fresh.

It should use the dummy packet "flush" at EOF, we call that operation
"draining" here, the decoder gets called with an empty packet in that
case (if it sets the delay flag, anyway).

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

Re: [FFmpeg-devel] [PATCH] avcodec/scpr: mask bits to prevent out of array read

[Michael Niedermayer]

On Tue, May 16, 2017 at 07:57:45AM +0200, Paul B Mahol wrote:
> On 5/16/17, Michael Niedermayer  wrote:
> > Fixes: 1615/clusterfuzz-testcase-minimized-6625214647500800
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/scpr.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> 
> lgtm

applied

thx

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] [PATCH] Added line to the af_bs2b filter docs mentioning --enable-libbs2b

[Michael Niedermayer]

On Tue, May 16, 2017 at 01:12:30PM +0200, Paul B Mahol wrote:
> On 5/16/17, Leo Izen  wrote:
> > ---
> >  doc/filters.texi | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 9611a41e28..a7c6063969 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -1911,6 +1911,9 @@ available are filtered.
> >  Bauer stereo to binaural transformation, which improves headphone listening
> > of
> >  stereo audio records.
> >
> > +To enable compilation of this filter you need to configure FFmpeg with
> > +@code{--enable-libbs2b}.
> > +
> >  It accepts the following parameters:
> >  @table @option
> >
> 
> lgtm

applied

thx

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

Re: [FFmpeg-devel] [PATCH] avcodec/cuvid: Use a dummy packet to flush cuvid.

[Philip Langdale]

On May 16, 2017, at 01:32, Timo Rothenpieler  wrote:
> 
>> Am 16.05.2017 um 10:27 schrieb Wiki Wang:
>> ---
>> libavcodec/cuvid.c | 13 +++--
>> 1 file changed, 3 insertions(+), 10 deletions(-)
>> 
>> diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
>> index 218be8495d..0b1710bd46 100644
>> --- a/libavcodec/cuvid.c
>> +++ b/libavcodec/cuvid.c
>> @@ -1029,20 +1029,13 @@ static void cuvid_flush(AVCodecContext *avctx)
>> return;
>> }
>> 
>> -if (ctx->cudecoder) {
>> -ctx->cvdl->cuvidDestroyDecoder(ctx->cudecoder);
>> -ctx->cudecoder = NULL;
>> -}
>> +seq_pkt.flags = CUVID_PKT_ENDOFSTREAM;
>> 
>> -if (ctx->cuparser) {
>> -ctx->cvdl->cuvidDestroyVideoParser(ctx->cuparser);
>> -ctx->cuparser = NULL;
>> -}
>> -
>> -ret = CHECK_CU(ctx->cvdl->cuvidCreateVideoParser(>cuparser, 
>> >cuparseinfo));
>> +ret = CHECK_CU(ctx->cvdl->cuvidParseVideoData(ctx->cuparser, _pkt));
>> if (ret < 0)
>> goto error;
>> 
>> +seq_pkt.flags = 0;
>> seq_pkt.payload = ctx->cuparse_ext.raw_seqhdr_data;
>> seq_pkt.payload_size = ctx->cuparse_ext.format.seqhdr_data_length;
>> 
>> 
> 
> I'm not exactly sure what was the issue for this to be done this way,
> but I remember there being some issue with just flushing the decoder,
> hence the re-creation.
> 
The issue is that when flushing for a media player, you need to drop all
frames in the pipeline too. Inserting EOS means you still have n frames
that will come out after the flush which breaks interactive seeking.

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

[FFmpeg-devel] 回覆: [PATCH 2/3] img2dec: .z, for piped SVG demuxing

[r97922...@gmail.com]

Pz
BE
MpR

從我的 HTC 寄出PC

- 回覆訊息 -
寄件者： "Carl Eugen Hoyos" 
收件者： "FFmpeg development discussions and patches" 
主旨： [FFmpeg-devel] [PATCH 2/3] img2dec: add support for piped SVG demuxing
日期： 週二, 5月 16 日, 2017 年 8:09 下午

2017-05-16 13:48 GMT+02:00 Rostislav Pehlivanov :
> On 16 May 2017 at 12:34, Carl Eugen Hoyos  wrote:
>
>> 2017-05-16 13:25 GMT+02:00 Rostislav Pehlivanov :
>> > On 16 May 2017 at 11:57, Carl Eugen Hoyos  wrote:
>> >
>> >> 2017-05-08 6:46 GMT+02:00 Rostislav Pehlivanov :
>> >> > Only checks the extension and MIME type, since determining whether
>> >> > a file is SVG is difficult since they're just XML files.
>> >>
>> >> Why didn't you just add svg and svgz to the image2 extensions?
>>
>> > image2 doesn't use extensions, it probes.
>>
>> The image2 demuxer only "probes" by looking at extensions.

> I see what you mean now, pushed a patch to use the same way of
> probing as the rest of img2dec.

What I meant was:
"Why didn't you add svg to the file libavformat/img2.c?"

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

Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects

[Steven Liu]

2017-05-16 20:23 GMT+08:00 wm4 :

> On Tue, 16 May 2017 05:04:36 -0700
> Aaron Levinson  wrote:
>
> > Add dxva2_pool_release_dummy() and use it in call to
> > av_buffer_create() in dxva2_pool_alloc().
> >
> > Prior to this change, av_buffer_create() was called with NULL for the
> > third argument, which indicates that av_buffer_default_free() should
> > be used to free the buffer's data.  Eventually, it gets to
> > buffer_pool_free() and calls buf->free() on a surface object (which is
> > av_buffer_default_free()).
> >
> > This can result in a crash when the debug version of the C-runtime is
> > used on Windows.  While it doesn't appear to result in a crash when
> > the release version of the C-runtime is used on Windows, it likely
> > results in memory corruption, since av_free() is being called on
> > memory that was allocated using
> > IDirectXVideoAccelerationService::CreateSurface().
> >
> > Signed-off-by: Aaron Levinson 
> > ---
> >  libavutil/hwcontext_dxva2.c | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
> > index 4ed0d56..6c41788 100644
> > --- a/libavutil/hwcontext_dxva2.c
> > +++ b/libavutil/hwcontext_dxva2.c
> > @@ -121,6 +121,13 @@ static void dxva2_frames_uninit(AVHWFramesContext
> *ctx)
> >  }
> >  }
> >
> > +static void dxva2_pool_release_dummy(void *opaque, uint8_t *data)
> > +{
> > +// important not to free anything here--data is a surface object
> > +// associated with the call to CreateSurface(), and these surfaces
> are
> > +// released in dxva2_frames_uninit()
> > +}
> > +
> >  static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
> >  {
> >  AVHWFramesContext  *ctx = (AVHWFramesContext*)opaque;
> > @@ -130,7 +137,7 @@ static AVBufferRef *dxva2_pool_alloc(void *opaque,
> int size)
> >  if (s->nb_surfaces_used < hwctx->nb_surfaces) {
> >  s->nb_surfaces_used++;
> >  return 
> > av_buffer_create((uint8_t*)s->surfaces_internal[s->nb_surfaces_used
> - 1],
> > -sizeof(*hwctx->surfaces), NULL, 0, 0);
> > +sizeof(*hwctx->surfaces),
> dxva2_pool_release_dummy, 0, 0);
> >  }
> >
> >  return NULL;
>
> LGTM
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] FFMpeg GPL license Violations by Android apps

[Steven Liu]

2017-05-16 18:32 GMT+08:00 Carl Eugen Hoyos :

> 2017-05-15 17:24 GMT+02:00 riya khanna :
> > Please find the list of apps here:
> > https://docs.google.com/spreadsheets/d/1YnBHbsYIyGxQbjpaIbU4LFjha3hx8
> 3ciKLk7htVjpT4/edit?usp=sharing
>
> As said, I believe it may be useful if you send this list - as plain text
> - to
> this mailing list.
>
> Please avoid top-posting here, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

if merge similar infomation maybe better


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

Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects

[wm4]

On Tue, 16 May 2017 05:04:36 -0700
Aaron Levinson  wrote:

> Add dxva2_pool_release_dummy() and use it in call to
> av_buffer_create() in dxva2_pool_alloc().
> 
> Prior to this change, av_buffer_create() was called with NULL for the
> third argument, which indicates that av_buffer_default_free() should
> be used to free the buffer's data.  Eventually, it gets to
> buffer_pool_free() and calls buf->free() on a surface object (which is
> av_buffer_default_free()).
> 
> This can result in a crash when the debug version of the C-runtime is
> used on Windows.  While it doesn't appear to result in a crash when
> the release version of the C-runtime is used on Windows, it likely
> results in memory corruption, since av_free() is being called on
> memory that was allocated using
> IDirectXVideoAccelerationService::CreateSurface().
> 
> Signed-off-by: Aaron Levinson 
> ---
>  libavutil/hwcontext_dxva2.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
> index 4ed0d56..6c41788 100644
> --- a/libavutil/hwcontext_dxva2.c
> +++ b/libavutil/hwcontext_dxva2.c
> @@ -121,6 +121,13 @@ static void dxva2_frames_uninit(AVHWFramesContext *ctx)
>  }
>  }
>  
> +static void dxva2_pool_release_dummy(void *opaque, uint8_t *data)
> +{
> +// important not to free anything here--data is a surface object
> +// associated with the call to CreateSurface(), and these surfaces are
> +// released in dxva2_frames_uninit()
> +}
> +
>  static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
>  {
>  AVHWFramesContext  *ctx = (AVHWFramesContext*)opaque;
> @@ -130,7 +137,7 @@ static AVBufferRef *dxva2_pool_alloc(void *opaque, int 
> size)
>  if (s->nb_surfaces_used < hwctx->nb_surfaces) {
>  s->nb_surfaces_used++;
>  return 
> av_buffer_create((uint8_t*)s->surfaces_internal[s->nb_surfaces_used - 1],
> -sizeof(*hwctx->surfaces), NULL, 0, 0);
> +sizeof(*hwctx->surfaces), 
> dxva2_pool_release_dummy, 0, 0);
>  }
>  
>  return NULL;

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

Re: [FFmpeg-devel] [PATCH 2/3] img2dec: add support for piped SVG demuxing

[Carl Eugen Hoyos]

2017-05-16 13:48 GMT+02:00 Rostislav Pehlivanov :
> On 16 May 2017 at 12:34, Carl Eugen Hoyos  wrote:
>
>> 2017-05-16 13:25 GMT+02:00 Rostislav Pehlivanov :
>> > On 16 May 2017 at 11:57, Carl Eugen Hoyos  wrote:
>> >
>> >> 2017-05-08 6:46 GMT+02:00 Rostislav Pehlivanov :
>> >> > Only checks the extension and MIME type, since determining whether
>> >> > a file is SVG is difficult since they're just XML files.
>> >>
>> >> Why didn't you just add svg and svgz to the image2 extensions?
>>
>> > image2 doesn't use extensions, it probes.
>>
>> The image2 demuxer only "probes" by looking at extensions.

> I see what you mean now, pushed a patch to use the same way of
> probing as the rest of img2dec.

What I meant was:
"Why didn't you add svg to the file libavformat/img2.c?"

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

Re: [FFmpeg-devel] [PATCH]Two patches from github

[Benoit Fouet]

Hi,


On 15/05/2017 12:40, Carl Eugen Hoyos wrote:
>
> 0002-avutil-Use-_SC_NPROCESSORS_CONF.patch
>
>
> From 42766f345dbf398716c6fd9072f072f5fa91c940 Mon Sep 17 00:00:00 2001
> From: Steve Kondik 
> Date: Tue, 16 Dec 2014 01:37:57 -0800
> Subject: [PATCH 2/2] avutil: Use _SC_NPROCESSORS_CONF
>
>  * On most Android devices, CPUs can appear and disappear due to hotplug
>or CPU cluster management. Use the total number of CPUs instead so
>that multithreaded decoding is properly optimized.

I'm not convinced the patch below fixes the issue described above.
The idea is to optimize the number of threads given the number of usable
CPUs.
If a user of libav* wants to make sure they use the right number, they
should make sure that the CPUs are woken up prior to calling this.
There are ways to force the system's power management to make sure that
the number of online CPUs is maximized, and, IMHO, that should be used
instead of returning the total number of CPUs on the platform.

> Change-Id: I1cbf000a1bda7b3abf0a84e971e752f176857385
> ---
>  libavutil/cpu.c |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavutil/cpu.c b/libavutil/cpu.c
> index 16e0c92..ab0965b 100644
> --- a/libavutil/cpu.c
> +++ b/libavutil/cpu.c
> @@ -282,6 +282,8 @@ int av_cpu_count(void)
>  
>  if (sysctl(mib, 2, _cpus, , NULL, 0) == -1)
>  nb_cpus = 0;
> +#elif defined(__ANDROID__) && HAVE_SYSCONF && defined(_SC_NPROCESSORS_CONF)
> +nb_cpus = sysconf(_SC_NPROCESSORS_CONF);
>  #elif HAVE_SYSCONF && defined(_SC_NPROC_ONLN)
>  nb_cpus = sysconf(_SC_NPROC_ONLN);
>  #elif HAVE_SYSCONF && defined(_SC_NPROCESSORS_ONLN)
> -- 1.7.10.4

-- 
Ben

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

[FFmpeg-devel] [PATCH] avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects

[Aaron Levinson]

Add dxva2_pool_release_dummy() and use it in call to
av_buffer_create() in dxva2_pool_alloc().

Prior to this change, av_buffer_create() was called with NULL for the
third argument, which indicates that av_buffer_default_free() should
be used to free the buffer's data.  Eventually, it gets to
buffer_pool_free() and calls buf->free() on a surface object (which is
av_buffer_default_free()).

This can result in a crash when the debug version of the C-runtime is
used on Windows.  While it doesn't appear to result in a crash when
the release version of the C-runtime is used on Windows, it likely
results in memory corruption, since av_free() is being called on
memory that was allocated using
IDirectXVideoAccelerationService::CreateSurface().

Signed-off-by: Aaron Levinson 
---
 libavutil/hwcontext_dxva2.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
index 4ed0d56..6c41788 100644
--- a/libavutil/hwcontext_dxva2.c
+++ b/libavutil/hwcontext_dxva2.c
@@ -121,6 +121,13 @@ static void dxva2_frames_uninit(AVHWFramesContext *ctx)
 }
 }
 
+static void dxva2_pool_release_dummy(void *opaque, uint8_t *data)
+{
+// important not to free anything here--data is a surface object
+// associated with the call to CreateSurface(), and these surfaces are
+// released in dxva2_frames_uninit()
+}
+
 static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
 {
 AVHWFramesContext  *ctx = (AVHWFramesContext*)opaque;
@@ -130,7 +137,7 @@ static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
 if (s->nb_surfaces_used < hwctx->nb_surfaces) {
 s->nb_surfaces_used++;
 return 
av_buffer_create((uint8_t*)s->surfaces_internal[s->nb_surfaces_used - 1],
-sizeof(*hwctx->surfaces), NULL, 0, 0);
+sizeof(*hwctx->surfaces), 
dxva2_pool_release_dummy, 0, 0);
 }
 
 return NULL;
-- 
2.10.1.windows.1

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

Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_dxva2: No longer improperly freeing IDirect3DSurface9 objects

[Aaron Levinson]

Please disregard--I will submit a new patch with a better commit message.

Aaron

On 5/16/2017 4:09 AM, Aaron Levinson wrote:

Purpose: No longer improperly freeing IDirect3DSurface9 objects in
hwcontext_dxva2.c.  Added dxva2_pool_release_dummy() and using it in
call to av_buffer_create() in dxva2_pool_alloc().  Prior to this
change, av_buffer_create() was called with NULL for the third
argument, which indicates that av_buffer_default_free() should be used
to free the buffer's data.  Eventually, it gets to buffer_pool_free()
and calls buf->free() on a surface object (which is
av_buffer_default_free()).  This can result in a crash when the debug
version of the C-runtime is used on Windows.  While it doesn't appear
to result in a crash when the release version of the C-runtime is used
on Windows, it likely results in memory corruption, since av_free() is
being called on memory that was allocated using
IDirectXVideoAccelerationService::CreateSurface().

Signed-off-by: Aaron Levinson 
---
 libavutil/hwcontext_dxva2.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
index 4ed0d56..6c41788 100644
--- a/libavutil/hwcontext_dxva2.c
+++ b/libavutil/hwcontext_dxva2.c
@@ -121,6 +121,13 @@ static void dxva2_frames_uninit(AVHWFramesContext *ctx)
 }
 }

+static void dxva2_pool_release_dummy(void *opaque, uint8_t *data)
+{
+// important not to free anything here--data is a surface object
+// associated with the call to CreateSurface(), and these surfaces are
+// released in dxva2_frames_uninit()
+}
+
 static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
 {
 AVHWFramesContext  *ctx = (AVHWFramesContext*)opaque;
@@ -130,7 +137,7 @@ static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
 if (s->nb_surfaces_used < hwctx->nb_surfaces) {
 s->nb_surfaces_used++;
 return 
av_buffer_create((uint8_t*)s->surfaces_internal[s->nb_surfaces_used - 1],
-sizeof(*hwctx->surfaces), NULL, 0, 0);
+sizeof(*hwctx->surfaces), 
dxva2_pool_release_dummy, 0, 0);
 }

 return NULL;


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

Re: [FFmpeg-devel] [PATCH 2/3] img2dec: add support for piped SVG demuxing

[Rostislav Pehlivanov]

On 16 May 2017 at 12:34, Carl Eugen Hoyos  wrote:

> 2017-05-16 13:25 GMT+02:00 Rostislav Pehlivanov :
> > On 16 May 2017 at 11:57, Carl Eugen Hoyos  wrote:
> >
> >> 2017-05-08 6:46 GMT+02:00 Rostislav Pehlivanov :
> >> > Only checks the extension and MIME type, since determining whether
> >> > a file is SVG is difficult since they're just XML files.
> >>
> >> Why didn't you just add svg and svgz to the image2 extensions?
>
> > image2 doesn't use extensions, it probes.
>
> The image2 demuxer only "probes" by looking at extensions.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


I see what you mean now, pushed a patch to use the same way of probing as
the rest of img2dec.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] img2dec: add support for piped SVG demuxing

[Carl Eugen Hoyos]

2017-05-16 13:25 GMT+02:00 Rostislav Pehlivanov :
> On 16 May 2017 at 11:57, Carl Eugen Hoyos  wrote:
>
>> 2017-05-08 6:46 GMT+02:00 Rostislav Pehlivanov :
>> > Only checks the extension and MIME type, since determining whether
>> > a file is SVG is difficult since they're just XML files.
>>
>> Why didn't you just add svg and svgz to the image2 extensions?

> image2 doesn't use extensions, it probes.

The image2 demuxer only "probes" by looking at extensions.

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

Re: [FFmpeg-devel] [PATCH 2/3] img2dec: add support for piped SVG demuxing

[Rostislav Pehlivanov]

On 16 May 2017 at 11:57, Carl Eugen Hoyos  wrote:

> 2017-05-08 6:46 GMT+02:00 Rostislav Pehlivanov :
> > Only checks the extension and MIME type, since determining whether
> > a file is SVG is difficult since they're just XML files.
>
> Why didn't you just add svg and svgz to the image2 extensions?
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

image2 doesn't use extensions, it probes. Hence why I couldn't use the
macro, since it doesn't actually make lavf check the extension and probing
svg is difficult (and librsvg doesn't offer support for probing).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]Two patches from github

[wm4]

On Tue, 16 May 2017 12:40:03 +0200
Carl Eugen Hoyos  wrote:

> 2017-05-15 12:53 GMT+02:00 wm4 :
> > On Mon, 15 May 2017 12:40:23 +0200
> > Carl Eugen Hoyos  wrote:
> >  
> >> From 42766f345dbf398716c6fd9072f072f5fa91c940 Mon Sep 17 00:00:00 2001
> >> From: Steve Kondik 
> >> Date: Tue, 16 Dec 2014 01:37:57 -0800
> >> Subject: [PATCH 2/2] avutil: Use _SC_NPROCESSORS_CONF
> >>
> >>  * On most Android devices, CPUs can appear and disappear due to hotplug
> >>or CPU cluster management. Use the total number of CPUs instead so
> >>that multithreaded decoding is properly optimized.  
> >
> > This explanation isn't really sufficient.  
> 
> Please suggest a better one assuming you are objecting pushing as-is.

Yes, I'm objecting. I don't have to suggest a better one - you're the
one who wants to push this.

> > Also not why you would want
> > this, or why you would want this only on Android.  
> 
> The explanation sounded to me as if this would be Android-only.

The explanation is completely insufficient.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] configure: use -x instead of -wN ..@ to strip assembly files

[Rostislav Pehlivanov]

Reduces the amount of debugging information of external asm from
uselessly verbose to informative enough.
---
 configure | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/configure b/configure
index e4862f6a35..df849df14f 100755
--- a/configure
+++ b/configure
@@ -6185,8 +6185,7 @@ enabled rpath && add_ldlibflags -Wl,-rpath,$libdir
 test_ldflags -Wl,-Bsymbolic && append SHFLAGS -Wl,-Bsymbolic
 
 # add some strip flags
-# -wN '..@*' is more selective than -x, but not available everywhere.
-check_stripflags -wN \'..@*\' || check_stripflags -x
+check_stripflags -x
 
 enabled neon_clobber_test &&
 check_ldflags -Wl,--wrap,avcodec_open2  \
-- 
2.13.0.303.g4ebf302169

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

Re: [FFmpeg-devel] [PATCH] Added line to the af_bs2b filter docs mentioning --enable-libbs2b

[Paul B Mahol]

On 5/16/17, Leo Izen  wrote:
> ---
>  doc/filters.texi | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 9611a41e28..a7c6063969 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -1911,6 +1911,9 @@ available are filtered.
>  Bauer stereo to binaural transformation, which improves headphone listening
> of
>  stereo audio records.
>
> +To enable compilation of this filter you need to configure FFmpeg with
> +@code{--enable-libbs2b}.
> +
>  It accepts the following parameters:
>  @table @option
>

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

[FFmpeg-devel] [PATCH] avutil/hwcontext_dxva2: No longer improperly freeing IDirect3DSurface9 objects

[Aaron Levinson]

Purpose: No longer improperly freeing IDirect3DSurface9 objects in
hwcontext_dxva2.c.  Added dxva2_pool_release_dummy() and using it in
call to av_buffer_create() in dxva2_pool_alloc().  Prior to this
change, av_buffer_create() was called with NULL for the third
argument, which indicates that av_buffer_default_free() should be used
to free the buffer's data.  Eventually, it gets to buffer_pool_free()
and calls buf->free() on a surface object (which is
av_buffer_default_free()).  This can result in a crash when the debug
version of the C-runtime is used on Windows.  While it doesn't appear
to result in a crash when the release version of the C-runtime is used
on Windows, it likely results in memory corruption, since av_free() is
being called on memory that was allocated using
IDirectXVideoAccelerationService::CreateSurface().

Signed-off-by: Aaron Levinson 
---
 libavutil/hwcontext_dxva2.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
index 4ed0d56..6c41788 100644
--- a/libavutil/hwcontext_dxva2.c
+++ b/libavutil/hwcontext_dxva2.c
@@ -121,6 +121,13 @@ static void dxva2_frames_uninit(AVHWFramesContext *ctx)
 }
 }
 
+static void dxva2_pool_release_dummy(void *opaque, uint8_t *data)
+{
+// important not to free anything here--data is a surface object
+// associated with the call to CreateSurface(), and these surfaces are
+// released in dxva2_frames_uninit()
+}
+
 static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
 {
 AVHWFramesContext  *ctx = (AVHWFramesContext*)opaque;
@@ -130,7 +137,7 @@ static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
 if (s->nb_surfaces_used < hwctx->nb_surfaces) {
 s->nb_surfaces_used++;
 return 
av_buffer_create((uint8_t*)s->surfaces_internal[s->nb_surfaces_used - 1],
-sizeof(*hwctx->surfaces), NULL, 0, 0);
+sizeof(*hwctx->surfaces), 
dxva2_pool_release_dummy, 0, 0);
 }
 
 return NULL;
-- 
2.10.1.windows.1

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

Re: [FFmpeg-devel] [PATCH 2/3] img2dec: add support for piped SVG demuxing

[Carl Eugen Hoyos]

2017-05-08 6:46 GMT+02:00 Rostislav Pehlivanov :
> Only checks the extension and MIME type, since determining whether
> a file is SVG is difficult since they're just XML files.

Why didn't you just add svg and svgz to the image2 extensions?

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

Re: [FFmpeg-devel] [PATCH 2/3] img2dec: add support for piped SVG demuxing

[Rostislav Pehlivanov]

On 8 May 2017 at 05:46, Rostislav Pehlivanov  wrote:

> Only checks the extension and MIME type, since determining whether
> a file is SVG is difficult since they're just XML files.
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavformat/Makefile |  1 +
>  libavformat/allformats.c |  1 +
>  libavformat/img2dec.c| 20 
>  3 files changed, 22 insertions(+)
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 4e169fdce5..bfba0c1cb4 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -237,6 +237,7 @@ OBJS-$(CONFIG_IMAGE_PPM_PIPE_DEMUXER) +=
> img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_PSD_PIPE_DEMUXER) += img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_QDRAW_PIPE_DEMUXER)   += img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_SGI_PIPE_DEMUXER) += img2dec.o img2.o
> +OBJS-$(CONFIG_IMAGE_SVG_PIPE_DEMUXER) += img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_SUNRAST_PIPE_DEMUXER) += img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_TIFF_PIPE_DEMUXER)+= img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_WEBP_PIPE_DEMUXER)+= img2dec.o img2.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 09e62c3cfc..62661d14a4 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -369,6 +369,7 @@ static void register_all(void)
>  REGISTER_DEMUXER (IMAGE_PSD_PIPE,image_psd_pipe);
>  REGISTER_DEMUXER (IMAGE_QDRAW_PIPE,  image_qdraw_pipe);
>  REGISTER_DEMUXER (IMAGE_SGI_PIPE,image_sgi_pipe);
> +REGISTER_DEMUXER (IMAGE_SVG_PIPE,image_svg_pipe);
>  REGISTER_DEMUXER (IMAGE_SUNRAST_PIPE,image_sunrast_pipe);
>  REGISTER_DEMUXER (IMAGE_TIFF_PIPE,   image_tiff_pipe);
>  REGISTER_DEMUXER (IMAGE_WEBP_PIPE,   image_webp_pipe);
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> index b454071168..1d532e9343 100644
> --- a/libavformat/img2dec.c
> +++ b/libavformat/img2dec.c
> @@ -971,6 +971,26 @@ AVInputFormat ff_image_ ## imgname ## _pipe_demuxer =
> {\
>  .raw_codec_id   = codecid,\
>  };
>
> +static const AVClass svg_class = {
> +.class_name = "svg demuxer",
> +.item_name  = av_default_item_name,
> +.option = ff_img_options,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +
> +AVInputFormat ff_image_svg_pipe_demuxer = {
> +.name   = "svg_pipe",
> +.long_name  = NULL_IF_CONFIG_SMALL("piped svg sequence"),
> +.priv_data_size = sizeof(VideoDemuxData),
> +.read_header= ff_img_read_header,
> +.read_packet= ff_img_read_packet,
> +.priv_class = _class,
> +.mime_type  = "image/svg+xml",
> +.extensions = "svg,svgz",
> +.flags  = AVFMT_GENERIC_INDEX,
> +.raw_codec_id   = AV_CODEC_ID_SVG,
> +};
> +
>  IMAGEAUTO_DEMUXER(bmp, AV_CODEC_ID_BMP)
>  IMAGEAUTO_DEMUXER(dds, AV_CODEC_ID_DDS)
>  IMAGEAUTO_DEMUXER(dpx, AV_CODEC_ID_DPX)
> --
> 2.13.0.rc1.294.g07d810a77f
>
>
Pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]Two patches from github

[Carl Eugen Hoyos]

2017-05-15 12:53 GMT+02:00 wm4 :
> On Mon, 15 May 2017 12:40:23 +0200
> Carl Eugen Hoyos  wrote:
>
>> From 42766f345dbf398716c6fd9072f072f5fa91c940 Mon Sep 17 00:00:00 2001
>> From: Steve Kondik 
>> Date: Tue, 16 Dec 2014 01:37:57 -0800
>> Subject: [PATCH 2/2] avutil: Use _SC_NPROCESSORS_CONF
>>
>>  * On most Android devices, CPUs can appear and disappear due to hotplug
>>or CPU cluster management. Use the total number of CPUs instead so
>>that multithreaded decoding is properly optimized.
>
> This explanation isn't really sufficient.

Please suggest a better one assuming you are objecting pushing as-is.

> Also not why you would want
> this, or why you would want this only on Android.

The explanation sounded to me as if this would be Android-only.

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

Re: [FFmpeg-devel] [PATCH 3/3] lavc: add a librsvg rasterization library wrapper

[Rostislav Pehlivanov]

On 8 May 2017 at 05:46, Rostislav Pehlivanov  wrote:

> Enables rendering of SVG images. This is possible since SVG images
> still contain and specify the dimensions in pixels to which they've
> been drawn to and thus enable browsers to display them without any
> external data. Users can still override and generate images with
> arbitrary resolutions.
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  configure   |   4 ++
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/librsvgdec.c | 127 ++
> ++
>  4 files changed, 133 insertions(+)
>  create mode 100644 libavcodec/librsvgdec.c
>
> diff --git a/configure b/configure
> index 2e1786a6fc..4f20d177a5 100755
> --- a/configure
> +++ b/configure
> @@ -245,6 +245,7 @@ External library support:
>--enable-libopenmpt  enable decoding tracked files via libopenmpt
> [no]
>--enable-libopus enable Opus de/encoding via libopus [no]
>--enable-libpulseenable Pulseaudio input via libpulse [no]
> +  --enable-librsvg enable SVG rasterization via librsvg [no]
>--enable-librubberband   enable rubberband needed for rubberband filter
> [no]
>--enable-librtmp enable RTMP[E] support via librtmp [no]
>--enable-libschroedinger enable Dirac de/encoding via libschroedinger
> [no]
> @@ -1557,6 +1558,7 @@ EXTERNAL_LIBRARY_LIST="
>  libopenmpt
>  libopus
>  libpulse
> +librsvg
>  librtmp
>  libschroedinger
>  libshine
> @@ -2867,6 +2869,7 @@ libopenmpt_demuxer_deps="libopenmpt"
>  libopus_decoder_deps="libopus"
>  libopus_encoder_deps="libopus"
>  libopus_encoder_select="audio_frame_queue"
> +librsvg_decoder_deps="librsvg"
>  libschroedinger_decoder_deps="libschroedinger"
>  libschroedinger_encoder_deps="libschroedinger"
>  libshine_encoder_deps="libshine"
> @@ -5819,6 +5822,7 @@ enabled libopus   && {
>  }
>  }
>  enabled libpulse  && require_pkg_config libpulse
> pulse/pulseaudio.h pa_context_new
> +enabled librsvg   && require_pkg_config librsvg-2.0
> librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
>  enabled librtmp   && require_pkg_config librtmp librtmp/rtmp.h
> RTMP_Socket
>  enabled librubberband && require_pkg_config "rubberband >= 1.8.1"
> rubberband/rubberband-c.h rubberband_new
>  enabled libschroedinger   && require_pkg_config schroedinger-1.0
> schroedinger/schro.h schro_init
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index b5c8cc1f98..5829063ee8 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -550,6 +550,7 @@ OBJS-$(CONFIG_SUBVIEWER1_DECODER)  += textdec.o
> ass.o
>  OBJS-$(CONFIG_SUBVIEWER_DECODER)   += subviewerdec.o ass.o
>  OBJS-$(CONFIG_SUNRAST_DECODER) += sunrast.o
>  OBJS-$(CONFIG_SUNRAST_ENCODER) += sunrastenc.o
> +OBJS-$(CONFIG_LIBRSVG_DECODER) += librsvgdec.o
>  OBJS-$(CONFIG_SVQ1_DECODER)+= svq1dec.o svq1.o svq13.o
> h263data.o
>  OBJS-$(CONFIG_SVQ1_ENCODER)+= svq1enc.o svq1.o  h263data.o  \
>h263.o ituh263enc.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 7fcc26f2c1..425a32c924 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -319,6 +319,7 @@ static void register_all(void)
>  REGISTER_DECODER(SPEEDHQ,   speedhq);
>  REGISTER_DECODER(SRGC,  srgc);
>  REGISTER_ENCDEC (SUNRAST,   sunrast);
> +REGISTER_DECODER(LIBRSVG,   librsvg);
>  REGISTER_ENCDEC (SVQ1,  svq1);
>  REGISTER_DECODER(SVQ3,  svq3);
>  REGISTER_ENCDEC (TARGA, targa);
> diff --git a/libavcodec/librsvgdec.c b/libavcodec/librsvgdec.c
> new file mode 100644
> index 00..29b771c5a3
> --- /dev/null
> +++ b/libavcodec/librsvgdec.c
> @@ -0,0 +1,127 @@
> +/*
> + * Librsvg rasterization wrapper
> + * Copyright (c) 2017 Rostislav Pehlivanov 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include "avcodec.h"
> +#include "internal.h"
> +#include "libavutil/opt.h"
> +#include 

Re: [FFmpeg-devel] [PATCH 1/3] lavc: add codec ID and description for SVG

[Rostislav Pehlivanov]

On 8 May 2017 at 05:46, Rostislav Pehlivanov  wrote:

> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/avcodec.h| 1 +
>  libavcodec/codec_desc.c | 8 
>  2 files changed, 9 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 35df4f6ced..4bbe5179b4 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -445,6 +445,7 @@ enum AVCodecID {
>  AV_CODEC_ID_BITPACKED,
>  AV_CODEC_ID_MSCC,
>  AV_CODEC_ID_SRGC,
> +AV_CODEC_ID_SVG,
>
>  /* various PCM "codecs" */
>  AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at
> the start of audio codecs
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 2d28f840af..8fb157cc5f 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -170,6 +170,14 @@ static const AVCodecDescriptor codec_descriptors[] = {
>  .props = AV_CODEC_PROP_LOSSY,
>  },
>  {
> +.id= AV_CODEC_ID_SVG,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "svq",
> +.long_name = NULL_IF_CONFIG_SMALL("Scalable Vector Graphics"),
> +.props = AV_CODEC_PROP_LOSSLESS,
> +.mime_types= MT("image/svg+xml"),
> +},
> +{
>  .id= AV_CODEC_ID_SVQ1,
>  .type  = AVMEDIA_TYPE_VIDEO,
>  .name  = "svq1",
> --
> 2.13.0.rc1.294.g07d810a77f
>
>
Pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFMpeg GPL license Violations by Android apps

[Carl Eugen Hoyos]

2017-05-15 17:24 GMT+02:00 riya khanna :
> Please find the list of apps here:
> https://docs.google.com/spreadsheets/d/1YnBHbsYIyGxQbjpaIbU4LFjha3hx83ciKLk7htVjpT4/edit?usp=sharing

As said, I believe it may be useful if you send this list - as plain text - to
this mailing list.

Please avoid top-posting here, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dcaenc: Do not abort process in case of bitrate deficit

[Rostislav Pehlivanov]

On 12 May 2017 at 00:33, Даниил Чередник  wrote:

> Hi.
>
> This patch removes assert which can cause abort process in case of limited
> bitrate:
>
> Old behaviour - abort if at least one subband has 1bit quantizer
> and consumed_bits still greater than frame_bits size. It was
> a bit strange - we still could reduce bits consumption by reducing
> SNR for other subbands. Same strange logic with upper threshold -
> stop bits allocation if at least one subband reach 26bits.
>
> New behaviour - if consumed_bits greater than frame_bits and all
> subbands has 1 bit quantizer we restart bits allocation and allow
> zero subbands.
>
> --
> Daniil Cherednik
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Hi, sorry for the delay.
Tested the patch and it did help reduce the minimum bitrate a little,
though I suppose it helps quality more.
Thanks, patch applied!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: jni no longer requires -ldl

[Matthieu Bouron]

On Sat, May 13, 2017 at 05:26:13PM +0200, Matthieu Bouron wrote:
> On Fri, May 12, 2017 at 12:14:20PM -0700, Aaron Levinson wrote:
> > On 5/12/2017 11:34 AM, Aman Gupta wrote:
> > > From: Aman Gupta 
> > > 
> > > this dependency was removed in 33d69a90085d30af8a292d9364b835a26565d6b9
> > > ---
> > >  configure | 3 +--
> > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > > 
> > > diff --git a/configure b/configure
> > > index 5ae5227868..ba33241a45 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -5766,8 +5766,7 @@ enabled decklink  && { { check_header 
> > > DeckLinkAPI.h || die "ERROR: DeckL
> > >  enabled frei0r&& { check_header frei0r.h || die "ERROR: 
> > > frei0r.h header not found"; }
> > >  enabled gmp   && require gmp gmp.h mpz_export -lgmp
> > >  enabled gnutls&& require_pkg_config gnutls gnutls/gnutls.h 
> > > gnutls_global_init
> > > -enabled jni   && { [ $target_os = "android" ] && 
> > > check_header jni.h && enabled pthreads &&
> > > -   check_lib jni "dlfcn.h" dlopen -ldl || 
> > > die "ERROR: jni not found"; }
> > > +enabled jni   && { [ $target_os = "android" ] && 
> > > check_header jni.h && enabled pthreads || die "ERROR: jni not found"; }
> > >  enabled ladspa&& { check_header ladspa.h || die "ERROR: 
> > > ladspa.h header not found"; }
> > >  enabled libiec61883   && require libiec61883 libiec61883/iec61883.h 
> > > iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
> > >  enabled libass&& require_pkg_config libass ass/ass.h 
> > > ass_library_init
> > > 
> > 
> > LGTM--I see that the use of dl was eliminated in 33d69a9 (at 
> > https://github.com/FFmpeg/FFmpeg/commit/33d69a90085d30af8a292d9364b835a26565d6b9
> > ).
> 
> LGTM too.

Patch applied.

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

Re: [FFmpeg-devel] [PATCH] avcodec/cuvid: Use a dummy packet to flush cuvid.

[Timo Rothenpieler]

Am 16.05.2017 um 10:27 schrieb Wiki Wang:
> ---
>  libavcodec/cuvid.c | 13 +++--
>  1 file changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
> index 218be8495d..0b1710bd46 100644
> --- a/libavcodec/cuvid.c
> +++ b/libavcodec/cuvid.c
> @@ -1029,20 +1029,13 @@ static void cuvid_flush(AVCodecContext *avctx)
>  return;
>  }
>  
> -if (ctx->cudecoder) {
> -ctx->cvdl->cuvidDestroyDecoder(ctx->cudecoder);
> -ctx->cudecoder = NULL;
> -}
> +seq_pkt.flags = CUVID_PKT_ENDOFSTREAM;
>  
> -if (ctx->cuparser) {
> -ctx->cvdl->cuvidDestroyVideoParser(ctx->cuparser);
> -ctx->cuparser = NULL;
> -}
> -
> -ret = CHECK_CU(ctx->cvdl->cuvidCreateVideoParser(>cuparser, 
> >cuparseinfo));
> +ret = CHECK_CU(ctx->cvdl->cuvidParseVideoData(ctx->cuparser, _pkt));
>  if (ret < 0)
>  goto error;
>  
> +seq_pkt.flags = 0;
>  seq_pkt.payload = ctx->cuparse_ext.raw_seqhdr_data;
>  seq_pkt.payload_size = ctx->cuparse_ext.format.seqhdr_data_length;
>  
> 

I'm not exactly sure what was the issue for this to be done this way,
but I remember there being some issue with just flushing the decoder,
hence the re-creation.



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

[FFmpeg-devel] [PATCH] avcodec/cuvid: Use a dummy packet to flush cuvid.

[Wiki Wang]

---
 libavcodec/cuvid.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index 218be8495d..0b1710bd46 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -1029,20 +1029,13 @@ static void cuvid_flush(AVCodecContext *avctx)
 return;
 }
 
-if (ctx->cudecoder) {
-ctx->cvdl->cuvidDestroyDecoder(ctx->cudecoder);
-ctx->cudecoder = NULL;
-}
+seq_pkt.flags = CUVID_PKT_ENDOFSTREAM;
 
-if (ctx->cuparser) {
-ctx->cvdl->cuvidDestroyVideoParser(ctx->cuparser);
-ctx->cuparser = NULL;
-}
-
-ret = CHECK_CU(ctx->cvdl->cuvidCreateVideoParser(>cuparser, 
>cuparseinfo));
+ret = CHECK_CU(ctx->cvdl->cuvidParseVideoData(ctx->cuparser, _pkt));
 if (ret < 0)
 goto error;
 
+seq_pkt.flags = 0;
 seq_pkt.payload = ctx->cuparse_ext.raw_seqhdr_data;
 seq_pkt.payload_size = ctx->cuparse_ext.format.seqhdr_data_length;
 
-- 
2.12.2.windows.2

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

Re: [FFmpeg-devel] [PATCH v10] - Added Turing codec interface for ffmpeg

[Saverio Blasi]

Dear all,

We would appreciate if you could let us know the procedure and expected 
timeline for integration of our patch related with the Turing codec within the 
ffmpeg project.

Thank you,
All the best,
Saverio



-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
Saverio Blasi
Sent: 11 May 2017 08:21
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH v10] - Added Turing codec interface for 
ffmpeg

Dear all,

First of all thank you very much for all the help you provided with this patch. 
We are now at the tenth iteration, and the patch greatly improved since the 
first time we submitted it. In fact most of the lines of code in the current 
version of the patch were suggested by you or revised many times already.

Regarding the implementation of the cmd parsing, as Hendrik is pointing out 
below, we followed other similar approaches (of other codecs). We already 
revised this implementation following your comments in previous iterations of 
this patch. At this stage, we would prefer to avoid changing again its 
structure and keep the implementation as it is, because this gives us more 
flexibility and also aligns it with other similar projects already integrated 
with ffmpeg.

We would appreciate if you could let us know the procedure from here on for 
integration of this patch within the ffmpeg project.

Thank you,
All the best,
Saverio

>> Dear Michael,
>>
 Why do you pass a single string of all options and then manually 
 parse all options out of it instead of specifying the options each 
 in teh AVOption array ?

>>> We prefer to pass a single string so that we can be more flexible 
>>> how we then parse it and what to do with it. This gives us more 
>>> freedom in the future in case we decide to change some of the codec 
>>> APIs, so that we do not need to change the interface with FFmpeg.
>>
>> That is unacceptable.

> libx264 and 265 pass options the same way, what exactly is the problem with 
> that?


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

Re: [FFmpeg-devel] [PATCH] avcodec/scpr: mask bits to prevent out of array read

[Paul B Mahol]

On 5/16/17, Michael Niedermayer  wrote:
> Fixes: 1615/clusterfuzz-testcase-minimized-6625214647500800
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/scpr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

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