Re: [FFmpeg-devel] [PATCH] Revert "Merge commit '741b494fa8cd28a7d096349bac183893c236e3f9'"

[Hendrik Leppkes]

On Thu, Dec 17, 2015 at 2:46 PM, Hendrik Leppkes  wrote:
> On Thu, Dec 17, 2015 at 2:06 PM, Michael Niedermayer  wrote:
>> From: Michael Niedermayer 
>>
>> This fixes a regression of the sample from Ticket 2371
>>
>> This reverts commit bc66451e5e903698ee0500faf04c1214f3dd157f, reversing
>> changes made to 9d1fb9ef313e0fb709ac4c35c7bf00264963fd85.
>> ---
>>  libavcodec/h264.h   |8 +++
>>  libavcodec/h264_refs.c  |   57 
>> ++-
>>  libavcodec/h264_slice.c |   17 +-
>>  3 files changed, 56 insertions(+), 26 deletions(-)
>
> Reverting big commits to fix one sample and making future merges
> harder or impossible seems not like the best option, unless it can be
> shown that the entire change is flawed, and not just a small bug.
> Otherwise, it should be attempted to fix regressions the usual way -
> by fixing things, not reverting.
>
> Once reverted, the change will never come back, we all know that.
>
> At least thats IMHO. You are the maintainer of the H264 decoder, so if
> you want to revert it, feel free.

Libav apparently has a fix for this one:
https://lists.libav.org/pipermail/libav-devel/2015-December/073673.html

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

Re: [FFmpeg-devel] [PATCH] avcodec/nellymoserenc: avoid wasteful pow

[Kacper Michajlow]

One minor nitpick about commit message. You could mention which compiler
was used to generate code for benchmark. For example Clang 3.7 replaces
pow(2,...) with exp2(...) call by itself. So you probably did use gcc.
Anyway since it is already merged I guess take my reply as a hint for next
time :)

Regards,
Kacper
17 gru 2015 5:14 PM "Ganesh Ajjanagadde"  napisał(a):

> On Tue, Dec 15, 2015 at 6:40 PM, Ganesh Ajjanagadde 
> wrote:
> > On Tue, Dec 15, 2015 at 5:25 PM, Ganesh Ajjanagadde 
> wrote:
> >> On Tue, Dec 15, 2015 at 2:23 AM, Michael Niedermayer 
> wrote:
> >>> On Wed, Dec 09, 2015 at 06:55:25PM -0500, Ganesh Ajjanagadde wrote:
> > [...]
> 
>  diff --git a/libavcodec/nellymoserenc.c b/libavcodec/nellymoserenc.c
>  index d998dba..e6023e3 100644
>  --- a/libavcodec/nellymoserenc.c
>  +++ b/libavcodec/nellymoserenc.c
>  @@ -179,8 +179,15 @@ static av_cold int encode_init(AVCodecContext
> *avctx)
> 
>   /* Generate overlap window */
>   ff_init_ff_sine_windows(7);
>  -for (i = 0; i < POW_TABLE_SIZE; i++)
>  -pow_table[i] = pow(2, -i / 2048.0 - 3.0 + POW_TABLE_OFFSET);
>  +pow_table[0] = 1;
>  +pow_table[1024] = M_SQRT1_2;
>  +for (i = 1; i < 513; i++) {
>  +double tmp = exp2(-i / 2048.0);
>  +pow_table[i] = tmp;
>  +pow_table[1024-i] = M_SQRT1_2 / tmp;
>  +pow_table[1024+i] = tmp * M_SQRT1_2;
>  +pow_table[2048-i] = 0.5 / tmp;
> >>>
> >>> how much overall init time is gained by this ?
> >>> that is time in ffmpeg main() from start to finish when just opening
> >>> the file with no decoding aka ./ffmpeg -i somefile
> >>
> >> Don't know, all I know is cycles are unnecessarily wasted. Will put in
> >> cycle numbers.
> >>
> >
> > Here they are:
> > proposed: 424160 decicycles in pow_table, 512 runs,  0 skips
> > exp2 only: 1262093 decicycles in pow_table, 512 runs,  0 skips
> > old: 2849085 decicycles in pow_table, 512 runs,  0 skips
> >
> > Thus old to exp2 is roughly 2.25x speedup, exp2 to proposed roughly 3x
> > speedup, net ~ 6.7x speedup.
>
> took Michael's comment as a general ack, so pushed with addition of a
> comment and cycle numbers.
> ___
> 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] ffplay: remove existing AVPicture usage

[Paul B Mahol]

On 12/18/15, Marton Balint  wrote:
> It is deprecated.
>
> Signed-off-by: Marton Balint 
> ---
>  ffplay.c | 51 +++
>  1 file changed, 27 insertions(+), 24 deletions(-)
>

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

[FFmpeg-devel] [PATCH 1/1] arm64: fix inverted register order in transpose_4x4H

[Janne Grunau]

Fix related register order issue in ff_h264_idct_add_neon.

Found-by: zjh8890 <243186...@qq.com>
---
 libavcodec/aarch64/h264idct_neon.S | 4 ++--
 libavcodec/aarch64/neon.S  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/aarch64/h264idct_neon.S 
b/libavcodec/aarch64/h264idct_neon.S
index 99c2cb5..78f780a 100644
--- a/libavcodec/aarch64/h264idct_neon.S
+++ b/libavcodec/aarch64/h264idct_neon.S
@@ -37,8 +37,8 @@ function ff_h264_idct_add_neon, export=1
 sub v7.4H,  v16.4H, v3.4H
 add v0.4H,  v4.4H,  v6.4H
 add v1.4H,  v5.4H,  v7.4H
-sub v2.4H,  v4.4H,  v6.4H
-sub v3.4H,  v5.4H,  v7.4H
+sub v3.4H,  v4.4H,  v6.4H
+sub v2.4H,  v5.4H,  v7.4H
 
 transpose_4x4H  v0, v1, v2, v3, v4, v5, v6, v7
 
diff --git a/libavcodec/aarch64/neon.S b/libavcodec/aarch64/neon.S
index 512ef19..cf3e24d 100644
--- a/libavcodec/aarch64/neon.S
+++ b/libavcodec/aarch64/neon.S
@@ -112,8 +112,8 @@
 .macro  transpose_4x4H  r0, r1, r2, r3, r4, r5, r6, r7
 trn1\r4\().4H,  \r0\().4H,  \r1\().4H
 trn2\r5\().4H,  \r0\().4H,  \r1\().4H
-trn1\r7\().4H,  \r3\().4H,  \r2\().4H
-trn2\r6\().4H,  \r3\().4H,  \r2\().4H
+trn1\r7\().4H,  \r2\().4H,  \r3\().4H
+trn2\r6\().4H,  \r2\().4H,  \r3\().4H
 trn1\r0\().2S,  \r4\().2S,  \r7\().2S
 trn2\r3\().2S,  \r4\().2S,  \r7\().2S
 trn1\r1\().2S,  \r5\().2S,  \r6\().2S
-- 
2.6.4

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

Re: [FFmpeg-devel] [PATCH] avcodec/nellymoserenc: avoid wasteful pow

[Kacper Michajlow]

18 gru 2015 10:06 AM "Kacper Michajlow"  napisał(a):
>
> One minor nitpick about commit message. You could mention which compiler
was used to generate code for benchmark. For example Clang 3.7 replaces
pow(2,...) with exp2(...) call by itself. So you probably did use gcc.
Anyway since it is already merged I guess take my reply as a hint for next
time :)
>
> Regards,
> Kacper
>
> 17 gru 2015 5:14 PM "Ganesh Ajjanagadde"  napisał(a):
>>
>> On Tue, Dec 15, 2015 at 6:40 PM, Ganesh Ajjanagadde 
wrote:
>> > On Tue, Dec 15, 2015 at 5:25 PM, Ganesh Ajjanagadde 
wrote:
>> >> On Tue, Dec 15, 2015 at 2:23 AM, Michael Niedermayer 
wrote:
>> >>> On Wed, Dec 09, 2015 at 06:55:25PM -0500, Ganesh Ajjanagadde wrote:
>> > [...]
>> 
>>  diff --git a/libavcodec/nellymoserenc.c b/libavcodec/nellymoserenc.c
>>  index d998dba..e6023e3 100644
>>  --- a/libavcodec/nellymoserenc.c
>>  +++ b/libavcodec/nellymoserenc.c
>>  @@ -179,8 +179,15 @@ static av_cold int encode_init(AVCodecContext
*avctx)
>> 
>>   /* Generate overlap window */
>>   ff_init_ff_sine_windows(7);
>>  -for (i = 0; i < POW_TABLE_SIZE; i++)
>>  -pow_table[i] = pow(2, -i / 2048.0 - 3.0 +
POW_TABLE_OFFSET);
>>  +pow_table[0] = 1;
>>  +pow_table[1024] = M_SQRT1_2;
>>  +for (i = 1; i < 513; i++) {
>>  +double tmp = exp2(-i / 2048.0);
>>  +pow_table[i] = tmp;
>>  +pow_table[1024-i] = M_SQRT1_2 / tmp;
>>  +pow_table[1024+i] = tmp * M_SQRT1_2;
>>  +pow_table[2048-i] = 0.5 / tmp;
>> >>>
>> >>> how much overall init time is gained by this ?
>> >>> that is time in ffmpeg main() from start to finish when just opening
>> >>> the file with no decoding aka ./ffmpeg -i somefile
>> >>
>> >> Don't know, all I know is cycles are unnecessarily wasted. Will put in
>> >> cycle numbers.
>> >>
>> >
>> > Here they are:
>> > proposed: 424160 decicycles in pow_table, 512 runs,  0 skips
>> > exp2 only: 1262093 decicycles in pow_table, 512 runs,  0 skips
>> > old: 2849085 decicycles in pow_table, 512 runs,  0 skips
>> >
>> > Thus old to exp2 is roughly 2.25x speedup, exp2 to proposed roughly 3x
>> > speedup, net ~ 6.7x speedup.
>>
>> took Michael's comment as a general ack, so pushed with addition of a
>> comment and cycle numbers.
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Sorry for top post.

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

Re: [FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}

[Matthieu Bouron]

On Thu, Dec 17, 2015 at 07:47:08PM +0100, Michael Niedermayer wrote:
> On Thu, Dec 17, 2015 at 04:54:31PM +0100, Matthieu Bouron wrote:
> > On Tue, Dec 15, 2015 at 06:22:43PM +0100, Michael Niedermayer wrote:
> > > On Tue, Dec 15, 2015 at 05:46:09PM +0100, Matthieu Bouron wrote:
> > > > From: Matthieu Bouron 
> > > > 
> > > > ---
> > > > 
> > > > Hi,
> > > > 
> > > > This commit is likely to break fate on arm since the current C code path
> > > > seems to use less precision.
> > > > 
> > > > How should I proceed to fix it ?
> > > 
> > > hmm
> > > can the precission of the C code path and any asm impl of it under
> > > bitexact (if they exist), be changed to higher precission without
> > > speedloss?
> > > if so that would be an option
> > 
> > We are currently facing 4 cases (with this patch applied)
> > 
> >   * [1] ARM +ACCURATE_RND: uses neon, 13bit coefficients and 32bit
> >   precision overall
> >   * [2] ARM -ACCURATE_RND: uses neon, 6bit coefficients and 16bit
> >   precision overall
> 
> >   * [3] X86 +ACCURATE_RND: uses a C code path with lookup tables
> 
> which LUT do you mean here ?

The table filled by ff_yuv2rgb_c_init_tables. Not sure if it's used
though, I haven't looked at the C code that actually does the conversion
(yet).

> 
> 
> >   * [4] X86 -ACCURATE_RND: uses MMX+MMXEXT with apparently 13bit
> >   coefficients (libswscale/yuv2rgb.c around line 800).
> > 
> > Notes:
> >   * The 4 outputs are different with [3] being ugly (ghosting/non-sharp
> >   edges).
> > 
> >   * [1] and [4] (13bit coefficient accuracy) should be the same but have
> >   slight differences.
> > 
> > Questions:
> > 
> 
> >   * What is the meaning of the ACCURATE_RND flag ?
> 
> it should enable accurate rounding
> 
> 
> >   * Does [3] use some kind of interpolation instead of duplicating
> >   chroma lines ? Its output seems inferior to the other code paths.
> 
> are you sure that is true for real images?
> its easy to end up with wrong conclusions with synthetic inputs
> unless you want to use the scaler only for such inputs.
> 
> either way line duplication is likely not optimal for real images
> iam not made of constant color blocks that are aligned to some cammeras
> 2x2 samples
> 
> 
> >   * Is [3] the output that should be taken as reference ?
> 
> id say, the reference is reality, making the output as close as a
> image of the new resolution would be if it had been taken that way
> 
> 
> >   * Should we use BITEXACT instead of ACCURATE_RND to determine the
> >   precision used ?
> 
> BITEXACT is to avoid platform differences and allow regression tests
> 
> if all else is equal it would be best if C and asm matches, and if
> C is bad then it should be improved

Here are the C, MMX and NEON outputs from a photo:
http://0x5c.me/yuv2rgb/photos

The C and NEON outputs look almost the same.
The MMX one have slightly different "colors" overall.

Since figuring out what the C code is actually doing and have the neon asm
matches its output is likely to take some time. Would you be OK if, on the
ARM platform, +ACCURATE_RND uses the C code path (so fate is not broken),
and -ACCURATE_RND uses the neon code path with a precision of 16bit (IMHO,
speed is preferred over the slight quality gain of the 32bit version on
this platform) ?

This behaviour will affect yuv420p but also nv12 and nv21 inputs.

This is a kind of a temporary (and lame) solution until I have some time
to work on it.

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

Re: [FFmpeg-devel] [PATCH 1/1] arm64: fix inverted register order in transpose_4x4H

[Carl Eugen Hoyos]

Janne Grunau  jannau.net> writes:

> Fix related register order issue in ff_h264_idct_add_neon.

Is there a public sample that allows to reproduce?

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] Vertical bands with RT21 (Intel Real Time Video 2.1) codec

[Mats Peterson]

On 12/18/2015 05:32 AM, Mats Peterson wrote:

On 12/18/2015 05:12 AM, Mats Peterson wrote:

On 12/18/2015 04:13 AM, Mats Peterson wrote:

Samples: https://drive.google.com/open?id=0B3_pEBoLs0faei1Sd1h6SG11QlE

Mats



The clips are sample clips from Video for Windows, in case anyone
wonders. I haven't created them myself.

