Re: [FFmpeg-devel] [PATCH 2/5] avcodec/dcaenc: move channel reordering tables to dcaenc.h

2016-04-30 Thread James Almer 
On 4/27/2016 2:20 PM, foo86 wrote:
> DCA core decoder no longer uses fixed tables for channel reordering.
> Move them into private encoder header (and drop ff_dca_ prefix).
> ---
>  libavcodec/dcadata.c | 42 --
>  libavcodec/dcadata.h |  5 -
>  libavcodec/dcaenc.c  |  6 +++---
>  libavcodec/dcaenc.h  | 42 ++
>  4 files changed, 45 insertions(+), 50 deletions(-)

Applied.

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

Re: [FFmpeg-devel] [PATCH 1/5] avcodec/dcaenc: reuse shared quant levels table

2016-04-30 Thread James Almer 
On 4/27/2016 2:19 PM, foo86 wrote:
> ---
>  libavcodec/dcaenc.c | 8 
>  libavcodec/dcaenc.h | 7 ---
>  2 files changed, 4 insertions(+), 11 deletions(-)

Applied.

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

Re: [FFmpeg-devel] [PATCH 57/57] support for matrox m703 mpeg-2

2016-04-30 Thread Michael Niedermayer 
On Sun, May 01, 2016 at 12:16:57AM +0200, Piotr Bandurski wrote:
> > On Tue, 26 Apr 2016 17:11:26 +0300
> > Александр Слободенюк  wrote:
> > 
> > >  { AV_CODEC_ID_MPEG2VIDEO,   MKTAG('M', '7', '0', '1') },
> > > +{ AV_CODEC_ID_MPEG2VIDEO,   MKTAG('M', '7', '0', '3') },
> > >  { AV_CODEC_ID_MPEG2VIDEO,   MKTAG('M', '7', '0', '5') },
> > 
> > i wonder if we can add m702 + m704 as well? i do not have samples but
> > it looks like mpeg2 from the information i have.
> 
> I think that decoding errors should be fixed first which happens with sample 
> from ticket #2616 (M704).

fixed the errors and added M704
note, there seems some extra stuff in there, i guess that is alpha
coded in a way similar to the luma, but i didnt try to revese engeneer
& implement decoding that.
But should be relatively easy

[...]
-- 
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] avformat/riff: assign g721 and g723codec tags to g726 decoder

2016-04-30 Thread Piotr Bandurski 
> > On Wed, 27 Apr 2016 20:39:34 +0200
> Piotr Bandurski  wrote:
> 
> > Subject: [PATCH] avformat/riff: assign g721 and g723 codec tags to
> > g726 decoder
> 
> > + { AV_CODEC_ID_ADPCM_G726, 0x0014 },
> > + { AV_CODEC_ID_ADPCM_G726, 0x0040 },
> 
> i wonder if we should make a comment that these are different codecs,
> in the unlikely eventuality that we split 721 723 and 726 decoders from
> one another?
> 
> > + { AV_CODEC_ID_ADPCM_G726, 0x0014 }, /* g723 Antex */
> > + { AV_CODEC_ID_ADPCM_G726, 0x0040 }, /* g721 Antex */
> 
> ?

I'm ok with this change.

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mpegts: Skip over broken 0x80 headers

2016-04-30 Thread Marton Balint 

On Sat, 30 Apr 2016, Michael Niedermayer wrote:


On Sat, Apr 30, 2016 at 10:12:11AM -0400, Ronald S. Bultje wrote:



Please revert it.


I would like to see the oppinion of the people who maintain
the mpeg ts demuxer before its reverted.
MAINTAINERs lists Marton for mpegts.c
in practice i did try to maintain the code a bit over the last few
years as well, mostly because noone else did it ...


Yep, I got involved in mpegts when I implemeneted teletext pts generation 
and while at it I also fixed some existing bugs. That said, I have less 
knowledge about mpegts compared to other areas of the codebase I 
maintain, so in practice this really is a shared maintainership among me 
and Michael.


For the current case, I personally don't find this patch intrusive enough 
to care, that is why I also don't quite understand the heated argument 
about it. IMHO this whole thread already took more time from capable 
developers than maitaining that additional 3 lines of code in the next 
few years.


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

[FFmpeg-devel] [PATCH] ffplay: force setting alsa buffer size

2016-04-30 Thread Marton Balint 
Signed-off-by: Marton Balint 
---
 ffplay.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/ffplay.c b/ffplay.c
