Re: [FFmpeg-devel] [PATCH 0/4] x86inc: Sync changes from x264

[Michael Niedermayer]

On Mon, Apr 18, 2016 at 07:03:40PM +0200, Henrik Gramner wrote:
> Anton Mitrofanov (3):
>   x86inc: Fix AVX emulation of some instructions
>   x86inc: Improve handling of %ifid with multi-token parameters
>   x86inc: Enable AVX emulation in additional cases
> 
> Henrik Gramner (1):
>   x86inc: Fix AVX emulation of scalar float instructions
> 
>  libavutil/x86/x86inc.asm | 95 
> ++--
>  1 file changed, 52 insertions(+), 43 deletions(-)

should be ok 

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

Re: [FFmpeg-devel] [PATCH v3 1/2] lavc/ccaption_dec: do not ignore repeated character commands

[Aman Gupta]

Please send me the sample and I will try to fix the issue.

Aman
On Mon, Apr 18, 2016 at 1:22 PM Thierry Foucu  wrote:

> Hi all
>
> On Sun, Feb 14, 2016 at 6:11 PM, Aman Gupta  wrote:
>
>> From: Aman Gupta 
>>
>> control codes in a cc stream can be repeated, and must be ignored.
>> however, repeated characters must not be ignored. the code attempted to
>> wipe prev_cmd in handle_char to allow repeated characters to be
>> processed, but prev_cmd would previously get reset _after_ handle_char()
>>
>> i also moved the prev_cmd reset out from handle_char() so it can be
>> re-used for special character sets, which _must_ be ignored when
>> repeated.
>> ---
>>  libavcodec/ccaption_dec.c | 19 ++-
>>  1 file changed, 10 insertions(+), 9 deletions(-)
>>
>> diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
>> index 790f071..5fb2ec6 100644
>> --- a/libavcodec/ccaption_dec.c
>> +++ b/libavcodec/ccaption_dec.c
>> @@ -484,9 +484,6 @@ static void handle_char(CCaptionSubContext *ctx, char
>> hi, char lo, int64_t pts)
>>  if (ctx->mode != CCMODE_POPON)
>>  ctx->screen_touched = 1;
>>
>> -/* reset prev command since character can repeat */
>> -ctx->prev_cmd[0] = 0;
>> -ctx->prev_cmd[1] = 0;
>>  if (lo)
>> ff_dlog(ctx, "(%c,%c)\n", hi, lo);
>>  else
>> @@ -497,8 +494,15 @@ static void process_cc608(CCaptionSubContext *ctx,
>> int64_t pts, uint8_t hi, uint
>>  {
>>  if (hi == ctx->prev_cmd[0] && lo == ctx->prev_cmd[1]) {
>>  /* ignore redundant command */
>> -} else if ( (hi == 0x10 && (lo >= 0x40 && lo <= 0x5f)) ||
>> -  ( (hi >= 0x11 && hi <= 0x17) && (lo >= 0x40 && lo <= 0x7f)
>> ) ) {
>> +return;
>> +}
>> +
>> +/* set prev command */
>> +ctx->prev_cmd[0] = hi;
>> +ctx->prev_cmd[1] = lo;
>> +
>> +if ( (hi == 0x10 && (lo >= 0x40 && lo <= 0x5f)) ||
>> +   ( (hi >= 0x11 && hi <= 0x17) && (lo >= 0x40 && lo <= 0x7f) ) ) {
>>  handle_pac(ctx, hi, lo);
>>  } else if ( ( hi == 0x11 && lo >= 0x20 && lo <= 0x2f ) ||
>>  ( hi == 0x17 && lo >= 0x2e && lo <= 0x2f) ) {
>> @@ -559,14 +563,11 @@ static void process_cc608(CCaptionSubContext *ctx,
>> int64_t pts, uint8_t hi, uint
>>  } else if (hi >= 0x20) {
>>  /* Standard characters (always in pairs) */
>>  handle_char(ctx, hi, lo, pts);
>> +ctx->prev_cmd[0] = ctx->prev_cmd[1] = 0;
>>  } else {
>>  /* Ignoring all other non data code */
>>  ff_dlog(ctx, "Unknown command 0x%hhx 0x%hhx\n", hi, lo);
>>  }
>> -
>> -/* set prev command */
>> -ctx->prev_cmd[0] = hi;
>> -ctx->prev_cmd[1] = lo;
>>  }
>>
>>  static int decode(AVCodecContext *avctx, void *data, int *got_sub,
>> AVPacket *avpkt)
>> --
>> 2.5.3
>>
>>
> This commit seems to break some US broadcast CC decoding. (I can provide a
> 15MB sample file if needed)
>
> Before this commit:
> ffmpeg -f lavfi -i "movie=IhedxzUUxNo.ts[out0+subcc]" -map s "ts.srt"
> cat ts.srt
> 1
> 00:00:01,035 --> 00:00:02,035
> FAR-RANGING IMPACT PLACES IN THE
>
> 2
> 00:00:02,036 --> 00:00:04,466
> FAR-RANGING IMPACT PLACES IN THE
> CHURCH AND AT THE LEVEL OF
>
> 3
> 00:00:04,471 --> 00:00:06,811
> CHURCH AND AT THE LEVEL OF
> POLICY ALL ACROSS THE GLOBE.
>
> 4
> 00:00:06,807 --> 00:00:08,537
> POLICY ALL ACROSS THE GLOBE.
> CERTAINLY IN THE AREA OF
>
> 5
> 00:00:08,542 --> 00:00:10,382
> CERTAINLY IN THE AREA OF
> PASTORAL CARE, I HOPE THAT IT
>
> 6
> 00:00:10,377 --> 00:00:14,677
> PASTORAL CARE, I HOPE THAT IT
> WILL LEAD TO LESS DOGMATICTI
>
> 7
> 00:00:14,682 --> 00:00:16,352
> WILL LEAD TO LESS DOGMATICTI
> INTERACTION WITH PEOPLE ACROSS A
>
> 8
> 00:00:16,350 --> 00:00:16,920
> INTERACTION WITH PEOPLE ACROSS A
> THE BOARD.
>
> 9
> 00:00:16,917 --> 00:00:18,287
> THE BOARD.
> I HOPE THAT, YOU KNOW, THERE'S
>
> 10
> 00:00:18,285 --> 00:00:20,785
> I HOPE THAT, YOU KNOW, THERE'S
> MORE OF A SENSE THAT THE CHURCH
>
>
>
> After that commit,
> cat ts.srt
> 1
> 00:00:01,035 --> 00:00:02,035
> FFFARARAR-R-R-RANANANGIGIGINGNGN
>
> 2
> 00:00:02,036 --> 00:00:04,466
> FFFARARAR-R-R-RANANANGIGIGINGNGN
> CCCHUHUHURCRCRCHHH A A ANNND D D
>
> 3
> 00:00:04,471 --> 00:00:06,811
> CCCHUHUHURCRCRCHHH A A ANNND D D
> POPOPOLILILICYCYCY A A A L L
>
> 4
> 00:00:06,807 --> 00:00:08,537
> POPOPOLILILICYCYCY A A A L L
> CCCERERERTATATAINININLYLYLY I I 
>
> 5
> 00:00:08,542 --> 00:00:10,382
> CCCERERERTATATAINININLYLYLY I I
> PAPAPASSSTOTOTORARARALLL C C CAA
>
> 6
> 00:00:10,377 --> 00:00:14,677
> PAPAPASSSTOTOTORARARALLL C C CAA
> WIWIWILL   LELELEADADAD   TO
>
> 7
> 00:00:14,682 --> 00:00:16,352
> WIWIWILL   LELELEADADAD   TO
> INININTETETERARARACTCTCTIOIOION 
>
> 8
> 00:00:16,350 --> 00:00:16,920
> INININTETETERARARACTCTCTIOIOION
> THTHTHE E E BOBOBOAAARDRDRD...
>
> 9
> 00:00:16,917 --> 00:00:18,287
> THTHTHE E E BOBOBOAAARDRDRD...
> I I I HHHOPOPOPEEE T T THHHATATA
>
> 10
> 00:00:18,285 

Re: [FFmpeg-devel] [PATCH 6/6] lossless audio dsp: unroll

[James Almer]

On 4/18/2016 2:52 PM, Christophe Gisquet wrote:
> 2016-04-18 19:15 GMT+02:00 James Almer :
>> On 4/18/2016 10:07 AM, Christophe Gisquet wrote:
>>> The loops are guaranteed to be at least multiples of 8, so this
>>> unrolling is safe but allows exploiting execution ports.
>>>
>>> For int32 version: 72 -> 57c.
>>
>> What compiler are you using, and what cpu at configure time?
> 
> gcc 5.1, Win64, haswell. I don't use mingw64 compiler.
> 
>> We're currently enabling tree vectorization for gcc 4.9 or newer on x86,
>> and at least with gcc 5.3.0 on mingw-w64 the resulting code now seems worse.
>> I didn't bench it, but after this patch it's not being vectorized anymore.
> 
> The code I benchmarked as being 72c is vectorized and keeps being
> vectorized here. It actually looks better than the previously
> vectorized one.
> 
> The 16_c version is no longer vectorized, but is really a mess here
> when vectorized.

The 16_c one isn't important since we have sse2 and even mmxext versions. But
you're right the 32_c one remains vectorized, even when targeting http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/6] x86: lossless audio: SSE4 madd 32bits

[Christophe Gisquet]

2016-04-18 21:18 GMT+02:00 Michael Niedermayer :
> this breaks (only noise)
> \[CCCP\]_Mega_Weird_Audio_Test.mkv track 23

Worthwhile sample.

I rewrote the patch to reduce code duplication, and I fixed the issue
(misread a shift).

-- 
Christophe
From a0d4a96c032d73bc0e34fec320497aefafba3c28 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet 
Date: Mon, 18 Apr 2016 13:20:07 +0200
Subject: [PATCH 5/7] x86: lossless audio: SSE4 madd 32bits

The unique user so far is wmalossless 24bits. The few samples tested show an
order of 8, so more unrolling or an avx2 version do not make sense.

Timings: 72 -> 49 cycles
---
 libavcodec/x86/lossless_audiodsp.asm| 31 +--
 libavcodec/x86/lossless_audiodsp_init.c |  7 +++
 2 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/libavcodec/x86/lossless_audiodsp.asm b/libavcodec/x86/lossless_audiodsp.asm
index 5597dad..d00869b 100644
--- a/libavcodec/x86/lossless_audiodsp.asm
+++ b/libavcodec/x86/lossless_audiodsp.asm
@@ -22,13 +22,17 @@
 
 SECTION .text
 
-%macro SCALARPRODUCT 0
+%macro SCALARPRODUCT 1
 ; int ff_scalarproduct_and_madd_int16(int16_t *v1, int16_t *v2, int16_t *v3,
 ; int order, int mul)
-cglobal scalarproduct_and_madd_int16, 4,4,8, v1, v2, v3, order, mul
-shl orderq, 1
+; int ff_scalarproduct_and_madd_int32(int32_t *v1, int32_t *v2, int32_t *v3,
+; int order, int mul)
+cglobal scalarproduct_and_madd_int %+ %1, 4,4,8, v1, v2, v3, order, mul
+shl orderq, (%1/16)
 movdm7, mulm
-%if mmsize == 16
+%if %1 == 32
+SPLATD  m7
+%elif mmsize == 16
 pshuflw m7, m7, 0
 punpcklqdq m7, m7
 %else
@@ -46,14 +50,26 @@ cglobal scalarproduct_and_madd_int16, 4,4,8, v1, v2, v3, order, mul
 movam5, [v1q + orderq + mmsize]
 movum2, [v3q + orderq]
 movum3, [v3q + orderq + mmsize]
+%if %1 == 32
+pmulld  m0, m4
+pmulld  m1, m5
+pmulld  m2, m7
+pmulld  m3, m7
+%else
 pmaddwd m0, m4
 pmaddwd m1, m5
 pmullw  m2, m7
 pmullw  m3, m7
+%endif
 paddd   m6, m0
 paddd   m6, m1
+%if %1 == 32
+paddd   m2, m4
+paddd   m3, m5
+%else
 paddw   m2, m4
 paddw   m3, m5
+%endif
 mova[v1q + orderq], m2
 mova[v1q + orderq + mmsize], m3
 add orderq, mmsize*2
@@ -64,9 +80,12 @@ cglobal scalarproduct_and_madd_int16, 4,4,8, v1, v2, v3, order, mul
 %endmacro
 
 INIT_MMX mmxext
-SCALARPRODUCT
+SCALARPRODUCT 16
 INIT_XMM sse2
-SCALARPRODUCT
+SCALARPRODUCT 16
+
+INIT_XMM sse4
+SCALARPRODUCT 32
 
 %macro SCALARPRODUCT_LOOP 1
 align 16
diff --git a/libavcodec/x86/lossless_audiodsp_init.c b/libavcodec/x86/lossless_audiodsp_init.c
index 197173c..85306cb 100644
--- a/libavcodec/x86/lossless_audiodsp_init.c
+++ b/libavcodec/x86/lossless_audiodsp_init.c
@@ -31,6 +31,10 @@ int32_t ff_scalarproduct_and_madd_int16_ssse3(int16_t *v1, const int16_t *v2,
   const int16_t *v3,
   int order, int mul);
 
+int32_t ff_scalarproduct_and_madd_int32_sse4(int32_t *v1, const int32_t *v2,
+ const int32_t *v3,
+ int order, int mul);
+
 av_cold void ff_llauddsp_init_x86(LLAudDSPContext *c)
 {
 #if HAVE_YASM
@@ -45,5 +49,8 @@ av_cold void ff_llauddsp_init_x86(LLAudDSPContext *c)
 if (EXTERNAL_SSSE3(cpu_flags) &&
 !(cpu_flags & (AV_CPU_FLAG_SSE42 | AV_CPU_FLAG_3DNOW))) // cachesplit
 c->scalarproduct_and_madd_int16 = ff_scalarproduct_and_madd_int16_ssse3;
+
+if (EXTERNAL_SSE4(cpu_flags))
+c->scalarproduct_and_madd_int32 = ff_scalarproduct_and_madd_int32_sse4;
 #endif
 }
-- 
2.8.1

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

Re: [FFmpeg-devel] [PATCH 1/6] fate: wma: add lossless 24bits test

[Christophe Gisquet]

2016-04-18 22:22 GMT+02:00 Christophe Gisquet :
> 2016-04-18 19:11 GMT+02:00 James Almer :
>> No way to create one using existing 24bit audio currently available in fate
>> or any redistributable 24 audio out there?
>> There are some dts-ma and truehd multichannel samples that are not sine 
>> waves.
>
> You're right. Just did that, except the encoder doesn't like the 7.1
> configuration.

Except this nice true 24bits sample didn't exhibit the issue found by
Michael (where the audio is coded as 24bits, but probably isn't).

Extracting a few wma packets from thefile is sufficient to show the
issue, generating a file that's 30KB.

Because of this, I would favour this sample over a true 24 bits
sample. Another option would be to add those 2 tests.

Opinions?

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

Re: [FFmpeg-devel] [PATCH] Add test for 012v codec

[Michael Niedermayer]

On Mon, Apr 18, 2016 at 05:05:01PM +, Petru Rares Sincraian wrote:
> 
> Hi there,
> 
> Here is a patch for 012v codec. You can download the sample file here: 
> https://drive.google.com/open?id=0ByhGgswO8BQcSDc0S3RONHFuN0k
> It is supposed to be in $(TARGET_SAMPLES)/012v/sample.avi.
> 
> md5: e07bb155180c0140960ea4deb6cdf6b6

>  fate/video.mak |3 +++
>  ref/fate/012v  |6 ++
>  2 files changed, 9 insertions(+)
> b039cc2a9b23a20f6eb5ba162e7a5d528915a2cc  0001-Add-test-for-012v-codec.patch
> From 418b709c534628781f24f25055c4c0e9c36ad6d1 Mon Sep 17 00:00:00 2001
> From: Petru Rares Sincraian 
> Date: Mon, 18 Apr 2016 18:52:51 +0200
> Subject: [PATCH] Add test for 012v codec

added "-pix_fmt yuv422p16le" (was found to be needed on MIPS as it
would return yuv422p16be and result in different checksum than 0xc5439580

file uploaded
applied
thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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/6] fate: wma: add lossless 24bits test

[Christophe Gisquet]

Hi,

2016-04-18 19:11 GMT+02:00 James Almer :
> No way to create one using existing 24bit audio currently available in fate
> or any redistributable 24 audio out there?
> There are some dts-ma and truehd multichannel samples that are not sine waves.

You're right. Just did that, except the encoder doesn't like the 7.1
configuration.

Because we're not testing the wma rematrixing, I changed that to stereo:
-i dts/master_audio_7.1_24bit.dts -af 'pan=stereo:c0=FL:c1=FR' -acodec pcm_s24le

The test file comes at 1.6MB, but fewer samples could be encoded.

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

Re: [FFmpeg-devel] [PATCH 5/6] x86: lossless audio: SSE4 madd 32bits

[Michael Niedermayer]

On Mon, Apr 18, 2016 at 03:07:30PM +0200, Christophe Gisquet wrote:
> The unique user so far is wmalossless 24bits. The few samples tested show an
> order of 8, so more unrolling or an avx2 version do not make sense.
> 
> Timings: 72 -> 49 cycles
> ---
>  libavcodec/x86/lossless_audiodsp.asm| 38 
> +
>  libavcodec/x86/lossless_audiodsp_init.c |  7 ++
>  2 files changed, 45 insertions(+)

this breaks (only noise)
\[CCCP\]_Mega_Weird_Audio_Test.mkv track 23


[...]
-- 
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 v3 1/2] lavc/ccaption_dec: do not ignore repeated character commands

[Thierry Foucu]

Hi all

On Sun, Feb 14, 2016 at 6:11 PM, Aman Gupta  wrote:

> From: Aman Gupta 
>
> control codes in a cc stream can be repeated, and must be ignored.
> however, repeated characters must not be ignored. the code attempted to
> wipe prev_cmd in handle_char to allow repeated characters to be
> processed, but prev_cmd would previously get reset _after_ handle_char()
>
> i also moved the prev_cmd reset out from handle_char() so it can be
> re-used for special character sets, which _must_ be ignored when
> repeated.
> ---
>  libavcodec/ccaption_dec.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
> index 790f071..5fb2ec6 100644
> --- a/libavcodec/ccaption_dec.c
> +++ b/libavcodec/ccaption_dec.c
> @@ -484,9 +484,6 @@ static void handle_char(CCaptionSubContext *ctx, char
> hi, char lo, int64_t pts)
>  if (ctx->mode != CCMODE_POPON)
>  ctx->screen_touched = 1;
>
> -/* reset prev command since character can repeat */
> -ctx->prev_cmd[0] = 0;
> -ctx->prev_cmd[1] = 0;
>  if (lo)
> ff_dlog(ctx, "(%c,%c)\n", hi, lo);
>  else
> @@ -497,8 +494,15 @@ static void process_cc608(CCaptionSubContext *ctx,
> int64_t pts, uint8_t hi, uint
>  {
>  if (hi == ctx->prev_cmd[0] && lo == ctx->prev_cmd[1]) {
>  /* ignore redundant command */
> -} else if ( (hi == 0x10 && (lo >= 0x40 && lo <= 0x5f)) ||
> -  ( (hi >= 0x11 && hi <= 0x17) && (lo >= 0x40 && lo <= 0x7f)
> ) ) {
> +return;
> +}
> +
> +/* set prev command */
> +ctx->prev_cmd[0] = hi;
> +ctx->prev_cmd[1] = lo;
> +
> +if ( (hi == 0x10 && (lo >= 0x40 && lo <= 0x5f)) ||
> +   ( (hi >= 0x11 && hi <= 0x17) && (lo >= 0x40 && lo <= 0x7f) ) ) {
>  handle_pac(ctx, hi, lo);
>  } else if ( ( hi == 0x11 && lo >= 0x20 && lo <= 0x2f ) ||
>  ( hi == 0x17 && lo >= 0x2e && lo <= 0x2f) ) {
> @@ -559,14 +563,11 @@ static void process_cc608(CCaptionSubContext *ctx,
> int64_t pts, uint8_t hi, uint
>  } else if (hi >= 0x20) {
>  /* Standard characters (always in pairs) */
>  handle_char(ctx, hi, lo, pts);
> +ctx->prev_cmd[0] = ctx->prev_cmd[1] = 0;
>  } else {
>  /* Ignoring all other non data code */
>  ff_dlog(ctx, "Unknown command 0x%hhx 0x%hhx\n", hi, lo);
>  }
> -
> -/* set prev command */
> -ctx->prev_cmd[0] = hi;
> -ctx->prev_cmd[1] = lo;
>  }
>
>  static int decode(AVCodecContext *avctx, void *data, int *got_sub,
> AVPacket *avpkt)
> --
> 2.5.3
>
>
This commit seems to break some US broadcast CC decoding. (I can provide a
15MB sample file if needed)

Before this commit:
ffmpeg -f lavfi -i "movie=IhedxzUUxNo.ts[out0+subcc]" -map s "ts.srt"
cat ts.srt
1
00:00:01,035 --> 00:00:02,035
FAR-RANGING IMPACT PLACES IN THE

2
00:00:02,036 --> 00:00:04,466
FAR-RANGING IMPACT PLACES IN THE
CHURCH AND AT THE LEVEL OF

3
00:00:04,471 --> 00:00:06,811
CHURCH AND AT THE LEVEL OF
POLICY ALL ACROSS THE GLOBE.

4
00:00:06,807 --> 00:00:08,537
POLICY ALL ACROSS THE GLOBE.
CERTAINLY IN THE AREA OF

5
00:00:08,542 --> 00:00:10,382
CERTAINLY IN THE AREA OF
PASTORAL CARE, I HOPE THAT IT

6
00:00:10,377 --> 00:00:14,677
PASTORAL CARE, I HOPE THAT IT
WILL LEAD TO LESS DOGMATICTI

7
00:00:14,682 --> 00:00:16,352
WILL LEAD TO LESS DOGMATICTI
INTERACTION WITH PEOPLE ACROSS A

8
00:00:16,350 --> 00:00:16,920
INTERACTION WITH PEOPLE ACROSS A
THE BOARD.

9
00:00:16,917 --> 00:00:18,287
THE BOARD.
I HOPE THAT, YOU KNOW, THERE'S

10
00:00:18,285 --> 00:00:20,785
I HOPE THAT, YOU KNOW, THERE'S
MORE OF A SENSE THAT THE CHURCH



After that commit,
cat ts.srt
1
00:00:01,035 --> 00:00:02,035
FFFARARAR-R-R-RANANANGIGIGINGNGN

2
00:00:02,036 --> 00:00:04,466
FFFARARAR-R-R-RANANANGIGIGINGNGN
CCCHUHUHURCRCRCHHH A A ANNND D D

3
00:00:04,471 --> 00:00:06,811
CCCHUHUHURCRCRCHHH A A ANNND D D
POPOPOLILILICYCYCY A A A L L

4
00:00:06,807 --> 00:00:08,537
POPOPOLILILICYCYCY A A A L L
CCCERERERTATATAINININLYLYLY I I 

5
00:00:08,542 --> 00:00:10,382
CCCERERERTATATAINININLYLYLY I I
PAPAPASSSTOTOTORARARALLL C C CAA

6
00:00:10,377 --> 00:00:14,677
PAPAPASSSTOTOTORARARALLL C C CAA
WIWIWILL   LELELEADADAD   TO

7
00:00:14,682 --> 00:00:16,352
WIWIWILL   LELELEADADAD   TO
INININTETETERARARACTCTCTIOIOION 

8
00:00:16,350 --> 00:00:16,920
INININTETETERARARACTCTCTIOIOION
THTHTHE E E BOBOBOAAARDRDRD...

9
00:00:16,917 --> 00:00:18,287
THTHTHE E E BOBOBOAAARDRDRD...
I I I HHHOPOPOPEEE T T THHHATATA

10
00:00:18,285 --> 00:00:20,785
I I I HHHOPOPOPEEE T T THHHATATA
MOMOMORRRE E E OFOFOF A A A   SE



> ___
> 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 2/6] wmalossless: allow calling madd_int16

[Christophe Gisquet]

Hi,

2016-04-18 20:09 GMT+02:00 Michael Niedermayer :
> On Mon, Apr 18, 2016 at 03:07:27PM +0200, Christophe Gisquet wrote:
>> This is done by actually handling the cascaded LMS data as if it
>> were int16_t, thus requiring switching at various locations the
>> computations.
>> ---
>>  libavcodec/wmalosslessdec.c | 61 
>> +
>>  1 file changed, 61 insertions(+)
>
> this causes a few new warnings

Yeah, I focused on the macro'ed version. If this one is favoured
instead, then I'll come back to it.

Otherwise, I'll squash the 3 patches, probably.

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

Re: [FFmpeg-devel] [PATCH 2/6] wmalossless: allow calling madd_int16

[Michael Niedermayer]

On Mon, Apr 18, 2016 at 03:07:27PM +0200, Christophe Gisquet wrote:
> This is done by actually handling the cascaded LMS data as if it
> were int16_t, thus requiring switching at various locations the
> computations.
> ---
>  libavcodec/wmalosslessdec.c | 61 
> +
>  1 file changed, 61 insertions(+)

this causes a few new warnings

libavcodec/wmalosslessdec.c: In function ‘lms_update’:
libavcodec/wmalosslessdec.c:739:31: warning: initialization from incompatible 
pointer type [enabled by default]
libavcodec/wmalosslessdec.c:740:28: warning: initialization from incompatible 
pointer type [enabled by default]
libavcodec/wmalosslessdec.c: In function ‘revert_cdlms’:
libavcodec/wmalosslessdec.c:829:31: warning: initialization from incompatible 
pointer type [enabled by default]
libavcodec/wmalosslessdec.c:830:35: warning: initialization from incompatible 
pointer type [enabled by default]
libavcodec/wmalosslessdec.c:831:32: warning: initialization from incompatible 
pointer type [enabled by default]

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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

Re: [FFmpeg-devel] [PATCH 6/6] lossless audio dsp: unroll

[Christophe Gisquet]

2016-04-18 19:15 GMT+02:00 James Almer :
> On 4/18/2016 10:07 AM, Christophe Gisquet wrote:
>> The loops are guaranteed to be at least multiples of 8, so this
>> unrolling is safe but allows exploiting execution ports.
>>
>> For int32 version: 72 -> 57c.
>
> What compiler are you using, and what cpu at configure time?

gcc 5.1, Win64, haswell. I don't use mingw64 compiler.

> We're currently enabling tree vectorization for gcc 4.9 or newer on x86,
> and at least with gcc 5.3.0 on mingw-w64 the resulting code now seems worse.
> I didn't bench it, but after this patch it's not being vectorized anymore.

The code I benchmarked as being 72c is vectorized and keeps being
vectorized here. It actually looks better than the previously
vectorized one.

The 16_c version is no longer vectorized, but is really a mess here
when vectorized.

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

Re: [FFmpeg-devel] [PATCH 1/6] fate: wma: add lossless 24bits test

[James Almer]

On 4/18/2016 1:48 PM, Christophe Gisquet wrote:
> 2016-04-18 18:39 GMT+02:00 Paul B Mahol :
>> Better to have real 24bit content.
> 
> Yeah, my point, but I'm not sure we'll get one redistribuable in fate,
> eg by pinging people from the various tickets.
> 
> And when would we decide this is better than nothing?

No way to create one using existing 24bit audio currently available in fate
or any redistributable 24 audio out there?
There are some dts-ma and truehd multichannel samples that are not sine waves.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/4] x86inc: Enable AVX emulation in additional cases

[Henrik Gramner]

From: Anton Mitrofanov 

Allows emulation to work when dst is equal to src2 as long as the
instruction is commutative, e.g. `addps m0, m1, m0`.
---
 libavutil/x86/x86inc.asm | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 0bcfeb3..b2e9c60 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -1130,14 +1130,12 @@ INIT_XMM
 %if __emulate_avx
 %xdefine __src1 %7
 %xdefine __src2 %8
-%ifnidn %6, %7
-%if %0 >= 9
-CHECK_AVX_INSTR_EMU {%1 %6, %7, %8, %9}, %6, %8, %9
-%else
-CHECK_AVX_INSTR_EMU {%1 %6, %7, %8}, %6, %8
-%endif
-%if %5 && %4 == 0
-%ifnnum sizeof%8
+%if %5 && %4 == 0
+%ifnidn %6, %7
+%ifidn %6, %8
+%xdefine __src1 %8
+%xdefine __src2 %7
+%elifnnum sizeof%8
 ; 3-operand AVX instructions with a memory arg can only 
have it in src2,
 ; whereas SSE emulation prefers to have it in src1 (i.e. 
the mov).
 ; So, if the instruction is commutative with a memory arg, 
swap them.
@@ -1145,6 +1143,13 @@ INIT_XMM
 %xdefine __src2 %7
 %endif
 %endif
+%endif
+%ifnidn %6, __src1
+%if %0 >= 9
+CHECK_AVX_INSTR_EMU {%1 %6, %7, %8, %9}, %6, __src2, %9
+%else
+CHECK_AVX_INSTR_EMU {%1 %6, %7, %8}, %6, __src2
+%endif
 %if __sizeofreg == 8
 MOVQ %6, __src1
 %elif %3
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 3/4] x86inc: Improve handling of %ifid with multi-token parameters

[Henrik Gramner]

From: Anton Mitrofanov 

The yasm/nasm preprocessor only checks the first token, which means that
parameters such as `dword [rax]` are treated as identifiers, which is
generally not what we want.
---
 libavutil/x86/x86inc.asm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index a53477b..0bcfeb3 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -1137,7 +1137,7 @@ INIT_XMM
 CHECK_AVX_INSTR_EMU {%1 %6, %7, %8}, %6, %8
 %endif
 %if %5 && %4 == 0
-%ifnid %8
+%ifnnum sizeof%8
 ; 3-operand AVX instructions with a memory arg can only 
have it in src2,
 ; whereas SSE emulation prefers to have it in src1 (i.e. 
the mov).
 ; So, if the instruction is commutative with a memory arg, 
swap them.
@@ -1501,7 +1501,7 @@ FMA_INSTR pmadcswd, pmaddwd, paddd
 v%5%6 %1, %2, %3, %4
 %elifidn %1, %2
 ; If %3 or %4 is a memory operand it needs to be encoded as 
the last operand.
-%ifid %3
+%ifnum sizeof%3
 v%{5}213%6 %2, %3, %4
 %else
 v%{5}132%6 %2, %4, %3
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 0/4] x86inc: Sync changes from x264

[Henrik Gramner]

Anton Mitrofanov (3):
  x86inc: Fix AVX emulation of some instructions
  x86inc: Improve handling of %ifid with multi-token parameters
  x86inc: Enable AVX emulation in additional cases

Henrik Gramner (1):
  x86inc: Fix AVX emulation of scalar float instructions

 libavutil/x86/x86inc.asm | 95 ++--
 1 file changed, 52 insertions(+), 43 deletions(-)

-- 
1.9.1

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

[FFmpeg-devel] [PATCH 2/4] x86inc: Fix AVX emulation of some instructions

[Henrik Gramner]

From: Anton Mitrofanov 

---
 libavutil/x86/x86inc.asm | 44 
 1 file changed, 24 insertions(+), 20 deletions(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 22608ea..a53477b 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -1097,7 +1097,7 @@ INIT_XMM
 ;%1 == instruction
 ;%2 == minimal instruction set
 ;%3 == 1 if float, 0 if int
-;%4 == 1 if non-destructive or 4-operand (xmm, xmm, xmm, imm), 0 otherwise
+;%4 == 1 if 4-operand emulation, 0 if 3-operand emulation, 255 otherwise (no 
emulation)
 ;%5 == 1 if commutative (i.e. doesn't matter which src arg is which), 0 if not
 ;%6+: operands
 %macro RUN_AVX_INSTR 6-9+
@@ -1172,9 +1172,9 @@ INIT_XMM
 ;%1 == instruction
 ;%2 == minimal instruction set
 ;%3 == 1 if float, 0 if int
-;%4 == 1 if non-destructive or 4-operand (xmm, xmm, xmm, imm), 0 otherwise
+;%4 == 1 if 4-operand emulation, 0 if 3-operand emulation, 255 otherwise (no 
emulation)
 ;%5 == 1 if commutative (i.e. doesn't matter which src arg is which), 0 if not
-%macro AVX_INSTR 1-5 fnord, 0, 1, 0
+%macro AVX_INSTR 1-5 fnord, 0, 255, 0
 %macro %1 1-10 fnord, fnord, fnord, fnord, %1, %2, %3, %4, %5
 %ifidn %2, fnord
 RUN_AVX_INSTR %6, %7, %8, %9, %10, %1
@@ -1208,10 +1208,10 @@ AVX_INSTR andnpd, sse2, 1, 0, 0
 AVX_INSTR andnps, sse, 1, 0, 0
 AVX_INSTR andpd, sse2, 1, 0, 1
 AVX_INSTR andps, sse, 1, 0, 1
-AVX_INSTR blendpd, sse4, 1, 0, 0
-AVX_INSTR blendps, sse4, 1, 0, 0
-AVX_INSTR blendvpd, sse4, 1, 0, 0
-AVX_INSTR blendvps, sse4, 1, 0, 0
+AVX_INSTR blendpd, sse4, 1, 1, 0
+AVX_INSTR blendps, sse4, 1, 1, 0
+AVX_INSTR blendvpd, sse4 ; can't be emulated
+AVX_INSTR blendvps, sse4 ; can't be emulated
 AVX_INSTR cmppd, sse2, 1, 1, 0
 AVX_INSTR cmpps, sse, 1, 1, 0
 AVX_INSTR cmpsd, sse2, 1, 1, 0
@@ -1282,7 +1282,7 @@ AVX_INSTR movsldup, sse3
 AVX_INSTR movss, sse, 1, 0, 0
 AVX_INSTR movupd, sse2
 AVX_INSTR movups, sse
-AVX_INSTR mpsadbw, sse4
+AVX_INSTR mpsadbw, sse4, 0, 1, 0
 AVX_INSTR mulpd, sse2, 1, 0, 1
 AVX_INSTR mulps, sse, 1, 0, 1
 AVX_INSTR mulsd, sse2, 1, 0, 0
@@ -1304,14 +1304,18 @@ AVX_INSTR paddsb, mmx, 0, 0, 1
 AVX_INSTR paddsw, mmx, 0, 0, 1
 AVX_INSTR paddusb, mmx, 0, 0, 1
 AVX_INSTR paddusw, mmx, 0, 0, 1
-AVX_INSTR palignr, ssse3
+AVX_INSTR palignr, ssse3, 0, 1, 0
 AVX_INSTR pand, mmx, 0, 0, 1
 AVX_INSTR pandn, mmx, 0, 0, 0
 AVX_INSTR pavgb, mmx2, 0, 0, 1
 AVX_INSTR pavgw, mmx2, 0, 0, 1
-AVX_INSTR pblendvb, sse4, 0, 0, 0
-AVX_INSTR pblendw, sse4
-AVX_INSTR pclmulqdq
+AVX_INSTR pblendvb, sse4 ; can't be emulated
+AVX_INSTR pblendw, sse4, 0, 1, 0
+AVX_INSTR pclmulqdq, fnord, 0, 1, 0
+AVX_INSTR pclmulhqhqdq, fnord, 0, 0, 0
+AVX_INSTR pclmulhqlqdq, fnord, 0, 0, 0
+AVX_INSTR pclmullqhqdq, fnord, 0, 0, 0
+AVX_INSTR pclmullqlqdq, fnord, 0, 0, 0
 AVX_INSTR pcmpestri, sse42
 AVX_INSTR pcmpestrm, sse42
 AVX_INSTR pcmpistri, sse42
@@ -1335,10 +1339,10 @@ AVX_INSTR phminposuw, sse4
 AVX_INSTR phsubw, ssse3, 0, 0, 0
 AVX_INSTR phsubd, ssse3, 0, 0, 0
 AVX_INSTR phsubsw, ssse3, 0, 0, 0
-AVX_INSTR pinsrb, sse4
-AVX_INSTR pinsrd, sse4
-AVX_INSTR pinsrq, sse4
-AVX_INSTR pinsrw, mmx2
+AVX_INSTR pinsrb, sse4, 0, 1, 0
+AVX_INSTR pinsrd, sse4, 0, 1, 0
+AVX_INSTR pinsrq, sse4, 0, 1, 0
+AVX_INSTR pinsrw, mmx2, 0, 1, 0
 AVX_INSTR pmaddwd, mmx, 0, 0, 1
 AVX_INSTR pmaddubsw, ssse3, 0, 0, 0
 AVX_INSTR pmaxsb, sse4, 0, 0, 1
@@ -1410,18 +1414,18 @@ AVX_INSTR punpcklwd, mmx, 0, 0, 0
 AVX_INSTR punpckldq, mmx, 0, 0, 0
 AVX_INSTR punpcklqdq, sse2, 0, 0, 0
 AVX_INSTR pxor, mmx, 0, 0, 1
-AVX_INSTR rcpps, sse, 1, 0, 0
+AVX_INSTR rcpps, sse
 AVX_INSTR rcpss, sse, 1, 0, 0
 AVX_INSTR roundpd, sse4
 AVX_INSTR roundps, sse4
 AVX_INSTR roundsd, sse4, 1, 1, 0
 AVX_INSTR roundss, sse4, 1, 1, 0
-AVX_INSTR rsqrtps, sse, 1, 0, 0
+AVX_INSTR rsqrtps, sse
 AVX_INSTR rsqrtss, sse, 1, 0, 0
 AVX_INSTR shufpd, sse2, 1, 1, 0
 AVX_INSTR shufps, sse, 1, 1, 0
-AVX_INSTR sqrtpd, sse2, 1, 0, 0
-AVX_INSTR sqrtps, sse, 1, 0, 0
+AVX_INSTR sqrtpd, sse2
+AVX_INSTR sqrtps, sse
 AVX_INSTR sqrtsd, sse2, 1, 0, 0
 AVX_INSTR sqrtss, sse, 1, 0, 0
 AVX_INSTR stmxcsr, sse
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 1/4] x86inc: Fix AVX emulation of scalar float instructions

[Henrik Gramner]

Those instructions are not commutative since they only change the first
element in the vector and leave the rest unmodified.
---
 libavutil/x86/x86inc.asm | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 3a0a261..22608ea 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -1194,8 +1194,8 @@ INIT_XMM
 ; Non-destructive instructions are written without parameters
 AVX_INSTR addpd, sse2, 1, 0, 1
 AVX_INSTR addps, sse, 1, 0, 1
-AVX_INSTR addsd, sse2, 1, 0, 1
-AVX_INSTR addss, sse, 1, 0, 1
+AVX_INSTR addsd, sse2, 1, 0, 0
+AVX_INSTR addss, sse, 1, 0, 0
 AVX_INSTR addsubpd, sse3, 1, 0, 0
 AVX_INSTR addsubps, sse3, 1, 0, 0
 AVX_INSTR aesdec, aesni, 0, 0, 0
@@ -1225,10 +1225,10 @@ AVX_INSTR cvtpd2ps, sse2
 AVX_INSTR cvtps2dq, sse2
 AVX_INSTR cvtps2pd, sse2
 AVX_INSTR cvtsd2si, sse2
-AVX_INSTR cvtsd2ss, sse2
-AVX_INSTR cvtsi2sd, sse2
-AVX_INSTR cvtsi2ss, sse
-AVX_INSTR cvtss2sd, sse2
+AVX_INSTR cvtsd2ss, sse2, 1, 0, 0
+AVX_INSTR cvtsi2sd, sse2, 1, 0, 0
+AVX_INSTR cvtsi2ss, sse, 1, 0, 0
+AVX_INSTR cvtss2sd, sse2, 1, 0, 0
 AVX_INSTR cvtss2si, sse
 AVX_INSTR cvttpd2dq, sse2
 AVX_INSTR cvttps2dq, sse2
@@ -1251,12 +1251,12 @@ AVX_INSTR ldmxcsr, sse
 AVX_INSTR maskmovdqu, sse2
 AVX_INSTR maxpd, sse2, 1, 0, 1
 AVX_INSTR maxps, sse, 1, 0, 1
-AVX_INSTR maxsd, sse2, 1, 0, 1
-AVX_INSTR maxss, sse, 1, 0, 1
+AVX_INSTR maxsd, sse2, 1, 0, 0
+AVX_INSTR maxss, sse, 1, 0, 0
 AVX_INSTR minpd, sse2, 1, 0, 1
 AVX_INSTR minps, sse, 1, 0, 1
-AVX_INSTR minsd, sse2, 1, 0, 1
-AVX_INSTR minss, sse, 1, 0, 1
+AVX_INSTR minsd, sse2, 1, 0, 0
+AVX_INSTR minss, sse, 1, 0, 0
 AVX_INSTR movapd, sse2
 AVX_INSTR movaps, sse
 AVX_INSTR movd, mmx
@@ -1285,8 +1285,8 @@ AVX_INSTR movups, sse
 AVX_INSTR mpsadbw, sse4
 AVX_INSTR mulpd, sse2, 1, 0, 1
 AVX_INSTR mulps, sse, 1, 0, 1
-AVX_INSTR mulsd, sse2, 1, 0, 1
-AVX_INSTR mulss, sse, 1, 0, 1
+AVX_INSTR mulsd, sse2, 1, 0, 0
+AVX_INSTR mulss, sse, 1, 0, 0
 AVX_INSTR orpd, sse2, 1, 0, 1
 AVX_INSTR orps, sse, 1, 0, 1
 AVX_INSTR pabsb, ssse3
@@ -1414,8 +1414,8 @@ AVX_INSTR rcpps, sse, 1, 0, 0
 AVX_INSTR rcpss, sse, 1, 0, 0
 AVX_INSTR roundpd, sse4
 AVX_INSTR roundps, sse4
-AVX_INSTR roundsd, sse4
-AVX_INSTR roundss, sse4
+AVX_INSTR roundsd, sse4, 1, 1, 0
+AVX_INSTR roundss, sse4, 1, 1, 0
 AVX_INSTR rsqrtps, sse, 1, 0, 0
 AVX_INSTR rsqrtss, sse, 1, 0, 0
 AVX_INSTR shufpd, sse2, 1, 1, 0
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH 6/6] lossless audio dsp: unroll

[James Almer]

On 4/18/2016 10:07 AM, Christophe Gisquet wrote:
> The loops are guaranteed to be at least multiples of 8, so this
> unrolling is safe but allows exploiting execution ports.
> 
> For int32 version: 72 -> 57c.

What compiler are you using, and what cpu at configure time?

We're currently enabling tree vectorization for gcc 4.9 or newer on x86,
and at least with gcc 5.3.0 on mingw-w64 the resulting code now seems worse.
I didn't bench it, but after this patch it's not being vectorized anymore.

> ---
>  libavcodec/lossless_audiodsp.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/lossless_audiodsp.c b/libavcodec/lossless_audiodsp.c
> index 55495d0..17a61cd 100644
> --- a/libavcodec/lossless_audiodsp.c
> +++ b/libavcodec/lossless_audiodsp.c
> @@ -29,10 +29,12 @@ static int32_t scalarproduct_and_madd_int16_c(int16_t 
> *v1, const int16_t *v2,
>  {
>  int res = 0;
>  
> -while (order--) {
> +do {
>  res   += *v1 * *v2++;
>  *v1++ += mul * *v3++;
> -}
> +res   += *v1 * *v2++;
> +*v1++ += mul * *v3++;
> +} while (order-=2);
>  return res;
>  }
>  
> @@ -42,10 +44,12 @@ static int32_t scalarproduct_and_madd_int32_c(int32_t 
> *v1, const int32_t *v2,
>  {
>  int res = 0;
>  
> -while (order--) {
> +do {
> +res   += *v1 * *v2++;
> +*v1++ += mul * *v3++;
>  res   += *v1 * *v2++;
>  *v1++ += mul * *v3++;
> -}
> +} while (order-=2);
>  return res;
>  }
>  
> 

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

[FFmpeg-devel] [PATCH] Add test for 012v codec

[Petru Rares Sincraian]

Hi there,

Here is a patch for 012v codec. You can download the sample file here: 
https://drive.google.com/open?id=0ByhGgswO8BQcSDc0S3RONHFuN0k
It is supposed to be in $(TARGET_SAMPLES)/012v/sample.avi.

md5: e07bb155180c0140960ea4deb6cdf6b6From 418b709c534628781f24f25055c4c0e9c36ad6d1 Mon Sep 17 00:00:00 2001
From: Petru Rares Sincraian 
Date: Mon, 18 Apr 2016 18:52:51 +0200
Subject: [PATCH] Add test for 012v codec

---
 tests/fate/video.mak | 3 +++
 tests/ref/fate/012v  | 6 ++
 2 files changed, 9 insertions(+)
 create mode 100644 tests/ref/fate/012v

diff --git a/tests/fate/video.mak b/tests/fate/video.mak
index dd24d28..ab7d0b2 100644
--- a/tests/fate/video.mak
+++ b/tests/fate/video.mak
@@ -7,6 +7,9 @@ fate-4xm-2: CMD = framecrc -i $(TARGET_SAMPLES)/4xm/version2.4xm -pix_fmt rgb24
 FATE_VIDEO-$(call DEMDEC, FOURXM, FOURXM) += $(FATE_4XM)
 fate-4xm: $(FATE_4XM)
 
+FATE_VIDEO-$(call DEMDEC, AVI, ZERO12V) += fate-012v
+fate-012v: CMD = framecrc -i $(TARGET_SAMPLES)/012v/sample.avi
+
 FATE_VIDEO-$(call DEMDEC, AVI, AASC) += fate-aasc
 fate-aasc: CMD = framecrc -i $(TARGET_SAMPLES)/aasc/AASC-1.5MB.AVI -pix_fmt rgb24
 
diff --git a/tests/ref/fate/012v b/tests/ref/fate/012v
new file mode 100644
index 000..198bba3
--- /dev/null
+++ b/tests/ref/fate/012v
@@ -0,0 +1,6 @@
+#tb 0: 1/10
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 316x240
+#sar 0: 0/1
+0,  0,  0,1,   303360, 0xc5439580
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH 1/6] fate: wma: add lossless 24bits test

[Christophe Gisquet]

2016-04-18 18:39 GMT+02:00 Paul B Mahol :
> Better to have real 24bit content.

Yeah, my point, but I'm not sure we'll get one redistribuable in fate,
eg by pinging people from the various tickets.

And when would we decide this is better than nothing?

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

Re: [FFmpeg-devel] [PATCH 1/6] fate: wma: add lossless 24bits test

[Paul B Mahol]

Dana 18. 4. 2016. 18:17 osoba "Christophe Gisquet" <
christophe.gisq...@gmail.com> napisala je:
>
> 2016-04-18 15:07 GMT+02:00 Christophe Gisquet <
christophe.gisq...@gmail.com>:
> > +fate-lossless-wma24: CMD = md5 -i
$(TARGET_SAMPLES)/lossless-audio/luckynight-partial-24.wma -f s24le -frames
209
>
> Btw, this is the regular luckynight whose samples have been shifted
> into 24 bits. Another type of bitdepth increase would be nice, but I
> haven't looked for it.
>
> For some reason, the default GUI doesn't let me select the bitdepth
> and downshifts to 16, so I had to resort to some command-line encoder.
>
> The sample is 1MB, and hasn't been uploaded yet.
>

Better to have real 24bit content.

> --
> Christophe
> ___
> 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 1/6] fate: wma: add lossless 24bits test

[Christophe Gisquet]

2016-04-18 15:07 GMT+02:00 Christophe Gisquet :
> +fate-lossless-wma24: CMD = md5 -i 
> $(TARGET_SAMPLES)/lossless-audio/luckynight-partial-24.wma -f s24le -frames 
> 209

Btw, this is the regular luckynight whose samples have been shifted
into 24 bits. Another type of bitdepth increase would be nice, but I
haven't looked for it.

For some reason, the default GUI doesn't let me select the bitdepth
and downshifts to 16, so I had to resort to some command-line encoder.

The sample is 1MB, and hasn't been uploaded yet.

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

Re: [FFmpeg-devel] [PATCH] Add test for mss1 codec

[Michael Niedermayer]

On Mon, Apr 18, 2016 at 03:11:45PM +, Petru Rares Sincraian wrote:
> Hi there,
> 
> Here I made a test for mss1 codec. The sample file for the FATE test can be 
> found at: 
> https://drive.google.com/file/d/0ByhGgswO8BQcRHJFU0VRWV9aSU0/view?usp=sharing

>  fate/microsoft.mak |6 
>  ref/fate/mss1-pal  | 1645 
> +
>  2 files changed, 1651 insertions(+)
> 9a50327fe6b1ba2a07e9b10ee40ee70fb2822fa8  0001-Add-test-for-mss1-codec.patch
> From 652d52f6d52a38ef25fa6d4446afd3f96b2d0280 Mon Sep 17 00:00:00 2001
> From: Petru Rares Sincraian 
> Date: Mon, 18 Apr 2016 17:03:01 +0200
> Subject: [PATCH] Add test for mss1 codec
> 
> The sample file for the FATE test is assumed to be stored as 
> $FATE_SAMPLES/mss1/screen_codec.wmv

sample shortened with dd  count=250
sample uploaded
tested n 32&64bit x86 and mips qemu, works applied

thanks

[...]

-- 
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] [PATCHv2] add signature filter for MPEG7 video signature

[Gerion Entrup]

On Samstag, 16. April 2016 05:16:04 CEST Michael Niedermayer wrote:
> On Sat, Apr 16, 2016 at 12:07:27AM +0200, Gerion Entrup wrote:
> > On Donnerstag, 14. April 2016 19:52:46 CEST Michael Niedermayer wrote:
> > > On Thu, Apr 14, 2016 at 07:06:29PM +0200, Gerion Entrup wrote:
> > > > On Montag, 11. April 2016 14:54:57 CEST Michael Niedermayer wrote:
> > > > > On Mon, Apr 11, 2016 at 02:30:37PM +0200, Gerion Entrup wrote:
> > > > > > On Montag, 11. April 2016 12:57:17 CEST Michael Niedermayer wrote:
> > > > > > > On Mon, Apr 11, 2016 at 04:25:28AM +0200, Gerion Entrup wrote:
> > > > > > > > On Donnerstag, 7. April 2016 00:35:25 CEST Michael Niedermayer 
> > > > > > > > wrote:
> > > > > > > > > On Wed, Mar 30, 2016 at 11:02:36PM +0200, Gerion Entrup wrote:
> > > > > > > > > > On Mittwoch, 30. März 2016 22:57:47 CEST Gerion Entrup 
> > > > > > > > > > wrote:
> > > > > > > > > > > Add improved patch.
> > > > > > > > > > 
> > > > > > > > > > Rebased to master.
> > > > > > > > > > 
> > > > > > > > > >  Changelog  |1
> > > > > > > > > >  configure  |1
> > > > > > > > > >  doc/filters.texi   |   70 +++
> > > > > > > > > >  libavfilter/Makefile   |1
> > > > > > > > > >  libavfilter/allfilters.c   |1
> > > > > > > > > >  libavfilter/signature.h|  554
> > > > > > > > > >  ++
> > > > > > > > > >  libavfilter/signature_lookup.c |  550
> > > > > > > > > >  ++
> > > > > > > > > >  libavfilter/version.h  |4
> > > > > > > > > >  libavfilter/vf_signature.c |  741
> > > > > > > > > >  + 9 files changed, 
> > > > > > > > > > 1921
> > > > > > > > > >  insertions(+), 2 deletions(-)
> > > > > > > > > > 
> > > > > > > > > > 9192f27ded45c607996b4e266b6746f807c9a7fd 
> > > > > > > > > > 0001-add-signature-filter-for-MPEG7-video-signature.patch 
> > > > > > > > > > From
> > > > > > > > > > 9646ed6f0cf78356cf2914a60705c98d8f21fe8a Mon Sep 17 
> > > > > > > > > > 00:00:00 2001
> > > > > > > > > > From: Gerion Entrup 
> > > > > > > > > > Date: Sun, 20 Mar 2016 11:10:31 +0100
> > > > > > > > > > Subject: [PATCH] add signature filter for MPEG7 video 
> > > > > > > > > > signature
> > > > > > > > > > 
> > > > > > > > > > This filter does not implement all features of MPEG7. 
> > > > > > > > > > Missing
> > > > > > > > > > features:
> > > > > > > > > > - compression of signature files
> > > > > > > > > > - work only on (cropped) parts of the video
> > > > > > > > > > ---
> > > > > > > > > > 
> > > > > > > > > >  Changelog  |   1 +
> > > > > > > > > >  configure  |   1 +
> > > > > > > > > >  doc/filters.texi   |  70 
> > > > > > > > > >  libavfilter/Makefile   |   1 +
> > > > > > > > > >  libavfilter/allfilters.c   |   1 +
> > > > > > > > > >  libavfilter/signature.h| 554
> > > > > > > > > >  ++
> > > > > > > > > >  libavfilter/signature_lookup.c | 550
> > > > > > > > > >  ++
> > > > > > > > > >  libavfilter/version.h  |   4 +-
> > > > > > > > > >  libavfilter/vf_signature.c | 741
> > > > > > > > > >  + 9 files changed, 
> > > > > > > > > > 1921
> > > > > > > > > >  insertions(+), 2 deletions(-)
> > > > > > > > > >  create mode 100644 libavfilter/signature.h
> > > > > > > > > >  create mode 100644 libavfilter/signature_lookup.c
> > > > > > > > > >  create mode 100644 libavfilter/vf_signature.c
> > > > > > > > > > 
> > > > > > > > > > diff --git a/Changelog b/Changelog
> > > > > > > > > > index 7b0187d..8a2b7fd 100644
> > > > > > > > > > --- a/Changelog
> > > > > > > > > > +++ b/Changelog
> > > > > > > > > > 
> > > > > > > > > > @@ -18,6 +18,7 @@ version :
> > > > > > > > > >  - coreimage filter (GPU based image filtering on OSX)
> > > > > > > > > >  - libdcadec removed
> > > > > > > > > >  - bitstream filter for extracting DTS core
> > > > > > > > > > 
> > > > > > > > > > +- MPEG-7 Video Signature filter
> > > > > > > > > > 
> > > > > > > > > >  version 3.0:
> > > > > > > > > >  - Common Encryption (CENC) MP4 encoding and decoding 
> > > > > > > > > > support
> > > > > > > > > > 
> > > > > > > > > > diff --git a/configure b/configure
> > > > > > > > > > index e550547..fe29827 100755
> > > > > > > > > > --- a/configure
> > > > > > > > > > +++ b/configure
> > > > > > > > > > @@ -2979,6 +2979,7 @@ showspectrum_filter_deps="avcodec"
> > > > > > > > > > 
> > > > > > > > > >  showspectrum_filter_select="fft"
> > > > > > > > > >  showspectrumpic_filter_deps="avcodec"
> > > > > > > > > >  showspectrumpic_filter_select="fft"
> > > > > > > > > > 
> > > > > > > > > > +signature_filter_deps="gpl avcodec avformat"
> > > > > > > > > > 
> > > > > > > > > >  smartblur_filter_deps="gpl swscale"
> > > > > > > > > >  sofalizer_filter_deps="netcdf avcodec"
> 

[FFmpeg-devel] [PATCH] Add test for mss1 codec

[Petru Rares Sincraian]

Hi there,

Here I made a test for mss1 codec. The sample file for the FATE test can be 
found at: 
https://drive.google.com/file/d/0ByhGgswO8BQcRHJFU0VRWV9aSU0/view?usp=sharingFrom 652d52f6d52a38ef25fa6d4446afd3f96b2d0280 Mon Sep 17 00:00:00 2001
From: Petru Rares Sincraian 
Date: Mon, 18 Apr 2016 17:03:01 +0200
Subject: [PATCH] Add test for mss1 codec

The sample file for the FATE test is assumed to be stored as $FATE_SAMPLES/mss1/screen_codec.wmv
---
 tests/fate/microsoft.mak |6 +
 tests/ref/fate/mss1-pal  | 1645 ++
 2 files changed, 1651 insertions(+)
 create mode 100644 tests/ref/fate/mss1-pal

diff --git a/tests/fate/microsoft.mak b/tests/fate/microsoft.mak
index 3da25a7..e72d408 100644
--- a/tests/fate/microsoft.mak
+++ b/tests/fate/microsoft.mak
@@ -1,6 +1,12 @@
 FATE_MICROSOFT-$(call DEMDEC, AVI, MSMPEG4V1) += fate-msmpeg4v1
 fate-msmpeg4v1: CMD = framecrc -flags +bitexact -idct simple -i $(TARGET_SAMPLES)/msmpeg4v1/mpg4.avi -an
 
+FATE_MSS1 += fate-mss1-pal
+fate-mss1-pal: CMD = framecrc -i $(TARGET_SAMPLES)/mss1/screen_codec.wmv
+
+FATE_SAMPLES_AVCONV-$(call DEMDEC, ASF, MSS1) += $(FATE_MSS1)
+fate-mss1: $(FATE_MSS1)
+
 FATE_MSS2 += fate-mss2-pal
 fate-mss2-pal: CMD = framecrc -i $(TARGET_SAMPLES)/mss2/rlepal.wmv
 
diff --git a/tests/ref/fate/mss1-pal b/tests/ref/fate/mss1-pal
new file mode 100644
index 000..eb73fc0
--- /dev/null
+++ b/tests/ref/fate/mss1-pal
@@ -0,0 +1,1645 @@
+#tb 0: 12/23
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 1024x768
+#sar 0: 0/1
+#tb 1: 1/8000
+#media_type 1: audio
+#codec_id 1: pcm_s16le
+#sample_rate 1: 8000
+#channel_layout 1: 4
+1,  0,  0,  512, 1024, 0x
+1,512,512,  512, 1024, 0x
+1,512,512,  512, 1024, 0x
+1,   1024,   1024,  512, 1024, 0x
+1,   1536,   1536,  512, 1024, 0x
+1,   2048,   2048,  512, 1024, 0x
+1,   2560,   2560,  512, 1024, 0x
+1,   3072,   3072,  512, 1024, 0x
+1,   3584,   3584,  512, 1024, 0x
+1,   4096,   4096,  512, 1024, 0x
+0,  1,  1,1,   787456, 0x9369daec
+1,   4608,   4608,  512, 1024, 0x
+1,   5120,   5120,  512, 1024, 0x
+1,   5632,   5632,  512, 1024, 0x
+1,   6144,   6144,  512, 1024, 0x
+1,   6656,   6656,  512, 1024, 0x
+1,   7168,   7168,  512, 1024, 0x
+1,   7680,   7680,  512, 1024, 0x
+1,   8192,   8192,  512, 1024, 0x
+0,  2,  2,1,   787456, 0x1c61a5b8
+1,   8704,   8704,  512, 1024, 0x
+1,   9216,   9216,  512, 1024, 0x
+1,   9728,   9728,  512, 1024, 0x
+1,  10240,  10240,  512, 1024, 0x
+1,  10752,  10752,  512, 1024, 0x
+1,  11264,  11264,  512, 1024, 0x
+1,  11776,  11776,  512, 1024, 0x
+1,  12288,  12288,  512, 1024, 0x
+0,  3,  3,1,   787456, 0xb9c3af1f
+1,  12800,  12800,  512, 1024, 0x
+1,  13312,  13312,  512, 1024, 0x
+1,  13824,  13824,  512, 1024, 0x
+1,  14336,  14336,  512, 1024, 0x
+1,  14848,  14848,  512, 1024, 0x
+1,  15360,  15360,  512, 1024, 0x
+1,  15872,  15872,  512, 1024, 0x
+1,  16384,  16384,  512, 1024, 0x
+0,  4,  4,1,   787456, 0xc078bec7
+1,  16896,  16896,  512, 1024, 0x
+1,  17408,  17408,  512, 1024, 0x
+1,  17920,  17920,  512, 1024, 0x
+1,  18432,  18432,  512, 1024, 0x
+1,  18944,  18944,  512, 1024, 0x
+1,  19456,  19456,  512, 1024, 0x
+1,  19968,  19968,  512, 1024, 0x
+1,  20480,  20480,  512, 1024, 0x
+0,  5,  5,1,   787456, 0x31aece7b
+1,  23296,  23296,  512, 1024, 0x
+1,  23808,  23808,  512, 1024, 0x
+1,  24320,  24320,  512, 1024, 0x
+1,  24832,  24832,  512, 1024, 0x
+0,  6,  6,1,   787456, 0x060a869e
+1,  25344,  25344,  512, 1024, 0x
+1,  25856,  25856,  512, 1024, 0x
+1,  26368,  26368,  512, 1024, 0x
+1,  26880,  26880,  512, 1024, 0x
+1,   

[FFmpeg-devel] [PATCH 6/6] lossless audio dsp: unroll

[Christophe Gisquet]

The loops are guaranteed to be at least multiples of 8, so this
unrolling is safe but allows exploiting execution ports.

For int32 version: 72 -> 57c.
---
 libavcodec/lossless_audiodsp.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/libavcodec/lossless_audiodsp.c b/libavcodec/lossless_audiodsp.c
index 55495d0..17a61cd 100644
--- a/libavcodec/lossless_audiodsp.c
+++ b/libavcodec/lossless_audiodsp.c
@@ -29,10 +29,12 @@ static int32_t scalarproduct_and_madd_int16_c(int16_t *v1, 
const int16_t *v2,
 {
 int res = 0;
 
-while (order--) {
+do {
 res   += *v1 * *v2++;
 *v1++ += mul * *v3++;
-}
+res   += *v1 * *v2++;
+*v1++ += mul * *v3++;
+} while (order-=2);
 return res;
 }
 
@@ -42,10 +44,12 @@ static int32_t scalarproduct_and_madd_int32_c(int32_t *v1, 
const int32_t *v2,
 {
 int res = 0;
 
-while (order--) {
+do {
+res   += *v1 * *v2++;
+*v1++ += mul * *v3++;
 res   += *v1 * *v2++;
 *v1++ += mul * *v3++;
-}
+} while (order-=2);
 return res;
 }
 
-- 
2.8.1

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

[FFmpeg-devel] [PATCH 4/6] wmalossless: template code to remove inloop if

[Christophe Gisquet]

Code size increase is minimal.
---
 libavcodec/wmalosslessdec.c | 140 ++--
 1 file changed, 57 insertions(+), 83 deletions(-)

diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c
index 77017ff..27510d4 100644
--- a/libavcodec/wmalosslessdec.c
+++ b/libavcodec/wmalosslessdec.c
@@ -759,90 +759,61 @@ static void use_normal_update_speed(WmallDecodeCtx *s, 
int ich)
 s->update_speed[ich] = 8;
 }
 
-static void lms_update(WmallDecodeCtx *s, int ich, int ilms, int input)
-{
-int recent = s->cdlms[ich][ilms].recent;
-int range  = 1 << s->bits_per_sample - 1;
-int order  = s->cdlms[ich][ilms].order;
-
-if (s->bits_per_sample > 16) {
-if (recent)
-recent--;
-else {
-memcpy(s->cdlms[ich][ilms].lms_prevvalues + order,
-   s->cdlms[ich][ilms].lms_prevvalues, 
sizeof(*s->cdlms[ich][ilms].lms_prevvalues) * order);
-memcpy(s->cdlms[ich][ilms].lms_updates + order,
-   s->cdlms[ich][ilms].lms_updates, 
sizeof(*s->cdlms[ich][ilms].lms_updates) * order);
-recent = order - 1;
-}
-
-s->cdlms[ich][ilms].lms_prevvalues[recent] = av_clip(input, -range, range 
- 1);
-s->cdlms[ich][ilms].lms_updates[recent] = WMASIGN(input) * 
s->update_speed[ich];
-
-s->cdlms[ich][ilms].lms_updates[recent + (order >> 4)] >>= 2;
-s->cdlms[ich][ilms].lms_updates[recent + (order >> 3)] >>= 1;
-s->cdlms[ich][ilms].recent = recent;
-memset(s->cdlms[ich][ilms].lms_updates + recent + order, 0,
-   sizeof(s->cdlms[ich][ilms].lms_updates) - 4*(recent+order));
-} else {
-int16_t *prevvalues = s->cdlms[ich][ilms].lms_prevvalues;
-int16_t *updates= s->cdlms[ich][ilms].lms_updates;
-if (recent)
-recent--;
-else {
-memcpy(prevvalues + order, prevvalues, 2 * order);
-memcpy(updates + order, updates, 2 * order);
-recent = order - 1;
-}
-
-prevvalues[recent] = av_clip(input, -range, range - 1);
-updates[recent] = WMASIGN(input) * s->update_speed[ich];
-
-updates[recent + (order >> 4)] >>= 2;
-updates[recent + (order >> 3)] >>= 1;
-s->cdlms[ich][ilms].recent = recent;
-memset(updates + recent + order, 0,
-   sizeof(s->cdlms[ich][ilms].lms_updates) - 2*(recent+order));
-}
+#define CD_LMS(bits, ROUND) \
+static void lms_update ## bits (WmallDecodeCtx *s, int ich, int ilms, int 
input) \
+{ \
+int recent = s->cdlms[ich][ilms].recent; \
+int range  = 1 << s->bits_per_sample - 1; \
+int order  = s->cdlms[ich][ilms].order; \
+int ##bits##_t *prev = (int##bits##_t 
*)s->cdlms[ich][ilms].lms_prevvalues; \
+int ##bits##_t *upd = (int##bits##_t *)s->cdlms[ich][ilms].lms_updates; \
+ \
+if (recent) \
+recent--; \
+else { \
+memcpy(prev + order, prev, (bits/8) * order); \
+memcpy(upd + order, upd, (bits/8) * order); \
+recent = order - 1; \
+} \
+ \
+prev[recent] = av_clip(input, -range, range - 1); \
+upd[recent] = WMASIGN(input) * s->update_speed[ich]; \
+ \
+upd[recent + (order >> 4)] >>= 2; \
+upd[recent + (order >> 3)] >>= 1; \
+s->cdlms[ich][ilms].recent = recent; \
+memset(upd + recent + order, 0, \
+   sizeof(s->cdlms[ich][ilms].lms_updates) - (bits/8)*(recent+order)); 
\
+} \
+ \
+static void revert_cdlms ## bits (WmallDecodeCtx *s, int ch, \
+  int coef_begin, int coef_end) \
+{ \
+int icoef, pred, ilms, num_lms, residue, input; \
+ \
+num_lms = s->cdlms_ttl[ch]; \
+for (ilms = num_lms - 1; ilms >= 0; ilms--) { \
+for (icoef = coef_begin; icoef < coef_end; icoef++) { \
+int##bits##_t *coeffs = (int##bits##_t *)s->cdlms[ch][ilms].coefs; 
\
+int##bits##_t *prevvalues = (int##bits##_t 
*)s->cdlms[ch][ilms].lms_prevvalues; \
+int##bits##_t *updates = (int##bits##_t 
*)s->cdlms[ch][ilms].lms_updates; \
+pred = 1 << (s->cdlms[ch][ilms].scaling - 1); \
+residue = s->channel_residues[ch][icoef]; \
+pred += s->dsp.scalarproduct_and_madd_int## bits (coeffs, \
+prevvalues + 
s->cdlms[ch][ilms].recent, \
+updates + 
s->cdlms[ch][ilms].recent, \
+
FFALIGN(s->cdlms[ch][ilms].order, ROUND), \
+WMASIGN(residue)); \
+input = residue + (pred >> s->cdlms[ch][ilms].scaling); \
+lms_update ## bits(s, ch, ilms, input); \
+s->channel_residues[ch][icoef] = input; \
+} \
+} \
+emms_c(); \
 }
 
-static void revert_cdlms(WmallDecodeCtx *s, int ch,
- int coef_begin, int coef_end)
-{
-int icoef, pred, ilms, num_lms, residue, input;
-
-

[FFmpeg-devel] [PATCH 1/6] fate: wma: add lossless 24bits test

[Christophe Gisquet]

---
 tests/fate/lossless-audio.mak | 4 +++-
 tests/ref/fate/lossless-wma24 | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/fate/lossless-wma24

diff --git a/tests/fate/lossless-audio.mak b/tests/fate/lossless-audio.mak
index 58641ab..ccc4d00 100644
--- a/tests/fate/lossless-audio.mak
+++ b/tests/fate/lossless-audio.mak
@@ -25,8 +25,10 @@ fate-lossless-tta: CMD = crc -i 
$(TARGET_SAMPLES)/lossless-audio/inside.tta
 FATE_SAMPLES_LOSSLESS_AUDIO-$(call DEMDEC, TTA, TTA) += 
fate-lossless-tta-encrypted
 fate-lossless-tta-encrypted: CMD = crc -password ffmpeg -i 
$(TARGET_SAMPLES)/lossless-audio/encrypted.tta
 
-FATE_SAMPLES_LOSSLESS_AUDIO-$(call DEMDEC, ASF, WMALOSSLESS) += 
fate-lossless-wma
+FATE_SAMPLES_LOSSLESS_AUDIO-$(call DEMDEC, ASF, WMALOSSLESS) += 
fate-lossless-wma fate-lossless-wma24
 fate-lossless-wma: CMD = md5 -i 
$(TARGET_SAMPLES)/lossless-audio/luckynight-partial.wma -f s16le -frames 209
+fate-lossless-wma24: CMD = md5 -i 
$(TARGET_SAMPLES)/lossless-audio/luckynight-partial-24.wma -f s24le -frames 209
+fate-lossless-wmal: fate-lossless-wma fate-lossless-wma24
 
 FATE_SAMPLES_LOSSLESS_AUDIO += $(FATE_SAMPLES_LOSSLESS_AUDIO-yes)
 
diff --git a/tests/ref/fate/lossless-wma24 b/tests/ref/fate/lossless-wma24
new file mode 100644
index 000..43862af
--- /dev/null
+++ b/tests/ref/fate/lossless-wma24
@@ -0,0 +1 @@
+e5aea78d60c407a88c4ff25994052b83
-- 
2.8.1

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

[FFmpeg-devel] [PATCH 2/6] wmalossless: allow calling madd_int16

[Christophe Gisquet]

This is done by actually handling the cascaded LMS data as if it
were int16_t, thus requiring switching at various locations the
computations.
---
 libavcodec/wmalosslessdec.c | 61 +
 1 file changed, 61 insertions(+)

diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c
index f7f249b..3885dc1 100644
--- a/libavcodec/wmalosslessdec.c
+++ b/libavcodec/wmalosslessdec.c
@@ -497,15 +497,29 @@ static int decode_cdlms(WmallDecodeCtx *s)
 s->cdlms[c][i].bitsend = get_bitsz(>gb, cbits) + 2;
 shift_l = 32 - s->cdlms[c][i].bitsend;
 shift_r = 32 - s->cdlms[c][i].scaling - 2;
+if (s->bits_per_sample > 16) {
 for (j = 0; j < s->cdlms[c][i].coefsend; j++)
 s->cdlms[c][i].coefs[j] =
 (get_bits(>gb, s->cdlms[c][i].bitsend) << shift_l) 
>> shift_r;
+} else {
+for (j = 0; j < s->cdlms[c][i].coefsend; j++) {
+int16_t *ptr = (int16_t*)s->cdlms[c][i].coefs;
+ptr[j] = (get_bits(>gb, s->cdlms[c][i].bitsend) << 
shift_l) >> shift_r;
+}
+}
 }
 }
 
+if (s->bits_per_sample > 16) {
 for (i = 0; i < s->cdlms_ttl[c]; i++)
 memset(s->cdlms[c][i].coefs + s->cdlms[c][i].order,
0, WMALL_COEFF_PAD_SIZE);
+} else {
+for (i = 0; i < s->cdlms_ttl[c]; i++) {
+int16_t *ptr = (int16_t*)s->cdlms[c][i].coefs;
+memset(ptr + s->cdlms[c][i].order, 0, 2*WMALL_COEFF_PAD_SIZE);
+}
+}
 }
 
 return 0;
@@ -702,6 +716,7 @@ static void lms_update(WmallDecodeCtx *s, int ich, int 
ilms, int input)
 int range  = 1 << s->bits_per_sample - 1;
 int order  = s->cdlms[ich][ilms].order;
 
+if (s->bits_per_sample > 16) {
 if (recent)
 recent--;
 else {
@@ -720,6 +735,26 @@ static void lms_update(WmallDecodeCtx *s, int ich, int 
ilms, int input)
 s->cdlms[ich][ilms].recent = recent;
 memset(s->cdlms[ich][ilms].lms_updates + recent + order, 0,
sizeof(s->cdlms[ich][ilms].lms_updates) - 4*(recent+order));
+} else {
+int16_t *prevvalues = s->cdlms[ich][ilms].lms_prevvalues;
+int16_t *updates= s->cdlms[ich][ilms].lms_updates;
+if (recent)
+recent--;
+else {
+memcpy(prevvalues + order, prevvalues, 2 * order);
+memcpy(updates + order, updates, 2 * order);
+recent = order - 1;
+}
+
+prevvalues[recent] = av_clip(input, -range, range - 1);
+updates[recent] = WMASIGN(input) * s->update_speed[ich];
+
+updates[recent + (order >> 4)] >>= 2;
+updates[recent + (order >> 3)] >>= 1;
+s->cdlms[ich][ilms].recent = recent;
+memset(updates + recent + order, 0,
+   sizeof(s->cdlms[ich][ilms].lms_updates) - 2*(recent+order));
+}
 }
 
 static void use_high_update_speed(WmallDecodeCtx *s, int ich)
@@ -729,6 +764,7 @@ static void use_high_update_speed(WmallDecodeCtx *s, int 
ich)
 recent = s->cdlms[ich][ilms].recent;
 if (s->update_speed[ich] == 16)
 continue;
+if (s->bits_per_sample > 16) {
 if (s->bV3RTM) {
 for (icoef = 0; icoef < s->cdlms[ich][ilms].order; icoef++)
 s->cdlms[ich][ilms].lms_updates[icoef + recent] *= 2;
@@ -736,6 +772,12 @@ static void use_high_update_speed(WmallDecodeCtx *s, int 
ich)
 for (icoef = 0; icoef < s->cdlms[ich][ilms].order; icoef++)
 s->cdlms[ich][ilms].lms_updates[icoef] *= 2;
 }
+} else {
+int16_t *updates = (int16_t *)s->cdlms[ich][ilms].lms_updates;
+if (s->bV3RTM) updates += recent;
+for (icoef = 0; icoef < s->cdlms[ich][ilms].order; icoef++)
+updates[icoef] *= 2;
+}
 }
 s->update_speed[ich] = 16;
 }
@@ -747,12 +789,19 @@ static void use_normal_update_speed(WmallDecodeCtx *s, 
int ich)
 recent = s->cdlms[ich][ilms].recent;
 if (s->update_speed[ich] == 8)
 continue;
+if (s->bits_per_sample > 16) {
 if (s->bV3RTM)
 for (icoef = 0; icoef < s->cdlms[ich][ilms].order; icoef++)
 s->cdlms[ich][ilms].lms_updates[icoef + recent] /= 2;
 else
 for (icoef = 0; icoef < s->cdlms[ich][ilms].order; icoef++)
 s->cdlms[ich][ilms].lms_updates[icoef] /= 2;
+} else {
+int16_t *updates = (int16_t *)s->cdlms[ich][ilms].lms_updates;
+if (s->bV3RTM) updates += recent;
+for (icoef = 0; icoef < s->cdlms[ich][ilms].order; icoef++)
+updates[icoef] /= 2;
+}
 }
 s->update_speed[ich] = 8;
 }
@@ -767,6 +816,7 @@ static void revert_cdlms(WmallDecodeCtx *s, int ch,
  

[FFmpeg-devel] [PATCH 5/6] x86: lossless audio: SSE4 madd 32bits

[Christophe Gisquet]

The unique user so far is wmalossless 24bits. The few samples tested show an
order of 8, so more unrolling or an avx2 version do not make sense.

Timings: 72 -> 49 cycles
---
 libavcodec/x86/lossless_audiodsp.asm| 38 +
 libavcodec/x86/lossless_audiodsp_init.c |  7 ++
 2 files changed, 45 insertions(+)

diff --git a/libavcodec/x86/lossless_audiodsp.asm 
b/libavcodec/x86/lossless_audiodsp.asm
index 5597dad..1e295de 100644
--- a/libavcodec/x86/lossless_audiodsp.asm
+++ b/libavcodec/x86/lossless_audiodsp.asm
@@ -155,3 +155,41 @@ SCALARPRODUCT_LOOP 0
 HADDD   m6, m0
 movd   eax, m6
 RET
+
+%macro SCALARPRODUCT32 0
+; int ff_scalarproduct_and_madd_int16(int16_t *v1, int16_t *v2, int16_t *v3,
+; int order, int mul)
+cglobal scalarproduct_and_madd_int32, 4,4,8, v1, v2, v3, order, mul
+movdm7, mulm
+SPLATD  m7
+pxorm6, m6
+add v1q, orderq
+add v2q, orderq
+add v3q, orderq
+neg orderq
+.loop:
+movum0, [v2q + orderq]
+movum1, [v2q + orderq + mmsize]
+movam4, [v1q + orderq]
+movam5, [v1q + orderq + mmsize]
+movum2, [v3q + orderq]
+movum3, [v3q + orderq + mmsize]
+pmulld  m0, m4
+pmulld  m1, m5
+pmulld  m2, m7
+pmulld  m3, m7
+paddd   m6, m0
+paddd   m6, m1
+paddd   m2, m4
+paddd   m3, m5
+mova[v1q + orderq], m2
+mova[v1q + orderq + mmsize], m3
+add orderq, mmsize*2
+jl .loop
+HADDD   m6, m0
+movd   eax, m6
+RET
+%endmacro
+
+INIT_XMM sse4
+SCALARPRODUCT32
diff --git a/libavcodec/x86/lossless_audiodsp_init.c 
b/libavcodec/x86/lossless_audiodsp_init.c
index 197173c..85306cb 100644
--- a/libavcodec/x86/lossless_audiodsp_init.c
+++ b/libavcodec/x86/lossless_audiodsp_init.c
@@ -31,6 +31,10 @@ int32_t ff_scalarproduct_and_madd_int16_ssse3(int16_t *v1, 
const int16_t *v2,
   const int16_t *v3,
   int order, int mul);
 
+int32_t ff_scalarproduct_and_madd_int32_sse4(int32_t *v1, const int32_t *v2,
+ const int32_t *v3,
+ int order, int mul);
+
 av_cold void ff_llauddsp_init_x86(LLAudDSPContext *c)
 {
 #if HAVE_YASM
@@ -45,5 +49,8 @@ av_cold void ff_llauddsp_init_x86(LLAudDSPContext *c)
 if (EXTERNAL_SSSE3(cpu_flags) &&
 !(cpu_flags & (AV_CPU_FLAG_SSE42 | AV_CPU_FLAG_3DNOW))) // cachesplit
 c->scalarproduct_and_madd_int16 = 
ff_scalarproduct_and_madd_int16_ssse3;
+
+if (EXTERNAL_SSE4(cpu_flags))
+c->scalarproduct_and_madd_int32 = ff_scalarproduct_and_madd_int32_sse4;
 #endif
 }
-- 
2.8.1

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

[FFmpeg-devel] [PATCH 3/6] wmalossless pro: move lms_update

[Christophe Gisquet]

Cosmetics before macroing it and another function.
---
 libavcodec/wmalosslessdec.c | 94 ++---
 1 file changed, 47 insertions(+), 47 deletions(-)

diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c
index 3885dc1..77017ff 100644
--- a/libavcodec/wmalosslessdec.c
+++ b/libavcodec/wmalosslessdec.c
@@ -710,53 +710,6 @@ static void revert_mclms(WmallDecodeCtx *s, int tile_size)
 }
 }
 