Mats



The output is generally washed-out, as well, apart from the bands.

Mats



I noticed this issue has been discussed as far back as in 2005 (see 
http://sourceforge.net/p/ffmpeg/bugs/310/), but using the slightly 
different terms "ghosting and shadow effects". In any case, it obviously 
still hasn't been fixed.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavfi/scale: add nb_slices debug option

[Clément Bœsch]

From: Clément Bœsch 

---
 libavfilter/vf_scale.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index f2f475e..d8f5f77 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -110,6 +110,8 @@ typedef struct ScaleContext {
 int in_v_chr_pos;
 
 int force_original_aspect_ratio;
+
+int nb_slices;
 } ScaleContext;
 
 AVFilter ff_vf_scale2ref;
@@ -575,6 +577,11 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 if(scale->interlaced>0 || (scale->interlaced<0 && in->interlaced_frame)){
 scale_slice(link, out, in, scale->isws[0], 0, (link->h+1)/2, 2, 0);
 scale_slice(link, out, in, scale->isws[1], 0,  link->h   /2, 2, 1);
+}else if (scale->nb_slices) {
+int i;
+const int slice_h = FFMAX(1, link->h / scale->nb_slices);
+for (i = 0; i < scale->nb_slices; i++)
+scale_slice(link, out, in, scale->sws, i*slice_h, slice_h, 1, 0);
 }else{
 scale_slice(link, out, in, scale->sws, 0, link->h, 1, 0);
 }
@@ -651,6 +658,7 @@ static const AVOption scale_options[] = {
 { "increase", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 2 }, 0, 0, FLAGS, 
"force_oar" },
 { "param0", "Scaler param 0", OFFSET(param[0]),  
AV_OPT_TYPE_DOUBLE, { .dbl = SWS_PARAM_DEFAULT  }, INT_MIN, INT_MAX, FLAGS },
 { "param1", "Scaler param 1", OFFSET(param[1]),  
AV_OPT_TYPE_DOUBLE, { .dbl = SWS_PARAM_DEFAULT  }, INT_MIN, INT_MAX, FLAGS },
+{ "nb_slices", "set the number of slices (debug purpose only)", 
OFFSET(nb_slices), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, FLAGS },
 { NULL }
 };
 
-- 
2.6.4

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

Re: [FFmpeg-devel] [PATCH] nuv: reject negative fps rate

[Andreas Cadhalpun]

On 18.12.2015 01:12, Michael Niedermayer wrote:
> On Thu, Dec 17, 2015 at 11:03:15PM +0100, Andreas Cadhalpun wrote:
>> On 16.12.2015 23:53, Michael Niedermayer wrote:
>>> On Wed, Dec 16, 2015 at 08:56:55PM +0100, Andreas Cadhalpun wrote:
 Signed-off-by: Andreas Cadhalpun 
 ---
  libavformat/nuv.c | 4 
  1 file changed, 4 insertions(+)
>>>
>>> looks logical iam not nuv maintainer though and i dont know if all
>>> files have fps set
>>
>> I don't know that either, so I'm attaching a version of this patch
>> that permits 0 fps. Which version do you prefer?
> 
> no real preferrance
> i might slightly tend to allow fps == 0
> but if 0 is disallowed and it occurs, people will tell us and we will
> fix that
> iam fine with either

OK.

> theres no spec or reference that can be "checked" i assume ?

I haven't found one (and this is not exactly a very popular format).

Best regards,
Andreas

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

[FFmpeg-devel] [PATCH] avfilter/vf_delogo: change the definition of logo_x2 and logo_y2

[Jean Delvare]

In the code we keep using logo_x2-1 and logo_y2-1 rather than logo_x2
and logo_y2 themselves. Define them to be what we need instead, to avoid
the repeated subtractions.

Signed-off-by: Jean Delvare 
---
 libavfilter/vf_delogo.c |   26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

