Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: improve junk skipping heuristic

2015-10-20 Thread wm4
On Tue, 20 Oct 2015 02:12:00 +0200
Michael Niedermayer  wrote:

> On Mon, Oct 19, 2015 at 11:12:03PM +0200, wm4 wrote:
> > Commit 2b3e9bbfb529e6bde238aeb511b55ebe461664c8 caused problems for a
> > certain API user:
> > 
> > https://code.google.com/p/chromium/issues/detail?id=537725
> > https://code.google.com/p/chromium/issues/detail?id=542032
> > 
> > The problem seems rather arbitrary, because if there's junk, anything
> > can happen. In this case, the imperfect junk skipping just caused it to
> > read different junk, from what I can see.
> > 
> > We can improve the accuracy of junk detection by a lot by checking if 2
> > consecutive frames use the same configuration. While in theory it might
> > be completely fine for the 1st frame to have a different format than the
> > 2nd frame, it's exceedingly unlikely, and I can't think of a legitimate
> > use-case.
> > 
> > This is approximately the same mpg123 does for junk skipping. The
> > set of compared header bits is the same as the libavcodec mp3 parser
> > uses for similar purposes.
> > ---
> > Now compares less header bits, as requested.
> > ---
> >  libavformat/mp3dec.c | 28 +---
> >  1 file changed, 21 insertions(+), 7 deletions(-)  
> 
> LGTM
> 
> thanks
> 
> [...]

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


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

2015-10-20 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_shuffleframes.c | 157 +
 3 files changed, 159 insertions(+)
 create mode 100644 libavfilter/vf_shuffleframes.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a095a10..8e776c1 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -215,6 +215,7 @@ OBJS-$(CONFIG_SETSAR_FILTER) += vf_aspect.o
 OBJS-$(CONFIG_SETTB_FILTER)  += settb.o
 OBJS-$(CONFIG_SHOWINFO_FILTER)   += vf_showinfo.o
 OBJS-$(CONFIG_SHOWPALETTE_FILTER)+= vf_showpalette.o
+OBJS-$(CONFIG_SHUFFLEFRAMES_FILTER)  += vf_shuffleframes.o
 OBJS-$(CONFIG_SHUFFLEPLANES_FILTER)  += vf_shuffleplanes.o
 OBJS-$(CONFIG_SIGNALSTATS_FILTER)+= vf_signalstats.o
 OBJS-$(CONFIG_SMARTBLUR_FILTER)  += vf_smartblur.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 3ab9a48..9385fdf 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -236,6 +236,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(SETTB,  settb,  vf);
 REGISTER_FILTER(SHOWINFO,   showinfo,   vf);
 REGISTER_FILTER(SHOWPALETTE,showpalette,vf);
+REGISTER_FILTER(SHUFFLEFRAMES,  shuffleframes,  vf);
 REGISTER_FILTER(SHUFFLEPLANES,  shuffleplanes,  vf);
 REGISTER_FILTER(SIGNALSTATS,signalstats,vf);
 REGISTER_FILTER(SMARTBLUR,  smartblur,  vf);
diff --git a/libavfilter/vf_shuffleframes.c b/libavfilter/vf_shuffleframes.c
new file mode 100644
index 000..97c4aa5
--- /dev/null
+++ b/libavfilter/vf_shuffleframes.c
@@ -0,0 +1,157 @@
+/*
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "libavutil/common.h"
+#include "libavutil/internal.h"
+#include "libavutil/opt.h"
+
+#include "avfilter.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct ShuffleFramesContext {
+const AVClass *class;
+char *mapping;
+AVFrame **frames;
+int *map;
+int64_t *pts;
+int in_frames;
+int nb_frames;
+} ShuffleFramesContext;
+
+static av_cold int init(AVFilterContext *ctx)
+{
+ShuffleFramesContext *s = ctx->priv;
+char *mapping, *saveptr = NULL, *p;
+int n, nb_items;
+
+mapping = av_strdup(s->mapping);
+if (!mapping)
+return AVERROR(ENOMEM);
+
+nb_items = 1;
+for (p = mapping; *p; p++) {
+if (*p == '|' || *p == ' ')
+nb_items++;
+}
+
+s->map= av_calloc(nb_items, sizeof(*s->map));
+s->pts= av_calloc(nb_items, sizeof(*s->pts));
+s->frames = av_calloc(nb_items, sizeof(*s->frames));
+if (!s->map || !s->frames || !s->pts) {
+return AVERROR(ENOMEM);
+}
+
+for (n = 0; n < nb_items; n++) {
+s->map[n] = -1;
+}
+
+for (n = 0; n < nb_items; n++) {
+char *map = av_strtok(n == 0 ? mapping : NULL, " |", );
+if (!map || sscanf(map, "%d", >map[n]) != 1)
+return AVERROR(EINVAL);
+if (s->map[n] < 0 || s->map[n] >= nb_items)
+return AVERROR(EINVAL);
+}
+
+s->nb_frames = nb_items;
+av_free(mapping);
+return 0;
+}
+
+static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
+{
+AVFilterContext*ctx = inlink->dst;
+ShuffleFramesContext *s = ctx->priv;
+int ret;
+
+if (s->in_frames < s->nb_frames) {
+s->frames[s->in_frames] = frame;
+s->pts[s->in_frames] = frame->pts;
+s->in_frames++;
+ret = 0;
+}
+
+if (s->in_frames == s->nb_frames) {
+int n, x;
+
+for (n = 0; n < s->nb_frames; n++) {
+AVFrame *out;
+
+x = s->map[n];
+out = av_frame_clone(s->frames[x]);
+out->pts = s->pts[n];
+ret = ff_filter_frame(ctx->outputs[0], out);
+s->in_frames--;
+}
+
+for (n = 0; n < s->nb_frames; n++)
+av_frame_free(>frames[n]);
+}
+
+return ret;
+}
+
+static av_cold void uninit(AVFilterContext *ctx)
+{
+ShuffleFramesContext *s = ctx->priv;
+
+

Re: [FFmpeg-devel] [PATCH] dca_parser: don't overwrite the sample rate, it may not be correct

2015-10-20 Thread Hendrik Leppkes
On Mon, Oct 19, 2015 at 3:50 AM, Michael Niedermayer
 wrote:
> On Sun, Oct 18, 2015 at 04:49:48PM +0200, Hendrik Leppkes wrote:
>> On Wed, Sep 30, 2015 at 1:09 PM, Hendrik Leppkes  wrote:
>> > The parser only reads the dca core sample rate, which is limited to a
>> > maximum of 48000 Hz, while X96 and HD extensions can increase the sample
>> > rate up to 192000 Hz.
>> >
>> > This change prevents the parser and decoder fighting over the sample rate,
>> > potentially confusing user applications. This also fixes sample rate
>> > display of >48000Hz files with ffmpeg/ffprobe when using libdcadec.
>> > ---
>> >  libavcodec/dca_parser.c | 1 -
>> >  1 file changed, 1 deletion(-)
>> >
>> > diff --git a/libavcodec/dca_parser.c b/libavcodec/dca_parser.c
>> > index 337a99d..70e64a8 100644
>> > --- a/libavcodec/dca_parser.c
>> > +++ b/libavcodec/dca_parser.c
>> > @@ -166,7 +166,6 @@ static int dca_parse(AVCodecParserContext *s, 
>> > AVCodecContext *avctx,
>> >  /* read the duration and sample rate from the frame header */
>> >  if (!dca_parse_params(buf, buf_size, , _rate, 
>> > >framesize)) {
>> >  s->duration= duration;
>> > -avctx->sample_rate = sample_rate;
>> >  } else
>> >  s->duration = 0;
>> >
>> > --
>> > 2.5.3.windows.1
>> >
>>
>> Any further comments? Otherwise I'm going to push this soon.
>
> i think the patch is ok
>

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


Re: [FFmpeg-devel] [PATCH] rtsp protocol : teardown packet not sent

2015-10-20 Thread Michael Niedermayer
On Sun, Oct 18, 2015 at 10:13:29PM +0200, Nicolas Adenis-Lamarre wrote:
> The rtsp protocol requires the client to send a packet at the end of the
> connexion.
> FFmpeg basic network function check wether the user aborted the
> communication and don't send the packet in this case.
> So the protocol is not respected.
> This commit removes the check. An other possibility would have to add an
> extra parameter to these functions to force the packet sending.

When the rt*p code and the connection is correctly functioning
then ff_check_interrupt() will return 0
When the code gets stuck due to the network connection or other
side failing then ff_check_interrupt() can return non zero if the
user application wants to get control back in a last ditch effort
before killing the process or thread.

Now i do no know enough to say what the problem is exactly
maybe this is a bug in the user application and it simply should not
use the interrupt callback to terminate things
or maybe the application has a good reason why it needs to use this
method, in which case maybe the API is too limited to indicate that
clean termination is requested instead of imedeate abortion of all
transfers.
If this is due to limitations of the API then extending the API is
welcome but it should be done in a way that doesnt break existing
user applications
I belive the patch here would break the case where a actual hard and
interruption is wanted because maybe all network communication would
timeout due to network being down or such

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- 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] libvpxenc: remove some unused ctrl id mappings

2015-10-20 Thread Michael Niedermayer
On Mon, Oct 19, 2015 at 10:49:16PM -0700, James Zern wrote:
> VP8E_UPD_ENTROPY, VP8E_UPD_REFERENCE, VP8E_USE_REFERENCE were removed
> from libvpx and the remaining values were never used here
> 
> Signed-off-by: James Zern 

LGTM

thx

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

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


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


Re: [FFmpeg-devel] [PATCHv2] avutil/mathematics: speed up av_gcd by using Stein's binary GCD algorithm

2015-10-20 Thread Ganesh Ajjanagadde
On Tue, Oct 20, 2015 at 12:52 AM, James Almer  wrote:
> On 10/11/2015 12:45 AM, Michael Niedermayer wrote:
>> On Sat, Oct 10, 2015 at 09:58:47PM -0400, Ganesh Ajjanagadde wrote:
>>> This uses Stein's binary GCD algorithm:
>>> https://en.wikipedia.org/wiki/Binary_GCD_algorithm
>>> to get a roughly 4x speedup over Euclidean GCD on standard architectures
>>> with a compiler intrinsic for ctzll, and a roughly 2x speedup otherwise.
>>> At the moment, the compiler intrinsic is used on GCC and Clang due to
>>> its easy availability.
>>>
>>> Quick note regarding overflow: yes, subtractions on int64_t can, but the
>>> llabs takes care of that. The llabs is also guaranteed to be safe, with
>>> no annoying INT64_MIN business since INT64_MIN being a power of 2, is
>>> shifted down before being sent to llabs.
>>>
>>> The binary GCD needs ff_ctzll, an extension of ff_ctz for long long 
>>> (int64_t). On
>>> GCC, this is provided by a built-in. On Microsoft, there is a
>>> BitScanForward64 analog of BitScanForward that should work; but I can't 
>>> confirm.
>>> Apparently it is not available on 32 bit builds; so this may or may not
>>> work correctly. On Intel, per the documentation there is only an
>>> intrinsic for _bit_scan_forward and people have posted on forums
>>> regarding _bit_scan_forward64, but often their documentation is
>>> woeful. Again, I don't have it, so I can't test.
>>>
>>> As such, to be safe, for now only the GCC/Clang intrinsic is added, the rest
>>> use a compiled version based on the De-Bruijn method of Leiserson et al:
>>> http://supertech.csail.mit.edu/papers/debruijn.pdf.
>>>
>>> Tested with FATE, sample benchmark (x86-64, GCC 5.2.0, Haswell)
>>> with a START_TIMER and STOP_TIMER in libavutil/rationsl.c, followed by a
>>> make fate.
>>>
>>> aac-am00_88.err:
>>> builtin:
>>> 714 decicycles in av_gcd,4095 runs,  1 skips
>>>
>>> de-bruijn:
>>> 1440 decicycles in av_gcd,4096 runs,  0 skips
>>>
>>> previous:
>>> 2889 decicycles in av_gcd,4096 runs,  0 skips
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavutil/intmath.h | 19 +++
>>>  libavutil/mathematics.c | 26 +-
>>>  2 files changed, 40 insertions(+), 5 deletions(-)
>>
>> applied
>>
>> thanks
>
> This broke fate with -ftrapv
> http://fate.ffmpeg.org/history.cgi?slot=x86_64-freebsd10-clang33-ftrapv
> http://fate.ffmpeg.org/history.cgi?slot=x86_64-openbsd5.6-gcc4.2-ftrapv
> I can reproduce this with GCC 5 on x86_64 ArchLinux as well.
>
> The problem seems to be in av_gcd() and not the De-Bruijn version of
> ff_ctzll since the gcc builtin is being used.

Don't have the time to investigate right now - revert for now unless
someone can fix it quickly.

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


Re: [FFmpeg-devel] [PATCH 1/2] libavformat/mxfenc.c: Fix segfault when writing an audio packet when there has not been a video one.

2015-10-20 Thread Marton Balint


On Mon, 19 Oct 2015, Tomas Härdin wrote:


On Mon, 2015-10-19 at 11:40 +0200, Alexis Ballier wrote:

On Mon, 19 Oct 2015 10:30:00 +0200
Michael Niedermayer  wrote:


On Fri, Oct 16, 2015 at 10:42:32AM +0200, Alexis Ballier wrote:

This happens when writing the trailer of a file containing audio
but that has not muxed any video packet. Fixes ticket #4817.




from IRC:
 maybe it should print a warning that there has been no
video?


maybe, but what would be the right condition ? just this case ? or when
writing any edit unit without video? or... ?
I haven't been able to find clear references on this (well, those smpte
specs I googled aren't esp. easy to read either), but e.g. the muxer
refuses to mux without exactly one video stream, so maybe, an empty
video stream is also an error; I don't know


I'm not particularly fond of second-guessing these kinds of things. D-10
is really anal about what constitutes a legal file, so it's probably
best not to write anything if something seems amiss. In the end, the
real test for correctness is whether the output works with all gear for
your particular use case. But segfaults are important to fix, so I'm not
too concerned here. Plus my main concern is mxfdec, not mxfenc.



Why not simply return error and print an error explaining "An audio packet 
was muxed before a video, this is not supported."


Segfault -> error is much better than segfault -> possibly broken file.

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


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

2015-10-20 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 doc/filters.texi   |  20 ++
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_shuffleframes.c | 159 +
 4 files changed, 181 insertions(+)
 create mode 100644 libavfilter/vf_shuffleframes.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 1af0a72..9ff5e24 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9945,6 +9945,26 @@ Set the size of the box used to represent one palette 
color entry. Default is
 @code{30} (for a @code{30x30} pixel box).
 @end table
 
+@section shuffleframes
+
+Reorder and/or duplicate video frames.
+
+It accepts the following parameters:
+
+@table @option
+@item mapping
+Set the destination indexes of input frames.
+This is space or '|' separated list of indexes that maps input frames to output
+frames. Number of indexes also sets maximal value that each index may have.
+@end table
+
+The first frame has the index 0. The default is to keep the input unchanged.
+
+Swap second and third frame of every three frames of the input:
+@example
+ffmpeg -i INPUT -vf "shuffleframes=0 2 1" OUTPUT
+@end example
+
 @section shuffleplanes
 
 Reorder and/or duplicate video planes.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a095a10..8e776c1 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -215,6 +215,7 @@ OBJS-$(CONFIG_SETSAR_FILTER) += vf_aspect.o
 OBJS-$(CONFIG_SETTB_FILTER)  += settb.o
 OBJS-$(CONFIG_SHOWINFO_FILTER)   += vf_showinfo.o
 OBJS-$(CONFIG_SHOWPALETTE_FILTER)+= vf_showpalette.o
+OBJS-$(CONFIG_SHUFFLEFRAMES_FILTER)  += vf_shuffleframes.o
 OBJS-$(CONFIG_SHUFFLEPLANES_FILTER)  += vf_shuffleplanes.o
 OBJS-$(CONFIG_SIGNALSTATS_FILTER)+= vf_signalstats.o
 OBJS-$(CONFIG_SMARTBLUR_FILTER)  += vf_smartblur.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 3ab9a48..9385fdf 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -236,6 +236,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(SETTB,  settb,  vf);
 REGISTER_FILTER(SHOWINFO,   showinfo,   vf);
 REGISTER_FILTER(SHOWPALETTE,showpalette,vf);
+REGISTER_FILTER(SHUFFLEFRAMES,  shuffleframes,  vf);
 REGISTER_FILTER(SHUFFLEPLANES,  shuffleplanes,  vf);
 REGISTER_FILTER(SIGNALSTATS,signalstats,vf);
 REGISTER_FILTER(SMARTBLUR,  smartblur,  vf);
diff --git a/libavfilter/vf_shuffleframes.c b/libavfilter/vf_shuffleframes.c
new file mode 100644
index 000..eb409c5
--- /dev/null
+++ b/libavfilter/vf_shuffleframes.c
@@ -0,0 +1,159 @@
+/*
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "libavutil/common.h"
+#include "libavutil/internal.h"
+#include "libavutil/opt.h"
+
+#include "avfilter.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct ShuffleFramesContext {
+const AVClass *class;
+char *mapping;
+AVFrame **frames;
+int *map;
+int64_t *pts;
+int in_frames;
+int nb_frames;
+} ShuffleFramesContext;
+
+static av_cold int init(AVFilterContext *ctx)
+{
+ShuffleFramesContext *s = ctx->priv;
+char *mapping, *saveptr = NULL, *p;
+int n, nb_items;
+
+nb_items = 1;
+for (p = s->mapping; *p; p++) {
+if (*p == '|' || *p == ' ')
+nb_items++;
+}
+
+s->map= av_calloc(nb_items, sizeof(*s->map));
+s->pts= av_calloc(nb_items, sizeof(*s->pts));
+s->frames = av_calloc(nb_items, sizeof(*s->frames));
+if (!s->map || !s->frames || !s->pts) {
+return AVERROR(ENOMEM);
+}
+
+mapping = av_strdup(s->mapping);
+if (!mapping)
+return AVERROR(ENOMEM);
+
+for (n = 0; n < nb_items; n++) {
+char *map = av_strtok(n == 0 ? mapping : NULL, " |", );
+if (!map || sscanf(map, "%d", >map[n]) != 1) {
+av_free(mapping);
+return AVERROR(EINVAL);
+}
+
+if (s->map[n] < 0 || s->map[n] >= nb_items) {
+av_log(ctx, AV_LOG_ERROR, "Index out of range.\n");
+

Re: [FFmpeg-devel] [PATCH] avfilter/vf_psnr: Add support for writing stats to stdout

2015-10-20 Thread Paul B Mahol
On 10/20/15, Tobias Rapp  wrote:
> Attached patch implements writing PSNR frame stats to standard output if
> the filename is "-".
>
> Regards,
> Tobias
>

Looks fine to me.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] Channel layout flags - Patch

2015-10-20 Thread Kevin Wells
I am looking for a patch so that when using the below Channel layout flags, the 
FC comes out flagged as 'Center', not Mono, and also the DL and DR comes out as 
'Left Total' 'Right Total'. Currently these 3 are coming out as 'Mono'. Is 
there a patch / command / flag to get these flagged correctly please?
The result currently comes out as: 
Video
Front Left
Front Right
Mono (should be Center)
Left Surround
Right Surround
Mono (should be Left Total)
Mono (shold be Right Total)

Here is the command: 
ffmpeg -i /Volumes/GRAID/EXPORTS/DESCRETE_TEST.mov -ss 45 -to 50 
-filter_complex \
"[0:1]pan=FL|c0=c0[FL]; \
 [0:1]pan=FR|c0=c1[FR]; \
 [0:1]pan=FC|c0=c2[FC]; \
 [0:1]pan=LFE|c0=c3[LFE]; \
 [0:1]pan=BL|c0=c4[BL]; \
 [0:1]pan=BR|c0=c5[BR]; \
 [0:1]pan=DL|c0=c6[DL]; \
 [0:1]pan=DR|c0=c7[DR]" \
-map v:0 \
-map "[FL]" \
-map "[FR]" \
-map "[FC]" \
-map "[LFE]" \
-map "[BL]" \
-map "[BR]" \
-map "[DL]" \
-map "[DR]" \
-vcodec prores -profile:v 3 -vtag apcn -f mov -y -c:a pcm_s24le 
/Volumes/GRAID/EXPORTS/DONE_TEST.mov

Below is the ffmpeg output from that. 
ffmpeg -i /Volumes/GRAID/EXPORTS/DESCRETE_TEST.mov -ss 45 -to 50 
-filter_complex \
> "[0:1]pan=FL|c0=c0[FL]; \
>  [0:1]pan=FR|c0=c1[FR]; \
>  [0:1]pan=FC|c0=c2[FC]; \
>  [0:1]pan=LFE|c0=c3[LFE]; \
>  [0:1]pan=BL|c0=c4[BL]; \
>  [0:1]pan=BR|c0=c5[BR]; \
>  [0:1]pan=DL|c0=c6[DL]; \
>  [0:1]pan=DR|c0=c7[DR]" \
> -map v:0 \
> -map "[FL]" \
> -map "[FR]" \
> -map "[FC]" \
> -map "[LFE]" \
> -map "[BL]" \
> -map "[BR]" \
> -map "[DL]" \
> -map "[DR]" \
> -vcodec prores -profile:v 3 -vtag apcn -f mov -y -c:a pcm_s24le 
> /Volumes/GRAID/EXPORTS/DONE_TEST.mov
ffmpeg version 2.8.1-tessus Copyright (c) 2000-2015 the FFmpeg developers
  built with Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
  configuration: --cc=/usr/bin/clang --prefix=/opt/ffmpeg --as=yasm 
--extra-version=tessus --enable-avisynth --enable-fontconfig --enable-gpl 
--enable-libass --enable-libbluray --enable-libfreetype --enable-libgsm 
--enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb 
--enable-libopencore-amrwb --enable-libopus --enable-libschroedinger 
--enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvidstab 
--enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis 
--enable-libvpx --enable-libwavpack --enable-libx264 --enable-libx265 
--enable-libxavs --enable-libxvid --enable-libzmq --enable-version3 
--disable-ffplay --disable-indev=qtkit --disable-indev=x11grab_xcb
  libavutil  54. 31.100 / 54. 31.100
  libavcodec 56. 60.100 / 56. 60.100
  libavformat56. 40.101 / 56. 40.101
  libavdevice56.  4.100 / 56.  4.100
  libavfilter 5. 40.101 /  5. 40.101
  libswscale  3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc53.  3.100 / 53.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 
'/Volumes/GRAID/EXPORTS/DESCRETE_TEST.mov':
  Metadata:
major_brand : qt  
minor_version   : 537199360
compatible_brands: qt  
creation_time   : 2015-10-20 14:25:55
  Duration: 00:01:37.08, start: 0.00, bitrate: 160894 kb/s
Stream #0:0(eng): Video: prores (apch / 0x68637061), yuv422p10le, 
1920x1080, 151675 kb/s, 24 fps, 24 tbr, 24 tbn, 24 tbc (default)
Metadata:
  creation_time   : 2015-10-20 14:25:55
  handler_name: Apple Alias Data Handler
  encoder : Apple ProRes 422 HQ
Stream #0:1(eng): Audio: pcm_s24le (lpcm / 0x6D63706C), 48000 Hz, 8 
channels (FL+FR+FC+LFE+SL+SR+DL+DR), s32 (24 bit), 9216 kb/s (default)
Metadata:
  creation_time   : 2015-10-20 14:28:55
  handler_name: Apple Alias Data Handler
[Parsed_pan_7 @ 0x7fe7d1e05dc0] Pure channel mapping detected: 7
[Parsed_pan_6 @ 0x7fe7d1e05b60] Pure channel mapping detected: 6
[Parsed_pan_5 @ 0x7fe7d1e05860] Pure channel mapping detected: 5
[Parsed_pan_4 @ 0x7fe7d1e05580] Pure channel mapping detected: 4
[Parsed_pan_3 @ 0x7fe7d1e05280] Pure channel mapping detected: 3
[Parsed_pan_2 @ 0x7fe7d1e04f80] Pure channel mapping detected: 2
[Parsed_pan_1 @ 0x7fe7d1e04ba0] Pure channel mapping detected: 1
[Parsed_pan_0 @ 0x7fe7d1e048c0] Pure channel mapping detected: 0
Output #0, mov, to '/Volumes/GRAID/EXPORTS/DONE_TEST.mov':
  Metadata:
major_brand : qt  
minor_version   : 537199360
compatible_brands: qt  
encoder : Lavf56.40.101
Stream #0:0(eng): Video: prores (apch) (apch / 0x68637061), yuv422p10le, 
1920x1080, q=2-31, 200 kb/s, 24 fps, 12288 tbn, 24 tbc (default)
Metadata:
  creation_time   : 2015-10-20 14:25:55
  handler_name: Apple Alias Data Handler
  encoder : Lavc56.60.100 prores
Stream #0:1: Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, 1 channels 
(FL), s32, 1152 kb/s (default)
Metadata:
  encoder : Lavc56.60.100 pcm_s24le
Stream #0:2: Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, 1 channels 
(FR), s32, 1152 kb/s
Metadata:
  encoder : Lavc56.60.100 pcm_s24le
Stream #0:3: Audio: 

[FFmpeg-devel] [PATCH] Adds support parsing the QuickTime Metadata Keys.

2015-10-20 Thread Tinglin Liu
The Apple dev specification:
https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/Metadata/Metadata.html
---
 libavformat/isom.h |  3 +++
 libavformat/mov.c  | 77 +-
 2 files changed, 74 insertions(+), 6 deletions(-)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 6e921c0..dba30a2 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -177,6 +177,9 @@ typedef struct MOVContext {
 int64_t duration; ///< duration of the longest track
 int found_moov;   ///< 'moov' atom has been found
 int found_mdat;   ///< 'mdat' atom has been found
+int found_hdlr_mdta;  ///< 'hdlr' atom with type 'mdta' has been found
+char **meta_keys;
+unsigned meta_keys_count;
 DVDemuxContext *dv_demux;
 AVFormatContext *dv_fctx;
 int isom; ///< 1 if file is ISO Media (mp4/3gp)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7c90d40..1ddd8cb 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -265,6 +265,7 @@ static int mov_read_udta_string(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 uint32_t data_type = 0, str_size, str_size_alloc;
 int (*parse)(MOVContext*, AVIOContext*, unsigned, const char*) = NULL;
 int raw = 0;
+int num = 0;
 
 switch (atom.type) {
 case MKTAG( '@','P','R','M'): key = "premiere_version"; raw = 1; break;
@@ -368,6 +369,11 @@ retry:
 av_log(c->fc, AV_LOG_ERROR, "Error parsing cover art.\n");
 }
 return ret;
+} else if (!key && c->found_hdlr_mdta && c->meta_keys) {
+uint32_t index = AV_RB32();
+if (index < c->meta_keys_count && c->meta_keys[index]) {
+key = c->meta_keys[index];
+}
 }
 } else return 0;
 } else if (atom.size > 4 && key && !c->itunes_metadata && !raw) {
@@ -394,8 +400,10 @@ retry:
 if (atom.size < 0 || str_size >= INT_MAX/2)
 return AVERROR_INVALIDDATA;
 
+// Allocates enough space if data_type is a float32 number, otherwise
 // worst-case requirement for output string in case of utf8 coded input
-str_size_alloc = (raw ? str_size : str_size * 2) + 1;
+num = (data_type == 23) ? 1 : 0;
+str_size_alloc = (num ? 512 : (raw ? str_size : str_size * 2)) + 1;
 str = av_mallocz(str_size_alloc);
 if (!str)
 return AVERROR(ENOMEM);
@@ -405,6 +413,10 @@ retry:
 else {
 if (!raw && (data_type == 3 || (data_type == 0 && (langcode < 0x400 || 
langcode == 0x7fff { // MAC Encoded
 mov_read_mac_string(c, pb, str_size, str, str_size_alloc);
+} else if (data_type == 23 && str_size >= 4) {  // BE float32
+union av_intfloat32 val;
+val.i = avio_rb32(pb);
+snprintf(str, str_size_alloc, "%f", val.f);
 } else {
 int ret = ffio_read_size(pb, str, str_size);
 if (ret < 0) {
@@ -599,11 +611,6 @@ static int mov_read_hdlr(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 char *title_str;
 int ret;
 
-if (c->fc->nb_streams < 1) // meta before first trak
-return 0;
-
-st = c->fc->streams[c->fc->nb_streams-1];
-
 avio_r8(pb); /* version */
 avio_rb24(pb); /* flags */
 