-static void lms_update(WmallDecodeCtx *s, int ich, int ilms, int input)
-{
-int recent = s->cdlms[ich][ilms].recent;
-int range  = 1 << s->bits_per_sample - 1;
-int order  = s->cdlms[ich][ilms].order;
-
-if (s->bits_per_sample > 16) {
-if (recent)
-recent--;
-else {
-memcpy(s->cdlms[ich][ilms].lms_prevvalues + order,
-   s->cdlms[ich][ilms].lms_prevvalues, 
sizeof(*s->cdlms[ich][ilms].lms_prevvalues) * order);
-memcpy(s->cdlms[ich][ilms].lms_updates + order,
-   s->cdlms[ich][ilms].lms_updates, 
sizeof(*s->cdlms[ich][ilms].lms_updates) * order);
-recent = order - 1;
-}
-
-s->cdlms[ich][ilms].lms_prevvalues[recent] = av_clip(input, -range, range 
- 1);
-s->cdlms[ich][ilms].lms_updates[recent] = WMASIGN(input) * 
s->update_speed[ich];
-
-s->cdlms[ich][ilms].lms_updates[recent + (order >> 4)] >>= 2;
-s->cdlms[ich][ilms].lms_updates[recent + (order >> 3)] >>= 1;
-s->cdlms[ich][ilms].recent = recent;
-memset(s->cdlms[ich][ilms].lms_updates + recent + order, 0,
-   sizeof(s->cdlms[ich][ilms].lms_updates) - 4*(recent+order));
-} else {
-int16_t *prevvalues = s->cdlms[ich][ilms].lms_prevvalues;
-int16_t *updates= s->cdlms[ich][ilms].lms_updates;
-if (recent)
-recent--;
-else {
-memcpy(prevvalues + order, prevvalues, 2 * order);
-memcpy(updates + order, updates, 2 * order);
-recent = order - 1;
-}
-
-prevvalues[recent] = av_clip(input, -range, range - 1);
-updates[recent] = WMASIGN(input) * s->update_speed[ich];
-
-updates[recent + (order >> 4)] >>= 2;
-updates[recent + (order >> 3)] >>= 1;
-s->cdlms[ich][ilms].recent = recent;
-memset(updates + recent + order, 0,
-   sizeof(s->cdlms[ich][ilms].lms_updates) - 2*(recent+order));
-}
-}
-
 static void use_high_update_speed(WmallDecodeCtx *s, int ich)
 {
 int ilms, recent, icoef;
@@ -806,6 +759,53 @@ static void use_normal_update_speed(WmallDecodeCtx *s, int 
ich)
 s->update_speed[ich] = 8;
 }
 