index 804bcbc..d5fcde8 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -3781,6 +3781,7 @@ int main(int argc, char **argv)
 int flags;
 VideoState *is;
 char dummy_videodriver[] = "SDL_VIDEODRIVER=dummy";
+char alsa_bufsize[] = "SDL_AUDIO_ALSA_SET_BUFFER_SIZE=1";
 
 av_log_set_flags(AV_LOG_SKIP_REPEATED);
 parse_loglevel(argc, argv, options);
@@ -3818,6 +3819,12 @@ int main(int argc, char **argv)
 flags = SDL_INIT_VIDEO | SDL_INIT_AUDIO | SDL_INIT_TIMER;
 if (audio_disable)
 flags &= ~SDL_INIT_AUDIO;
+else {
+/* Try to work around an occasional ALSA buffer underflow issue when 
the
+ * period size is NPOT due to ALSA resampling by forcing the buffer 
size. */
+if (!SDL_getenv("SDL_AUDIO_ALSA_SET_BUFFER_SIZE"))
+SDL_putenv(alsa_bufsize);
+}
 if (display_disable)
 SDL_putenv(dummy_videodriver); /* For the event queue, we always need 
a video driver. */
 #if !defined(_WIN32) && !defined(__APPLE__)
-- 
2.6.6

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mpegts: Skip over broken 0x80 headers

2016-04-30 Thread Michael Niedermayer 
On Sat, Apr 30, 2016 at 10:12:11AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Sat, Apr 30, 2016 at 9:02 AM, Carl Eugen Hoyos  wrote:
> 
> > > cane please revert this patch?
> > > I don't think there's wide support for it.
> >

> > Two developers seem to wait for an explanation why it should be reverted.

i think this comment is not helping to resolve things, its possibly
also not accurate, i wasnt waiting on anything in case iam the 2nd
devel, i just worked on other things and did not read this thread
for a day or 2


> 
> 
> Last time I checked, commits were not free-for-all, but should be done only
> after main concerns have been addressed.
> 
> I've raised a main concern, and several developers have expressed support
> for the concern.
> 

> The patch should not have been committed.

The patch was posted to the mailing list and noone objected to it
or asked to wait, it was commited 2 weeks after being posted.


> Please revert it.

I would like to see the oppinion of the people who maintain
the mpeg ts demuxer before its reverted.
MAINTAINERs lists Marton for mpegts.c
in practice i did try to maintain the code a bit over the last few
years as well, mostly because noone else did it ...

Maintaince burden was mentioned in this thread. I think the oppinion
of the people maintaining the code thus is important

If people want my oppinion, iam not sure if these 3 lines of code
would cause more burden than the potential of redebuging and re-fixing
this issue if a 2nd such file is found.
I think if the fix is removed it should at least be replaced by a
av_log warning so no time is wasted in debuging this again


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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH] ffplay: use 48 kHz for ALSA output

2016-04-30 Thread Marton Balint 


On Thu, 21 Apr 2016, Reimar Döffinger wrote:


On 20.04.2016, at 23:59, Marton Balint  wrote:


Signed-off-by: Marton Balint 
---
ffplay.c | 5 +
1 file changed, 5 insertions(+)

diff --git a/ffplay.c b/ffplay.c
index 804bcbc..89a34d2 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -2578,12 +2578,17 @@ static int audio_open(void *opaque, int64_t 
wanted_channel_layout, int wanted_nb
static const int next_nb_channels[] = {0, 0, 1, 6, 2, 6, 4, 6};
static const int next_sample_rates[] = {0, 44100, 48000, 96000, 192000};
int next_sample_rate_idx = FF_ARRAY_ELEMS(next_sample_rates) - 1;
+char driver_name[32];

env = SDL_getenv("SDL_AUDIO_CHANNELS");
if (env) {
wanted_nb_channels = atoi(env);
wanted_channel_layout = 
av_get_default_channel_layout(wanted_nb_channels);
}
+/* By using the default dmix sample rate we should be able to avoid the
+ * ALSA resampler because using it causes small buffers and underruns. */


That only makes sense if the alsa device used actually uses dmix. Plus I 
am generally sceptical about such a hackish workaround (in particular 
making assumptions on internals like default sample rate) for what 
sounds like an ALSA issue (assuming we can't/shouldn't just request a 
larger buffer or query the "native" sample rate).


You're right, this is a hack, and probably alsa is buggy, or SDL could 
create the player differently. I tried to reproduce the issue 
with pure alsa, unfotunately without success.


In the meantime I also found another workaround, setting the 
SDL_AUDIO_ALSA_SET_BUFFER_SIZE environment variable, as this causes the 
initialized alsa buffer to have 4 periods instead of 2, which also makes 
the issue disappear. Setting this (if the variable is not already defined) 
is an acceptable workaround?


I see little chance of me digging into the deep of ALSA, I have no better 
idea which benefits everybody other than setting the 
SDL_AUDIO_ALSA_SET_BUFFER_SIZE environment variable.


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

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

2016-04-30 Thread Christophe Gisquet 
---
 tests/fate/lossless-audio.mak   | 5 -
 tests/ref/fate/lossless-wma24-1 | 1 +
 tests/ref/fate/lossless-wma24-2 | 1 +
 3 files changed, 6 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/fate/lossless-wma24-1
 create mode 100644 tests/ref/fate/lossless-wma24-2

diff --git a/tests/fate/lossless-audio.mak b/tests/fate/lossless-audio.mak
index 58641ab..dbd0c0e 100644
--- a/tests/fate/lossless-audio.mak
+++ b/tests/fate/lossless-audio.mak
@@ -25,8 +25,11 @@ 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-1 fate-lossless-wma24-2
 fate-lossless-wma: CMD = md5 -i 
$(TARGET_SAMPLES)/lossless-audio/luckynight-partial.wma -f s16le -frames 209
+fate-lossless-wma24-1: CMD = md5 -i 
$(TARGET_SAMPLES)/lossless-audio/master_audio_2.0_24bit.wma -f s24le
+fate-lossless-wma24-2: CMD = md5 -i 
$(TARGET_SAMPLES)/lossless-audio/Mega_Weird_Audio_Test_24bit.wma -f s24le
+fate-lossless-wmall: fate-lossless-wma fate-lossless-wma24-1 
fate-lossless-wma24-2
 
 FATE_SAMPLES_LOSSLESS_AUDIO += $(FATE_SAMPLES_LOSSLESS_AUDIO-yes)
 
diff --git a/tests/ref/fate/lossless-wma24-1 b/tests/ref/fate/lossless-wma24-1
new file mode 100644
index 000..ddee31c
--- /dev/null
+++ b/tests/ref/fate/lossless-wma24-1
@@ -0,0 +1 @@
+9ade91f506bc025854f6ffea0d635bc6
diff --git a/tests/ref/fate/lossless-wma24-2 b/tests/ref/fate/lossless-wma24-2
new file mode 100644
index 000..5ebdfd1
--- /dev/null
+++ b/tests/ref/fate/lossless-wma24-2
@@ -0,0 +1 @@
+908ec5c16f497bf7d5658d2689d125c8
-- 
2.8.1

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

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

2016-04-30 Thread 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 | 146 +---
 1 file changed, 84 insertions(+), 62 deletions(-)

diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c
index 9d56d97..f3a2217 100644
--- a/libavcodec/wmalosslessdec.c
+++ b/libavcodec/wmalosslessdec.c
@@ -147,9 +147,9 @@ typedef struct WmallDecodeCtx {
 int scaling;
 int coefsend;
 int bitsend;
-DECLARE_ALIGNED(16, int32_t, coefs)[MAX_ORDER + 
WMALL_COEFF_PAD_SIZE/sizeof(int16_t)];
-DECLARE_ALIGNED(16, int32_t, lms_prevvalues)[MAX_ORDER * 2 + 
WMALL_COEFF_PAD_SIZE/sizeof(int16_t)];
-DECLARE_ALIGNED(16, int32_t, lms_updates)[MAX_ORDER * 2 + 
WMALL_COEFF_PAD_SIZE/sizeof(int16_t)];
+DECLARE_ALIGNED(16, int32_t, coefs)[MAX_ORDER + 
WMALL_COEFF_PAD_SIZE/sizeof(int32_t)];
+DECLARE_ALIGNED(16, int32_t, lms_prevvalues)[MAX_ORDER * 2 + 
WMALL_COEFF_PAD_SIZE/sizeof(int32_t)];
+DECLARE_ALIGNED(16, int32_t, lms_updates)[MAX_ORDER * 2 + 
WMALL_COEFF_PAD_SIZE/sizeof(int32_t)];
 int recent;
 } cdlms[WMALL_MAX_CHANNELS][9];
 
@@ -458,6 +458,7 @@ static int decode_cdlms(WmallDecodeCtx *s)
 int cdlms_send_coef = get_bits1(>gb);
 
 for (c = 0; c < s->num_channels; c++) {
+int shift = s->bits_per_sample > 16 ? 0 : 1;
 s->cdlms_ttl[c] = get_bits(>gb, 3) + 1;
 for (i = 0; i < s->cdlms_ttl[c]; i++) {
 s->cdlms[c][i].order = (get_bits(>gb, 7) + 1) * 8;
@@ -495,14 +496,20 @@ 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 {
+int16_t *ptr = (int16_t*)s->cdlms[c][i].coefs;
+for (j = 0; j < s->cdlms[c][i].coefsend; j++)
+ptr[j] = (get_bits(>gb, s->cdlms[c][i].bitsend) << 
shift_l) >> shift_r;
+}
 }
 }
 
 for (i = 0; i < s->cdlms_ttl[c]; i++)
-memset(s->cdlms[c][i].coefs + s->cdlms[c][i].order,
+memset(s->cdlms[c][i].coefs + (s->cdlms[c][i].order >> shift),
0, WMALL_COEFF_PAD_SIZE);
 }
 
@@ -694,32 +701,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 (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));
-}
-
 static void use_high_update_speed(WmallDecodeCtx *s, int ich)
 {
 int ilms, recent, icoef;
@@ -727,12 +708,16 @@ 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->bV3RTM) {
+if (s->bits_per_sample > 16) {
+int32_t *updates = s->cdlms[ich][ilms].lms_updates;
+if (s->bV3RTM) updates += recent;
 for (icoef = 0; icoef < s->cdlms[ich][ilms].order; icoef++)
-s->cdlms[ich][ilms].lms_updates[icoef + recent] *= 2;
+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++)
-s->cdlms[ich][ilms].lms_updates[icoef] *= 2;
+updates[icoef] *= 2;
 }
 }
 s->update_speed[ich] = 16;
@@ -745,42 +730,76 @@ static void use_normal_update_speed(WmallDecodeCtx *s, 
int ich)

[FFmpeg-devel] [PATCH 5/5] wmalossless: silence a sample request

2016-04-30 Thread Christophe Gisquet 
16bits samples with CDLMS orders of 8 are currently unsupported, but have never
been encountered before.

However, 8 seems to be the most frequent, if not the only order used for 24bits.
In that case, the dsp functions are fine with handling order that are multiples
of 8, so silence the warning.
---
 libavcodec/wmalosslessdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c
index f3a2217..83b3174 100644
--- a/libavcodec/wmalosslessdec.c
+++ b/libavcodec/wmalosslessdec.c
@@ -469,7 +469,7 @@ static int decode_cdlms(WmallDecodeCtx *s)
 s->cdlms[0][0].order = 0;
 return AVERROR_INVALIDDATA;
 }
-if(s->cdlms[c][i].order & 8) {
+if(s->cdlms[c][i].order & 8 && s->bits_per_sample == 16) {
 static int warned;
 if(!warned)
 avpriv_request_sample(s->avctx, "CDLMS of order %d",
-- 
2.8.1

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

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

2016-04-30 Thread 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| 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

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

2016-04-30 Thread 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 0/5] wmalossless: fix 16bits speed regression v2

2016-04-30 Thread Christophe Gisquet 
Patch 2 is the squashing of several previous commits, as there were
no opinion on their contents nor the way to go.

The SSE4 one is the final version from its last thread.

The last patch in this set is new, and silences a warning that's only
meaningful for 16bits content.

Christophe Gisquet (5):
  fate: wma: add lossless 24bits test
  wmalossless: allow calling madd_int16
  x86: lossless audio: SSE4 madd 32bits
  lossless audio dsp: unroll
  wmalossless: silence a sample request

 libavcodec/lossless_audiodsp.c  |  12 ++-
 libavcodec/wmalosslessdec.c | 148 ++--
 libavcodec/x86/lossless_audiodsp.asm|  31 +--
 libavcodec/x86/lossless_audiodsp_init.c |   7 ++
 tests/fate/lossless-audio.mak   |   5 +-
 tests/ref/fate/lossless-wma24-1 |   1 +
 tests/ref/fate/lossless-wma24-2 |   1 +
 7 files changed, 131 insertions(+), 74 deletions(-)
 create mode 100644 tests/ref/fate/lossless-wma24-1
 create mode 100644 tests/ref/fate/lossless-wma24-2

-- 
2.8.1

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mpegts: Skip over broken 0x80 headers

2016-04-30 Thread James Almer 
On 4/30/2016 11:12 AM, Ronald S. Bultje wrote:
> Hi,
> 
> On Sat, Apr 30, 2016 at 9:02 AM, Carl Eugen Hoyos  wrote:
> 
>>> cane please revert this patch?
>>> I don't think there's wide support for it.
>>
>> Two developers seem to wait for an explanation why it should be reverted.
> 
> 
> Last time I checked, commits were not free-for-all, but should be done only
> after main concerns have been addressed.
> 
> I've raised a main concern, and several developers have expressed support
> for the concern.
> 
> The patch should not have been committed. Please revert it.

It's not his commit. No need to ask or waste your time arguing with him about
it.

> 
> And lastly, please stop arguing for the sole sake of having an argument
> with me (us) where you show how politically clever you are. I don't care
> about any of that. I just ask you to revert the patch. Focus on that, and
> that alone.
> 
> Thank you,
> Ronald
> ___
> 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/2] avformat/mpegts: Skip over broken 0x80 headers

2016-04-30 Thread Ronald S. Bultje 
Hi,

On Sat, Apr 30, 2016 at 9:02 AM, Carl Eugen Hoyos  wrote:

> > cane please revert this patch?
> > I don't think there's wide support for it.
>
> Two developers seem to wait for an explanation why it should be reverted.


Last time I checked, commits were not free-for-all, but should be done only
after main concerns have been addressed.

I've raised a main concern, and several developers have expressed support
for the concern.

The patch should not have been committed. Please revert it.

And lastly, please stop arguing for the sole sake of having an argument
with me (us) where you show how politically clever you are. I don't care
about any of that. I just ask you to revert the patch. Focus on that, and
that alone.

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mpegts: Skip over broken 0x80 headers

2016-04-30 Thread Nicolas George 
Le duodi 12 floréal, an CCXXIV, Carl Eugen Hoyos a écrit :
> Why?
> Does it brake something?

It increases the maintenance burden. Fixing the file itself would have no
such consequence, and make it work with other software too.

Also, could you please fix your mail software so that it does not break
threads? I have noticed it a few days ago.

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] [PATCH 2/2] avformat/mpegts: Skip over broken 0x80 headers