@@ -614,6 +621,15 @@ static int mov_read_hdlr(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 av_log(c->fc, AV_LOG_TRACE, "ctype= %.4s (0x%08x)\n", (char*), 
ctype);
 av_log(c->fc, AV_LOG_TRACE, "stype= %.4s\n", (char*));
 
+if (c->fc->nb_streams < 1) {  // meta before first trak
+if (type == MKTAG('m','d','t','a')) {
+c->found_hdlr_mdta = 1;
+}
+return 0;
+}
+
+st = c->fc->streams[c->fc->nb_streams-1];
+
 if (type == MKTAG('v','i','d','e'))
 st->codec->codec_type = AVMEDIA_TYPE_VIDEO;
 else if (type == MKTAG('s','o','u','n'))
@@ -3127,6 +3143,40 @@ static int mov_read_ilst(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 return ret;
 }
 
+static int mov_read_keys(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+uint32_t count;
+uint32_t i;
+
+if (atom.size < 8)
+return 0;
+
+avio_skip(pb, 4);
+count = avio_rb32(pb);
+if (count > UINT_MAX / sizeof(*c->meta_keys))
+return 0;
+
+av_freep(>meta_keys);
+c->meta_keys_count = count + 1;
+c->meta_keys = av_mallocz(c->meta_keys_count * sizeof(*c->meta_keys));
+if (!c->meta_keys)
+return AVERROR(ENOMEM);
+
+for (i = 1; i <= count; ++i) {
+uint32_t key_size = avio_rb32(pb);
+uint32_t type = avio_rl32(pb);
+if (type != MKTAG('m','d','t','a') || key_size < 8)
+return 0;
+key_size -= 8;
+c->meta_keys[i] = av_mallocz(key_size + 1);
+if (!c->meta_keys[i])
+return AVERROR(ENOMEM);
+avio_read(pb, c->meta_keys[i], key_size);
+}
+
+return 0;
+}
+
 static int mov_read_custom_2plus(MOVContext 

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

2015-10-20 Thread Clément Bœsch
On Tue, Oct 20, 2015 at 08:10:55PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi   |  20 ++
>  libavfilter/Makefile   |   1 +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/vf_shuffleframes.c | 159 
> +
>  4 files changed, 181 insertions(+)
>  create mode 100644 libavfilter/vf_shuffleframes.c
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 1af0a72..9ff5e24 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -9945,6 +9945,26 @@ Set the size of the box used to represent one palette 
> color entry. Default is
>  @code{30} (for a @code{30x30} pixel box).
>  @end table
>  
> +@section shuffleframes
> +
> +Reorder and/or duplicate video frames.
> +
> +It accepts the following parameters:
> +
> +@table @option
> +@item mapping
> +Set the destination indexes of input frames.
> +This is space or '|' separated list of indexes that maps input frames to 
> output
> +frames. Number of indexes also sets maximal value that each index may have.
> +@end table
> +
> +The first frame has the index 0. The default is to keep the input unchanged.
> +
> +Swap second and third frame of every three frames of the input:
> +@example
> +ffmpeg -i INPUT -vf "shuffleframes=0 2 1" OUTPUT
> +@end example
> +

No random shuffle of batches of frames?

[...]

-- 
Clément B.


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


Re: [FFmpeg-devel] [PATCH 2/2] pixblockdsp: Use memcpy for get_pixels_16_c

2015-10-20 Thread Michael Niedermayer
On Sat, Oct 17, 2015 at 06:05:46PM -0700, Timothy Gu wrote:
> Before:
>   15543 decicycles in get_pixels, 4193214 runs,   1090 skips
> After:
>5713 decicycles in get_pixels, 8387564 runs,   1044 skips
> ---
>  libavcodec/pixblockdsp.c  | 38 -
>  libavcodec/pixblockdsp_template.c | 40 
> ---
>  2 files changed, 33 insertions(+), 45 deletions(-)
>  delete mode 100644 libavcodec/pixblockdsp_template.c

breaks fate:

--- ./tests/ref/vsynth/vsynth1-dnxhd-720p-10bit 2015-10-17 19:12:46.567154035 
+0200
+++ tests/data/fate/vsynth1-dnxhd-720p-10bit2015-10-20 17:13:03.600463343 
+0200
@@ -1,4 +1,4 @@
-f8c4b7aa165a80df2485d526161290a3 
*tests/data/fate/vsynth1-dnxhd-720p-10bit.dnxhd
+cb729072a15682440da8a443f922ac8c 
*tests/data/fate/vsynth1-dnxhd-720p-10bit.dnxhd
 2293760 tests/data/fate/vsynth1-dnxhd-720p-10bit.dnxhd
-87f1f0e074466facd3a9922ecc8311db 
*tests/data/fate/vsynth1-dnxhd-720p-10bit.out.rawvideo
-stddev:6.23 PSNR: 32.23 MAXDIFF:   64 bytes:  7603200/   760320
+17bc71b58b687ffe06c13b99a5e55ac3 
*tests/data/fate/vsynth1-dnxhd-720p-10bit.out.rawvideo
+stddev:   32.92 PSNR: 17.78 MAXDIFF:  211 bytes:  7603200/   760320
Test vsynth1-dnxhd-720p-10bit failed. Look at 
tests/data/fate/vsynth1-dnxhd-720p-10bit.err for details.
make: *** [fate-vsynth1-dnxhd-720p-10bit] Error 1
make: *** Waiting for unfinished jobs
--- ./tests/ref/vsynth/vsynth1-dnxhd-1080i-10bit2015-10-17 
19:12:46.567154035 +0200
+++ tests/data/fate/vsynth1-dnxhd-1080i-10bit   2015-10-20 17:13:03.836463348 
+0200
@@ -1,4 +1,4 @@
-f562845d1848bf5d3e524b418b742e01 *tests/data/fate/vsynth1-dnxhd-1080i-10bit.mov
+90be2539a8ad5475cdda2421874ccfaa *tests/data/fate/vsynth1-dnxhd-1080i-10bit.mov
 4588391 tests/data/fate/vsynth1-dnxhd-1080i-10bit.mov
-31032fcb7e6af79daaac02288254c6d6 
*tests/data/fate/vsynth1-dnxhd-1080i-10bit.out.rawvideo
-stddev:5.69 PSNR: 33.02 MAXDIFF:   55 bytes:  7603200/   760320
+50a342f03d5b00a51b65804814c857ff 
*tests/data/fate/vsynth1-dnxhd-1080i-10bit.out.rawvideo
+stddev:   22.26 PSNR: 21.18 MAXDIFF:  233 bytes:  7603200/   760320
Test vsynth1-dnxhd-1080i-10bit failed. Look at 
tests/data/fate/vsynth1-dnxhd-1080i-10bit.err for details.
make: *** [fate-vsynth1-dnxhd-1080i-10bit] Error 1

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

Republics decline into democracies and democracies degenerate into
despotisms. -- 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] rtsp protocol : teardown packet not sent

2015-10-20 Thread Nicolas Adenis-Lamarre
Let's take the example of ffplay in which the code always fails.
ie : ffplay 'rtsp://
mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1=201=ld'
fails to respect the protocol in 100% of the cases.

When i close the window,
ffplay.c : stream_close() is called
=> is->abort_request = 1;
=> avformat_close_input(>ic);

then
rstpdec.c : rtsp_read_close(AVFormatContext *s)
=> ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
=> this call always fails because it calls sub routines like
network.c:ff_network_wait_fd_timeout which fails if interrupt is done.

In my humble opinion, network.c:ff_network_wait_fd_timeout should not
decicde to not send a packet because interrupt is done,
it makes it impossible to send a packet after the interrup is done, which
makes impossible to respect the rtsp protocol.
In my humble opinion, the choice should be done in the upper stacks.

This is why i made this patch.
An other suggestion if you fear to break something, is to add an extra
parameter called "ignore_interrupt", to add a check, but in the absolute, i
think the choice in my patch is preferable, even it could break things at
the beginning, the time, people find where to add correctly the interrupt
check at the good place, not in the low stack.

Nicolas



2015-10-20 15:50 GMT+02:00 Michael Niedermayer :

> On Sun, Oct 18, 2015 at 10:13:29PM +0200, Nicolas Adenis-Lamarre wrote:
> > The rtsp protocol requires the client to send a packet at the end of the
> > connexion.
> > FFmpeg basic network function check wether the user aborted the
> > communication and don't send the packet in this case.
> > So the protocol is not respected.
> > This commit removes the check. An other possibility would have to add an
> > extra parameter to these functions to force the packet sending.
>
> When the rt*p code and the connection is correctly functioning
> then ff_check_interrupt() will return 0
> When the code gets stuck due to the network connection or other
> side failing then ff_check_interrupt() can return non zero if the
> user application wants to get control back in a last ditch effort
> before killing the process or thread.
>
> Now i do no know enough to say what the problem is exactly
> maybe this is a bug in the user application and it simply should not
> use the interrupt callback to terminate things
> or maybe the application has a good reason why it needs to use this
> method, in which case maybe the API is too limited to indicate that
> clean termination is requested instead of imedeate abortion of all
> transfers.
> If this is due to limitations of the API then extending the API is
> welcome but it should be done in a way that doesnt break existing
> user applications
> I belive the patch here would break the case where a actual hard and
> interruption is wanted because maybe all network communication would
> timeout due to network being down or such
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> it is not once nor twice but times without number that the same ideas make
> their appearance in the world. -- Aristotle
>
> ___
> 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] rtsp protocol : teardown packet not sent

2015-10-20 Thread Michael Niedermayer
On Tue, Oct 20, 2015 at 06:16:12PM +0200, Nicolas Adenis-Lamarre wrote:
> Let's take the example of ffplay in which the code always fails.
> ie : ffplay 'rtsp://
> mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1=201=ld'
> fails to respect the protocol in 100% of the cases.
> 
> When i close the window,
> ffplay.c : stream_close() is called
> => is->abort_request = 1;
> => avformat_close_input(>ic);
> 
> then
> rstpdec.c : rtsp_read_close(AVFormatContext *s)
> => ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
> => this call always fails because it calls sub routines like
> network.c:ff_network_wait_fd_timeout which fails if interrupt is done.
> 
> In my humble opinion, network.c:ff_network_wait_fd_timeout should not
> decicde to not send a packet because interrupt is done,
> it makes it impossible to send a packet after the interrup is done, which
> makes impossible to respect the rtsp protocol.
> In my humble opinion, the choice should be done in the upper stacks.
> 
> This is why i made this patch.
> An other suggestion if you fear to break something, is to add an extra
> parameter called "ignore_interrupt", to add a check, but in the absolute, i
> think the choice in my patch is preferable, even it could break things at
> the beginning, the time, people find where to add correctly the interrupt
> check at the good place, not in the low stack.


avio.h:
/**
* Callback for checking whether to abort blocking functions.
* AVERROR_EXIT is returned in this case by the interrupted
* function. During blocking operations, callback is called with
* opaque as parameter. If the callback returns 1, the
* blocking operation will be aborted.
*
* No members can be added to this struct without a major bump, if
* new elements have been added after this struct in AVFormatContext
* or AVIOContext.
*/
typedef struct AVIOInterruptCB {

Thus if the callback is set for the protocol and if it returns 1
the fuction must abort if its (potentially) blocking. That also is
true for any teardown operations because they can block too.

you cannot just ignore the API as it is documented and disable
the interrupt callback machanism more or less entirely

What you can do is,
* extend/improve/fix the API
* change the user application to not return 1 from the callback
* not just copy the callback for the demuxer to the protocol used for
  tearing down the connection while still by some means ensuring that
  a user request for interrupting a possibly blocking demuxer is
  fullfilled
* There are probably other options, but the documented API must match
  the implementation and should be sane and also not do
  unexpected things to existing implementations writen based on the
  current API



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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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


Re: [FFmpeg-devel] [PATCHv2] avutil/mathematics: speed up av_gcd by using Stein's binary GCD algorithm

2015-10-20 Thread Ganesh Ajjanagadde
On Tue, Oct 20, 2015 at 12:52 AM, James Almer  wrote:
> On 10/11/2015 12:45 AM, Michael Niedermayer wrote:
>> On Sat, Oct 10, 2015 at 09:58:47PM -0400, Ganesh Ajjanagadde wrote:
>>> This uses Stein's binary GCD algorithm:
>>> https://en.wikipedia.org/wiki/Binary_GCD_algorithm
>>> to get a roughly 4x speedup over Euclidean GCD on standard architectures
>>> with a compiler intrinsic for ctzll, and a roughly 2x speedup otherwise.
>>> At the moment, the compiler intrinsic is used on GCC and Clang due to
>>> its easy availability.
>>>
>>> Quick note regarding overflow: yes, subtractions on int64_t can, but the
>>> llabs takes care of that. The llabs is also guaranteed to be safe, with
>>> no annoying INT64_MIN business since INT64_MIN being a power of 2, is
>>> shifted down before being sent to llabs.
>>>
>>> The binary GCD needs ff_ctzll, an extension of ff_ctz for long long 
>>> (int64_t). On
>>> GCC, this is provided by a built-in. On Microsoft, there is a
>>> BitScanForward64 analog of BitScanForward that should work; but I can't 
>>> confirm.
>>> Apparently it is not available on 32 bit builds; so this may or may not
>>> work correctly. On Intel, per the documentation there is only an
>>> intrinsic for _bit_scan_forward and people have posted on forums
>>> regarding _bit_scan_forward64, but often their documentation is
>>> woeful. Again, I don't have it, so I can't test.
>>>
>>> As such, to be safe, for now only the GCC/Clang intrinsic is added, the rest
>>> use a compiled version based on the De-Bruijn method of Leiserson et al:
>>> http://supertech.csail.mit.edu/papers/debruijn.pdf.
>>>
>>> Tested with FATE, sample benchmark (x86-64, GCC 5.2.0, Haswell)
>>> with a START_TIMER and STOP_TIMER in libavutil/rationsl.c, followed by a
>>> make fate.
>>>
>>> aac-am00_88.err:
>>> builtin:
>>> 714 decicycles in av_gcd,4095 runs,  1 skips
>>>
>>> de-bruijn:
>>> 1440 decicycles in av_gcd,4096 runs,  0 skips
>>>
>>> previous:
>>> 2889 decicycles in av_gcd,4096 runs,  0 skips
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavutil/intmath.h | 19 +++
>>>  libavutil/mathematics.c | 26 +-
>>>  2 files changed, 40 insertions(+), 5 deletions(-)
>>
>> applied
>>
>> thanks
>
> This broke fate with -ftrapv
> http://fate.ffmpeg.org/history.cgi?slot=x86_64-freebsd10-clang33-ftrapv
> http://fate.ffmpeg.org/history.cgi?slot=x86_64-openbsd5.6-gcc4.2-ftrapv
> I can reproduce this with GCC 5 on x86_64 ArchLinux as well.

Can't reproduce on GCC 5.2, ftrapv, x86_64 ArchLinux (checkasm fails
on ftrapv before and after the commit though). Are you sure it is this
commit that broke the ftrapv build? At least the "last good rev" on
fate.ffmpeg.org does not point to this commit or its parent.

>
> The problem seems to be in av_gcd() and not the De-Bruijn version of
> ff_ctzll since the gcc builtin is being used.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Channel layout flags - Patch

2015-10-20 Thread Nicolas George
Le nonidi 29 vendémiaire, an CCXXIV, Kevin Wells a écrit :
> I am looking for a patch so that when using the below Channel layout

If you are not proposing a patch, then this is a usage question and should
be on ffmpeg-user. Reply-to placed accordingly.

> flags, the FC comes out flagged as 'Center', not Mono, and also the DL and
> DR comes out as 'Left Total' 'Right Total'. Currently these 3 are coming
> out as 'Mono'. Is there a patch / command / flag to get these flagged
> correctly please?

> The result currently comes out as: 
> Video
> Front Left
> Front Right

How do you observe these "result"s?

> Mono (should be Center)

Center is the name of the channel, mono is the name of the channel layout
that has only the center channel. The output produced by ffmpeg is correct.

> Left Surround
> Right Surround

> Mono (should be Left Total)
> Mono (shold be Right Total)

Should be according to who?

> Press [q] to stop, [?] for help
> [pcm_s24le @ 0x7fe7d3007c00] not writing 'chan' tag due to lack of channel 
> information 
> [pcm_s24le @ 0x7fe7d3010a00] not writing 'chan' tag due to lack of channel 
> information

This may indicate that two of the layouts are not supported by FFmpeg's
implementation, I suspect the these are the downmix channels.

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] rtsp protocol : teardown packet not sent

2015-10-20 Thread Nicolas George
Le nonidi 29 vendémiaire, an CCXXIV, Nicolas Adenis-Lamarre a écrit :
> Probably i misunderstood again, but,
> I don't understand however in which case an application would use a
> callback to avoid any io at all.
> For example, i don't understand why ffplay, when a user close the window,
> choose to avoid any io at all.

Any I/O can cause delay. When the user close the window, they want it to
close immediately, not in five seconds. Even a tenth of a second gives a
noticeable lag, it is not annoying in itself bug will cause the user to
unconsciously consider the program badly finished.

> in ffplay.c, would it be ok to change
> static int decode_interrupt_cb(void *ctx) { return ctx->abort_request; }
> by
> static int decode_interrupt_cb(void *ctx) { return 0; }
> ?
> (i don't think so)

Look at the code:

static void stream_close(VideoState *is)
{
/* XXX: use a special url_shutdown call to abort parse cleanly */
is->abort_request = 1;
SDL_WaitThread(is->read_tid, NULL);

The author was well aware of the issue, but interrupting the network flow is
simpler.

Note that it should not matter: the teardown packet is required by the
protocol, but the closure is also transmitted by other means (probably TCP
RST or ICMP, depending on the transport layer used), and if the server does
not take it into account, blame it for being stupid.

> * change the user application to not return 1 from the callback
> => i could, but i'm afraid that even ffplay which is a part of ffmpeg has
> the problem.

As you can see, a correct implementation of the shutdown would be
appreciated. IMHO, the best way of doing so would be:

- queue an immediate display of having taken the user's request into
  account;

- start clean shutdown;

- wait a configurable amount of time and revert to interrupting the I/O.

All this is necessary because there are various causes for blocking; if
ffplay is stuck waiting for more data in the middle of a packet header but
the network went down, interrupting the I/O is the only solution.

> 2015-10-20 19:20 GMT+02:00 Michael Niedermayer :

Please remember not to top-post on this list; if you do not know what it
means, look it up.

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] rtsp protocol : teardown packet not sent

2015-10-20 Thread Nicolas Adenis-Lamarre
Thanks for your answer.
Thanks for your light. It's clear that my patch is wrong (even if it makes
ffplay working).
I've 2 solutions at the end, i hope that one of them could be valid for you.

For the moment, i still don't know what is the best way to fix it.

Probably i misunderstood again, but,
I don't understand however in which case an application would use a
callback to avoid any io at all.
For example, i don't understand why ffplay, when a user close the window,
choose to avoid any io at all.

in ffplay.c, would it be ok to change
static int decode_interrupt_cb(void *ctx) { return ctx->abort_request; }
by
static int decode_interrupt_cb(void *ctx) { return 0; }
?
(i don't think so)

* extend/improve/fix the API => hard to me to say if that's the good way
for the moment
"Callback for checking whether to abort blocking functions."
What i understand, is that ffmpeg has a callback(ff_check_interrupt) saying
that at some point, no more io must be done.

* change the user application to not return 1 from the callback
=> i could, but i'm afraid that even ffplay which is a part of ffmpeg has
the problem.
So, i guess it's not the only application to have the problem (kodi has
too, while it's my target).
More over, i don't think that application must known that in some case,
close must do io.

* not just copy the callback for the demuxer to the protocol used for
  tearing down the connection while still by some means ensuring that
  a user request for interrupting a possibly blocking demuxer is
  fullfilled
=> i think it would not respect the protocol, while it would bypass the io
callback.

* There are probably other options, but the documented API must match
  the implementation and should be sane and also not do
  unexpected things to existing implementations writen based on the
  current API
=> I agree

>>> so, because i would like to fix it, i suggest 2 things, tell me if one
of them could be ok or both have no chance to be validated :
1) as you suggested, bypass the check in the case of rtsp. It's not perfect
and i don't really like it, but i would make things working.

2) add an extra argument to tell the io is important or not and change the
api so that the blocking callback is only on non important io
by important, it could be protocol satisfaction, versus packet not
mandatory / not required / to abort if it is not so important.

Nicolas


2015-10-20 19:20 GMT+02:00 Michael Niedermayer :

> On Tue, Oct 20, 2015 at 06:16:12PM +0200, Nicolas Adenis-Lamarre wrote:
> > Let's take the example of ffplay in which the code always fails.
> > ie : ffplay 'rtsp://
> > mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1=201=ld
> '
> > fails to respect the protocol in 100% of the cases.
> >
> > When i close the window,
> > ffplay.c : stream_close() is called
> > => is->abort_request = 1;
> > => avformat_close_input(>ic);
> >
> > then
> > rstpdec.c : rtsp_read_close(AVFormatContext *s)
> > => ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
> > => this call always fails because it calls sub routines like
> > network.c:ff_network_wait_fd_timeout which fails if interrupt is done.
> >
> > In my humble opinion, network.c:ff_network_wait_fd_timeout should not
> > decicde to not send a packet because interrupt is done,
> > it makes it impossible to send a packet after the interrup is done, which
> > makes impossible to respect the rtsp protocol.
> > In my humble opinion, the choice should be done in the upper stacks.
> >
> > This is why i made this patch.
> > An other suggestion if you fear to break something, is to add an extra
> > parameter called "ignore_interrupt", to add a check, but in the
> absolute, i
> > think the choice in my patch is preferable, even it could break things at
> > the beginning, the time, people find where to add correctly the interrupt
> > check at the good place, not in the low stack.
>
>
> avio.h:
> /**
> * Callback for checking whether to abort blocking functions.
> * AVERROR_EXIT is returned in this case by the interrupted
> * function. During blocking operations, callback is called with
> * opaque as parameter. If the callback returns 1, the
> * blocking operation will be aborted.
> *
> * No members can be added to this struct without a major bump, if
> * new elements have been added after this struct in AVFormatContext
> * or AVIOContext.
> */
> typedef struct AVIOInterruptCB {
>
> Thus if the callback is set for the protocol and if it returns 1
> the fuction must abort if its (potentially) blocking. That also is
> true for any teardown operations because they can block too.
>
> you cannot just ignore the API as it is documented and disable
> the interrupt callback machanism more or less entirely
>
> What you can do is,
> * extend/improve/fix the API
> * change the user application to not return 1 from the callback
> * not just copy the callback for the demuxer to the protocol used for
>   tearing down the 

Re: [FFmpeg-devel] [PATCH 1/2] dnxhdenc: Optimize get_pixels_8x4_sym for 10-bit

2015-10-20 Thread Timothy Gu
On Tue, Oct 20, 2015 at 9:30 AM Michael Niedermayer 
wrote:

> On Sat, Oct 17, 2015 at 06:05:45PM -0700, Timothy Gu wrote:
> > This reverts commit 628e6d0164febc8e69b0f10dfa487e8a2dd1a28a and uses
> > a better fix.
> >
> > Before:
> > 4483 decicycles in get_pixels_8x4_sym,  131032 runs, 40 skips
> >
> > After:
> > 2569 decicycles in get_pixels_8x4_sym,  131054 runs, 18 skips
> > ---
> >  libavcodec/dnxhdenc.c | 24 
> >  1 file changed, 8 insertions(+), 16 deletions(-)
>
> LGTM
>

Applied.

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


Re: [FFmpeg-devel] [PATCH] pixblockdsp: Use memcpy for get_pixels_16_c

2015-10-20 Thread Ganesh Ajjanagadde
On Tue, Oct 20, 2015 at 4:20 PM, Timothy Gu  wrote:
> Before:
>   15543 decicycles in get_pixels, 4193214 runs,   1090 skips
> After:
>5713 decicycles in get_pixels, 8387564 runs,   1044 skips
> ---
>  libavcodec/pixblockdsp.c  | 36 ++-
>  libavcodec/pixblockdsp_template.c | 40 
> ---
>  2 files changed, 31 insertions(+), 45 deletions(-)
>  delete mode 100644 libavcodec/pixblockdsp_template.c
>
> diff --git a/libavcodec/pixblockdsp.c b/libavcodec/pixblockdsp.c
> index 322e1dd..0f23d8a 100644
> --- a/libavcodec/pixblockdsp.c
> +++ b/libavcodec/pixblockdsp.c
> @@ -23,12 +23,38 @@
>  #include "avcodec.h"
>  #include "pixblockdsp.h"
>
> -#define BIT_DEPTH 16
> -#include "pixblockdsp_template.c"
> -#undef BIT_DEPTH
> +static void get_pixels_16_c(int16_t *av_restrict block, const uint8_t 
> *pixels,
> +ptrdiff_t line_size)
> +{
> +memcpy(block + 0 * 8, pixels + 0 * line_size, sizeof(int16_t) * 8);
> +memcpy(block + 1 * 8, pixels + 1 * line_size, sizeof(int16_t) * 8);
> +memcpy(block + 2 * 8, pixels + 2 * line_size, sizeof(int16_t) * 8);
> +memcpy(block + 3 * 8, pixels + 3 * line_size, sizeof(int16_t) * 8);
> +memcpy(block + 4 * 8, pixels + 4 * line_size, sizeof(int16_t) * 8);
> +memcpy(block + 5 * 8, pixels + 5 * line_size, sizeof(int16_t) * 8);
> +memcpy(block + 6 * 8, pixels + 6 * line_size, sizeof(int16_t) * 8);
> +memcpy(block + 7 * 8, pixels + 7 * line_size, sizeof(int16_t) * 8);
> +}
> +
> +static void get_pixels_8_c(int16_t *av_restrict block, const uint8_t *pixels,
> +   ptrdiff_t line_size)
> +{
> +int i;
>
> -#define BIT_DEPTH 8
> -#include "pixblockdsp_template.c"
> +/* read the pixels */
> +for (i = 0; i < 8; i++) {
> +block[0] = pixels[0];
> +block[1] = pixels[1];
> +block[2] = pixels[2];
> +block[3] = pixels[3];
> +block[4] = pixels[4];
> +block[5] = pixels[5];
> +block[6] = pixels[6];
> +block[7] = pixels[7];
> +pixels  += line_size;
> +block   += 8;
> +}
> +}

out of curiosity: do you get gains for get_pixels_8_c as well? What I
am surprised to see is that even with the restrict keyword, a compiler
does not optimize the assignments within the loop to some sort of
block assignment (which I assume memcpy is doing).

>
>  static void diff_pixels_c(int16_t *av_restrict block, const uint8_t *s1,
>const uint8_t *s2, int stride)
> diff --git a/libavcodec/pixblockdsp_template.c 
> b/libavcodec/pixblockdsp_template.c
> deleted file mode 100644
> index d1e9102..000
> --- a/libavcodec/pixblockdsp_template.c
> +++ /dev/null
> @@ -1,40 +0,0 @@
> -/*
> - * This file is part of FFmpeg.
> - *
> - * FFmpeg is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU Lesser General Public
> - * License as published by the Free Software Foundation; either
> - * version 2.1 of the License, or (at your option) any later version.
> - *
> - * FFmpeg is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> - * Lesser General Public License for more details.
> - *
> - * You should have received a copy of the GNU Lesser General Public
> - * License along with FFmpeg; if not, write to the Free Software
> - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> - */
> -
> -#include "bit_depth_template.c"
> -
> -static void FUNCC(get_pixels)(int16_t *av_restrict block, const uint8_t 
> *_pixels,
> -  ptrdiff_t line_size)
> -{
> -const pixel *pixels = (const pixel *) _pixels;
> -int i;
> -
> -/* read the pixels */
> -for (i = 0; i < 8; i++) {
> -block[0] = pixels[0];
> -block[1] = pixels[1];
> -block[2] = pixels[2];
> -block[3] = pixels[3];
> -block[4] = pixels[4];
> -block[5] = pixels[5];
> -block[6] = pixels[6];
> -block[7] = pixels[7];
> -pixels  += line_size / sizeof(pixel);
> -block   += 8;
> -}
> -}
> --
> 1.9.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] huffyuvencdsp: Convert ff_diff_bytes_mmx to yasm

2015-10-20 Thread James Almer
On 10/19/2015 11:11 PM, Timothy Gu wrote:
> Heavily based upon ff_add_bytes by Christophe Gisquet.
> ---
> 
> Taken into account James' comment, and fixed x86_32. Also saves one additional
> GPR.
> 
> ---
>  libavcodec/x86/Makefile|  1 +
>  libavcodec/x86/huffyuvencdsp.asm   | 73 
> ++
>  libavcodec/x86/huffyuvencdsp_mmx.c | 37 ---
>  3 files changed, 80 insertions(+), 31 deletions(-)
>  create mode 100644 libavcodec/x86/huffyuvencdsp.asm
> 
> diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
> index 4591e4b..e1b1f0c 100644
> --- a/libavcodec/x86/Makefile
> +++ b/libavcodec/x86/Makefile
> @@ -115,6 +115,7 @@ YASM-OBJS-$(CONFIG_H264QPEL)   += 
> x86/h264_qpel_8bit.o  \
>  YASM-OBJS-$(CONFIG_HPELDSP)+= x86/fpel.o\
>x86/hpeldsp.o
>  YASM-OBJS-$(CONFIG_HUFFYUVDSP) += x86/huffyuvdsp.o
> +YASM-OBJS-$(CONFIG_HUFFYUVENCDSP)  += x86/huffyuvencdsp.o
>  YASM-OBJS-$(CONFIG_IDCTDSP)+= x86/idctdsp.o
>  YASM-OBJS-$(CONFIG_LLAUDDSP)   += x86/lossless_audiodsp.o
>  YASM-OBJS-$(CONFIG_LLVIDDSP)   += x86/lossless_videodsp.o
> diff --git a/libavcodec/x86/huffyuvencdsp.asm 
> b/libavcodec/x86/huffyuvencdsp.asm
> new file mode 100644
> index 000..e001906
> --- /dev/null
> +++ b/libavcodec/x86/huffyuvencdsp.asm
> @@ -0,0 +1,73 @@
> +;
> +;* SIMD-optimized HuffYUV encoding functions
> +;* Copyright (c) 2000, 2001 Fabrice Bellard
> +;* Copyright (c) 2002-2004 Michael Niedermayer 
> +;*
> +;* MMX optimization by Nick Kurshev 
> +;* Conversion to NASM format by Tiancheng "Timothy" Gu 
> 
> +;*
> +;* This file is part of FFmpeg.
> +;*
> +;* FFmpeg is free software; you can redistribute it and/or
> +;* modify it under the terms of the GNU Lesser General Public
> +;* License as published by the Free Software Foundation; either
> +;* version 2.1 of the License, or (at your option) any later version.
> +;*
> +;* FFmpeg is distributed in the hope that it will be useful,
> +;* but WITHOUT ANY WARRANTY; without even the implied warranty of
> +;* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +;* Lesser General Public License for more details.
> +;*
> +;* You should have received a copy of the GNU Lesser General Public
> +;* License along with FFmpeg; if not, write to the Free Software
> +;* 51, Inc., Foundation Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> +;**
> +
> +%include "libavutil/x86/x86util.asm"
> +
> +section .text
> +
> +INIT_MMX mmx
> +; void ff_diff_bytes_mmx(uint8_t *dst, const uint8_t *src1, const uint8_t 
> *src2,
> +;intptr_t w);
> +%if ARCH_X86_32
> +cglobal diff_bytes, 3,5,2, dst, src1, src2
> +%define wq r4q
> +DECLARE_REG_TMP 3
> +mov   wq, r3mp
> +%else
> +cglobal diff_bytes, 4,5,2, dst, src1, src2, w
> +DECLARE_REG_TMP 4
> +%endif ; ARCH_X86_32
> +%define i t0q
> +movi, wq
> +andi, -2 * mmsize
> +jz  .setup_loop2
> +add dstq, i
> +addsrc1q, i
> +addsrc2q, i
> +negi
> +.loop:
> +mova  m0, [src1q + i]
> +mova  m1, [src1q + i + mmsize]
> +psubb m0, [src2q + i]
> +psubb m1, [src2q + i + mmsize]
> +mova  [dstq + i], m0
> +mova [mmsize + dstq + i], m1
> +addi, 2 * mmsize
> +jl .loop
> +.setup_loop2:
> +and   wq, 2 * mmsize - 1
> +jz  .end
> +add dstq, wq
> +addsrc1q, wq
> +addsrc2q, wq
> +neg   wq
> +.loop2:
> +mov  t0b, [src1q + wq]
> +sub  t0b, [src2q + wq]
> +mov  [dstq + wq], t0b
> +inc   wq
> +jl.loop2
> +.end:
> +REP_RET
> diff --git a/libavcodec/x86/huffyuvencdsp_mmx.c 
> b/libavcodec/x86/huffyuvencdsp_mmx.c
> index ee60f4c..c5f81c8 100644
> --- a/libavcodec/x86/huffyuvencdsp_mmx.c
> +++ b/libavcodec/x86/huffyuvencdsp_mmx.c
> @@ -29,33 +29,10 @@
>  #include "libavcodec/huffyuvencdsp.h"
>  #include "libavcodec/mathops.h"
>  
> -#if HAVE_INLINE_ASM
> -
> -static void diff_bytes_mmx(uint8_t *dst, const uint8_t *src1, const uint8_t 
> *src2,
> -   intptr_t w)
> -{
> -x86_reg i = 0;
> -
> -if (w >= 16)
> -__asm__ volatile (
> -"1: \n\t"
> -"movq  (%2, %0), %%mm0  \n\t"
> -"movq  (%1, %0), %%mm1  \n\t"
> -"psubb %%mm0, %%mm1 \n\t"
> -"movq %%mm1, (%3, %0)   \n\t"
> -"movq 8(%2, %0), 

[FFmpeg-devel] [PATCH] pixblockdsp: Use memcpy for get_pixels_16_c

2015-10-20 Thread Timothy Gu
Before:
  15543 decicycles in get_pixels, 4193214 runs,   1090 skips
After:
   5713 decicycles in get_pixels, 8387564 runs,   1044 skips
---
 libavcodec/pixblockdsp.c  | 36 ++-
 libavcodec/pixblockdsp_template.c | 40 ---
 2 files changed, 31 insertions(+), 45 deletions(-)
 delete mode 100644 libavcodec/pixblockdsp_template.c

diff --git a/libavcodec/pixblockdsp.c b/libavcodec/pixblockdsp.c
index 322e1dd..0f23d8a 100644
--- a/libavcodec/pixblockdsp.c
+++ b/libavcodec/pixblockdsp.c
@@ -23,12 +23,38 @@
 #include "avcodec.h"
 #include "pixblockdsp.h"
 
-#define BIT_DEPTH 16
-#include "pixblockdsp_template.c"
-#undef BIT_DEPTH
+static void get_pixels_16_c(int16_t *av_restrict block, const uint8_t *pixels,
+ptrdiff_t line_size)
+{
+memcpy(block + 0 * 8, pixels + 0 * line_size, sizeof(int16_t) * 8);
+memcpy(block + 1 * 8, pixels + 1 * line_size, sizeof(int16_t) * 8);
+memcpy(block + 2 * 8, pixels + 2 * line_size, sizeof(int16_t) * 8);
+memcpy(block + 3 * 8, pixels + 3 * line_size, sizeof(int16_t) * 8);
+memcpy(block + 4 * 8, pixels + 4 * line_size, sizeof(int16_t) * 8);
+memcpy(block + 5 * 8, pixels + 5 * line_size, sizeof(int16_t) * 8);
+memcpy(block + 6 * 8, pixels + 6 * line_size, sizeof(int16_t) * 8);
+memcpy(block + 7 * 8, pixels + 7 * line_size, sizeof(int16_t) * 8);
+}
+
+static void get_pixels_8_c(int16_t *av_restrict block, const uint8_t *pixels,
+   ptrdiff_t line_size)
+{
+int i;
 
-#define BIT_DEPTH 8
-#include "pixblockdsp_template.c"
+/* read the pixels */
+for (i = 0; i < 8; i++) {
+block[0] = pixels[0];
+block[1] = pixels[1];
+block[2] = pixels[2];
+block[3] = pixels[3];
+block[4] = pixels[4];
+block[5] = pixels[5];
+block[6] = pixels[6];
+block[7] = pixels[7];
+pixels  += line_size;
+block   += 8;
+}
+}
 
 static void diff_pixels_c(int16_t *av_restrict block, const uint8_t *s1,
   const uint8_t *s2, int stride)
diff --git a/libavcodec/pixblockdsp_template.c 
b/libavcodec/pixblockdsp_template.c
deleted file mode 100644
index d1e9102..000
--- a/libavcodec/pixblockdsp_template.c
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- */
-
-#include "bit_depth_template.c"
-
-static void FUNCC(get_pixels)(int16_t *av_restrict block, const uint8_t 
*_pixels,
-  ptrdiff_t line_size)
-{
-const pixel *pixels = (const pixel *) _pixels;
-int i;
-
-/* read the pixels */
-for (i = 0; i < 8; i++) {
-block[0] = pixels[0];
-block[1] = pixels[1];
-block[2] = pixels[2];
-block[3] = pixels[3];
-block[4] = pixels[4];
-block[5] = pixels[5];
-block[6] = pixels[6];
-block[7] = pixels[7];
-pixels  += line_size / sizeof(pixel);
-block   += 8;
-}
-}
-- 
1.9.1

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


Re: [FFmpeg-devel] [PATCH] avcodec: remove unused avpriv_ac3_parse_header

2015-10-20 Thread Andreas Cadhalpun
On 14.10.2015 01:53, James Almer wrote:
> On 10/13/2015 8:50 PM, Andreas Cadhalpun wrote:
>> It was replaced by avpriv_ac3_parse_header2.
> 
> You could rename it to avpriv_ac3_parse_header() while at it.
> The 2 suffix becomes silly with this.

I'll send a separate patch for that.

Best regards,
Andreas

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


Re: [FFmpeg-devel] [PATCH] avutil: install des.h, rc4.h and tree.h as public headers

2015-10-20 Thread Andreas Cadhalpun
On 14.10.2015 14:07, Michael Niedermayer wrote:
> On Wed, Oct 14, 2015 at 12:37:31AM +0200, Andreas Cadhalpun wrote:
>> These headers contain functions supposed to be public.
>>
>> libavutil/des.h:
>>  av_des_alloc
>>  av_des_crypt
>>  av_des_init
>>  av_des_mac
>> libavutil/rc4.h:
>>  av_rc4_alloc
>>  av_rc4_crypt
>>  av_rc4_init
>> libavutil/tree.h
>>  av_tree_destroy
>>  av_tree_enumerate
>>  av_tree_find
>>  av_tree_insert
>>  av_tree_node_alloc
>>  av_tree_node_size
> 
> LGTM, but maybe you want to wait a day or 2 in case others have
> comments

FF_API_CRYPTO_CONTEXT has been removed, so I pushed this now.

Best regards,
Andreas

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


Re: [FFmpeg-devel] [PATCH] avcodec: remove unused avpriv_ac3_parse_header

2015-10-20 Thread Andreas Cadhalpun
On 14.10.2015 02:07, Michael Niedermayer wrote:
> On Wed, Oct 14, 2015 at 01:50:13AM +0200, Andreas Cadhalpun wrote:
>> It was replaced by avpriv_ac3_parse_header2.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/ac3_parser.c | 9 -
>>  libavcodec/ac3_parser.h | 2 --
>>  2 files changed, 11 deletions(-)
> 
> should be ok

Pushed.

Best regards,
Andreas

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


Re: [FFmpeg-devel] [PATCH] avutil: merge avpriv_float_dsp_init into avpriv_float_dsp_alloc

2015-10-20 Thread Andreas Cadhalpun
On 14.10.2015 02:04, James Almer wrote:
> On 10/13/2015 8:48 PM, Andreas Cadhalpun wrote:
>> Also replace the last two usages of avpriv_float_dsp_init with
>> avpriv_float_dsp_alloc.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavutil/float_dsp.c | 47 ++-
>>  libavutil/float_dsp.h |  9 -
>>  2 files changed, 26 insertions(+), 30 deletions(-)
>>
>> diff --git a/libavutil/float_dsp.c b/libavutil/float_dsp.c
>> index 337708e..c1430f0 100644
>> --- a/libavutil/float_dsp.c
>> +++ b/libavutil/float_dsp.c
>> @@ -116,8 +116,12 @@ float avpriv_scalarproduct_float_c(const float *v1, 
>> const float *v2, int len)
>>  return p;
>>  }
>>  
>> -av_cold void avpriv_float_dsp_init(AVFloatDSPContext *fdsp, int bit_exact)
>> +av_cold AVFloatDSPContext *avpriv_float_dsp_alloc(int bit_exact)
>>  {
>> +AVFloatDSPContext *fdsp = av_mallocz(sizeof(AVFloatDSPContext));
>> +if (!fdsp)
>> +return NULL;
>> +
>>  fdsp->vector_fmul = vector_fmul_c;
>>  fdsp->vector_fmac_scalar = vector_fmac_scalar_c;
>>  fdsp->vector_fmul_scalar = vector_fmul_scalar_c;
>> @@ -138,14 +142,7 @@ av_cold void avpriv_float_dsp_init(AVFloatDSPContext 
>> *fdsp, int bit_exact)
>>  ff_float_dsp_init_x86(fdsp);
>>  if (ARCH_MIPS)
>>  ff_float_dsp_init_mips(fdsp);
>> -}
>> -
>> -av_cold AVFloatDSPContext *avpriv_float_dsp_alloc(int bit_exact)
>> -{
>> -AVFloatDSPContext *ret = av_mallocz(sizeof(AVFloatDSPContext));
>> -if (ret)
>> -avpriv_float_dsp_init(ret, bit_exact);
>> -return ret;
>> +return fdsp;
>>  }
>>  
>>  
>> @@ -386,7 +383,7 @@ int main(int argc, char **argv)
>>  {
>>  int ret = 0, seeded = 0;
>>  uint32_t seed;
>> -AVFloatDSPContext fdsp, cdsp;
>> +AVFloatDSPContext *fdsp, *cdsp;
>>  AVLFG lfg;
>>  
>>  LOCAL_ALIGNED(32, float, src0, [LEN]);
>> @@ -430,29 +427,37 @@ int main(int argc, char **argv)
>>  fill_double_array(, dbl_src0, LEN);
>>  fill_double_array(, dbl_src1, LEN);
>>  
>> -avpriv_float_dsp_init(, 1);
>> +fdsp = avpriv_float_dsp_alloc(1);
>>  av_force_cpu_flags(0);
>> -avpriv_float_dsp_init(, 1);
>> +cdsp = avpriv_float_dsp_alloc(1);
>> +
>> +if (!fdsp || !cdsp) {
>> +ret = 1;
>> +goto end;
>> +}
> 
> This could go above the av_log or av_lfg_init lines, to avoid pointlessly
> running all the array filling code when the test is going to fail anyway.
> 
> LGTM nonetheless.

Changed and pushed.

Best regards,
Andreas

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


Re: [FFmpeg-devel] [PATCH] avfilter/vf_psnr: Add support for writing stats to stdout

2015-10-20 Thread Michael Niedermayer
On Tue, Oct 20, 2015 at 09:10:53PM +0200, Paul B Mahol wrote:
> On 10/20/15, Tobias Rapp  wrote:
> > Attached patch implements writing PSNR frame stats to standard output if
> > the filename is "-".
> >
> > Regards,
> > Tobias
> >
> 
> Looks fine to me.

applied

thanks

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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


[FFmpeg-devel] [PATCH] avcodec: remove old avpriv_mpa_decode_header function

2015-10-20 Thread Andreas Cadhalpun
Replace its last use by avpriv_mpa_decode_header2 and drop the 2 suffix.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/mpegaudio_parser.c   | 2 +-
 libavcodec/mpegaudiodecheader.c | 7 +--
 libavcodec/mpegaudiodecheader.h | 4 +---
 libavformat/mp3dec.c| 4 ++--
 4 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/libavcodec/mpegaudio_parser.c b/libavcodec/mpegaudio_parser.c
index 4c72131..4c7e778 100644
--- a/libavcodec/mpegaudio_parser.c
+++ b/libavcodec/mpegaudio_parser.c
@@ -69,7 +69,7 @@ static int mpegaudio_parse(AVCodecParserContext *s1,
 
 state= (state<<8) + buf[i++];
 
-ret = avpriv_mpa_decode_header2(state, , , 
_size, _rate, _id);
+ret = avpriv_mpa_decode_header(state, , , 
_size, _rate, _id);
 if (ret < 4) {
 if (i > 4)
 s->header_count = -2;
diff --git a/libavcodec/mpegaudiodecheader.c b/libavcodec/mpegaudiodecheader.c
index d522c06..3d00586 100644
--- a/libavcodec/mpegaudiodecheader.c
+++ b/libavcodec/mpegaudiodecheader.c
@@ -113,7 +113,7 @@ int avpriv_mpegaudio_decode_header(MPADecodeHeader *s, 
uint32_t header)
 return 0;
 }
 
-int avpriv_mpa_decode_header2(uint32_t head, int *sample_rate, int *channels, 
int *frame_size, int *bit_rate, enum AVCodecID *codec_id)
+int avpriv_mpa_decode_header(uint32_t head, int *sample_rate, int *channels, 
int *frame_size, int *bit_rate, enum AVCodecID *codec_id)
 {
 MPADecodeHeader s1, *s = 
 
@@ -149,8 +149,3 @@ int avpriv_mpa_decode_header2(uint32_t head, int 
*sample_rate, int *channels, in
 *bit_rate = s->bit_rate;
 return s->frame_size;
 }
-
-int avpriv_mpa_decode_header(AVCodecContext *avctx, uint32_t head, int 
*sample_rate, int *channels, int *frame_size, int *bit_rate)
-{
-return avpriv_mpa_decode_header2(head, sample_rate, channels, frame_size, 
bit_rate, >codec_id);
-}
diff --git a/libavcodec/mpegaudiodecheader.h b/libavcodec/mpegaudiodecheader.h
index 444b85f..e5e7bda 100644
--- a/libavcodec/mpegaudiodecheader.h
+++ b/libavcodec/mpegaudiodecheader.h
@@ -54,9 +54,7 @@ int avpriv_mpegaudio_decode_header(MPADecodeHeader *s, 
uint32_t header);
 
 /* useful helper to get mpeg audio stream infos. Return -1 if error in
header, otherwise the coded frame size in bytes */
-int avpriv_mpa_decode_header(AVCodecContext *avctx, uint32_t head, int 
*sample_rate, int *channels, int *frame_size, int *bitrate);
-
-int avpriv_mpa_decode_header2(uint32_t head, int *sample_rate, int *channels, 
int *frame_size, int *bitrate, enum AVCodecID *codec_id);
+int avpriv_mpa_decode_header(uint32_t head, int *sample_rate, int *channels, 
int *frame_size, int *bitrate, enum AVCodecID *codec_id);
 
 /* fast header check for resync */
 static inline int ff_mpa_check_header(uint32_t header){
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 32ca00c..6829523 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -88,8 +88,8 @@ static int mp3_read_probe(AVProbeData *p)
 for(frames = 0; buf2 < end; frames++) {
 int dummy;
 header = AV_RB32(buf2);
-fsize = avpriv_mpa_decode_header(avctx, header,
- , , , );
+fsize = avpriv_mpa_decode_header(header, , , ,
+ , >codec_id);
 if(fsize < 0)
 break;
 buf2 += fsize;
-- 
2.6.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avcodec: drop 2 suffix from avpriv_ac3_parse_header2

2015-10-20 Thread Andreas Cadhalpun
avpriv_ac3_parse_header was removed in commit 3dfb643.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/ac3_parser.c | 4 ++--
 libavcodec/ac3_parser.h | 2 +-
 libavcodec/ac3dec.c | 2 +-
 libavformat/ac3dec.c| 2 +-
 libavformat/movenc.c| 4 ++--
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavcodec/ac3_parser.c b/libavcodec/ac3_parser.c
index 0dd98b9..83dd90f 100644
--- a/libavcodec/ac3_parser.c
+++ b/libavcodec/ac3_parser.c
@@ -47,7 +47,7 @@ static const uint8_t center_levels[4] = { 4, 5, 6, 5 };
 static const uint8_t surround_levels[4] = { 4, 6, 7, 6 };
 
 
-int avpriv_ac3_parse_header2(GetBitContext *gbc, AC3HeaderInfo **phdr)
+int avpriv_ac3_parse_header(GetBitContext *gbc, AC3HeaderInfo **phdr)
 {
 int frame_size_code;
 AC3HeaderInfo *hdr;
@@ -163,7 +163,7 @@ static int ac3_sync(uint64_t state, AACAC3ParseContext 
*hdr_info,
 GetBitContext gbc;
 
 init_get_bits(, tmp.u8+8-AC3_HEADER_SIZE, 54);
-err = avpriv_ac3_parse_header2(, );
+err = avpriv_ac3_parse_header(, );
 
 if(err < 0)
 return 0;
diff --git a/libavcodec/ac3_parser.h b/libavcodec/ac3_parser.h
index 80bc5ef..dc5d035 100644
--- a/libavcodec/ac3_parser.h
+++ b/libavcodec/ac3_parser.h
@@ -37,6 +37,6 @@
  * -2 if the bsid (version) element is invalid, -3 if the fscod (sample rate)
  * element is invalid, or -4 if the frmsizecod (bit rate) element is invalid.
  */
-int avpriv_ac3_parse_header2(GetBitContext *gbc, AC3HeaderInfo **hdr);
+int avpriv_ac3_parse_header(GetBitContext *gbc, AC3HeaderInfo **hdr);
 
 #endif /* AVCODEC_AC3_PARSER_H */
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 6df697e..ad91405 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -298,7 +298,7 @@ static int parse_frame_header(AC3DecodeContext *s)
 AC3HeaderInfo hdr, *phdr=
 int err;
 
-err = avpriv_ac3_parse_header2(>gbc, );
+err = avpriv_ac3_parse_header(>gbc, );
 if (err)
 return err;
 
diff --git a/libavformat/ac3dec.c b/libavformat/ac3dec.c
index bef55cb..363a32e 100644
--- a/libavformat/ac3dec.c
+++ b/libavformat/ac3dec.c
@@ -55,7 +55,7 @@ static int ac3_eac3_probe(AVProbeData *p, enum AVCodecID 
expected_codec_id)
 init_get_bits(, buf3, 54);
 }else
 init_get_bits(, buf2, 54);
-if(avpriv_ac3_parse_header2(, ) < 0)
+if(avpriv_ac3_parse_header(, ) < 0)
 break;
 if(buf2 + phdr->frame_size > end)
 break;
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 5115585..05198b4 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -341,7 +341,7 @@ static int handle_eac3(MOVMuxContext *mov, AVPacket *pkt, 
MOVTrack *track)
 info = track->eac3_priv;
 
 init_get_bits(, pkt->data, pkt->size * 8);
-if (avpriv_ac3_parse_header2(, ) < 0) {
+if (avpriv_ac3_parse_header(, ) < 0) {
 /* drop the packets until we see a good one */
 if (!track->entry) {
 av_log(mov, AV_LOG_WARNING, "Dropping invalid packet from start of 
the stream\n");
@@ -391,7 +391,7 @@ static int handle_eac3(MOVMuxContext *mov, AVPacket *pkt, 
MOVTrack *track)
 while (cumul_size != pkt->size) {
 int i;
 init_get_bits(, pkt->data + cumul_size, (pkt->size - 
cumul_size) * 8);
-if (avpriv_ac3_parse_header2(, ) < 0)
+if (avpriv_ac3_parse_header(, ) < 0)
 return AVERROR_INVALIDDATA;
 if (hdr->frame_type != EAC3_FRAME_TYPE_DEPENDENT)
 return AVERROR(EINVAL);
-- 
2.6.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec: rename avpriv_color_frame to ff_color_frame

2015-10-20 Thread Andreas Cadhalpun
On 14.10.2015 01:50, Andreas Cadhalpun wrote:
> It is only used inside libavcodec.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/h264_slice.c | 2 +-
>  libavcodec/internal.h   | 2 +-
>  libavcodec/utils.c  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index a346ccb..3f41e9b 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -617,7 +617,7 @@ static int h264_frame_start(H264Context *h)
> && !(h->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU)
>  #endif
> )
> -avpriv_color_frame(pic->f, c);
> +ff_color_frame(pic->f, c);
>  
>  h->cur_pic_ptr = pic;
>  ff_h264_unref_picture(h, >cur_pic);
> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> index 324f099..0abe17f 100644
> --- a/libavcodec/internal.h
> +++ b/libavcodec/internal.h
> @@ -178,7 +178,7 @@ unsigned int avpriv_toupper4(unsigned int x);
>  int ff_init_buffer_info(AVCodecContext *s, AVFrame *frame);
>  
>  
> -void avpriv_color_frame(AVFrame *frame, const int color[4]);
> +void ff_color_frame(AVFrame *frame, const int color[4]);
>  
>  extern volatile int ff_avcodec_locked;
>  int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec);
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 0e4f3c0..07535ad 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -687,7 +687,7 @@ fail:
>  return AVERROR(ENOMEM);
>  }
>  
> -void avpriv_color_frame(AVFrame *frame, const int c[4])
> +void ff_color_frame(AVFrame *frame, const int c[4])
>  {
>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
>  int p, y, x;
> 

Ping.

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


[FFmpeg-devel] [PATCH] huffyuvencdsp: Add ff_diff_bytes_{sse2, avx2}

2015-10-20 Thread Timothy Gu
SSE2 version 4%-35% faster than MMX depending on the width.
AVX2 version 1%-13% faster than SSE2 depending on the width.
---

Addressed James's and Henrik's advices. Removed heuristics based on width.
Made available both aligned and unaligned versions. For AVX2 version,
gracefully fall back on SSE2.

---
 libavcodec/huffyuvenc.c|   4 +-
 libavcodec/x86/huffyuvencdsp.asm   | 110 +++--
 libavcodec/x86/huffyuvencdsp_mmx.c |  14 -
 3 files changed, 107 insertions(+), 21 deletions(-)

diff --git a/libavcodec/huffyuvenc.c b/libavcodec/huffyuvenc.c
index 49d711a..e080cd9 100644
--- a/libavcodec/huffyuvenc.c
+++ b/libavcodec/huffyuvenc.c
@@ -60,12 +60,12 @@ static inline int sub_left_prediction(HYuvContext *s, 
uint8_t *dst,
 }
 return left;
 } else {
-for (i = 0; i < 16; i++) {
+for (i = 0; i < 32; i++) {
 const int temp = src[i];
 dst[i] = temp - left;
 left   = temp;
 }
-s->hencdsp.diff_bytes(dst + 16, src + 16, src + 15, w - 16);
+s->hencdsp.diff_bytes(dst + 32, src + 32, src + 31, w - 32);
 return src[w-1];
 }
 } else {
diff --git a/libavcodec/x86/huffyuvencdsp.asm b/libavcodec/x86/huffyuvencdsp.asm
index e001906..699fd38 100644
--- a/libavcodec/x86/huffyuvencdsp.asm
+++ b/libavcodec/x86/huffyuvencdsp.asm
@@ -27,9 +27,9 @@
 
 section .text
 
-INIT_MMX mmx
 ; void ff_diff_bytes_mmx(uint8_t *dst, const uint8_t *src1, const uint8_t 
*src2,
 ;intptr_t w);
+%macro DIFF_BYTES_PROLOGUE 0
 %if ARCH_X86_32
 cglobal diff_bytes, 3,5,2, dst, src1, src2
 %define wq r4q
@@ -40,34 +40,108 @@ cglobal diff_bytes, 4,5,2, dst, src1, src2, w
 DECLARE_REG_TMP 4
 %endif ; ARCH_X86_32
 %define i t0q
+%endmacro
+
+; label to jump to if w < regsize
+%macro DIFF_BYTES_LOOP_PREP 1
 movi, wq
-andi, -2 * mmsize
-jz  .setup_loop2
+andi, -2 * regsize
+jz%1
 add dstq, i
 addsrc1q, i
 addsrc2q, i
 negi
-.loop:
-mova  m0, [src1q + i]
-mova  m1, [src1q + i + mmsize]
-psubb m0, [src2q + i]
-psubb m1, [src2q + i + mmsize]
-mova  [dstq + i], m0
-mova [mmsize + dstq + i], m1
-addi, 2 * mmsize
-jl .loop
-.setup_loop2:
-and   wq, 2 * mmsize - 1
-jz  .end
+%endmacro
+
+; mov type used for src1q, dstq, first reg, second reg
+%macro DIFF_BYTES_LOOP_CORE 4
+%if regsize != 16
+mov%1 %3, [src1q + i]
+mov%1 %4, [src1q + i + regsize]
+psubb %3, [src2q + i]
+psubb %4, [src2q + i + regsize]
+mov%2   [dstq + i], %3
+mov%2 [regsize + dstq + i], %4
+%else
+; SSE enforces alignment of psubb operand
+mov%1 %3, [src1q + i]
+movu  %4, [src2q + i]
+psubb %3, %4
+mov%2 [dstq + i], %3
+mov%1 %3, [src1q + i + regsize]
+movu  %4, [src2q + i + regsize]
+psubb %3, %4
+mov%2 [regsize + dstq + i], %3
+%endif
+%endmacro
+
+%macro DIFF_BYTES_BODY 2 ; mov type used for src1q, for dstq
+%define regsize mmsize
+.loop_%1%2:
+DIFF_BYTES_LOOP_CORE %1, %2, m0, m1
+addi, 2 * regsize
+jl.loop_%1%2
+.skip_main_%1%2:
+and   wq, 2 * regsize - 1
+jz .end_%1%2
+%if mmsize > 16
+; fall back to narrower xmm
+%define regsize mmsize / 2
+DIFF_BYTES_LOOP_PREP .setup_loop_gpr_aa
+.loop2_%1%2:
+DIFF_BYTES_LOOP_CORE %1, %2, xm0, xm1
+addi, 2 * regsize
+jl   .loop2_%1%2
+.setup_loop_gpr_%1%2:
+and   wq, 2 * regsize - 1
+jz .end_%1%2
+%endif
 add dstq, wq
 addsrc1q, wq
 addsrc2q, wq
 neg   wq
-.loop2:
+.loop_gpr_%1%2:
 mov  t0b, [src1q + wq]
 sub  t0b, [src2q + wq]
 mov  [dstq + wq], t0b
 inc   wq
-jl.loop2
-.end:
+jl .loop_gpr_%1%2
+.end_%1%2:
 REP_RET
+%endmacro
+
+%if ARCH_X86_32
+INIT_MMX mmx
+DIFF_BYTES_PROLOGUE
+%define regsize mmsize
+DIFF_BYTES_LOOP_PREP .skip_main_aa
+DIFF_BYTES_BODYa, a
+%endif
+
+INIT_XMM sse2
+DIFF_BYTES_PROLOGUE
+%define regsize mmsize
+DIFF_BYTES_LOOP_PREP .skip_main_aa
+testdstq, regsize - 1
+jnz .loop_uu
+test   src1q, regsize - 1
+jnz .loop_ua
+DIFF_BYTES_BODYa, a
+DIFF_BYTES_BODYu, a
+DIFF_BYTES_BODYu, u
+
+%if HAVE_AVX2_EXTERNAL
+INIT_YMM avx2
+DIFF_BYTES_PROLOGUE
+%define regsize mmsize
+; Directly using unaligned SSE2 version is marginally faster than

Re: [FFmpeg-devel] [PATCH] avcodec: drop 2 suffix from avpriv_ac3_parse_header2

2015-10-20 Thread Michael Niedermayer
On Wed, Oct 21, 2015 at 12:36:59AM +0200, Andreas Cadhalpun wrote:
> avpriv_ac3_parse_header was removed in commit 3dfb643.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/ac3_parser.c | 4 ++--
>  libavcodec/ac3_parser.h | 2 +-
>  libavcodec/ac3dec.c | 2 +-
>  libavformat/ac3dec.c| 2 +-
>  libavformat/movenc.c| 4 ++--
>  5 files changed, 7 insertions(+), 7 deletions(-)

LGTM

thx

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

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


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


[FFmpeg-devel] [PATCH] Don't needlessly reinitialize ff_cos_## tables.

2015-10-20 Thread Dale Curtis
Minor waste and more annoyingly triggers race detectors when the
re-initialization happens across multiple threads. cos(0) == 1 and by
default statics initialize to 0, so this check is safe.

Signed-off-by: Dale Curtis 
---
 libavcodec/fft_template.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c
index 23ea453..2165ed0 100644
--- a/libavcodec/fft_template.c
+++ b/libavcodec/fft_template.c
@@ -92,6 +92,8 @@ av_cold void ff_init_ff_cos_tabs(int index)
 int m = 1<

Re: [FFmpeg-devel] [PATCH] huffyuvencdsp: Convert ff_diff_bytes_mmx to yasm

2015-10-20 Thread Timothy Gu
On Tue, Oct 20, 2015 at 2:18 PM James Almer  wrote:

> Removing this will make the INLINE_MMXEXT if statement below fail to
> compile on
> builds with inline asm disabled (msvc, etc). Even with dead code
> elimination in
> mind you'd need at least a prototype for the relevant functions.
> Just move this line below to keep the INLINE_MMXEXT if statement wrapped
> with it.
>

Good catch!


> Fate passes, so aside from the above it LGTM.
>

Pushed, thanks for the review.

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


Re: [FFmpeg-devel] [PATCH] huffyuvencdsp: Add ff_diff_bytes_{sse2, avx2}

2015-10-20 Thread James Almer
On 10/20/2015 10:32 PM, Timothy Gu wrote:
> SSE2 version 4%-35% faster than MMX depending on the width.
> AVX2 version 1%-13% faster than SSE2 depending on the width.
> ---
> 
> Addressed James's and Henrik's advices. Removed heuristics based on width.
> Made available both aligned and unaligned versions. For AVX2 version,
> gracefully fall back on SSE2.
> 
> ---
>  libavcodec/huffyuvenc.c|   4 +-
>  libavcodec/x86/huffyuvencdsp.asm   | 110 
> +++--
>  libavcodec/x86/huffyuvencdsp_mmx.c |  14 -
>  3 files changed, 107 insertions(+), 21 deletions(-)
> 
> diff --git a/libavcodec/huffyuvenc.c b/libavcodec/huffyuvenc.c
> index 49d711a..e080cd9 100644
> --- a/libavcodec/huffyuvenc.c
> +++ b/libavcodec/huffyuvenc.c
> @@ -60,12 +60,12 @@ static inline int sub_left_prediction(HYuvContext *s, 
> uint8_t *dst,
>  }
>  return left;
>  } else {
> -for (i = 0; i < 16; i++) {
> +for (i = 0; i < 32; i++) {
>  const int temp = src[i];
>  dst[i] = temp - left;
>  left   = temp;
>  }
> -s->hencdsp.diff_bytes(dst + 16, src + 16, src + 15, w - 16);
> +s->hencdsp.diff_bytes(dst + 32, src + 32, src + 31, w - 32);
>  return src[w-1];
>  }
>  } else {
> diff --git a/libavcodec/x86/huffyuvencdsp.asm 
> b/libavcodec/x86/huffyuvencdsp.asm
> index e001906..699fd38 100644
> --- a/libavcodec/x86/huffyuvencdsp.asm
> +++ b/libavcodec/x86/huffyuvencdsp.asm
> @@ -27,9 +27,9 @@
>  
>  section .text
>  
> -INIT_MMX mmx
>  ; void ff_diff_bytes_mmx(uint8_t *dst, const uint8_t *src1, const uint8_t 
> *src2,
>  ;intptr_t w);
> +%macro DIFF_BYTES_PROLOGUE 0
>  %if ARCH_X86_32
>  cglobal diff_bytes, 3,5,2, dst, src1, src2
>  %define wq r4q
> @@ -40,34 +40,108 @@ cglobal diff_bytes, 4,5,2, dst, src1, src2, w
>  DECLARE_REG_TMP 4
>  %endif ; ARCH_X86_32
>  %define i t0q
> +%endmacro
> +
> +; label to jump to if w < regsize
> +%macro DIFF_BYTES_LOOP_PREP 1
>  movi, wq
> -andi, -2 * mmsize
> -jz  .setup_loop2
> +andi, -2 * regsize
> +jz%1
>  add dstq, i
>  addsrc1q, i
>  addsrc2q, i
>  negi
> -.loop:
> -mova  m0, [src1q + i]
> -mova  m1, [src1q + i + mmsize]
> -psubb m0, [src2q + i]
> -psubb m1, [src2q + i + mmsize]
> -mova  [dstq + i], m0
> -mova [mmsize + dstq + i], m1
> -addi, 2 * mmsize
> -jl .loop
> -.setup_loop2:
> -and   wq, 2 * mmsize - 1
> -jz  .end
> +%endmacro
> +
> +; mov type used for src1q, dstq, first reg, second reg
> +%macro DIFF_BYTES_LOOP_CORE 4
> +%if regsize != 16

%if mmsize != 16

By checking regsize you're using the SSE2 version in the AVX2 xmm loop. Check
for mmsize instead, which it's always 32 since you used INIT_YMM.

Should be good otherwise, but wait for Hendrik in case he wants to comment.

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


Re: [FFmpeg-devel] [PATCH] libvpxenc: remove some unused ctrl id mappings

2015-10-20 Thread James Zern
On Tue, Oct 20, 2015 at 7:02 AM, Michael Niedermayer
 wrote:
> On Mon, Oct 19, 2015 at 10:49:16PM -0700, James Zern wrote:
>> VP8E_UPD_ENTROPY, VP8E_UPD_REFERENCE, VP8E_USE_REFERENCE were removed
>> from libvpx and the remaining values were never used here
>>
>> Signed-off-by: James Zern 
>
> LGTM
>

applied. thanks.

> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is dangerous to be right in matters on which the established authorities
> are wrong. -- Voltaire
>
> ___
> 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] forcing ints to be 64 bits, possible new FATE client idea

2015-10-20 Thread Mark Harris
On Tue, Oct 20, 2015 at 7:08 PM, Ganesh Ajjanagadde  wrote:
> Hi all,
>
> It is known that there exist at least certain parts of the codebase
> that do not work correctly if ints are 64 bits. One of them I noticed
> was in avutil/intmath.h: ff_ctz_c does not compute the right thing if
> int is 64 bits. This is true both before and after the De-Bruijn
> optimization.
>
> A more interesting (and serious) question is whether FATE is broken if
> int's are 64 bits. I did some digging, and found the following from
> "The Definitive Guide to GCC" - On GCC prior to 4.x, there was a flag
> -mint64, documented as follows (see e.g
> https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc.pdf):
> "Force int and long types to be 64 bits wide. See -mlong32 for an
> explanation of the default and the way that the pointer size is
> determined".
>
> This should be helpful in setting up a FATE client to test (and
> possibly fix) bad code that assumed int = 32 bits. I myself can't
> easily run such an outdated GCC, but I noticed a bunch of clients
> running GCC < 4.0 where this may be set up.

This option was only valid on MIPS targets, not on x86_64 or other
common platforms.  It produced code that was incompatible with the
ABI, which made it not very useful if you want to link with system
libraries.  It was therefore removed.

Although it would be possible to modify gcc to add a new x86_64 target
where int is 64 bits, you would probably have the same ABI issues
because libc and other system libraries would be assuming a 32-bit
int.

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


Re: [FFmpeg-devel] forcing ints to be 64 bits, possible new FATE client idea

2015-10-20 Thread Timothy Gu
On Tue, Oct 20, 2015 at 7:09 PM Ganesh Ajjanagadde  wrote:

> Hi all,
>
> It is known that there exist at least certain parts of the codebase
> that do not work correctly if ints are 64 bits. One of them I noticed
> was in avutil/intmath.h: ff_ctz_c does not compute the right thing if
> int is 64 bits. This is true both before and after the De-Bruijn
> optimization.
>
> A more interesting (and serious) question is whether FATE is broken if
> int's are 64 bits. I did some digging, and found the following from
> "The Definitive Guide to GCC" - On GCC prior to 4.x, there was a flag
> -mint64, documented as follows (see e.g
> https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc.pdf):
> "Force int and long types to be 64 bits wide. See -mlong32 for an
> explanation of the default and the way that the pointer size is
> determined".
>
> This should be helpful in setting up a FATE client to test (and
> possibly fix) bad code that assumed int = 32 bits. I myself can't
> easily run such an outdated GCC, but I noticed a bunch of clients
> running GCC < 4.0 where this may be set up.
>

For lack of milder wording, this is a terrible idea.

FATE is set up, not to test every single possible combination of compiler,
compiler flags, and operating system, but to make sure FFmpeg works on the
ones people actually use. There are already not many people using GCC 3,
and the addition of a flag that completely changes the API is nowhere near
realistic.

Sometimes it's necessary to draw a line between "what's written in ISO/IEC
9899" and "real world."

Plus Mark's point on technical possibility of it (thank GOD GCC didn't do
something as crazy as this on other platforms).

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


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

2015-10-20 Thread Clément Bœsch
On Tue, Oct 20, 2015 at 12:28:32PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/Makefile   |   1 +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/vf_shuffleframes.c | 157 
> +

doc please

>  3 files changed, 159 insertions(+)
>  create mode 100644 libavfilter/vf_shuffleframes.c
> 
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index a095a10..8e776c1 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -215,6 +215,7 @@ OBJS-$(CONFIG_SETSAR_FILTER) += 
> vf_aspect.o
>  OBJS-$(CONFIG_SETTB_FILTER)  += settb.o
>  OBJS-$(CONFIG_SHOWINFO_FILTER)   += vf_showinfo.o
>  OBJS-$(CONFIG_SHOWPALETTE_FILTER)+= vf_showpalette.o
> +OBJS-$(CONFIG_SHUFFLEFRAMES_FILTER)  += vf_shuffleframes.o
>  OBJS-$(CONFIG_SHUFFLEPLANES_FILTER)  += vf_shuffleplanes.o
>  OBJS-$(CONFIG_SIGNALSTATS_FILTER)+= vf_signalstats.o
>  OBJS-$(CONFIG_SMARTBLUR_FILTER)  += vf_smartblur.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 3ab9a48..9385fdf 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -236,6 +236,7 @@ void avfilter_register_all(void)
>  REGISTER_FILTER(SETTB,  settb,  vf);
>  REGISTER_FILTER(SHOWINFO,   showinfo,   vf);
>  REGISTER_FILTER(SHOWPALETTE,showpalette,vf);
> +REGISTER_FILTER(SHUFFLEFRAMES,  shuffleframes,  vf);
>  REGISTER_FILTER(SHUFFLEPLANES,  shuffleplanes,  vf);
>  REGISTER_FILTER(SIGNALSTATS,signalstats,vf);
>  REGISTER_FILTER(SMARTBLUR,  smartblur,  vf);
> diff --git a/libavfilter/vf_shuffleframes.c b/libavfilter/vf_shuffleframes.c
> new file mode 100644
> index 000..97c4aa5
> --- /dev/null
> +++ b/libavfilter/vf_shuffleframes.c
> @@ -0,0 +1,157 @@
> +/*
> + * Copyright (c) 2015 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "libavutil/avstring.h"
> +#include "libavutil/common.h"
> +#include "libavutil/internal.h"
> +#include "libavutil/opt.h"
> +
> +#include "avfilter.h"
> +#include "internal.h"
> +#include "video.h"
> +
> +typedef struct ShuffleFramesContext {
> +const AVClass *class;
> +char *mapping;
> +AVFrame **frames;
> +int *map;
> +int64_t *pts;
> +int in_frames;
> +int nb_frames;
> +} ShuffleFramesContext;
> +
> +static av_cold int init(AVFilterContext *ctx)
> +{
> +ShuffleFramesContext *s = ctx->priv;
> +char *mapping, *saveptr = NULL, *p;
> +int n, nb_items;
> +
> +mapping = av_strdup(s->mapping);
> +if (!mapping)
> +return AVERROR(ENOMEM);
> +
> +nb_items = 1;
> +for (p = mapping; *p; p++) {
> +if (*p == '|' || *p == ' ')
> +nb_items++;
> +}
> +
> +s->map= av_calloc(nb_items, sizeof(*s->map));
> +s->pts= av_calloc(nb_items, sizeof(*s->pts));
> +s->frames = av_calloc(nb_items, sizeof(*s->frames));
> +if (!s->map || !s->frames || !s->pts) {
> +return AVERROR(ENOMEM);

leaks mapping

> +}
> +
> +for (n = 0; n < nb_items; n++) {
> +s->map[n] = -1;
> +}
> +
> +for (n = 0; n < nb_items; n++) {
> +char *map = av_strtok(n == 0 ? mapping : NULL, " |", );

> +if (!map || sscanf(map, "%d", >map[n]) != 1)
> +return AVERROR(EINVAL);
> +if (s->map[n] < 0 || s->map[n] >= nb_items)
> +return AVERROR(EINVAL);

ditto mapping leak

> +}
> +
> +s->nb_frames = nb_items;
> +av_free(mapping);
> +return 0;
> +}
> +
> +static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
> +{
> +AVFilterContext*ctx = inlink->dst;
> +ShuffleFramesContext *s = ctx->priv;
> +int ret;
> +
> +if (s->in_frames < s->nb_frames) {
> +s->frames[s->in_frames] = frame;
> +s->pts[s->in_frames] = frame->pts;
> +s->in_frames++;
> +ret = 0;
> +}
> +
> +if (s->in_frames == s->nb_frames) {
> +int n, x;
> +
> +for (n = 0; n < s->nb_frames; n++) {
> +AVFrame *out;
> +
> +x = s->map[n];
> +out = 

[FFmpeg-devel] [PATCH] avfilter/vf_psnr: Add support for writing stats to stdout

2015-10-20 Thread Tobias Rapp
Attached patch implements writing PSNR frame stats to standard output if 
the filename is "-".


Regards,
Tobias
>From 163f8a547e7a4c4847c8b988017fd1ec73768d9e Mon Sep 17 00:00:00 2001
From: Tobias Rapp 
Date: Tue, 20 Oct 2015 15:02:21 +0200
Subject: [PATCH] avfilter/vf_psnr: Add support for writing stats to stdout

---
 doc/filters.texi  | 3 ++-
 libavfilter/vf_psnr.c | 6 --
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 5300134..4edc4f3 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8933,7 +8933,8 @@ The description of the accepted parameters follows.
 @table @option
 @item stats_file, f
 If specified the filter will use the named file to save the PSNR of
-each individual frame.
+each individual frame. When filename equals "-" the data is sent to
+standard output.
 @end table
 
 The file printed if @var{stats_file} is selected, contains a sequence of
diff --git a/libavfilter/vf_psnr.c b/libavfilter/vf_psnr.c
index a01b2c1..bfb0711 100644
--- a/libavfilter/vf_psnr.c
+++ b/libavfilter/vf_psnr.c
@@ -193,7 +193,9 @@ static av_cold int init(AVFilterContext *ctx)
 s->min_mse = +INFINITY;
 s->max_mse = -INFINITY;
 
-if (s->stats_file_str) {
+if (!strcmp(s->stats_file_str, "-")) {
+s->stats_file = stdout;
+} else if (s->stats_file_str) {
 s->stats_file = fopen(s->stats_file_str, "w");
 if (!s->stats_file) {
 int err = AVERROR(errno);
@@ -334,7 +336,7 @@ static av_cold void uninit(AVFilterContext *ctx)
 
 ff_dualinput_uninit(>dinput);
 
-if (s->stats_file)
+if (s->stats_file && s->stats_file != stdout)
 fclose(s->stats_file);
 }
 
-- 
1.9.1

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