+static void lms_update(WmallDecodeCtx *s, int ich, int ilms, int input)
+{
+int recent = s->cdlms[ich][ilms].recent;
+int range  = 1 << s->bits_per_sample - 1;
+int order  = s->cdlms[ich][ilms].order;
+
+if (s->bits_per_sample > 16) {
+if (recent)
+recent--;
+else {
+memcpy(s->cdlms[ich][ilms].lms_prevvalues + order,
+   s->cdlms[ich][ilms].lms_prevvalues, 
sizeof(*s->cdlms[ich][ilms].lms_prevvalues) * order);
+memcpy(s->cdlms[ich][ilms].lms_updates + order,
+   s->cdlms[ich][ilms].lms_updates, 
sizeof(*s->cdlms[ich][ilms].lms_updates) * order);
+recent = order - 1;
+}
+
+s->cdlms[ich][ilms].lms_prevvalues[recent] = av_clip(input, -range, range 
- 1);
+s->cdlms[ich][ilms].lms_updates[recent] = WMASIGN(input) * 
s->update_speed[ich];
+
+s->cdlms[ich][ilms].lms_updates[recent + (order >> 4)] >>= 2;
+s->cdlms[ich][ilms].lms_updates[recent + (order >> 3)] >>= 1;
+s->cdlms[ich][ilms].recent = recent;
+memset(s->cdlms[ich][ilms].lms_updates + recent + order, 0,
+   sizeof(s->cdlms[ich][ilms].lms_updates) - 4*(recent+order));
+} else {
+int16_t *prevvalues = s->cdlms[ich][ilms].lms_prevvalues;
+int16_t *updates= s->cdlms[ich][ilms].lms_updates;
+if (recent)
+recent--;
+else {
+memcpy(prevvalues + order, prevvalues, 2 * order);
+memcpy(updates + order, updates, 2 * order);
+recent = order - 1;
+}
+
+prevvalues[recent] = av_clip(input, -range, range - 1);
+updates[recent] = WMASIGN(input) * s->update_speed[ich];
+
+updates[recent + (order >> 4)] >>= 2;
+updates[recent + (order >> 3)] >>= 1;
+s->cdlms[ich][ilms].recent = recent;
+memset(updates + recent + order, 0,
+   sizeof(s->cdlms[ich][ilms].lms_updates) - 2*(recent+order));
+}
+}
+
 static void revert_cdlms(WmallDecodeCtx *s, int ch,
  int coef_begin, int coef_end)
 {
-- 
2.8.1

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

[FFmpeg-devel] [PATCH 0/6] wmalossless: fix 16bits speed regression

[Christophe Gisquet]

I think only the 2 first patches are needed, but I prefer the code
from the 3rd+4th patches. Overall, it's still not the nicest code, and
valgrind-proofing the patchset is needed (not possible atm for me).

The SSE4 implementation is not worthwhile in my opinion.

Christophe Gisquet (6):
  fate: wma: add lossless 24bits test
  wmalossless: allow calling madd_int16
  wmalossless pro: move lms_update
  wmalossless: template code to remove inloop if
  x86: lossless audio: SSE4 madd 32bits
  lossless audio dsp: unroll

 libavcodec/lossless_audiodsp.c  |  12 ++-
 libavcodec/wmalosslessdec.c | 137 
 libavcodec/x86/lossless_audiodsp.asm|  38 +
 libavcodec/x86/lossless_audiodsp_init.c |   7 ++
 tests/fate/lossless-audio.mak   |   4 +-
 tests/ref/fate/lossless-wma24   |   1 +
 6 files changed, 143 insertions(+), 56 deletions(-)
 create mode 100644 tests/ref/fate/lossless-wma24

-- 
2.8.1

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

Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.

[Dmitriy Kuminov]

On 2016-04-18 11:52:15 +, KO Myung-Hun said:


Strange conclusion. Anyway not important.


In Dave's case the symlink functionality check fails because it is 
performed in TMPDIR which is located on ramfs.ifs (which fails to use 
symlinks). But I believe his real build directory is not on ramfs.ifs 
and symlinks are in fact supported there (and can be used). But this 
problem is not OS/2-specific, it may happen on any platform where 
TMPDIR is on a volume that doesn't support symlinks for sojme reason. I 
think the FFmpeg guys should fix this check to make it performed inside 
the build directory, not in TMPDIR.



Good to know that. I wish to see the latest bash for OS/2 soon.


Well, in fact, having bash would be not bad indeed, but since it has 
little impact on end users, this is postponed for later. Your 
contribution is (as always) welcome.



I meant those who don't use ln at all for compatibility with other OS/2
programs not built with kLIBC, like me.


Okay, but still. I don't think ongoing OS/2 development should be 
chained by people like you :) (nothing personal, of course). For 
instance, you won't be able to build the latest Firefox if your system 
doesn't support symlinks (at least because of python's virtualenv). And 
I'm not going to invest time in making it work in such a case, not at 
all (it's a pure waste). This is clearly offtopic for this mailing list 
though, so let's continue this conversation in private if you want.



My "correction" is not removing ln_s overriding. I don't want to use ln
-s on OS/2.


Sorry but I really doubt things affecting other people should happen or 
not happen just because you want it or not. We are all here to 
collaborate. I added what I needed and what I think is the best. You 
don't agree, that's OK, so I offered you a compromise - write your own 
patch that will make it work for you the way you want it w/o breaking 
what I need. You refuse to do so and I don't find it collaborative. 
It's upto FFmpeg maintainers to decide what to do here, but I won't 
accept symlink usage removal in our repositiries. I will, however, 
accept your patch that will allow to go both ways (with the symlink 
usage being the default choice if supported by the underlying IFS).


--
Kind regards,
Dmitriy Kuminov
CPO of bww bitwise works GmbH


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

Re: [FFmpeg-devel] [PATCH 1/3 v2] doc/examples: Add fffuzz example

[Paweł Goliński]

Hi,

I’ll try to clear some things up. Here it goes:

1. About the copyright thing, kierank didn’t say to add him to copyright 
section and I’m not sure whether its his code, so I left it as it is.
2. I got instructions not to hook this up to build system just yet, I think one 
of the reasons is that we’re not sure whether compile this with afl 
instrumentation (afl-clang-fast command), or just normally. This is something 
that will be clear later.
3. About failure checks, I guess I’ll add them in next version of the patch.

Also, sorry for ignoring previous email, I discussed the review of my previous 
patch with kierank so I thought it was enough.

——
Paweł

> Wiadomość napisana przez Michael Niedermayer  w dniu 
> 17.04.2016, o godz. 04:03:
> 
> Hi
> 
> On Sat, Apr 16, 2016 at 12:12:41AM +0200, Pawel Golinski wrote:
>> There are some afl specific macros inside,
>> to make the example usable with afl fuzzer.
>> ---
>> doc/examples/fffuzz.c | 370 
>> ++
>> 1 file changed, 370 insertions(+)
>> create mode 100644 doc/examples/fffuzz.c
>> 
>> diff --git a/doc/examples/fffuzz.c b/doc/examples/fffuzz.c
>> new file mode 100644
>> index 000..6672f42
>> --- /dev/null
>> +++ b/doc/examples/fffuzz.c
>> @@ -0,0 +1,370 @@
>> +/*
>> + * Copyright (c) 2012 Stefano Sabatini
>> + * Copyright (c) 2015 Andreas Cadhalpun
> 
> there was a review comment about this, please do not ignore review
> comments
> for reference;
  the first patch in the patchset is my patch so I can't review it
 would suggest to me that he should be listed in the Copyright too
> 
> also when at this, please make sure the author metadata in the commits
> is correct, i dont know who wrote what
> 
> also the code is still not hooked up to the build system
> 
> 
> [...]
>> +/**
>> + * @file
>> + * Demuxing and decoding (a codec/format combination) example.
>> + *
>> + * This can be useful for fuzz testing.
>> + * @example ddcf.c
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* needed for decoding video */
>> +static int width, height;
>> +static enum AVPixelFormat pix_fmt;
>> +static uint8_t *video_dst_data[4] = {NULL};
>> +static int  video_dst_linesize[4];
>> +static int video_dst_bufsize;
>> +
>> +static int decode_packet(AVCodecContext *dec_ctx, FILE *dst_file, AVFrame 
>> *frame, int *got_frame, int *frame_count, AVPacket *pkt)
>> +{
>> +int ret = -1;
>> +*got_frame = 0;
>> +AVSubtitle sub;
>> +unsigned i, j, k, l;
>> +
>> +if (dec_ctx->codec_type == AVMEDIA_TYPE_VIDEO) {
>> +/* decode video frame */
>> +ret = avcodec_decode_video2(dec_ctx, frame, got_frame, pkt);
>> +if (ret < 0) {
>> +fprintf(stderr, "Error decoding video frame (%s)\n", 
>> av_err2str(ret));
>> +return ret;
>> +}
>> +
>> +if (*got_frame) {
>> +
>> +if (frame->width != width || frame->height != height ||
>> +frame->format != pix_fmt) {
>> +fprintf(stderr, "Error: input video width/height/format 
>> changed:\n"
>> +"old: width = %d, height = %d, format = %s\n"
>> +"new: width = %d, height = %d, format = %s\n",
>> +width, height, av_get_pix_fmt_name(pix_fmt),
>> +dec_ctx->width, dec_ctx->height,
>> +av_get_pix_fmt_name(dec_ctx->pix_fmt));
>> +return -1;
>> +}
>> +
>> +printf("video_frame n:%d coded_n:%d pts:%s\n",
>> +   *frame_count, frame->coded_picture_number,
>> +   av_ts2timestr(frame->pts, _ctx->time_base));
>> +
>> +/* copy decoded frame to destination buffer:
>> + * this is required since rawvideo expects non aligned data */
>> +av_image_copy(video_dst_data, video_dst_linesize,
>> +  (const uint8_t **)(frame->data), frame->linesize,
>> +  pix_fmt, width, height);
>> +*frame_count += 1;
>> +
>> +/* write to rawvideo file */
>> +fwrite(video_dst_data[0], 1, video_dst_bufsize, dst_file);
>> +}
>> +} else if (dec_ctx->codec_type == AVMEDIA_TYPE_AUDIO) {
>> +/* decode audio frame */
>> +ret = avcodec_decode_audio4(dec_ctx, frame, got_frame, pkt);
>> +if (ret < 0) {
>> +fprintf(stderr, "Error decoding audio frame (%s)\n", 
>> av_err2str(ret));
>> +return ret;
>> +}
> 
>> +/* Some audio decoders decode only part of the packet, and have to 
>> be
>> + * called again with the remainder of the packet data.
>> + * Sample: fate-suite/lossless-audio/luckynight-partial.shn
>> + * Also, some decoders might over-read the packet. */
>> +ret = FFMIN(ret, pkt->size);
> 
> overreads should not be ignored silently
> 
> 
> 

Re: [FFmpeg-devel] [PATCH 2/2 v2] fate: add readvitc filter test

[Michael Niedermayer]

On Mon, Apr 18, 2016 at 09:38:13AM +0200, Tobias Rapp wrote:
> On 16.04.2016 23:25, Michael Niedermayer wrote:
> > On Fri, Apr 15, 2016 at 09:49:46AM +0200, Tobias Rapp wrote:
> >> Attached an updated patch, rebased onto current git master.
> >>
> >> The sample file for the FATE test can be found at:
> >> https://cerebrum.noa-archive.com/noacloud/public.php?service=filest=88eeb716819bba39584be03c2d1f053b
> >>  (1.4MB)
> > 
> > wget 
> > https://cerebrum.noa-archive.com/noacloud/public.php?service=filest=88eeb716819bba39584be03c2d1f053b
> > --2016-04-16 23:25:03--  
> > https://cerebrum.noa-archive.com/noacloud/public.php?service=filest=88eeb716819bba39584be03c2d1f053b
> > Resolving cerebrum.noa-archive.com (cerebrum.noa-archive.com)... 
> > 78.46.20.104
> > Connecting to cerebrum.noa-archive.com 
> > (cerebrum.noa-archive.com)|78.46.20.104|:443... connected.
> > HTTP request sent, awaiting response... 404 Not Found
> > 2016-04-16 23:25:03 ERROR 404: Not Found.
> > 
> 
> Sorry, it seems I dropped a "&" in the link and there was an intermediate 
> HTML redirection page which breaks downloading with wget. The following 
> command should work:
> 
> wget -O sample-vitc.avi 
> 'https://cerebrum.noa-archive.com/noacloud/public.php?service=files=88eeb716819bba39584be03c2d1f053b'

uploaded

thx

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.

[KO Myung-Hun]

Dmitriy Kuminov wrote:
> On 2016-04-17 05:21:31 +, KO Myung-Hun said:
> 
>> Even if it's a bug of ramfs.ifs, its bug should be considered when using
>> ln -s.
> 
> Yes, and in this particular case configure handles it safely. It results
> into a false fallback though because the symlink dir check is performed
> in TMPDIR which in fact may be on a different FS than the directory used
> for the shadow build. But this is a bug in configure not related to OS/2
> at all.
> 

Strange conclusion. Anyway not important.

>> However, some shells such as bash and pdksh using EMX does not support a
>> symbolic link.
> 
> This is a valid point per se. But I believe there is little sense in
> putting any afforts to support some dead software from 90s for which we
> have a better and somewhat supported alternative. Both bash and pdksh
> can be rebuilt with kLIBC if really needed (not top priprity for BWW atm
> as there are much more improtant things to do).
> 

Good to know that. I wish to see the latest bash for OS/2 soon.

>>  In addition, there are people not using ln -s for
>> compatibility. So if possible, it would be better to avoid a symbolic
>> link.
> 
> Well some people may still use FAT with OS/2 for compatibility. I don't
> think ongoing development should be chained by them...
> 

I meant those who don't use ln at all for compatibility with other OS/2
programs not built with kLIBC, like me.

>> Anyway, test if ln -s really works and override ln_s if it fails.
> 
> To that I agree, it's the best solution. Can you provide your correction
> to this patch that prefrorms such a check in the "os/2" case at least? I
> guess you use EMX bash/pdksh so you can test it right away.
> 

My "correction" is not removing ln_s overriding. I don't want to use ln
-s on OS/2.


-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr

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

Re: [FFmpeg-devel] [PATCH] Fix chroma height ratio for yuv410p

[Hendrik Leppkes]

On Mon, Apr 18, 2016 at 12:07 PM, Michael Niedermayer
 wrote:
> On Mon, Apr 18, 2016 at 09:49:40AM +, Isamu Mogi wrote:
>> Chroma height for yuv410p is luma/2. Same as yuv440p and yuv420p.
>
> no
> but why was the first thought i had "wikipedia" and why was i correct
> "4:1:0 This ratio is possible, and some codecs support it, but it is not 
> widely used. This ratio uses half of the vertical ..."
>
> do NOT ever use wikipedia for important decissions, its great to
> look something up but its not accurate especially for things where
> the correct awnser is unintuitv
> also seems this one is known, check
> https://en.wikipedia.org/wiki/Talk%3AChroma_subsampling about 4:1:0
>
>

The problem with 4:1:0 is that its used wrong in many many places.
The 4:1:0 notation would say that its one chroma sample for a 4x2
block, and one sample for a 4x4 block would be impossible in this
notation - this variant is otherwise commonly called YUV9.

However, many formats and software treat 4:1:0 like a special case for
some reason, ignoring the J:a:b notation and handling it as the 4x4
block.

So while its technically wrong, it appears to match what software
typically uses. To be fully accurate, we should rename yuv410p to
something more fitting, and introduce a new 4:1:0 format afterwards,
but this is a lot of effort with deprecation cycles and not colliding
the names etc for an obscure format..

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

Re: [FFmpeg-devel] [PATCH] Fix chroma height ratio for yuv410p

[Michael Niedermayer]

On Mon, Apr 18, 2016 at 09:49:40AM +, Isamu Mogi wrote:
> Chroma height for yuv410p is luma/2. Same as yuv440p and yuv420p.

no
but why was the first thought i had "wikipedia" and why was i correct
"4:1:0 This ratio is possible, and some codecs support it, but it is not widely 
used. This ratio uses half of the vertical ..."

do NOT ever use wikipedia for important decissions, its great to
look something up but its not accurate especially for things where
the correct awnser is unintuitv
also seems this one is known, check
https://en.wikipedia.org/wiki/Talk%3AChroma_subsampling about 4:1:0


[...]
> diff --git a/tests/ref/lavf/pixfmt b/tests/ref/lavf/pixfmt
> index ec75d4c..f0db104 100644
> --- a/tests/ref/lavf/pixfmt
> +++ b/tests/ref/lavf/pixfmt
> @@ -6,7 +6,7 @@ ac68f9fdd9d55efd0306d9b004038761 
> *./tests/data/pixfmt/yuv422p.yuv
>  304128 ./tests/data/pixfmt/yuv444p.yuv
>  ac68f9fdd9d55efd0306d9b004038761 *./tests/data/pixfmt/yuyv422.yuv
>  304128 ./tests/data/pixfmt/yuyv422.yuv
> -507c7e9f0c97660385df977469ca9e6d *./tests/data/pixfmt/yuv410p.yuv
> +f0d62d407a9bf98d25d8c0ae5493830f *./tests/data/pixfmt/yuv410p.yuv
>  304128 ./tests/data/pixfmt/yuv410p.yuv
>  8594ea0b8d7c2c964525b0801b5351de *./tests/data/pixfmt/yuv411p.yuv
>  304128 ./tests/data/pixfmt/yuv411p.yuv
> diff --git a/tests/ref/vsynth/vsynth1-svq1 b/tests/ref/vsynth/vsynth1-svq1
> index 9c1b6ff..d57dfb5 100644
> --- a/tests/ref/vsynth/vsynth1-svq1
> +++ b/tests/ref/vsynth/vsynth1-svq1
> @@ -1,4 +1,4 @@
> -a3206831d34197a2d236d82dd0248646 *tests/data/fate/vsynth1-svq1.mov
> -1334233 tests/data/fate/vsynth1-svq1.mov
> -9cc35c54b2c77d36bd7e308b393c1f81 *tests/data/fate/vsynth1-svq1.out.rawvideo
> -stddev:9.58 PSNR: 28.50 MAXDIFF:  210 bytes:  7603200/  7603200
> +2396b396b25cffa0445d360977f5987a *tests/data/fate/vsynth1-svq1.mov
> +1295093 tests/data/fate/vsynth1-svq1.mov
> +cc95d739b3fb597f881d6c3a25f99f7d *tests/data/fate/vsynth1-svq1.out.rawvideo
> +stddev:   54.61 PSNR: 13.38 MAXDIFF:  249 bytes:  7603200/  7603200
 ^
this also shows that the change is wrong, the images dont match
anymore after it

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

[FFmpeg-devel] [PATCH] Fix chroma height ratio for yuv410p

[Isamu Mogi]

Chroma height for yuv410p is luma/2. Same as yuv440p and yuv420p.

Signed-off-by: Isamu Mogi 
---
 libavutil/pixdesc.c  | 2 +-
 libavutil/pixfmt.h   | 2 +-
 tests/ref/fate/filter-pixdesc-yuv410p| 2 +-
 tests/ref/fate/filter-pixfmts-copy   | 2 +-
 tests/ref/fate/filter-pixfmts-crop   | 2 +-
 tests/ref/fate/filter-pixfmts-field  | 2 +-
 tests/ref/fate/filter-pixfmts-fieldmatch | 2 +-
 tests/ref/fate/filter-pixfmts-hflip  | 2 +-
 tests/ref/fate/filter-pixfmts-il | 2 +-
 tests/ref/fate/filter-pixfmts-lut| 2 +-
 tests/ref/fate/filter-pixfmts-null   | 2 +-
 tests/ref/fate/filter-pixfmts-pad| 2 +-
 tests/ref/fate/filter-pixfmts-rotate | 2 +-
 tests/ref/fate/filter-pixfmts-scale  | 2 +-
 tests/ref/fate/filter-pixfmts-swapuv | 2 +-
 tests/ref/fate/filter-pixfmts-vflip  | 2 +-
 tests/ref/lavf/pixfmt| 2 +-
 tests/ref/vsynth/vsynth1-svq1| 8 
 tests/ref/vsynth/vsynth2-svq1| 8 
 tests/ref/vsynth/vsynth3-svq1| 8 
 20 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 8a9475c..b3f4c6d 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -217,7 +217,7 @@ static const AVPixFmtDescriptor 
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
 .name = "yuv410p",
 .nb_components = 3,
 .log2_chroma_w = 2,
-.log2_chroma_h = 2,
+.log2_chroma_h = 1,
 .comp = {
 { 0, 1, 0, 0, 8, 0, 7, 1 },/* Y */
 { 1, 1, 0, 0, 8, 0, 7, 1 },/* U */
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 546eb44..f9730be 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -65,7 +65,7 @@ enum AVPixelFormat {
 AV_PIX_FMT_BGR24, ///< packed RGB 8:8:8, 24bpp, BGRBGR...
 AV_PIX_FMT_YUV422P,   ///< planar YUV 4:2:2, 16bpp, (1 Cr & Cb sample per 
2x1 Y samples)
 AV_PIX_FMT_YUV444P,   ///< planar YUV 4:4:4, 24bpp, (1 Cr & Cb sample per 
1x1 Y samples)
-AV_PIX_FMT_YUV410P,   ///< planar YUV 4:1:0,  9bpp, (1 Cr & Cb sample per 
4x4 Y samples)
+AV_PIX_FMT_YUV410P,   ///< planar YUV 4:1:0,  9bpp, (1 Cr & Cb sample per 
4x2 Y samples)
 AV_PIX_FMT_YUV411P,   ///< planar YUV 4:1:1, 12bpp, (1 Cr & Cb sample per 
4x1 Y samples)
 AV_PIX_FMT_GRAY8, ///

Re: [FFmpeg-devel] [PATCH 2/2 v2] fate: add readvitc filter test

[Tobias Rapp]

On 16.04.2016 23:25, Michael Niedermayer wrote:
> On Fri, Apr 15, 2016 at 09:49:46AM +0200, Tobias Rapp wrote:
>> Attached an updated patch, rebased onto current git master.
>>
>> The sample file for the FATE test can be found at:
>> https://cerebrum.noa-archive.com/noacloud/public.php?service=filest=88eeb716819bba39584be03c2d1f053b
>>  (1.4MB)
> 
> wget 
> https://cerebrum.noa-archive.com/noacloud/public.php?service=filest=88eeb716819bba39584be03c2d1f053b
> --2016-04-16 23:25:03--  
> https://cerebrum.noa-archive.com/noacloud/public.php?service=filest=88eeb716819bba39584be03c2d1f053b
> Resolving cerebrum.noa-archive.com (cerebrum.noa-archive.com)... 78.46.20.104
> Connecting to cerebrum.noa-archive.com 
> (cerebrum.noa-archive.com)|78.46.20.104|:443... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 2016-04-16 23:25:03 ERROR 404: Not Found.
> 

Sorry, it seems I dropped a "&" in the link and there was an intermediate HTML 
redirection page which breaks downloading with wget. The following command 
should work:

wget -O sample-vitc.avi 
'https://cerebrum.noa-archive.com/noacloud/public.php?service=files=88eeb716819bba39584be03c2d1f053b'

Regards,
Tobias

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