2016-04-30 Thread Carl Eugen Hoyos 
Hi!

> cane please revert this patch?

Why?
Does it brake something?

> I don't think there's wide support for it.

Two developers seem to wait for an explanation why it should be reverted.

> If  we find out more about the origins of the file, we can revisit this 
> issue. 

I thought the file is a broken network dump, is this wrong?

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mpegts: Skip over broken 0x80 headers

2016-04-30 Thread Ronald S. Bultje 
Hi,

On Fri, Apr 29, 2016 at 9:08 AM, Michael Niedermayer  wrote:

> On Fri, Apr 29, 2016 at 08:09:34AM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Fri, Apr 29, 2016 at 7:52 AM, Carl Eugen Hoyos 
> wrote:
> >
> > > I was under the impression that the only reason that demuxers and
> decoders
> > > are written like that is that we all want FFmpeg to support invalid
> streams
> > > as long as this doesn't affect valid streams.
> >
> >
> > It's too broad. I want to know the origin so we know the scope of this
> > problem. All we know is that somehow, one file came into existence and
> this
> > patch fixes this one file. I have doubts that multiple of these files
> > exist. If so, then what exactly do we gain from this "enhancement"? Our
> > codebase is full of this crap, and it becomes harder and harder to do
> > actual work because of these hacks.
>
> i dont know about this specific commit but more generally the case of
> "RTP encapsulations remaining in the data stream" was more widespread,
> for example longer ago there where users trying to play H263 streams
> encapsulated in RTP
> i do not know if these as a sideeffect of other changes can be
> played now or if that just stoped being an issue due to h263 being
> less common or something else ...
>
>
> >
> > At least the baby monitor (supposedly) is a class of files. This patch
> > doesn't fix one class, it fixes just one. And we have no idea where that
> > one came from.
>
> > You don't even seem mildly concerned that under your current
> > assumed "rule", anyone can generate any slightly-broken file to
> auto-amend
> > any decoder or demuxer in ffmpeg with any change whatsoever without
> concern
> > for code validity, code cleanliness or anything else.
>
> Has this ever happened ?
> Also what about the work needed to verify the widespreadness and
> origin of a type of file.
> A task that could be very difficult


You're asking questions that make the main issue stick around longer: can
we please revert this patch? I don't think there's wide support for it. If
we find out more about the origins of the file, we can revisit this issue.

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

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

2016-04-30 Thread Christophe Gisquet 
2016-04-29 10:50 GMT+02:00 Paul B Mahol :
> Should be OK if it doesn't break anything.

I'll resend the current state of this patchset for easier testing &
applying. Michael ran this under valgrind with nothing popping up, and
fate passes.

I think the remaining thing is: is the first version (with if inside
loops) preferred over the second version (macroing to reduce such
ifs)?

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