--- ffmpeg.orig/libavfilter/vf_delogo.c 2015-12-11 15:24:55.81499 +0100
+++ ffmpeg/libavfilter/vf_delogo.c  2015-12-11 15:26:09.345968761 +0100
@@ -75,13 +75,13 @@ static void apply_delogo(uint8_t *dst, i
 yclipb = FFMAX(logo_y+logo_h-h, 0);
 
 logo_x1 = logo_x + xclipl;
-logo_x2 = logo_x + logo_w - xclipr;
+logo_x2 = logo_x + logo_w - xclipr - 1;
 logo_y1 = logo_y + yclipt;
-logo_y2 = logo_y + logo_h - yclipb;
+logo_y2 = logo_y + logo_h - yclipb - 1;
 
-topleft  = src+logo_y1 * src_linesize+logo_x1;
-topright = src+logo_y1 * src_linesize+logo_x2-1;
-botleft  = src+(logo_y2-1) * src_linesize+logo_x1;
+topleft  = src+logo_y1 * src_linesize+logo_x1;
+topright = src+logo_y1 * src_linesize+logo_x2;
+botleft  = src+logo_y2 * src_linesize+logo_x1;
 
 if (!direct)
 av_image_copy_plane(dst, dst_linesize, src, src_linesize, w, h);
@@ -89,7 +89,7 @@ static void apply_delogo(uint8_t *dst, i
 dst += (logo_y1 + 1) * dst_linesize;
 src += (logo_y1 + 1) * src_linesize;
 
-for (y = logo_y1+1; y < logo_y2-1; y++) {
+for (y = logo_y1+1; y < logo_y2; y++) {
 left_sample = topleft[src_linesize*(y-logo_y1)]   +
   topleft[src_linesize*(y-logo_y1-1)] +
   topleft[src_linesize*(y-logo_y1+1)];
@@ -99,19 +99,19 @@ static void apply_delogo(uint8_t *dst, i
 
 for (x = logo_x1+1,
  xdst = dst+logo_x1+1,
- xsrc = src+logo_x1+1; x < logo_x2-1; x++, xdst++, xsrc++) {
+ xsrc = src+logo_x1+1; x < logo_x2; x++, xdst++, xsrc++) {
 
-if (show && (y == logo_y1+1 || y == logo_y2-2 ||
- x == logo_x1+1 || x == logo_x2-2)) {
+if (show && (y == logo_y1+1 || y == logo_y2-1 ||
+ x == logo_x1+1 || x == logo_x2-1)) {
 *xdst = 0;
 continue;
 }
 
 /* Weighted interpolation based on relative distances, taking SAR 
into account */
-weightl = (uint64_t)  (logo_x2-1-x) * (y-logo_y1) * 
(logo_y2-1-y) * sar.den;
-weightr = (uint64_t)(x-logo_x1) * (y-logo_y1) * 
(logo_y2-1-y) * sar.den;
-weightt = (uint64_t)(x-logo_x1) * (logo_x2-1-x)   * 
(logo_y2-1-y) * sar.num;
-weightb = (uint64_t)(x-logo_x1) * (logo_x2-1-x) * (y-logo_y1)  
   * sar.num;
+weightl = (uint64_t)  (logo_x2-x) * (y-logo_y1) * 
(logo_y2-y) * sar.den;
+weightr = (uint64_t)(x-logo_x1)   * (y-logo_y1) * 
(logo_y2-y) * sar.den;
+weightt = (uint64_t)(x-logo_x1) * (logo_x2-x)   * 
(logo_y2-y) * sar.num;
+weightb = (uint64_t)(x-logo_x1) * (logo_x2-x) * (y-logo_y1)
   * sar.num;
 
 interp =
 left_sample * weightl


-- 
Jean Delvare
SUSE L3 Support
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] exr: fix out of bounds read in get_code

[Andreas Cadhalpun]

On 13.12.2015 23:37, Andreas Cadhalpun wrote:
> This macro unconditionally used out[-1], which causes an out of bounds
> read, if out is the very beginning of the buffer.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/exr.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> index 86a9908..cf28374 100644
> --- a/libavcodec/exr.c
> +++ b/libavcodec/exr.c
> @@ -461,7 +461,7 @@ static int huf_build_dec_table(const uint64_t *hcode, int 
> im,
>  lc += 8; 
>  \
>  }
>  
> -#define get_code(po, rlc, c, lc, gb, out, oe)
>  \
> +#define get_code(po, rlc, c, lc, gb, out, oe, outb)  
>  \
>  {
>  \
>  if (po == rlc) { 
>  \
>  if (lc < 8)  
>  \
> @@ -470,7 +470,7 @@ static int huf_build_dec_table(const uint64_t *hcode, int 
> im,
>   
>  \
>  cs = c >> lc;
>  \
>   
>  \
> -if (out + cs > oe)   
>  \
> +if (out + cs > oe || out == outb)
>  \
>  return AVERROR_INVALIDDATA;  
>  \
>   
>  \
>  s = out[-1]; 
>  \
> @@ -503,7 +503,7 @@ static int huf_decode(const uint64_t *hcode, const HufDec 
> *hdecod,
>  
>  if (pl.len) {
>  lc -= pl.len;
> -get_code(pl.lit, rlc, c, lc, gb, out, oe);
> +get_code(pl.lit, rlc, c, lc, gb, out, oe, outb);
>  } else {
>  int j;
>  
> @@ -520,7 +520,7 @@ static int huf_decode(const uint64_t *hcode, const HufDec 
> *hdecod,
>  if ((hcode[pl.p[j]] >> 6) ==
>  ((c >> (lc - l)) & ((1LL << l) - 1))) {
>  lc -= l;
> -get_code(pl.p[j], rlc, c, lc, gb, out, oe);
> +get_code(pl.p[j], rlc, c, lc, gb, out, oe, outb);
>  break;
>  }
>  }
> @@ -541,7 +541,7 @@ static int huf_decode(const uint64_t *hcode, const HufDec 
> *hdecod,
>  
>  if (pl.len) {
>  lc -= pl.len;
> -get_code(pl.lit, rlc, c, lc, gb, out, oe);
> +get_code(pl.lit, rlc, c, lc, gb, out, oe, outb);
>  } else {
>  return AVERROR_INVALIDDATA;
>  }
> 

This was applied to Libav, so I've pushed it also to FFmpeg.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] on2avc: limit number of bits to 30 in get_egolomb

[Andreas Cadhalpun]

On 18.12.2015 01:44, Michael Niedermayer wrote:
> On Thu, Dec 17, 2015 at 11:30:01PM +0100, Andreas Cadhalpun wrote:
>> On 17.12.2015 13:28, Michael Niedermayer wrote:
>>> On Wed, Dec 16, 2015 at 08:20:18PM +0100, Andreas Cadhalpun wrote:
 More don't fit into the integer output.

 Also use get_bits_long, since get_bits only supports reading up to 25
 bits, while get_bits_long supports the full integer range.

 Signed-off-by: Andreas Cadhalpun 
 ---
  libavcodec/on2avc.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/libavcodec/on2avc.c b/libavcodec/on2avc.c
 index 15f4dd1..10861b5 100644
 --- a/libavcodec/on2avc.c
 +++ b/libavcodec/on2avc.c
 @@ -211,9 +211,9 @@ static inline int get_egolomb(GetBitContext *gb)
  {
  int v = 4;
  
 -while (get_bits1(gb)) v++;
 +while (get_bits1(gb) && v < 30) v++;
>>>
>>> it could make sense to print a warning or error in case its too long
>>
>> OK, updated patch attached.
>>
>> Best regards,
>> Andreas
>>
> 
>>  on2avc.c |   11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>> d59b0416b141d4f10ee758b9816850e660fb968b  
>> 0001-on2avc-limit-number-of-bits-to-30-in-get_egolomb.patch
>> From 7b71f91162ee10c7e3482111a6f5b117623e01c0 Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun 
>> Date: Wed, 16 Dec 2015 16:48:19 +0100
>> Subject: [PATCH] on2avc: limit number of bits to 30 in get_egolomb
>>
>> More don't fit into the integer output.
>>
>> Also use get_bits_long, since get_bits only supports reading up to 25
>> bits, while get_bits_long supports the full integer range.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/on2avc.c | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/on2avc.c b/libavcodec/on2avc.c
>> index 15f4dd1..04c8e41 100644
>> --- a/libavcodec/on2avc.c
>> +++ b/libavcodec/on2avc.c
>> @@ -211,9 +211,16 @@ static inline int get_egolomb(GetBitContext *gb)
>>  {
>>  int v = 4;
>>  
>> -while (get_bits1(gb)) v++;
>> +while (get_bits1(gb)) {
>> +v++;
>> +if (v > 30) {
>> +av_log(NULL, AV_LOG_WARNING, "Too large golomb code in 
>> get_egolomb.\n");
>> +v = 30;
>> +break;
>> +}
>> +}
>>  
>> -return (1 << v) + get_bits(gb, v);
>> +return (1 << v) + get_bits_long(gb, v);
> 
> should be fine until someone finds a tighter bound of what is allowed

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/aacsbr: sbr_dequant optimization

[Ganesh Ajjanagadde]

On Tue, Dec 15, 2015 at 9:53 PM, Ganesh Ajjanagadde
 wrote:
> This uses ff_exp2fi to get a speedup (~ 6x).
>
> sample benchmark (Haswell, GNU/Linux):
> old:
>   19102 decicycles in sbr_dequant,1023 runs,  1 skips
>   19002 decicycles in sbr_dequant,2045 runs,  3 skips
>   17638 decicycles in sbr_dequant,4093 runs,  3 skips
>   15825 decicycles in sbr_dequant,8189 runs,  3 skips
>   16404 decicycles in sbr_dequant,   16379 runs,  5 skips
>
> new:
>3063 decicycles in sbr_dequant,1024 runs,  0 skips
>3049 decicycles in sbr_dequant,2048 runs,  0 skips
>2968 decicycles in sbr_dequant,4096 runs,  0 skips
>2818 decicycles in sbr_dequant,8191 runs,  1 skips
>2853 decicycles in sbr_dequant,   16383 runs,  1 skips
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/aacsbr.c | 34 ++
>  1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/aacsbr.c b/libavcodec/aacsbr.c
> index d1e3a91..15956e3 100644
> --- a/libavcodec/aacsbr.c
> +++ b/libavcodec/aacsbr.c
> @@ -33,6 +33,7 @@
>  #include "aacsbrdata.h"
>  #include "aacsbr_tablegen.h"
>  #include "fft.h"
> +#include "internal.h"
>  #include "aacps.h"
>  #include "sbrdsp.h"
>  #include "libavutil/internal.h"
> @@ -73,15 +74,22 @@ static void sbr_dequant(SpectralBandReplication *sbr, int 
> id_aac)
>  {
>  int k, e;
>  int ch;
> -
> +static const double exp2_tab[2] = {1, M_SQRT2};
>  if (id_aac == TYPE_CPE && sbr->bs_coupling) {
> -float alpha  = sbr->data[0].bs_amp_res ?  1.0f :  0.5f;
> -float pan_offset = sbr->data[0].bs_amp_res ? 12.0f : 24.0f;
> +int pan_offset = sbr->data[0].bs_amp_res ? 12 : 24;
>  for (e = 1; e <= sbr->data[0].bs_num_env; e++) {
>  for (k = 0; k < sbr->n[sbr->data[0].bs_freq_res[e]]; k++) {
> -float temp1 = exp2f(sbr->data[0].env_facs_q[e][k] * alpha + 
> 7.0f);
> -float temp2 = exp2f((pan_offset - 
> sbr->data[1].env_facs_q[e][k]) * alpha);
> -float fac;
> +float temp1, temp2, fac;
> +if (sbr->data[0].bs_amp_res) {
> +temp1 = ff_exp2fi(sbr->data[0].env_facs_q[e][k] + 7);
> +temp2 = ff_exp2fi(pan_offset - 
> sbr->data[1].env_facs_q[e][k]);
> +}
> +else {
> +temp1 = ff_exp2fi((sbr->data[0].env_facs_q[e][k]>>1) + 
> 7) *
> +exp2_tab[sbr->data[0].env_facs_q[e][k] & 1];
> +temp2 = ff_exp2fi((pan_offset - 
> sbr->data[1].env_facs_q[e][k])>>1) *
> +exp2_tab[(pan_offset - 
> sbr->data[1].env_facs_q[e][k]) & 1];
> +}
>  if (temp1 > 1E20) {
>  av_log(NULL, AV_LOG_ERROR, "envelope scalefactor 
> overflow in dequant\n");
>  temp1 = 1;
> @@ -93,8 +101,8 @@ static void sbr_dequant(SpectralBandReplication *sbr, int 
> id_aac)
>  }
>  for (e = 1; e <= sbr->data[0].bs_num_noise; e++) {
>  for (k = 0; k < sbr->n_q; k++) {
> -float temp1 = exp2f(NOISE_FLOOR_OFFSET - 
> sbr->data[0].noise_facs_q[e][k] + 1);
> -float temp2 = exp2f(12 - sbr->data[1].noise_facs_q[e][k]);
> +float temp1 = ff_exp2fi(NOISE_FLOOR_OFFSET - 
> sbr->data[0].noise_facs_q[e][k] + 1);
> +float temp2 = ff_exp2fi(12 - 
> sbr->data[1].noise_facs_q[e][k]);
>  float fac;
>  av_assert0(temp1 <= 1E20);
>  fac = temp1 / (1.0f + temp2);
> @@ -104,11 +112,13 @@ static void sbr_dequant(SpectralBandReplication *sbr, 
> int id_aac)
>  }
>  } else { // SCE or one non-coupled CPE
>  for (ch = 0; ch < (id_aac == TYPE_CPE) + 1; ch++) {
> -float alpha = sbr->data[ch].bs_amp_res ? 1.0f : 0.5f;
>  for (e = 1; e <= sbr->data[ch].bs_num_env; e++)
>  for (k = 0; k < sbr->n[sbr->data[ch].bs_freq_res[e]]; k++){
> -sbr->data[ch].env_facs[e][k] =
> -exp2f(alpha * sbr->data[ch].env_facs_q[e][k] + 6.0f);
> +if (sbr->data[ch].bs_amp_res)
> +sbr->data[ch].env_facs[e][k] = 
> ff_exp2fi(sbr->data[ch].env_facs_q[e][k] + 6);
> +else
> +sbr->data[ch].env_facs[e][k] = 
> ff_exp2fi((sbr->data[ch].env_facs_q[e][k]>>1) + 6)
> +   * 
> exp2_tab[sbr->data[ch].env_facs_q[e][k] & 1];
>  if (sbr->data[ch].env_facs[e][k] > 1E20) {
>  av_log(NULL, AV_LOG_ERROR, "envelope scalefactor 
> overflow in dequant\n");
>  sbr->data[ch].env_facs[e][k] = 1;
> @@ -118,7 +128,7 @@ static void sbr_dequant(SpectralBandReplication *sbr, 

[FFmpeg-devel] [PATCH] aacenc: remove depricated avctx->frame_bits use

[Rostislav Pehlivanov]

The type of last_frame_pb_count was chosen to be an int since overflow
is impossible (the spec says the maximum bits per frame is 6144 per
channel and the encoder checks for that).

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/aacenc.c | 9 +++--
 libavcodec/aacenc.h | 1 +
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
index 3b7dc16..20a8f5a 100644
--- a/libavcodec/aacenc.c
+++ b/libavcodec/aacenc.c
@@ -649,7 +649,7 @@ static int aac_encode_frame(AVCodecContext *avctx, AVPacket 
*avpkt,
 sce->band_type[w] = 0;
 }
 s->psy.bitres.alloc = -1;
-s->psy.bitres.bits = avctx->frame_bits / s->channels;
+s->psy.bitres.bits = s->last_frame_pb_count / s->channels;
 s->psy.model->analyze(>psy, start_ch, coeffs, wi);
 if (s->psy.bitres.alloc > 0) {
 /* Lambda unused here on purpose, we need to take psy's 
unscaled allocation */
@@ -819,11 +819,7 @@ static int aac_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 put_bits(>pb, 3, TYPE_END);
 flush_put_bits(>pb);
 
-#if FF_API_STAT_BITS
-FF_DISABLE_DEPRECATION_WARNINGS
-avctx->frame_bits = put_bits_count(>pb);
-FF_ENABLE_DEPRECATION_WARNINGS
-#endif
+s->last_frame_pb_count = put_bits_count(>pb);
 
 s->lambda_sum += s->lambda;
 s->lambda_count++;
@@ -911,6 +907,7 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
 s->channels = avctx->channels;
 s->chan_map = aac_chan_configs[s->channels-1];
 s->lambda = avctx->global_quality > 0 ? avctx->global_quality : 120;
+s->last_frame_pb_count = 0;
 avctx->extradata_size = 5;
 avctx->frame_size = 1024;
 avctx->initial_padding = 1024;
diff --git a/libavcodec/aacenc.h b/libavcodec/aacenc.h
index 2b721d3..a4a49c5 100644
--- a/libavcodec/aacenc.h
+++ b/libavcodec/aacenc.h
@@ -118,6 +118,7 @@ typedef struct AACEncContext {
 int last_frame;
 int random_state;
 float lambda;
+int last_frame_pb_count; ///< number of bits for the 
previous frame
 float lambda_sum;///< sum(lambda), for Qvg 
reporting
 int lambda_count;///< count(lambda), for Qvg 
reporting
 enum RawDataBlockType cur_type;  ///< channel group type 
cur_channel belongs to
-- 
2.6.4

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

Re: [FFmpeg-devel] [PATCH] aacenc: remove depricated avctx->frame_bits use

[Paul B Mahol]

On 12/18/15, Rostislav Pehlivanov  wrote:
> The type of last_frame_pb_count was chosen to be an int since overflow
> is impossible (the spec says the maximum bits per frame is 6144 per
> channel and the encoder checks for that).
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/aacenc.c | 9 +++--
>  libavcodec/aacenc.h | 1 +
>  2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
> index 3b7dc16..20a8f5a 100644
> --- a/libavcodec/aacenc.c
> +++ b/libavcodec/aacenc.c
> @@ -649,7 +649,7 @@ static int aac_encode_frame(AVCodecContext *avctx,
> AVPacket *avpkt,
>  sce->band_type[w] = 0;
>  }
>  s->psy.bitres.alloc = -1;
> -s->psy.bitres.bits = avctx->frame_bits / s->channels;
> +s->psy.bitres.bits = s->last_frame_pb_count / s->channels;
>  s->psy.model->analyze(>psy, start_ch, coeffs, wi);
>  if (s->psy.bitres.alloc > 0) {
>  /* Lambda unused here on purpose, we need to take psy's
> unscaled allocation */
> @@ -819,11 +819,7 @@ static int aac_encode_frame(AVCodecContext *avctx,
> AVPacket *avpkt,
>  put_bits(>pb, 3, TYPE_END);
>  flush_put_bits(>pb);
>
> -#if FF_API_STAT_BITS
> -FF_DISABLE_DEPRECATION_WARNINGS
> -avctx->frame_bits = put_bits_count(>pb);
> -FF_ENABLE_DEPRECATION_WARNINGS
> -#endif
> +s->last_frame_pb_count = put_bits_count(>pb);
>
>  s->lambda_sum += s->lambda;
>  s->lambda_count++;
> @@ -911,6 +907,7 @@ static av_cold int aac_encode_init(AVCodecContext
> *avctx)
>  s->channels = avctx->channels;
>  s->chan_map = aac_chan_configs[s->channels-1];
>  s->lambda = avctx->global_quality > 0 ? avctx->global_quality : 120;
> +s->last_frame_pb_count = 0;
>  avctx->extradata_size = 5;
>  avctx->frame_size = 1024;
>  avctx->initial_padding = 1024;
> diff --git a/libavcodec/aacenc.h b/libavcodec/aacenc.h
> index 2b721d3..a4a49c5 100644
> --- a/libavcodec/aacenc.h
> +++ b/libavcodec/aacenc.h
> @@ -118,6 +118,7 @@ typedef struct AACEncContext {
>  int last_frame;
>  int random_state;
>  float lambda;
> +int last_frame_pb_count; ///< number of bits for
> the previous frame
>  float lambda_sum;///< sum(lambda), for Qvg
> reporting
>  int lambda_count;///< count(lambda), for
> Qvg reporting
>  enum RawDataBlockType cur_type;  ///< channel group type
> cur_channel belongs to
> --
> 2.6.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

*deprecated, rest looks fine.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}

[Matthieu Bouron]

On Fri, Dec 18, 2015 at 3:59 PM, Matthieu Bouron 
wrote:

> From: Matthieu Bouron 
>
> ---
>  libswscale/arm/swscale_unscaled.c | 52 +++---
>  libswscale/arm/yuv2rgb_neon.S | 77
> ---
>  2 files changed, 118 insertions(+), 11 deletions(-)
>
> diff --git a/libswscale/arm/swscale_unscaled.c
> b/libswscale/arm/swscale_unscaled.c
> index 8aa6432..dce987e 100644
> --- a/libswscale/arm/swscale_unscaled.c
> +++ b/libswscale/arm/swscale_unscaled.c
> @@ -63,6 +63,50 @@ static int rgbx_to_nv12_neon_16_wrapper(SwsContext
> *context, const uint8_t *src[
>  }
>  #endif
>
> +#define YUV_TO_RGB_TABLE(precision)
>\
> +c->yuv2rgb_v2r_coeff / ((precision) == 16 ? 1 << 7 : 1),
>   \
> +c->yuv2rgb_u2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
>   \
> +c->yuv2rgb_v2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
>   \
> +c->yuv2rgb_u2b_coeff / ((precision) == 16 ? 1 << 7 : 1),
>   \
> +
> +#define DECLARE_FF_YUV420P_TO_RGBX_FUNCS(ofmt, precision)
>\
> +int ff_yuv420p_to_##ofmt##_neon_##precision(int w, int h,
>\
> + uint8_t *dst, int linesize,
>   \
> + const uint8_t *srcY, int linesizeY,
>   \
> + const uint8_t *srcU, int linesizeU,
>   \
> + const uint8_t *srcV, int linesizeV,
>   \
> + const int16_t *table,
>   \
> + int y_offset,
>   \
> + int y_coeff);
>   \
> +
>   \
> +static int yuv420p_to_##ofmt##_neon_wrapper_##precision(SwsContext *c,
> const uint8_t *src[],\
> +   int srcStride[], int
> srcSliceY, int srcSliceH,   \
> +   uint8_t *dst[], int
> dstStride[]) {   \
> +const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE(precision) };
>   \
> +
>   \
> +ff_yuv420p_to_##ofmt##_neon_##precision(c->srcW, srcSliceH,
>\
> + dst[0] +  srcSliceY  * dstStride[0],
> dstStride[0], \
> + src[0] +  srcSliceY  * srcStride[0],
> srcStride[0], \
> + src[1] + (srcSliceY / 2) * srcStride[1],
> srcStride[1], \
> + src[2] + (srcSliceY / 2) * srcStride[2],
> srcStride[2], \
> + yuv2rgb_table,
>\
> + c->yuv2rgb_y_offset >> 9,
>   \
> + c->yuv2rgb_y_coeff / ((precision) == 16
> ? 1 << 7 : 1));\
> +
>   \
> +return 0;
>\
> +}
>\
> +
> +#define DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(precision)
>\
> +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(argb, precision)
>\
> +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(rgba, precision)
>\
> +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(abgr, precision)
>\
> +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(bgra, precision)
>\
> +
> +#define DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS
>   \
> +DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(16)
>   \
> +
> +DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS
> +
>  #define DECLARE_FF_NVX_TO_RGBX_FUNCS(ifmt, ofmt, precision)
>\
>  int ff_##ifmt##_to_##ofmt##_neon_##precision(int w, int h,
>   \
>   uint8_t *dst, int linesize,
>   \
> @@ -75,12 +119,7 @@ int ff_##ifmt##_to_##ofmt##_neon_##precision(int w,
> int h,
>  static int ifmt##_to_##ofmt##_neon_wrapper_##precision(SwsContext *c,
> const uint8_t *src[], \
> int srcStride[], int
> srcSliceY, int srcSliceH,   \
> uint8_t *dst[], int
> dstStride[]) {   \
> -const int16_t yuv2rgb_table[] = {
>\
> -c->yuv2rgb_v2r_coeff / ((precision) == 16 ? 1 << 7 : 1),
>   \
> -c->yuv2rgb_u2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
>   \
> -c->yuv2rgb_v2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
>   \
> -c->yuv2rgb_u2b_coeff / ((precision) == 16 ? 1 << 7 : 1),
>   \
> -};
>   \
> +const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE(precision) };
>   \
>
>\
>  

Re: [FFmpeg-devel] [libav-devel] [PATCH] nuv: reject negative fps rate

[Andreas Cadhalpun]

On 18.12.2015 12:00, Luca Barbato wrote:
> On 17/12/15 23:01, Andreas Cadhalpun wrote:
>> On 16.12.2015 22:18, Luca Barbato wrote:
>>> On 16/12/15 20:56, Andreas Cadhalpun wrote:
 Signed-off-by: Andreas Cadhalpun 
 ---
  libavformat/nuv.c | 4 
  1 file changed, 4 insertions(+)

 diff --git a/libavformat/nuv.c b/libavformat/nuv.c
 index 2a1b70f..4cb28d5 100644
 --- a/libavformat/nuv.c
 +++ b/libavformat/nuv.c
 @@ -172,6 +172,10 @@ static int nuv_header(AVFormatContext *s)
  if (aspect > 0. && aspect < 1.0001)
  aspect = 4.0 / 3.0;
  fps = av_int2double(avio_rl64(pb));
 +if (fps <= 0.0f) {
 +av_log(s, AV_LOG_ERROR, "Invalid frame rate %f\n", fps);
 +return AVERROR_INVALIDDATA;
 +}
  
  // number of packets per stream type, -1 means unknown, e.g. streaming
  v_packs = avio_rl32(pb);

>>>
>>> What happens if a negative fps is used?
>>
>> It doesn't make sense. Or what is a negative frame rate supposed to mean?
> 
> So the options are:
> 
> a- not demux at all

That's what my patch does.

> b- mark the framerate as invalid

How does one do that?

> and let the user decide what to do,
> e.g. override it with a value that works for them.
> c- a or b depending on explode.
> 
> A framerate of 0 is the same as a negative framerate for all the
> intended purposes.

So should a negative framerate simply be set to 0?

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] avcodec/nellymoserenc: avoid wasteful pow

[Ganesh Ajjanagadde]

On Fri, Dec 18, 2015 at 1:11 AM, Kacper Michajlow  wrote:
> 18 gru 2015 10:06 AM "Kacper Michajlow"  napisał(a):
>>
>> One minor nitpick about commit message. You could mention which compiler
> was used to generate code for benchmark. For example Clang 3.7 replaces
> pow(2,...) with exp2(...) call by itself. So you probably did use gcc.
> Anyway since it is already merged I guess take my reply as a hint for next
> time :)

Thanks: yes, I have been sloppy about this.

>>
>> Regards,
>> Kacper
>>
>> 17 gru 2015 5:14 PM "Ganesh Ajjanagadde"  napisał(a):
>>>
>>> On Tue, Dec 15, 2015 at 6:40 PM, Ganesh Ajjanagadde 
> wrote:
>>> > On Tue, Dec 15, 2015 at 5:25 PM, Ganesh Ajjanagadde 
> wrote:
>>> >> On Tue, Dec 15, 2015 at 2:23 AM, Michael Niedermayer 
> wrote:
>>> >>> On Wed, Dec 09, 2015 at 06:55:25PM -0500, Ganesh Ajjanagadde wrote:
>>> > [...]
>>> 
>>>  diff --git a/libavcodec/nellymoserenc.c b/libavcodec/nellymoserenc.c
>>>  index d998dba..e6023e3 100644
>>>  --- a/libavcodec/nellymoserenc.c
>>>  +++ b/libavcodec/nellymoserenc.c
>>>  @@ -179,8 +179,15 @@ static av_cold int encode_init(AVCodecContext
> *avctx)
>>> 
>>>   /* Generate overlap window */
>>>   ff_init_ff_sine_windows(7);
>>>  -for (i = 0; i < POW_TABLE_SIZE; i++)
>>>  -pow_table[i] = pow(2, -i / 2048.0 - 3.0 +
> POW_TABLE_OFFSET);
>>>  +pow_table[0] = 1;
>>>  +pow_table[1024] = M_SQRT1_2;
>>>  +for (i = 1; i < 513; i++) {
>>>  +double tmp = exp2(-i / 2048.0);
>>>  +pow_table[i] = tmp;
>>>  +pow_table[1024-i] = M_SQRT1_2 / tmp;
>>>  +pow_table[1024+i] = tmp * M_SQRT1_2;
>>>  +pow_table[2048-i] = 0.5 / tmp;
>>> >>>
>>> >>> how much overall init time is gained by this ?
>>> >>> that is time in ffmpeg main() from start to finish when just opening
>>> >>> the file with no decoding aka ./ffmpeg -i somefile
>>> >>
>>> >> Don't know, all I know is cycles are unnecessarily wasted. Will put in
>>> >> cycle numbers.
>>> >>
>>> >
>>> > Here they are:
>>> > proposed: 424160 decicycles in pow_table, 512 runs,  0 skips
>>> > exp2 only: 1262093 decicycles in pow_table, 512 runs,  0 skips
>>> > old: 2849085 decicycles in pow_table, 512 runs,  0 skips
>>> >
>>> > Thus old to exp2 is roughly 2.25x speedup, exp2 to proposed roughly 3x
>>> > speedup, net ~ 6.7x speedup.
>>>
>>> took Michael's comment as a general ack, so pushed with addition of a
>>> comment and cycle numbers.
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> Sorry for top post.

No problem.

>
> -Kacper
> ___
> 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 1/2] swscale/arm/yuv2rgb: disable neon if accurate_rnd is enabled

[Matthieu Bouron]

From: Matthieu Bouron 

This disables the 32bit precision neon code path in favor of the
default C one and avoids breaking fate if accurate_rnd is enabled.
---
 libswscale/arm/swscale_unscaled.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/libswscale/arm/swscale_unscaled.c 
b/libswscale/arm/swscale_unscaled.c
index dbb0fb0..8aa6432 100644
--- a/libswscale/arm/swscale_unscaled.c
+++ b/libswscale/arm/swscale_unscaled.c
@@ -101,7 +101,6 @@ DECLARE_FF_NVX_TO_RGBX_FUNCS(nvx, bgra, precision)
 
 #define DECLARE_FF_NVX_TO_ALL_RGBX_ALL_PRECISION_FUNCS(nvx)
 \
 DECLARE_FF_NVX_TO_ALL_RGBX_FUNCS(nvx, 16)  
 \
-DECLARE_FF_NVX_TO_ALL_RGBX_FUNCS(nvx, 32)  
 \
 
 DECLARE_FF_NVX_TO_ALL_RGBX_ALL_PRECISION_FUNCS(nv12)
 DECLARE_FF_NVX_TO_ALL_RGBX_ALL_PRECISION_FUNCS(nv21)
@@ -114,9 +113,9 @@ DECLARE_FF_NVX_TO_ALL_RGBX_ALL_PRECISION_FUNCS(nv21)
 if (c->srcFormat == AV_PIX_FMT_##IFMT  
 \
 && c->dstFormat == AV_PIX_FMT_##OFMT   
 \
 && !(c->srcH & 1)  
 \
-&& !(c->srcW & 15)) {  
 \
-c->swscale = (accurate_rnd) ? ifmt##_to_##ofmt##_neon_wrapper_32 : 
 \
-  ifmt##_to_##ofmt##_neon_wrapper_16 ; 
 \
+&& !(c->srcW & 15) 
 \
+&& !accurate_rnd) {
 \
+c->swscale = ifmt##_to_##ofmt##_neon_wrapper_16;   
 \
 }  
 \
 } while (0)
 
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libswscale/arm/swscale_unscaled.c | 52 +++---
 libswscale/arm/yuv2rgb_neon.S | 77 ---
 2 files changed, 118 insertions(+), 11 deletions(-)

diff --git a/libswscale/arm/swscale_unscaled.c 
b/libswscale/arm/swscale_unscaled.c
index 8aa6432..dce987e 100644
--- a/libswscale/arm/swscale_unscaled.c
+++ b/libswscale/arm/swscale_unscaled.c
@@ -63,6 +63,50 @@ static int rgbx_to_nv12_neon_16_wrapper(SwsContext *context, 
const uint8_t *src[
 }
 #endif
 
+#define YUV_TO_RGB_TABLE(precision)
 \
+c->yuv2rgb_v2r_coeff / ((precision) == 16 ? 1 << 7 : 1),   
 \
+c->yuv2rgb_u2g_coeff / ((precision) == 16 ? 1 << 7 : 1),   
 \
+c->yuv2rgb_v2g_coeff / ((precision) == 16 ? 1 << 7 : 1),   
 \
+c->yuv2rgb_u2b_coeff / ((precision) == 16 ? 1 << 7 : 1),   
 \
+
+#define DECLARE_FF_YUV420P_TO_RGBX_FUNCS(ofmt, precision)  
 \
+int ff_yuv420p_to_##ofmt##_neon_##precision(int w, int h,  
 \
+ uint8_t *dst, int linesize,   
 \
+ const uint8_t *srcY, int linesizeY,   
 \
+ const uint8_t *srcU, int linesizeU,   
 \
+ const uint8_t *srcV, int linesizeV,   
 \
+ const int16_t *table, 
 \
+ int y_offset, 
 \
+ int y_coeff); 
 \
+   
 \
+static int yuv420p_to_##ofmt##_neon_wrapper_##precision(SwsContext *c, const 
uint8_t *src[],\
+   int srcStride[], int srcSliceY, int 
srcSliceH,   \
+   uint8_t *dst[], int dstStride[]) {  
 \
+const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE(precision) };   
 \
+   
 \
+ff_yuv420p_to_##ofmt##_neon_##precision(c->srcW, srcSliceH,
 \
+ dst[0] +  srcSliceY  * dstStride[0], 
dstStride[0], \
+ src[0] +  srcSliceY  * srcStride[0], 
srcStride[0], \
+ src[1] + (srcSliceY / 2) * srcStride[1], 
srcStride[1], \
+ src[2] + (srcSliceY / 2) * srcStride[2], 
srcStride[2], \
+ yuv2rgb_table,
 \
+ c->yuv2rgb_y_offset >> 9, 
 \
+ c->yuv2rgb_y_coeff / ((precision) == 16 ? 1 
<< 7 : 1));\
+   
 \
+return 0;  
 \
+}  
 \
+
+#define DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(precision)
 \
+DECLARE_FF_YUV420P_TO_RGBX_FUNCS(argb, precision)  
 \
+DECLARE_FF_YUV420P_TO_RGBX_FUNCS(rgba, precision)  
 \
+DECLARE_FF_YUV420P_TO_RGBX_FUNCS(abgr, precision)  
 \
+DECLARE_FF_YUV420P_TO_RGBX_FUNCS(bgra, precision)  
 \
+
+#define DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS 
 \
+DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(16)   
 \
+
+DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS
+
 #define DECLARE_FF_NVX_TO_RGBX_FUNCS(ifmt, ofmt, precision)
 \
 int ff_##ifmt##_to_##ofmt##_neon_##precision(int w, int h, 
 \
  uint8_t *dst, int linesize,   
 \
@@ -75,12 +119,7 @@ int ff_##ifmt##_to_##ofmt##_neon_##precision(int w, int h,
 static int ifmt##_to_##ofmt##_neon_wrapper_##precision(SwsContext *c, const 
uint8_t *src[], \
int srcStride[], int srcSliceY, int 
srcSliceH,   \
uint8_t *dst[], int dstStride[]) {  
 \
-const int16_t yuv2rgb_table[] = {

[FFmpeg-devel] [PATCH] nutdec: reject negative sm_size

[Andreas Cadhalpun]

If it is negative, it makes size larger than the size of the packet
buffer, causing invalid writes in avio_read.

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/nutdec.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
index 286d1ee..47ae7a7 100644
--- a/libavformat/nutdec.c
+++ b/libavformat/nutdec.c
@@ -1146,6 +1146,11 @@ static int decode_frame(NUTContext *nut, AVPacket *pkt, 
int frame_code)
 goto fail;
 }
 sm_size = avio_tell(bc) - pkt->pos;
+if (sm_size < 0) {
+av_log(nut->avf, AV_LOG_ERROR, "negative sm_size %d\n", sm_size);
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
 size  -= sm_size;
 pkt->size -= sm_size;
 }
-- 
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Vertical bands with RT21 (Intel Real Time Video 2.1) codec

[Paul B Mahol]

On 12/18/15, Mats Peterson  wrote:
> On 12/18/2015 05:32 AM, Mats Peterson wrote:
>> On 12/18/2015 05:12 AM, Mats Peterson wrote:
>>> On 12/18/2015 04:13 AM, Mats Peterson wrote:
 Samples: https://drive.google.com/open?id=0B3_pEBoLs0faei1Sd1h6SG11QlE

 Mats

>>>
>>> The clips are sample clips from Video for Windows, in case anyone
>>> wonders. I haven't created them myself.
>>>
>>> Mats
>>>
>>
>> The output is generally washed-out, as well, apart from the bands.
>>
>> Mats
>>
>
> I noticed this issue has been discussed as far back as in 2005 (see
> http://sourceforge.net/p/ffmpeg/bugs/310/), but using the slightly
> different terms "ghosting and shadow effects". In any case, it obviously
> still hasn't been fixed.

No, this is different issue. Do you know a software that actually
plays such videos correctly?

> Mats
>
> --
> Mats Peterson
> http://matsp888.no-ip.org/~mats/
> ___
> 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] lavfi/scale: add nb_slices debug option

[Clément Bœsch]

On Fri, Dec 18, 2015 at 04:33:18PM +0100, Nicolas George wrote:
> L'octidi 28 frimaire, an CCXXIV, Clement Boesch a écrit :
> > +const int slice_h = FFMAX(1, link->h / scale->nb_slices);
> > +for (i = 0; i < scale->nb_slices; i++)
> > +scale_slice(link, out, in, scale->sws, i*slice_h, slice_h, 1, 
> > 0);
> 
> What happens if link->h is not a multiple of nb_slices?
> 

That wasn't very rigorous, sorry. New patch attached.

Note: the option is not really documented since it doesn't serve any
purpose aside from debugging slicing, and not from a threading
perspective, but more like a locality, as in CPU cache wise apparently.

-- 
Clément B.
From 43b22797e4b549e2b3eedbfe5ee5734ed97f2521 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?= 
Date: Fri, 18 Dec 2015 15:44:33 +0100
Subject: [PATCH] lavfi/scale: add nb_slices debug option

---
 libavfilter/vf_scale.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index f2f475e..0d5f79a 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -110,6 +110,8 @@ typedef struct ScaleContext {
 int in_v_chr_pos;
 
 int force_original_aspect_ratio;
+
+int nb_slices;
 } ScaleContext;
 
 AVFilter ff_vf_scale2ref;
@@ -575,6 +577,15 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 if(scale->interlaced>0 || (scale->interlaced<0 && in->interlaced_frame)){
 scale_slice(link, out, in, scale->isws[0], 0, (link->h+1)/2, 2, 0);
 scale_slice(link, out, in, scale->isws[1], 0,  link->h   /2, 2, 1);
+}else if (scale->nb_slices) {
+int i;
+const int nb_slices = FFMIN(scale->nb_slices, link->h);
+for (i = 0; i < nb_slices; i++) {
+const int slice_start = (link->h *  i   ) / nb_slices;
+const int slice_end   = (link->h * (i+1)) / nb_slices;
+const int slice_h = slice_end - slice_start;
+scale_slice(link, out, in, scale->sws, slice_start, slice_h, 1, 0);
+}
 }else{
 scale_slice(link, out, in, scale->sws, 0, link->h, 1, 0);
 }
@@ -651,6 +662,7 @@ static const AVOption scale_options[] = {
 { "increase", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 2 }, 0, 0, FLAGS, "force_oar" },
 { "param0", "Scaler param 0", OFFSET(param[0]),  AV_OPT_TYPE_DOUBLE, { .dbl = SWS_PARAM_DEFAULT  }, INT_MIN, INT_MAX, FLAGS },
 { "param1", "Scaler param 1", OFFSET(param[1]),  AV_OPT_TYPE_DOUBLE, { .dbl = SWS_PARAM_DEFAULT  }, INT_MIN, INT_MAX, FLAGS },
+{ "nb_slices", "set the number of slices (debug purpose only)", OFFSET(nb_slices), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, FLAGS },
 { NULL }
 };
 
-- 
2.6.4



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

Re: [FFmpeg-devel] [libav-devel] [PATCH] nutdec: only copy the header if it exists

[Andreas Cadhalpun]

On 18.12.2015 18:53, Luca Barbato wrote:
> On 18/12/15 17:24, Andreas Cadhalpun wrote:
>> Fixes runtime error: null pointer passed as argument 2, which is
>> declared to never be null
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavformat/nutdec.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
>> index 47ae7a7..3aa7a88 100644
>> --- a/libavformat/nutdec.c
>> +++ b/libavformat/nutdec.c
>> @@ -1133,7 +1133,8 @@ static int decode_frame(NUTContext *nut, AVPacket 
>> *pkt, int frame_code)
>>  ret = av_new_packet(pkt, size + nut->header_len[header_idx]);
>>  if (ret < 0)
>>  return ret;
>> -memcpy(pkt->data, nut->header[header_idx], nut->header_len[header_idx]);
>> +if (nut->header[header_idx])
>> +memcpy(pkt->data, nut->header[header_idx], 
>> nut->header_len[header_idx]);
>>  pkt->pos = avio_tell(bc); // FIXME
>>  if (stc->last_flags & FLAG_SM_DATA) {
>>  int sm_size;
>>
> 
> When it happens exactly?

When header_idx is 0 and thus nut->header_len[0] = 0 and nut->header[0] = NULL.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] aacenc: remove depricated avctx->frame_bits use

[Claudio Freire]

On Fri, Dec 18, 2015 at 10:59 AM, Rostislav Pehlivanov
 wrote:
> The type of last_frame_pb_count was chosen to be an int since overflow
> is impossible (the spec says the maximum bits per frame is 6144 per
> channel and the encoder checks for that).


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

Re: [FFmpeg-devel] [PATCH] lavu/libm: add copysign hack

[Ronald S. Bultje]

Hi,

On Fri, Dec 18, 2015 at 2:18 PM, Ganesh Ajjanagadde 
wrote:

> For systems with broken libms.
> Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular double x and
> combinations of these.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  configure| 2 +-
>  libavutil/libm.h | 9 +
>  2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 123d1df..7917386 100755
> --- a/configure
> +++ b/configure
> @@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl"
>  delogo_filter_deps="gpl"
>  deshake_filter_select="pixelutils"
>  drawtext_filter_deps="libfreetype"
> -dynaudnorm_filter_deps="copysign erf"
> +dynaudnorm_filter_deps="erf"
>  ebur128_filter_deps="gpl"
>  eq_filter_deps="gpl"
>  fftfilt_filter_deps="avcodec"
> diff --git a/libavutil/libm.h b/libavutil/libm.h
> index 6d8bd68..637de19 100644
> --- a/libavutil/libm.h
> +++ b/libavutil/libm.h
> @@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x)
>  }
>  #endif
>
> +#if !HAVE_COPYSIGN
> +static av_always_inline double copysign(double x, double y)
> +{
> +uint64_t vx = av_double2int(x);
> +uint64_t vy = av_double2int(y);
> +return av_int2double((vx & 0x7fff) | (vy &
> 0x8000));
> +}
> +#endif


Don't these need type suffixes (e.g. UINT64_C(val)) on some systems?

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

Re: [FFmpeg-devel] [libav-devel] [PATCH] xwddec: prevent overflow of lsize * avctx->height

[Andreas Cadhalpun]

On 18.12.2015 20:08, Luca Barbato wrote:
> On 18/12/15 20:04, Andreas Cadhalpun wrote:
>> This is used to check if the input buffer is larger enough, so if this
>> overflows it can cause a false negative leading to a segmentation fault
>> in bytestream2_get_bufferu.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/xwddec.c | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/libavcodec/xwddec.c b/libavcodec/xwddec.c
>> index 2febedc..311eeec 100644
>> --- a/libavcodec/xwddec.c
>> +++ b/libavcodec/xwddec.c
>> @@ -127,6 +127,12 @@ static int xwd_decode_frame(AVCodecContext *avctx, void 
>> *data,
>>  return AVERROR_INVALIDDATA;
>>  }
>>  
>> +if (lsize > UINT_MAX / avctx->height) {
>> +av_log(avctx, AV_LOG_ERROR, "lsize %u too large for height %d\n",
>> +   lsize, avctx->height);
>> +return AVERROR_INVALIDDATA;
>> +}
>> +
>>  if (ncolors > 256) {
>>  av_log(avctx, AV_LOG_ERROR, "invalid number of entries in 
>> colormap\n");
>>  return AVERROR_INVALIDDATA;
>>
> 
> Should go after the av_image_check_size or you'd have a division by 0.

Indeed. Updated patch attached.

Best regards,
Andreas

>From fb40616d7b432680b92dc3adc44a5b5d12fac55d Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Fri, 18 Dec 2015 19:28:51 +0100
Subject: [PATCH] xwddec: prevent overflow of lsize * avctx->height

This is used to check if the input buffer is larger enough, so if this
overflows it can cause a false negative leading to a segmentation fault
in bytestream2_get_bufferu.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/xwddec.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavcodec/xwddec.c b/libavcodec/xwddec.c
index 2febedc..103252b 100644
--- a/libavcodec/xwddec.c
+++ b/libavcodec/xwddec.c
@@ -135,6 +135,12 @@ static int xwd_decode_frame(AVCodecContext *avctx, void *data,
 if ((ret = av_image_check_size(avctx->width, avctx->height, 0, NULL)) < 0)
 return ret;
 
+if (lsize > UINT_MAX / avctx->height) {
+av_log(avctx, AV_LOG_ERROR, "lsize %u too large for height %d\n",
+   lsize, avctx->height);
+return AVERROR_INVALIDDATA;
+}
+
 rsize = FFALIGN(avctx->width * bpp, bpad) / 8;
 if (lsize < rsize) {
 av_log(avctx, AV_LOG_ERROR, "invalid bytes per scan-line\n");
-- 
2.6.2

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

Re: [FFmpeg-devel] [libav-devel] [PATCH] nutdec: only copy the header if it exists

[Andreas Cadhalpun]

On 18.12.2015 20:06, Luca Barbato wrote:
> On 18/12/15 19:05, Andreas Cadhalpun wrote:
>> On 18.12.2015 18:53, Luca Barbato wrote:
>>> On 18/12/15 17:24, Andreas Cadhalpun wrote:
 Fixes runtime error: null pointer passed as argument 2, which is
 declared to never be null

 Signed-off-by: Andreas Cadhalpun 
 ---
  libavformat/nutdec.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
 index 47ae7a7..3aa7a88 100644
 --- a/libavformat/nutdec.c
 +++ b/libavformat/nutdec.c
 @@ -1133,7 +1133,8 @@ static int decode_frame(NUTContext *nut, AVPacket 
 *pkt, int frame_code)
  ret = av_new_packet(pkt, size + nut->header_len[header_idx]);
  if (ret < 0)
  return ret;
 -memcpy(pkt->data, nut->header[header_idx], 
 nut->header_len[header_idx]);
 +if (nut->header[header_idx])
 +memcpy(pkt->data, nut->header[header_idx], 
 nut->header_len[header_idx]);
  pkt->pos = avio_tell(bc); // FIXME
  if (stc->last_flags & FLAG_SM_DATA) {
  int sm_size;

>>>
>>> When it happens exactly?
>>
>> When header_idx is 0 and thus nut->header_len[0] = 0 and nut->header[0] = 
>> NULL.
>>
> 
> if header_len is 0 what's exactly the problem?

gcc's undefined behavior sanitizer prints the error from the commit message.
That's all. See e.g. [1].

Best regards,
Andreas


1: 
https://stackoverflow.com/questions/5243012/is-it-guaranteed-to-be-safe-to-perform-memcpy0-0-0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] decklink: support all valid numbers of audio channels

[Matthias Hunstock]

As it is already written in the documentation, BMD DeckLink cards
are capable of capturing 2, 8 or 16 audio channels (for SDI Inputs).
Currently the value is hardcoded to 2. Introduces new option.

Signed-off-by: Matthias Hunstock 
---
 doc/indevs.texi | 13 -
 libavdevice/decklink_common_c.h |  1 +
 libavdevice/decklink_dec.cpp| 16 ++--
 libavdevice/decklink_dec_c.c|  2 ++
 4 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index 6cf626d..6003b9f 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -218,7 +218,8 @@ On Windows, you need to run the IDL files through 
@command{widl}.
 DeckLink is very picky about the formats it supports. Pixel format is
 uyvy422 or v210, framerate and video size must be determined for your device 
with
 @command{-list_formats 1}. Audio sample rate is always 48 kHz and the number
-of channels can be 2, 8 or 16.
+of channels can be 2, 8 or 16. Note that all audio channels are bundled in one 
single
+audio track.
 
 @subsection Options
 
@@ -236,6 +237,10 @@ Defaults to @option{false}.
 If set to @samp{1}, video is captured in 10 bit v210 instead
 of uyvy422. Not all Blackmagic devices support this option.
 
+@item audio_channels
+Defines number of audio channels to capture. Must be @samp{2}, @samp{8} or 
@samp{16}.
+Defaults to @samp{2}.
+
 @end table
 
 @subsection Examples
@@ -266,6 +271,12 @@ Capture video clip at 1080i50 10 bit:
 ffmpeg -bm_v210 1 -f decklink -i 'UltraStudio Mini Recorder@@11' -acodec copy 
-vcodec copy output.avi
 @end example
 
+@item
+Capture video clip at 1080i50 with 16 audio channels:
+@example
+ffmpeg -audio_channels 16 -f decklink -i 'UltraStudio Mini Recorder@@11' 
-acodec copy -vcodec copy output.avi
+@end example
+
 @end itemize
 
 @section dshow
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index fb2b788..403956f 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -29,5 +29,6 @@ struct decklink_cctx {
 int list_formats;
 double preroll;
 int v210;
+int audio_channels;
 };
 
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 89f93de..1588933 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -381,6 +381,17 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
 ctx->preroll  = cctx->preroll;
 cctx->ctx = ctx;
 
+/* Check audio channel option for valid values: 2, 8 or 16 */
+switch (cctx->audio_channels) {
+case 2:
+case 8:
+case 16:
+break;
+default:
+av_log(avctx, AV_LOG_ERROR, "Value of channels option must be one 
of 2, 8 or 16\n");
+return AVERROR(EINVAL);
+}
+
 iter = CreateDeckLinkIteratorInstance();
 if (!iter) {
 av_log(avctx, AV_LOG_ERROR, "Could not create DeckLink iterator\n");
@@ -458,7 +469,7 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
 st->codec->codec_type  = AVMEDIA_TYPE_AUDIO;
 st->codec->codec_id= AV_CODEC_ID_PCM_S16LE;
 st->codec->sample_rate = bmdAudioSampleRate48kHz;
-st->codec->channels= 2;
+st->codec->channels= cctx->audio_channels;
 avpriv_set_pts_info(st, 64, 1, 100);  /* 64 bits pts in us */
 ctx->audio_st=st;
 
@@ -488,7 +499,8 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
 
 ctx->video_st=st;
 
-result = ctx->dli->EnableAudioInput(bmdAudioSampleRate48kHz, 
bmdAudioSampleType16bitInteger, 2);
+av_log(avctx, AV_LOG_VERBOSE, "Using %d input audio channels\n", 
ctx->audio_st->codec->channels);
+result = ctx->dli->EnableAudioInput(bmdAudioSampleRate48kHz, 
bmdAudioSampleType16bitInteger, ctx->audio_st->codec->channels);
 
 if (result != S_OK) {
 av_log(avctx, AV_LOG_ERROR, "Cannot enable audio input\n");
diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
index b1a65e6..487bfd6 100644
--- a/libavdevice/decklink_dec_c.c
+++ b/libavdevice/decklink_dec_c.c
@@ -32,6 +32,8 @@ static const AVOption options[] = {
 { "list_devices", "list available devices"  , OFFSET(list_devices), 
AV_OPT_TYPE_INT   , { .i64 = 0   }, 0, 1, DEC },
 { "list_formats", "list supported formats"  , OFFSET(list_formats), 
AV_OPT_TYPE_INT   , { .i64 = 0   }, 0, 1, DEC },
 { "bm_v210",  "v210 10 bit per channel" , OFFSET(v210), 
AV_OPT_TYPE_INT   , { .i64 = 0   }, 0, 1, DEC },
+{ "audio_channels", "number of audio channels; must be 2, 8 or 16",
+  OFFSET(audio_channels), 
AV_OPT_TYPE_INT,  { .i64 = 2   }, 2, 16, DEC },
 { NULL },
 };
 
-- 
2.4.10

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

[FFmpeg-devel] Patch for libavcodec dvdec.c

[Dan Haddix]

This is a patch for the bug filed here... 

https://trac.ffmpeg.org/ticket/5092

as described in the bug report the current code is designed against the SMPTE 
314M spec, which only applies to SD content. In the SMPTE 370M spec they have 
flipped the meaning of "field 1" and "field 2" so the bits in the VAUX mean the 
opposite with regards to TFF or BFF. This patch checks the resolution of the 
video and if it exceeds the resolution allowed by SMPTE 314M then it flips the 
top_field_first flag. 

This is my first patch so hopefully I did it correctly. If not let me know and 
I will fix it. 

Dan
  

dvdec.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavu/libm: add copysign hack

[Ganesh Ajjanagadde]

For systems with broken libms.
Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular double x and
combinations of these.

Signed-off-by: Ganesh Ajjanagadde 
---
 configure| 2 +-
 libavutil/libm.h | 9 +
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 123d1df..7917386 100755
--- a/configure
+++ b/configure
@@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl"
 delogo_filter_deps="gpl"
 deshake_filter_select="pixelutils"
 drawtext_filter_deps="libfreetype"
-dynaudnorm_filter_deps="copysign erf"
+dynaudnorm_filter_deps="erf"
 ebur128_filter_deps="gpl"
 eq_filter_deps="gpl"
 fftfilt_filter_deps="avcodec"
diff --git a/libavutil/libm.h b/libavutil/libm.h
index 6d8bd68..637de19 100644
--- a/libavutil/libm.h
+++ b/libavutil/libm.h
@@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x)
 }
 #endif
 
+#if !HAVE_COPYSIGN
+static av_always_inline double copysign(double x, double y)
+{
+uint64_t vx = av_double2int(x);
+uint64_t vy = av_double2int(y);
+return av_int2double((vx & 0x7fff) | (vy & 
0x8000));
+}
+#endif
+
 #if !HAVE_COSF
 #undef cosf
 #define cosf(x) ((float)cos(x))
-- 
2.6.4

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

[FFmpeg-devel] [PATCH] xwddec: prevent overflow of lsize * avctx->height

[Andreas Cadhalpun]

This is used to check if the input buffer is larger enough, so if this
overflows it can cause a false negative leading to a segmentation fault
in bytestream2_get_bufferu.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/xwddec.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavcodec/xwddec.c b/libavcodec/xwddec.c
index 2febedc..311eeec 100644
--- a/libavcodec/xwddec.c
+++ b/libavcodec/xwddec.c
@@ -127,6 +127,12 @@ static int xwd_decode_frame(AVCodecContext *avctx, void 
*data,
 return AVERROR_INVALIDDATA;
 }
 
+if (lsize > UINT_MAX / avctx->height) {
+av_log(avctx, AV_LOG_ERROR, "lsize %u too large for height %d\n",
+   lsize, avctx->height);
+return AVERROR_INVALIDDATA;
+}
+
 if (ncolors > 256) {
 av_log(avctx, AV_LOG_ERROR, "invalid number of entries in colormap\n");
 return AVERROR_INVALIDDATA;
-- 
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [libav-devel] [PATCH] xwddec: prevent overflow of lsize * avctx->height

[Michael Niedermayer]

On Fri, Dec 18, 2015 at 08:13:06PM +0100, Andreas Cadhalpun wrote:
> On 18.12.2015 20:08, Luca Barbato wrote:
> > On 18/12/15 20:04, Andreas Cadhalpun wrote:
> >> This is used to check if the input buffer is larger enough, so if this
> >> overflows it can cause a false negative leading to a segmentation fault
> >> in bytestream2_get_bufferu.
> >>
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  libavcodec/xwddec.c | 6 ++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/libavcodec/xwddec.c b/libavcodec/xwddec.c
> >> index 2febedc..311eeec 100644
> >> --- a/libavcodec/xwddec.c
> >> +++ b/libavcodec/xwddec.c
> >> @@ -127,6 +127,12 @@ static int xwd_decode_frame(AVCodecContext *avctx, 
> >> void *data,
> >>  return AVERROR_INVALIDDATA;
> >>  }
> >>  
> >> +if (lsize > UINT_MAX / avctx->height) {
> >> +av_log(avctx, AV_LOG_ERROR, "lsize %u too large for height %d\n",
> >> +   lsize, avctx->height);
> >> +return AVERROR_INVALIDDATA;
> >> +}
> >> +
> >>  if (ncolors > 256) {
> >>  av_log(avctx, AV_LOG_ERROR, "invalid number of entries in 
> >> colormap\n");
> >>  return AVERROR_INVALIDDATA;
> >>
> > 
> > Should go after the av_image_check_size or you'd have a division by 0.
> 
> Indeed. Updated patch attached.
> 
> Best regards,
> Andreas
> 

>  xwddec.c |6 ++
>  1 file changed, 6 insertions(+)
> 0be27d89a669445b523bfdac99884065e3581f3c  
> 0001-xwddec-prevent-overflow-of-lsize-avctx-height.patch
> From fb40616d7b432680b92dc3adc44a5b5d12fac55d Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Fri, 18 Dec 2015 19:28:51 +0100
> Subject: [PATCH] xwddec: prevent overflow of lsize * avctx->height
> 
> This is used to check if the input buffer is larger enough, so if this
> overflows it can cause a false negative leading to a segmentation fault
> in bytestream2_get_bufferu.

cant the addition overflow too in the input buffer check ?
if so then using 64bit in the input buffer check would avoid the
need for a explicit check on lsize

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

Re: [FFmpeg-devel] [PATCH] lavfi/scale: add nb_slices debug option

[Michael Niedermayer]

On Fri, Dec 18, 2015 at 05:31:32PM +0100, Clément Bœsch wrote:
> On Fri, Dec 18, 2015 at 04:33:18PM +0100, Nicolas George wrote:
> > L'octidi 28 frimaire, an CCXXIV, Clement Boesch a écrit :
> > > +const int slice_h = FFMAX(1, link->h / scale->nb_slices);
> > > +for (i = 0; i < scale->nb_slices; i++)
> > > +scale_slice(link, out, in, scale->sws, i*slice_h, slice_h, 
> > > 1, 0);
> > 
> > What happens if link->h is not a multiple of nb_slices?
> > 
> 
> That wasn't very rigorous, sorry. New patch attached.
> 
> Note: the option is not really documented since it doesn't serve any
> purpose aside from debugging slicing, and not from a threading
> perspective, but more like a locality, as in CPU cache wise apparently.
> 
> -- 
> Clément B.

>  vf_scale.c |   12 
>  1 file changed, 12 insertions(+)
> ad9a7000977be97bbb57ca284ad0fdf53271beda  
> 0001-lavfi-scale-add-nb_slices-debug-option.patch
> From 43b22797e4b549e2b3eedbfe5ee5734ed97f2521 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?= 
> Date: Fri, 18 Dec 2015 15:44:33 +0100
> Subject: [PATCH] lavfi/scale: add nb_slices debug option

LGTM

it seems this segfaults if NEW_FILTER is defined though (and nb_slices
is set)
(thus CCing pedro)

[...]

-- 
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] [PATCH] nutdec: reject negative sm_size

[Michael Niedermayer]

On Fri, Dec 18, 2015 at 05:22:31PM +0100, Andreas Cadhalpun wrote:
> If it is negative, it makes size larger than the size of the packet
> buffer, causing invalid writes in avio_read.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/nutdec.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
> index 286d1ee..47ae7a7 100644
> --- a/libavformat/nutdec.c
> +++ b/libavformat/nutdec.c
> @@ -1146,6 +1146,11 @@ static int decode_frame(NUTContext *nut, AVPacket 
> *pkt, int frame_code)
>  goto fail;
>  }
>  sm_size = avio_tell(bc) - pkt->pos;
> +if (sm_size < 0) {

did sm_size overflow and should be 64bit ?
did the byte position (avio_tell) move backward ? (this should not
happen)

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_delogo: change the definition of logo_x2 and logo_y2

[Michael Niedermayer]

On Fri, Dec 18, 2015 at 04:16:38PM +0100, Jean Delvare wrote:
> In the code we keep using logo_x2-1 and logo_y2-1 rather than logo_x2
> and logo_y2 themselves. Define them to be what we need instead, to avoid
> the repeated subtractions.
> 
> Signed-off-by: Jean Delvare 
> ---
>  libavfilter/vf_delogo.c |   26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)

applied

thanks

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

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please


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

Re: [FFmpeg-devel] [PATCH] lavfi/scale: add nb_slices debug option

[Nicolas George]

L'octidi 28 frimaire, an CCXXIV, Clement Boesch a écrit :
> +const int slice_h = FFMAX(1, link->h / scale->nb_slices);
> +for (i = 0; i < scale->nb_slices; i++)
> +scale_slice(link, out, in, scale->sws, i*slice_h, slice_h, 1, 0);

What happens if link->h is not a multiple of nb_slices?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [libav-devel] [PATCH] nuv: reject negative fps rate

[Andreas Cadhalpun]

On 18.12.2015 15:46, Anton Khirnov wrote:
> Quoting Luca Barbato (2015-12-18 15:36:33)
>> On 18/12/15 15:25, Andreas Cadhalpun wrote:
>>> On 18.12.2015 12:00, Luca Barbato wrote:
 b- mark the framerate as invalid
>>>
>>> How does one do that?
>>>
 and let the user decide what to do,
 e.g. override it with a value that works for them.
 c- a or b depending on explode.

 A framerate of 0 is the same as a negative framerate for all the
 intended purposes.
>>>
>>> So should a negative framerate simply be set to 0?
>>>
>>
>> I'd just have an explode mode: either error out or otherwise set it to
>> invalid (0 is fine as invalid) and let the user decide what to do.

OK, patch doing that attached.

> To elaborate, check if AV_EF_EXPLODE is set in
> AVFormatContext.error_recognition

And thanks for the reminder.

Best regards,
Andreas

>From 06dbcdf1bdcdf30923109da5195948297a828628 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Wed, 16 Dec 2015 20:52:39 +0100
Subject: [PATCH] nuv: sanitize negative fps rate

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/nuv.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavformat/nuv.c b/libavformat/nuv.c
index 2a1b70f..c30da60 100644
--- a/libavformat/nuv.c
+++ b/libavformat/nuv.c
@@ -172,6 +172,15 @@ static int nuv_header(AVFormatContext *s)
 if (aspect > 0. && aspect < 1.0001)
 aspect = 4.0 / 3.0;
 fps = av_int2double(avio_rl64(pb));
+if (fps < 0.0f) {
+if (s->error_recognition & AV_EF_EXPLODE) {
+av_log(s, AV_LOG_ERROR, "Invalid frame rate %f\n", fps);
+return AVERROR_INVALIDDATA;
+} else {
+av_log(s, AV_LOG_WARNING, "Invalid frame rate %f, setting to 0.\n", fps);
+fps = 0.0f;
+}
+}
 
 // number of packets per stream type, -1 means unknown, e.g. streaming
 v_packs = avio_rl32(pb);
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] nutdec: only copy the header if it exists

[Michael Niedermayer]

On Fri, Dec 18, 2015 at 05:24:09PM +0100, Andreas Cadhalpun wrote:
> Fixes runtime error: null pointer passed as argument 2, which is
> declared to never be null
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/nutdec.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

LGTM

thanks

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

Re: [FFmpeg-devel] [PATCH] lavu/libm: add copysign hack

[Ganesh Ajjanagadde]

On Fri, Dec 18, 2015 at 12:41 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Fri, Dec 18, 2015 at 2:18 PM, Ganesh Ajjanagadde 
> wrote:
>>
>> For systems with broken libms.
>> Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular double x and
>> combinations of these.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  configure| 2 +-
>>  libavutil/libm.h | 9 +
>>  2 files changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index 123d1df..7917386 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl"
>>  delogo_filter_deps="gpl"
>>  deshake_filter_select="pixelutils"
>>  drawtext_filter_deps="libfreetype"
>> -dynaudnorm_filter_deps="copysign erf"
>> +dynaudnorm_filter_deps="erf"
>>  ebur128_filter_deps="gpl"
>>  eq_filter_deps="gpl"
>>  fftfilt_filter_deps="avcodec"
>> diff --git a/libavutil/libm.h b/libavutil/libm.h
>> index 6d8bd68..637de19 100644
>> --- a/libavutil/libm.h
>> +++ b/libavutil/libm.h
>> @@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x)
>>  }
>>  #endif
>>
>> +#if !HAVE_COPYSIGN
>> +static av_always_inline double copysign(double x, double y)
>> +{
>> +uint64_t vx = av_double2int(x);
>> +uint64_t vy = av_double2int(y);
>> +return av_int2double((vx & 0x7fff) | (vy &
>> 0x8000));
>> +}
>> +#endif
>
>
> Don't these need type suffixes (e.g. UINT64_C(val)) on some systems?

I believe not, see
http://en.cppreference.com/w/cpp/language/integer_literal and a long
discussion at libav-devel
https://lists.libav.org/pipermail/libav-devel/2015-October/072866.html
and related messages.

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

Re: [FFmpeg-devel] Vertical bands with RT21 (Intel Real Time Video2.1) codec

[Paul B Mahol]

On 12/18/15, Piotr Bandurski  wrote:
>
>
>
> Dnia 18 grudnia 2015 18:54 Paul B Mahol  napisal/(a):
>
>
>
>>
>> > On 12/18/15, Mats Peterson  wrote:
>> > On 12/18/2015 05:32 AM, Mats Peterson wrote:
>> >> On 12/18/2015 05:12 AM, Mats Peterson wrote:
>> >>> On 12/18/2015 04:13 AM, Mats Peterson wrote:
>>  Samples:
>>  https://drive.google.com/open?id=0B3_pEBoLs0faei1Sd1h6SG11QlE
>> 
>>  Mats
>> 
>> >>>
>> >>> The clips are sample clips from Video for Windows, in case anyone
>> >>> wonders. I haven't created them myself.
>> >>>
>> >>> Mats
>> >>>
>> >>
>> >> The output is generally washed-out, as well, apart from the bands.
>> >>
>> >> Mats
>> >>
>> >
>> > I noticed this issue has been discussed as far back as in 2005 (see
>> > http://sourceforge.net/p/ffmpeg/bugs/310/), but using the slightly
>> > different terms "ghosting and shadow effects". In any case, it obviously
>> > still hasn't been fixed.
>>
>> No, this is different issue. Do you know a software that actually
>> plays such videos correctly?
>
> Here is ir21.dll output:

And ir21.dll ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Vertical bands with RT21 (Intel Real Time Video2.1) codec

[Piotr Bandurski]

Dnia 18 grudnia 2015 18:54 Paul B Mahol  napisał(a):



> 
> > On 12/18/15, Mats Peterson  wrote:
> > On 12/18/2015 05:32 AM, Mats Peterson wrote:
> >> On 12/18/2015 05:12 AM, Mats Peterson wrote:
> >>> On 12/18/2015 04:13 AM, Mats Peterson wrote:
>  Samples: https://drive.google.com/open?id=0B3_pEBoLs0faei1Sd1h6SG11QlE
> 
>  Mats
> 
> >>>
> >>> The clips are sample clips from Video for Windows, in case anyone
> >>> wonders. I haven't created them myself.
> >>>
> >>> Mats
> >>>
> >>
> >> The output is generally washed-out, as well, apart from the bands.
> >>
> >> Mats
> >>
> >
> > I noticed this issue has been discussed as far back as in 2005 (see
> > http://sourceforge.net/p/ffmpeg/bugs/310/), but using the slightly
> > different terms "ghosting and shadow effects". In any case, it obviously
> > still hasn't been fixed.
> 
> No, this is different issue. Do you know a software that actually
> plays such videos correctly?

Here is ir21.dll output:

http://www.datafilehost.com/d/feb72d79



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

Re: [FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}

[Michael Niedermayer]

On Fri, Dec 18, 2015 at 04:33:37PM +0100, Matthieu Bouron wrote:
> On Fri, Dec 18, 2015 at 3:59 PM, Matthieu Bouron 
> wrote:
> 
> > From: Matthieu Bouron 
> >
> > ---
> >  libswscale/arm/swscale_unscaled.c | 52 +++---
> >  libswscale/arm/yuv2rgb_neon.S | 77
> > ---
> >  2 files changed, 118 insertions(+), 11 deletions(-)
> >
> > diff --git a/libswscale/arm/swscale_unscaled.c
> > b/libswscale/arm/swscale_unscaled.c
> > index 8aa6432..dce987e 100644
> > --- a/libswscale/arm/swscale_unscaled.c
> > +++ b/libswscale/arm/swscale_unscaled.c
> > @@ -63,6 +63,50 @@ static int rgbx_to_nv12_neon_16_wrapper(SwsContext
> > *context, const uint8_t *src[
> >  }
> >  #endif
> >
> > +#define YUV_TO_RGB_TABLE(precision)
> >\
> > +c->yuv2rgb_v2r_coeff / ((precision) == 16 ? 1 << 7 : 1),
> >   \
> > +c->yuv2rgb_u2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
> >   \
> > +c->yuv2rgb_v2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
> >   \
> > +c->yuv2rgb_u2b_coeff / ((precision) == 16 ? 1 << 7 : 1),
> >   \
> > +
> > +#define DECLARE_FF_YUV420P_TO_RGBX_FUNCS(ofmt, precision)
> >\
> > +int ff_yuv420p_to_##ofmt##_neon_##precision(int w, int h,
> >\
> > + uint8_t *dst, int linesize,
> >   \
> > + const uint8_t *srcY, int linesizeY,
> >   \
> > + const uint8_t *srcU, int linesizeU,
> >   \
> > + const uint8_t *srcV, int linesizeV,
> >   \
> > + const int16_t *table,
> >   \
> > + int y_offset,
> >   \
> > + int y_coeff);
> >   \
> > +
> >   \
> > +static int yuv420p_to_##ofmt##_neon_wrapper_##precision(SwsContext *c,
> > const uint8_t *src[],\
> > +   int srcStride[], int
> > srcSliceY, int srcSliceH,   \
> > +   uint8_t *dst[], int
> > dstStride[]) {   \
> > +const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE(precision) };
> >   \
> > +
> >   \
> > +ff_yuv420p_to_##ofmt##_neon_##precision(c->srcW, srcSliceH,
> >\
> > + dst[0] +  srcSliceY  * dstStride[0],
> > dstStride[0], \
> > + src[0] +  srcSliceY  * srcStride[0],
> > srcStride[0], \
> > + src[1] + (srcSliceY / 2) * srcStride[1],
> > srcStride[1], \
> > + src[2] + (srcSliceY / 2) * srcStride[2],
> > srcStride[2], \
> > + yuv2rgb_table,
> >\
> > + c->yuv2rgb_y_offset >> 9,
> >   \
> > + c->yuv2rgb_y_coeff / ((precision) == 16
> > ? 1 << 7 : 1));\
> > +
> >   \
> > +return 0;
> >\
> > +}
> >\
> > +
> > +#define DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(precision)
> >\
> > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(argb, precision)
> >\
> > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(rgba, precision)
> >\
> > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(abgr, precision)
> >\
> > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(bgra, precision)
> >\
> > +
> > +#define DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS
> >   \
> > +DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(16)
> >   \
> > +
> > +DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS
> > +
> >  #define DECLARE_FF_NVX_TO_RGBX_FUNCS(ifmt, ofmt, precision)
> >\
> >  int ff_##ifmt##_to_##ofmt##_neon_##precision(int w, int h,
> >   \
> >   uint8_t *dst, int linesize,
> >   \
> > @@ -75,12 +119,7 @@ int ff_##ifmt##_to_##ofmt##_neon_##precision(int w,
> > int h,
> >  static int ifmt##_to_##ofmt##_neon_wrapper_##precision(SwsContext *c,
> > const uint8_t *src[], \
> > int srcStride[], int
> > srcSliceY, int srcSliceH,   \
> > uint8_t *dst[], int
> > dstStride[]) {   \
> > -const int16_t yuv2rgb_table[] = {
> >\
> > -c->yuv2rgb_v2r_coeff / ((precision) == 16 ? 1 << 7 : 1),
> >   \
> > -c->yuv2rgb_u2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
> >   \
> > -c->yuv2rgb_v2g_coeff / ((precision) == 

Re: [FFmpeg-devel] [PATCH 1/1] arm64: fix inverted register order in transpose_4x4H

[Michael Niedermayer]

On Fri, Dec 18, 2015 at 11:27:05AM +0100, Janne Grunau wrote:
> Fix related register order issue in ff_h264_idct_add_neon.
> 
> Found-by: zjh8890 <243186...@qq.com>
> ---
>  libavcodec/aarch64/h264idct_neon.S | 4 ++--
>  libavcodec/aarch64/neon.S  | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)

applied

thanks

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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

Re: [FFmpeg-devel] [PATCH 1/1] arm64: fix inverted register order in transpose_4x4H

[Michael Niedermayer]

On Fri, Dec 18, 2015 at 11:07:56AM +, Carl Eugen Hoyos wrote:
> Janne Grunau  jannau.net> writes:
> 
> > Fix related register order issue in ff_h264_idct_add_neon.
> 
> Is there a public sample that allows to reproduce?

i dont think this fixes a sample, its more a cosmetic/internal API fix
IIUC

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] Vertical bands with RT21 (Intel Real Time Video 2.1) codec

[Mats Peterson]

On 12/19/2015 04:03 AM, Mats Peterson wrote:

On 12/19/2015 04:01 AM, Mats Peterson wrote:

On 12/18/2015 01:22 PM, Mats Peterson wrote:

On 12/18/2015 05:32 AM, Mats Peterson wrote:

On 12/18/2015 05:12 AM, Mats Peterson wrote:

On 12/18/2015 04:13 AM, Mats Peterson wrote:

Samples:
https://drive.google.com/open?id=0B3_pEBoLs0faei1Sd1h6SG11QlE

Mats



The clips are sample clips from Video for Windows, in case anyone
wonders. I haven't created them myself.

Mats



The output is generally washed-out, as well, apart from the bands.

Mats



I noticed this issue has been discussed as far back as in 2005 (see
http://sourceforge.net/p/ffmpeg/bugs/310/), but using the slightly
different terms "ghosting and shadow effects". In any case, it obviously
still hasn't been fixed.

Mats



Sorry, Paul, I accidentally removed your reply. Anyway, as an answer to
your question regarding whether I know software that plays/decodes the
videos correctly, yes, the IR21 codec in Windows 3.1. Support for RT21
was unfortunately dropped in later versions of Windows, as far as I
know. And thanks, Piotr Bandursky, for providing the raw output from
ir21.dll. That's the way it should look.

Mats



Bandurski, sorry.



I have (once again) checked the videos in dosbox/windows 3.1, and there 
is still a tendency of vertical bands, but that seems to be inherent to 
the codec. In any case it is to a much lesser degree than in the output 
from FFmpeg.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 11/12] lavfi/vf_histogram: replace round by lrint

[Ganesh Ajjanagadde]

lrint is at least as fast, and more accurate.

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

diff --git a/libavfilter/vf_histogram.c b/libavfilter/vf_histogram.c
index 8e6f531..3f50f12 100644
--- a/libavfilter/vf_histogram.c
+++ b/libavfilter/vf_histogram.c
@@ -281,7 +281,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 int col_height;
 
 if (h->levels_mode)
-col_height = round(h->level_height * (1. - 
(log2(h->histogram[i] + 1) / max_hval_log)));
+col_height = lrint(h->level_height * (1. - 
(log2(h->histogram[i] + 1) / max_hval_log)));
 else
 col_height = h->level_height - (h->histogram[i] * 
(int64_t)h->level_height + max_hval - 1) / max_hval;
 
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 07/12] lavc/libvpxenc: replace round by lrint

[Ganesh Ajjanagadde]

Mostly cosmetic here.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/libvpxenc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 96b1ac6..585c218 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -477,7 +477,7 @@ static av_cold int vpx_init(AVCodecContext *avctx,
 enccfg.rc_dropframe_thresh = avctx->frame_skip_threshold;
 
 //0-100 (0 => CBR, 100 => VBR)
-enccfg.rc_2pass_vbr_bias_pct   = round(avctx->qcompress * 100);
+enccfg.rc_2pass_vbr_bias_pct   = lrint(avctx->qcompress * 100);
 if (avctx->bit_rate)
 enccfg.rc_2pass_vbr_minsection_pct =
 avctx->rc_min_rate * 100LL / avctx->bit_rate;
@@ -497,7 +497,7 @@ static av_cold int vpx_init(AVCodecContext *avctx,
 if (avctx->rc_buffer_aggressivity != 1.0) {
 av_log(avctx, AV_LOG_WARNING, "The rc_buffer_aggressivity option is "
"deprecated, use the undershoot-pct private option instead.\n");
-enccfg.rc_undershoot_pct = round(avctx->rc_buffer_aggressivity * 100);
+enccfg.rc_undershoot_pct = lrint(avctx->rc_buffer_aggressivity * 100);
 }
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 09/12] lavfi/af_dynaudnorm: replace round by lrint

[Ganesh Ajjanagadde]

lrint is at least as fast, and is more accurate.

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

diff --git a/libavfilter/af_dynaudnorm.c b/libavfilter/af_dynaudnorm.c
index 5f412f5..6401595 100644
--- a/libavfilter/af_dynaudnorm.c
+++ b/libavfilter/af_dynaudnorm.c
@@ -135,7 +135,7 @@ static int query_formats(AVFilterContext *ctx)
 
 static inline int frame_size(int sample_rate, int frame_len_msec)
 {
-const int frame_size = round((double)sample_rate * (frame_len_msec / 
1000.0));
+const int frame_size = lrint((double)sample_rate * (frame_len_msec / 
1000.0));
 return frame_size + (frame_size % 2);
 }
 
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 12/12] lavd/pulse_audio_enc: replace lround by lrint

[Ganesh Ajjanagadde]

Here it is mostly a cosmetic change, but there might be benefits in that
there are no compat hacks for lround, while there are for lrint.

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

diff --git a/libavdevice/pulse_audio_enc.c b/libavdevice/pulse_audio_enc.c
index bc4d1f0..d8501e3 100644
--- a/libavdevice/pulse_audio_enc.c
+++ b/libavdevice/pulse_audio_enc.c
@@ -333,7 +333,7 @@ static int pulse_set_volume(PulseData *s, double volume)
 pa_volume_t vol;
 const pa_sample_spec *ss = pa_stream_get_sample_spec(s->stream);
 
-vol = pa_sw_volume_multiply(lround(volume * PA_VOLUME_NORM), 
s->base_volume);
+vol = pa_sw_volume_multiply(lrint(volume * PA_VOLUME_NORM), 
s->base_volume);
 pa_cvolume_set(, ss->channels, PA_VOLUME_NORM);
 pa_sw_cvolume_multiply_scalar(, , vol);
 pa_threaded_mainloop_lock(s->mainloop);
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 10/12] lavfi/vf_cropdetect: replace round by lrint

[Ganesh Ajjanagadde]

lrint is at least as fast, and more accurate.

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

diff --git a/libavfilter/vf_cropdetect.c b/libavfilter/vf_cropdetect.c
index d456377..4a89875 100644
--- a/libavfilter/vf_cropdetect.c
+++ b/libavfilter/vf_cropdetect.c
@@ -165,7 +165,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 int w, h, x, y, shrink_by;
 AVDictionary **metadata;
 int outliers, last_y;
-int limit = round(s->limit);
+int limit = lrint(s->limit);
 
 // ignore first 2 frames - they may be empty
 if (++s->frame_nb > 0) {
-- 
2.6.4

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

Re: [FFmpeg-devel] Vertical bands with RT21 (Intel Real Time Video 2.1) codec

[Dave Yeo]

On 12/18/15 09:54 AM, Paul B Mahol wrote:

On 12/18/15, Mats Peterson  wrote:

>On 12/18/2015 05:32 AM, Mats Peterson wrote:

>>On 12/18/2015 05:12 AM, Mats Peterson wrote:

>>>On 12/18/2015 04:13 AM, Mats Peterson wrote:

Samples:https://drive.google.com/open?id=0B3_pEBoLs0faei1Sd1h6SG11QlE

Mats


>>>
>>>The clips are sample clips from Video for Windows, in case anyone
>>>wonders. I haven't created them myself.
>>>
>>>Mats
>>>

>>
>>The output is generally washed-out, as well, apart from the bands.
>>
>>Mats
>>

>
>I noticed this issue has been discussed as far back as in 2005 (see
>http://sourceforge.net/p/ffmpeg/bugs/310/), but using the slightly
>different terms "ghosting and shadow effects". In any case, it obviously
>still hasn't been fixed.

No, this is different issue. Do you know a software that actually
plays such videos correctly?



They play correctly using the builtin OS/2 video player, especially at 
the preferred resolution, maybe 240x320. FFplay shows the colours as 
washed out and the banding that is mentioned. If I enlarge the OS/2 
window to the same size as the FFplay window, it looks somewhat staticy 
with vertical lines of static but still much better then FFplay. MPlayer 
plays at the correct resolution but has the same issues as FFplay, 
banding and washed out colours.
Video for Windows didn't like the fact that I tried to install it on a 
drive with over 2GBs free so didn't test under real hardware.

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

Re: [FFmpeg-devel] Vertical bands with RT21 (Intel Real Time Video 2.1) codec

[Mats Peterson]

On 12/19/2015 07:52 AM, Mats Peterson wrote:

On 12/19/2015 07:20 AM, Dave Yeo wrote:

On 12/18/15 09:54 AM, Paul B Mahol wrote:

On 12/18/15, Mats Peterson  wrote:

>On 12/18/2015 05:32 AM, Mats Peterson wrote:

>>On 12/18/2015 05:12 AM, Mats Peterson wrote:

>>>On 12/18/2015 04:13 AM, Mats Peterson wrote:

Samples:https://drive.google.com/open?id=0B3_pEBoLs0faei1Sd1h6SG11QlE



Mats


>>>
>>>The clips are sample clips from Video for Windows, in case anyone
>>>wonders. I haven't created them myself.
>>>
>>>Mats
>>>

>>
>>The output is generally washed-out, as well, apart from the bands.
>>
>>Mats
>>

>
>I noticed this issue has been discussed as far back as in 2005 (see
>http://sourceforge.net/p/ffmpeg/bugs/310/), but using the slightly
>different terms "ghosting and shadow effects". In any case, it
obviously
>still hasn't been fixed.

No, this is different issue. Do you know a software that actually
plays such videos correctly?



They play correctly using the builtin OS/2 video player, especially at
the preferred resolution, maybe 240x320. FFplay shows the colours as
washed out and the banding that is mentioned. If I enlarge the OS/2
window to the same size as the FFplay window, it looks somewhat staticy
with vertical lines of static but still much better then FFplay. MPlayer
plays at the correct resolution but has the same issues as FFplay,
banding and washed out colours.
Video for Windows didn't like the fact that I tried to install it on a
drive with over 2GBs free so didn't test under real hardware.
Dave
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Yes, and the reason MPlayer has the same issues is because it uses
FFmpeg to decode the video. Thanks for another "proof". I have used
Windows 3.1 in dosbox, and it works "fine" there, albeit with a tiny
hint of vertical bands still showing. As I said before, this is probably
inheherent to the codec itself.

Mats



Not inheherent, inherent. Nothing funny about this ;)

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}

[Michael Niedermayer]

On Fri, Dec 18, 2015 at 11:44:27AM +0100, Matthieu Bouron wrote:
> On Thu, Dec 17, 2015 at 07:47:08PM +0100, Michael Niedermayer wrote:
> > On Thu, Dec 17, 2015 at 04:54:31PM +0100, Matthieu Bouron wrote:
> > > On Tue, Dec 15, 2015 at 06:22:43PM +0100, Michael Niedermayer wrote:
> > > > On Tue, Dec 15, 2015 at 05:46:09PM +0100, Matthieu Bouron wrote:
> > > > > From: Matthieu Bouron 
> > > > > 
> > > > > ---
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > This commit is likely to break fate on arm since the current C code 
> > > > > path
> > > > > seems to use less precision.
> > > > > 
> > > > > How should I proceed to fix it ?
> > > > 
> > > > hmm
> > > > can the precission of the C code path and any asm impl of it under
> > > > bitexact (if they exist), be changed to higher precission without
> > > > speedloss?
> > > > if so that would be an option
> > > 
> > > We are currently facing 4 cases (with this patch applied)
> > > 
> > >   * [1] ARM +ACCURATE_RND: uses neon, 13bit coefficients and 32bit
> > >   precision overall
> > >   * [2] ARM -ACCURATE_RND: uses neon, 6bit coefficients and 16bit
> > >   precision overall
> > 
> > >   * [3] X86 +ACCURATE_RND: uses a C code path with lookup tables
> > 
> > which LUT do you mean here ?
> 
> The table filled by ff_yuv2rgb_c_init_tables. Not sure if it's used
> though, I haven't looked at the C code that actually does the conversion
> (yet).
> 
> > 
> > 
> > >   * [4] X86 -ACCURATE_RND: uses MMX+MMXEXT with apparently 13bit
> > >   coefficients (libswscale/yuv2rgb.c around line 800).
> > > 
> > > Notes:
> > >   * The 4 outputs are different with [3] being ugly (ghosting/non-sharp
> > >   edges).
> > > 
> > >   * [1] and [4] (13bit coefficient accuracy) should be the same but have
> > >   slight differences.
> > > 
> > > Questions:
> > > 
> > 
> > >   * What is the meaning of the ACCURATE_RND flag ?
> > 
> > it should enable accurate rounding
> > 
> > 
> > >   * Does [3] use some kind of interpolation instead of duplicating
> > >   chroma lines ? Its output seems inferior to the other code paths.
> > 
> > are you sure that is true for real images?
> > its easy to end up with wrong conclusions with synthetic inputs
> > unless you want to use the scaler only for such inputs.
> > 
> > either way line duplication is likely not optimal for real images
> > iam not made of constant color blocks that are aligned to some cammeras
> > 2x2 samples
> > 
> > 
> > >   * Is [3] the output that should be taken as reference ?
> > 
> > id say, the reference is reality, making the output as close as a
> > image of the new resolution would be if it had been taken that way
> > 
> > 
> > >   * Should we use BITEXACT instead of ACCURATE_RND to determine the
> > >   precision used ?
> > 
> > BITEXACT is to avoid platform differences and allow regression tests
> > 
> > if all else is equal it would be best if C and asm matches, and if
> > C is bad then it should be improved
> 
> Here are the C, MMX and NEON outputs from a photo:
> http://0x5c.me/yuv2rgb/photos
> 
> The C and NEON outputs look almost the same.
> The MMX one have slightly different "colors" overall.
> 
> Since figuring out what the C code is actually doing and have the neon asm
> matches its output is likely to take some time. Would you be OK if, on the
> ARM platform, +ACCURATE_RND uses the C code path (so fate is not broken),
> and -ACCURATE_RND uses the neon code path with a precision of 16bit (IMHO,
> speed is preferred over the slight quality gain of the 32bit version on
> this platform) ?
> 
> This behaviour will affect yuv420p but also nv12 and nv21 inputs.
> 
> This is a kind of a temporary (and lame) solution until I have some time
> to work on it.

no objections

thanks

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

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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

[FFmpeg-devel] [PATCH 06/12] lavf/hlsenc: replace round by lrint

[Ganesh Ajjanagadde]

Mainly cosmetic here.

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

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index adcf7df..f2d7a52 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -430,7 +430,7 @@ static int hls_window(AVFormatContext *s, int last)
 }
 
 if (hls->flags & HLS_ROUND_DURATIONS)
-avio_printf(out, "#EXTINF:%d,\n",  (int)round(en->duration));
+avio_printf(out, "#EXTINF:%ld,\n",  lrint(en->duration));
 else
 avio_printf(out, "#EXTINF:%f,\n", en->duration);
 if (hls->flags & HLS_SINGLE_FILE)
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 04/12] lavfi/vf_drawtext: replace round by llrint

[Ganesh Ajjanagadde]

llrint is at least as fast, and better accuracy wise.

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

diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index fc77be4..d5770ad 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -812,7 +812,7 @@ static int func_pts(AVFilterContext *ctx, AVBPrint *bp,
 if (isnan(pts)) {
 av_bprintf(bp, " ??:??:??.???");
 } else {
-int64_t ms = round(pts * 1000);
+int64_t ms = llrint(pts * 1000);
 char sign = ' ';
 if (ms < 0) {
 sign = '-';
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 08/12] lavfi/vf_crop: replace round by lrint

[Ganesh Ajjanagadde]

lrint is at least as fast, and more accurate.

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

diff --git a/libavfilter/vf_crop.c b/libavfilter/vf_crop.c
index 93a58da..01773fa 100644
--- a/libavfilter/vf_crop.c
+++ b/libavfilter/vf_crop.c
@@ -126,7 +126,7 @@ static inline int normalize_double(int *n, double d)
 *n = d > INT_MAX ? INT_MAX : INT_MIN;
 ret = AVERROR(EINVAL);
 } else
-*n = round(d);
+*n = lrint(d);
 
 return ret;
 }
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 01/12] lavfi/vf_idet: replace round and cast by lrint

[Ganesh Ajjanagadde]

lrint is faster and conveys the intent better here. It is safe as long int has
at least 32 bits.

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

diff --git a/libavfilter/vf_idet.c b/libavfilter/vf_idet.c
index e4fe6cb..60ec23a 100644
--- a/libavfilter/vf_idet.c
+++ b/libavfilter/vf_idet.c
@@ -409,7 +409,7 @@ static av_cold int init(AVFilterContext *ctx)
 memset(idet->history, UNDETERMINED, HIST_SIZE);
 
 if( idet->half_life > 0 )
-idet->decay_coefficient = (uint64_t) round( PRECISION * exp2(-1.0 / 
idet->half_life) );
+idet->decay_coefficient = lrint( PRECISION * exp2(-1.0 / 
idet->half_life) );
 else
 idet->decay_coefficient = PRECISION;
 
-- 
2.6.4

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

[FFmpeg-devel] [PATCH 03/12] lavfi/vf_colorlevels: replace round by lrint

[Ganesh Ajjanagadde]

lrint is more accurate, and is not slower on non-broken libm's. Thus this
represents a Pareto improvement.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/vf_colorlevels.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavfilter/vf_colorlevels.c b/libavfilter/vf_colorlevels.c
index cb3314b..dedbe30 100644
--- a/libavfilter/vf_colorlevels.c
+++ b/libavfilter/vf_colorlevels.c
@@ -132,10 +132,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 const uint8_t offset = s->rgba_map[i];
 const uint8_t *srcrow = in->data[0];
 uint8_t *dstrow = out->data[0];
-int imin = round(r->in_min  * UINT8_MAX);
-int imax = round(r->in_max  * UINT8_MAX);
-int omin = round(r->out_min * UINT8_MAX);
-int omax = round(r->out_max * UINT8_MAX);
+int imin = lrint(r->in_min  * UINT8_MAX);
+int imax = lrint(r->in_max  * UINT8_MAX);
+int omin = lrint(r->out_min * UINT8_MAX);
+int omax = lrint(r->out_max * UINT8_MAX);
 double coeff;
 
 if (imin < 0) {
@@ -179,10 +179,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 const uint8_t offset = s->rgba_map[i];
 const uint8_t *srcrow = in->data[0];
 uint8_t *dstrow = out->data[0];
-int imin = round(r->in_min  * UINT16_MAX);
-int imax = round(r->in_max  * UINT16_MAX);
-int omin = round(r->out_min * UINT16_MAX);
-int omax = round(r->out_max * UINT16_MAX);
+int imin = lrint(r->in_min  * UINT16_MAX);
+int imax = lrint(r->in_max  * UINT16_MAX);
+int omin = lrint(r->out_min * UINT16_MAX);
+int omax = lrint(r->out_max * UINT16_MAX);
 double coeff;
 
 if (imin < 0) {
-- 
2.6.4

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

Re: [FFmpeg-devel] Vertical bands with RT21 (Intel Real Time Video 2.1) codec

[Mats Peterson]

On 12/19/2015 07:20 AM, Dave Yeo wrote:

On 12/18/15 09:54 AM, Paul B Mahol wrote:

On 12/18/15, Mats Peterson  wrote:

>On 12/18/2015 05:32 AM, Mats Peterson wrote:

>>On 12/18/2015 05:12 AM, Mats Peterson wrote:

>>>On 12/18/2015 04:13 AM, Mats Peterson wrote:

Samples:https://drive.google.com/open?id=0B3_pEBoLs0faei1Sd1h6SG11QlE


Mats


>>>
>>>The clips are sample clips from Video for Windows, in case anyone
>>>wonders. I haven't created them myself.
>>>
>>>Mats
>>>

>>
>>The output is generally washed-out, as well, apart from the bands.
>>
>>Mats
>>

>
>I noticed this issue has been discussed as far back as in 2005 (see
>http://sourceforge.net/p/ffmpeg/bugs/310/), but using the slightly
>different terms "ghosting and shadow effects". In any case, it
obviously
>still hasn't been fixed.

No, this is different issue. Do you know a software that actually
plays such videos correctly?



They play correctly using the builtin OS/2 video player, especially at
the preferred resolution, maybe 240x320. FFplay shows the colours as
washed out and the banding that is mentioned. If I enlarge the OS/2
window to the same size as the FFplay window, it looks somewhat staticy
with vertical lines of static but still much better then FFplay. MPlayer
plays at the correct resolution but has the same issues as FFplay,
banding and washed out colours.
Video for Windows didn't like the fact that I tried to install it on a
drive with over 2GBs free so didn't test under real hardware.
Dave
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Yes, and the reason MPlayer has the same issues is because it uses 
FFmpeg to decode the video. Thanks for another "proof". I have used 
Windows 3.1 in dosbox, and it works "fine" there, albeit with a tiny 
hint of vertical bands still showing. As I said before, this is probably 
inheherent to the codec itself.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Vertical bands with RT21 (Intel Real Time Video 2.1) codec

[Mats Peterson]

On 12/19/2015 04:01 AM, Mats Peterson wrote:

On 12/18/2015 01:22 PM, Mats Peterson wrote:

On 12/18/2015 05:32 AM, Mats Peterson wrote:

On 12/18/2015 05:12 AM, Mats Peterson wrote:

On 12/18/2015 04:13 AM, Mats Peterson wrote:

Samples: https://drive.google.com/open?id=0B3_pEBoLs0faei1Sd1h6SG11QlE

Mats



The clips are sample clips from Video for Windows, in case anyone
wonders. I haven't created them myself.

Mats



The output is generally washed-out, as well, apart from the bands.

Mats



I noticed this issue has been discussed as far back as in 2005 (see
http://sourceforge.net/p/ffmpeg/bugs/310/), but using the slightly
different terms "ghosting and shadow effects". In any case, it obviously
still hasn't been fixed.

Mats



Sorry, Paul, I accidentally removed your reply. Anyway, as an answer to
your question regarding whether I know software that plays/decodes the
videos correctly, yes, the IR21 codec in Windows 3.1. Support for RT21
was unfortunately dropped in later versions of Windows, as far as I
know. And thanks, Piotr Bandursky, for providing the raw output from
ir21.dll. That's the way it should look.

Mats



Bandurski, sorry.

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel