Re: [FFmpeg-devel] [PATCH] tests/fate: Add S302M test
On 02.03.2015, at 00:41, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > tests/fate/acodec.mak |6 ++ > tests/ref/acodec/s302m |4 > 2 files changed, 10 insertions(+) > create mode 100644 tests/ref/acodec/s302m Should be fine, more tests are always welcome, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: autodetect opencl
Hi, Similar to the way SDL is being autodetected, the attached patch proposes to autodetect OpenCL. Rationale for the change: * OpenCL linking typically happens against the OpenCL ICD's import library. Hence there is no hard-linking against the OpenCL ICD's DLL/shared library. So ffmpeg should continue to run fine for non-OpenCL cases even when OpenCL runtime is not available on the user's system. * Enabling OpenCL is relatively low-impact since it does not automatically disable or override any existing functionality. The user still needs to explicitly specify opencl=1 in the filter options when using ffmpeg to use the OpenCL path. Please review the patch and share your comments on the same. Thanks and Regards, Maneesh 0001-configure-autodetect-opencl.patch Description: 0001-configure-autodetect-opencl.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] aac: smal fix in aacpsy pe reduction step
This is a small patch, but it does have a big impact on bit allocation.
Measured with the attached scripts (in case someone might find them
useful), all the regressions marked in the report have no audible
difference (I didn't check them all though), but the improvements can
be heard.
This affects mostly high bit rates. It's related to issue #2686.
In the report, A is the patched version, B is unpatched, all
comparisons show deltas in the form (A-B), so a positive pSNR delta
means a better quality in the patched version, and negative a
regression. Regressions are only considered for pSNR deltas below
-1db, they're considered serious below -6db.
All measurements were done with tiny_psnr.
The summary of the report inline for quick reading:
Files: 58
Bitrates: 6
Tests: 347
Serious Regressions: 0 (0%)
Regressions: 10 (2%)
Improvements: 54 (15%)
Big improvements: 26 (7%)
Worst regression - sine_tester.flac - 384k
- StdDev: 1.68pSNR: -3.05 maxdiff: -178.00
Best improvement - 07 - Bound.flac - 384k
- StdDev: -1700.05pSNR: 20.64 maxdiff: -29595.00
Average - StdDev: -55.67 pSNR: 1.20 maxdiff: -1593.00
From f9159b5514a80f4e19c8b6da108ac9f87272a871 Mon Sep 17 00:00:00 2001
From: Claudio Freire
Date: Sun, 1 Mar 2015 20:11:12 -0300
Subject: [PATCH] Fix AAC Psy PE reduction calculation when multiple iterations
are required AB testing results: http://pastebin.com/051BXYTy
---
libavcodec/aacpsy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/aacpsy.c b/libavcodec/aacpsy.c
index 068fbcd..d1e65f6 100644
--- a/libavcodec/aacpsy.c
+++ b/libavcodec/aacpsy.c
@@ -717,7 +717,7 @@ static void psy_3gpp_analyze_channel(FFPsyContext *ctx, int channel,
}
desired_pe_no_ah = FFMAX(desired_pe - (pe - pe_no_ah), 0.0f);
if (active_lines > 0.0f)
-reduction += calc_reduction_3gpp(a, desired_pe_no_ah, pe_no_ah, active_lines);
+reduction = calc_reduction_3gpp(a, desired_pe_no_ah, pe_no_ah, active_lines);
pe = 0.0f;
for (w = 0; w < wi->num_windows*16; w += 16) {
--
1.8.4.5
abtest.sh
Description: Bourne shell script
#!/usr/bin/python
import sys
import re
import collections
import functools
if len(sys.argv) < 3:
print "Usage: abreport "
sys.exit()
testre = re.compile(r"^-+ +(?P[0-9a-zA-Z]*) +- +(?P.*) +-+$")
statre = re.compile(r"^ *(?P[a-zA-Z]+) *: *stddev *: *(?P[0-9.]+) *PSNR *: *(?P[0-9.]+) *MAXDIFF *: *(?P[0-9]+) *bytes: *[0-9]+ */ *[0-9]+ *$")
A = sys.argv[1]
B = sys.argv[2]
stats = collections.defaultdict(functools.partial(collections.defaultdict, dict))
allbps = set()
curname = None
curbps = None
for l in sys.stdin:
m = testre.match(l)
if m:
curname = m.group('name')
curbps = m.group('bps')
m = statre.match(l)
if m:
curset = m.group('name')
stddev = float(m.group('stddev'))
psnr = float(m.group('psnr'))
maxdiff = int(m.group('maxdiff'))
stats[curname][curbps][curset] = (stddev,psnr,maxdiff)
allbps.add(curbps)
regressions = []
big_regressions = []
improvements = []
big_improvements = []
deltas = []
worstname = worstbps = worstdelta = None
bestname = bestbps = bestdelta = None
avgdelta = [0,0,0]
for name, bstats in stats.iteritems():
for bps, sets in bstats.iteritems():
astddev, apsnr, amaxdiff = stats[name][bps][A]
bstddev, bpsnr, bmaxdiff = stats[name][bps][B]
dpsnr = apsnr - bpsnr
dstddev = astddev - bstddev
dmaxdiff = amaxdiff - bmaxdiff
delta = (dstddev,dpsnr,dmaxdiff)
deltas.append(delta)
avgdelta[0] += delta[0]
avgdelta[1] += delta[1]
avgdelta[2] += delta[2]
if worstdelta is None or worstdelta[1] > delta[1]:
worstname, worstbps, worstdelta = name, bps, delta
if bestdelta is None or bestdelta[1] < delta[1]:
bestname, bestbps, bestdelta = name, bps, delta
if dpsnr < -1:
regressions.append((name, bps))
if dpsnr < -6:
big_regressions.append((name, bps))
elif dpsnr > 1:
improvements.append((name, bps))
if dpsnr > 6:
big_improvements.append((name, bps))
avgdelta = (avgdelta[0]/len(deltas), avgdelta[1]/len(deltas), avgdelta[2]/len(deltas))
ntests = 0
for name in stats:
ntests += len(stats[name])
print "Summary:\n"
print "Files:", len(stats)
print "Bitrates:", len(allbps)
print "Tests:", ntests
print "Serious Regressions:", len(big_regressions), "(%d%%)" % (len(big_regressions) * 100 / ntests,)
for rname,rbps in big_regressions:
print " - %s - %s" % (rbps, rname)
print "Regressions:", len(regressions), "(%d%%)" % (len(regressions) * 100 / ntests,)
for rname,rbps in regressions:
print " - %s - %s" % (rbps, rname)
print "Improvements:", len(improvements), "(%d%%)" % (len(improvements) * 100 / ntests,)
for rname,rbps in improvements:
print " - %s - %s" % (rbps, rname)
print "Big improvements:", len(big_improvements), "(%d%%)"
Re: [FFmpeg-devel] [PATCH 1/2] libavformat/avio: added avio_put_str16be
On Sun, Mar 1, 2015 at 1:31 PM Mark Reid wrote: > --- > libavformat/avio.h| 6 ++ > libavformat/aviobuf.c | 50 +++--- > > libavformat/version.h | 2 +- > 3 files changed, 34 insertions(+), 24 deletions(-) > Also doc/APICHANGES Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/7] ffprobe: Change string_validation to int, its accessed via AVOption as int
On Mon, Feb 02, 2015 at 11:22:09PM +0100, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > ffprobe.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) patchset applied after clement expressed preferrance and stefano did not object [...] -- 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] [PATCH] ffprobe: Force string_validation to int type, its accessed via AVOption as int
On Mon, Feb 09, 2015 at 05:21:59AM +0100, Michael Niedermayer wrote:
> On Mon, Feb 09, 2015 at 01:44:43AM +0100, Clément Bœsch wrote:
> > On Fri, Feb 06, 2015 at 10:10:22PM +0100, Michael Niedermayer wrote:
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > ffprobe.c |3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/ffprobe.c b/ffprobe.c
> > > index d352bb6b..8617c96 100644
> > > --- a/ffprobe.c
> > > +++ b/ffprobe.c
> > > @@ -294,7 +294,8 @@ typedef enum {
> > > WRITER_STRING_VALIDATION_FAIL,
> > > WRITER_STRING_VALIDATION_REPLACE,
> > > WRITER_STRING_VALIDATION_IGNORE,
> > > -WRITER_STRING_VALIDATION_NB
> > > +WRITER_STRING_VALIDATION_NB,
> > > +WRITER_STRING_VALIDATION_FORCE_ENUM_TO_INT_TYPE= 0x76543210,
> > > } StringValidation;
> > >
> >
> > I prefer the int approach you originally proposed. This hack makes me
> > quite uncomfortable, and the idea of having it all over the code base as
> > well.
>
> perfectly fine with me as well, saste i think you preferred above?
> or did i misunderstand ?
question timedout
will apply original patchset and continue along its lines
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat/mxfdec: refactor reading strong ref array
hi,
I was unsure whether this should be a function or a macro, I went with a
function.
---
libavformat/mxfdec.c | 61 +++-
1 file changed, 22 insertions(+), 39 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 1376a7a..f3501da 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -671,6 +671,19 @@ static int mxf_read_cryptographic_context(void *arg,
AVIOContext *pb, int tag, i
return 0;
}
+static int mxf_read_strong_ref_array(AVIOContext *pb, UID **refs, int *count)
+{
+*count = avio_rb32(pb);
+*refs = av_calloc(*count, sizeof(UID));
+if (!*refs) {
+*count = 0;
+return AVERROR(ENOMEM);
+}
+avio_skip(pb, 4); /* useless size of objects, always 16 according to specs
*/
+avio_read(pb, (uint8_t *)*refs, *count * sizeof(UID));
+return 0;
+}
+
static int mxf_read_content_storage(void *arg, AVIOContext *pb, int tag, int
size, UID uid, int64_t klv_offset)
{
MXFContext *mxf = arg;
@@ -679,13 +692,7 @@ static int mxf_read_content_storage(void *arg, AVIOContext
*pb, int tag, int siz
if (mxf->packages_refs)
av_log(mxf->fc, AV_LOG_VERBOSE, "Multiple packages_refs\n");
av_free(mxf->packages_refs);
-mxf->packages_count = avio_rb32(pb);
-mxf->packages_refs = av_calloc(mxf->packages_count, sizeof(UID));
-if (!mxf->packages_refs)
-return AVERROR(ENOMEM);
-avio_skip(pb, 4); /* useless size of objects, always 16 according to
specs */
-avio_read(pb, (uint8_t *)mxf->packages_refs, mxf->packages_count *
sizeof(UID));
-break;
+return mxf_read_strong_ref_array(pb, &mxf->packages_refs,
&mxf->packages_count);
}
return 0;
}
@@ -775,15 +782,8 @@ static int mxf_read_sequence(void *arg, AVIOContext *pb,
int tag, int size, UID
sequence->origin = avio_r8(pb);
break;
case 0x1001:
-sequence->structural_components_count = avio_rb32(pb);
-sequence->structural_components_refs =
av_calloc(sequence->structural_components_count, sizeof(UID));
-if (!sequence->structural_components_refs) {
-sequence->structural_components_count = 0;
-return AVERROR(ENOMEM);
-}
-avio_skip(pb, 4); /* useless size of objects, always 16 according to
specs */
-avio_read(pb, (uint8_t *)sequence->structural_components_refs,
sequence->structural_components_count * sizeof(UID));
-break;
+return mxf_read_strong_ref_array(pb,
&sequence->structural_components_refs,
+
&sequence->structural_components_count);
}
return 0;
}
@@ -796,15 +796,8 @@ static int mxf_read_essence_group(void *arg, AVIOContext
*pb, int tag, int size,
essence_group->duration = avio_rb64(pb);
break;
case 0x0501:
-essence_group->structural_components_count = avio_rb32(pb);
-essence_group->structural_components_refs =
av_calloc(essence_group->structural_components_count, sizeof(UID));
-if (!essence_group->structural_components_refs) {
-essence_group->structural_components_count = 0;
-return AVERROR(ENOMEM);
-}
-avio_skip(pb, 4); /* useless size of objects, always 16 according to
specs */
-avio_read(pb, (uint8_t *)essence_group->structural_components_refs,
essence_group->structural_components_count * sizeof(UID));
-break;
+return mxf_read_strong_ref_array(pb,
&essence_group->structural_components_refs,
+
&essence_group->structural_components_count);
}
return 0;
}
@@ -835,13 +828,8 @@ static int mxf_read_package(void *arg, AVIOContext *pb,
int tag, int size, UID u
MXFPackage *package = arg;
switch(tag) {
case 0x4403:
-package->tracks_count = avio_rb32(pb);
-package->tracks_refs = av_calloc(package->tracks_count, sizeof(UID));
-if (!package->tracks_refs)
-return AVERROR(ENOMEM);
-avio_skip(pb, 4); /* useless size of objects, always 16 according to
specs */
-avio_read(pb, (uint8_t *)package->tracks_refs, package->tracks_count *
sizeof(UID));
-break;
+return mxf_read_strong_ref_array(pb, &package->tracks_refs,
+ &package->tracks_count);
case 0x4401:
/* UMID */
avio_read(pb, package->package_ul, 16);
@@ -944,13 +932,8 @@ static int mxf_read_generic_descriptor(void *arg,
AVIOContext *pb, int tag, int
MXFDescriptor *descriptor = arg;
switch(tag) {
case 0x3F01:
-descriptor->sub_descriptors_count = avio_rb32(pb);
-descriptor->sub_descriptors_refs =
av_calloc(descriptor->sub_descriptors_count, sizeof(UID));
-if (!descriptor->sub_descriptors_refs)
-return AVERROR(ENOMEM);
-avio_skip(pb, 4); /* useless size of objects
Re: [FFmpeg-devel] [PATCH] avcodec/pngenc: cast double to integer type to avoid problems with some AV_WB32() implementations
Hi, On Sun, Mar 1, 2015 at 7:38 PM, Michael Niedermayer wrote: > alternatively lrint(f)() could be used > or various other options > > Signed-off-by: Michael Niedermayer > --- > libavcodec/pngenc.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c > index 9fd8eef..3a94366 100644 > --- a/libavcodec/pngenc.c > +++ b/libavcodec/pngenc.c > @@ -231,7 +231,7 @@ static int png_write_row(PNGEncContext *s, const > uint8_t *data, int size) > return 0; > } > > -#define AV_WB32_PNG(buf, n) (AV_WB32(buf, round((n) * 10))) > +#define AV_WB32_PNG(buf, n) (AV_WB32(buf, (unsigned int)round((n) * > 10)) > The typical solution here is to use lrint(f), and that is the C-recommended way of converting a double to a integer(ish). So I'd prefer we use that instead of this sort of frankenversion of the same concept. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/pngenc: cast double to integer type to avoid problems with some AV_WB32() implementations
alternatively lrint(f)() could be used
or various other options
Signed-off-by: Michael Niedermayer
---
libavcodec/pngenc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index 9fd8eef..3a94366 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -231,7 +231,7 @@ static int png_write_row(PNGEncContext *s, const uint8_t
*data, int size)
return 0;
}
-#define AV_WB32_PNG(buf, n) (AV_WB32(buf, round((n) * 10)))
+#define AV_WB32_PNG(buf, n) (AV_WB32(buf, (unsigned int)round((n) * 10)))
static int png_get_chrm(enum AVColorPrimaries prim, uint8_t *buf)
{
double rx, ry, gx, gy, bx, by, wx = 0.3127, wy = 0.3290;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avutil/common: minor simplification in av_clip_intp2_c()
On Fri, Feb 27, 2015 at 11:07:23PM +0100, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavutil/common.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Port FFT domain filter.
On date Saturday 2015-02-28 20:22:49 +0530, Arwa Arif encoded:
> Updated the patch.
> From ba761516b97b146f4c62d6c5c08dc5ea02c06af5 Mon Sep 17 00:00:00 2001
> From: Arwa Arif
> Date: Tue, 24 Feb 2015 12:17:30 +0530
> Subject: [PATCH] Port FFT domain filter.
Subject: lavfi: add FFT domain filter
>
> ---
> libavfilter/Makefile |1 +
> libavfilter/allfilters.c |1 +
> libavfilter/vf_fftfilt.c | 258
> ++
this could be renamed to fft, the "filt" part is redundant.
Also missing documentation.
> 3 files changed, 260 insertions(+)
> create mode 100644 libavfilter/vf_fftfilt.c
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 289c63b..b184f07 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -120,6 +120,7 @@ OBJS-$(CONFIG_EDGEDETECT_FILTER) +=
> vf_edgedetect.o
> OBJS-$(CONFIG_EQ_FILTER) += vf_eq.o
> OBJS-$(CONFIG_EXTRACTPLANES_FILTER) += vf_extractplanes.o
> OBJS-$(CONFIG_FADE_FILTER) += vf_fade.o
> +OBJS-$(CONFIG_FFTFILT_FILTER)+= vf_fftfilt.o
> OBJS-$(CONFIG_FIELD_FILTER) += vf_field.o
> OBJS-$(CONFIG_FIELDMATCH_FILTER) += vf_fieldmatch.o
> OBJS-$(CONFIG_FIELDORDER_FILTER) += vf_fieldorder.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 55de154..043ac56 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -136,6 +136,7 @@ void avfilter_register_all(void)
> REGISTER_FILTER(EQ, eq, vf);
> REGISTER_FILTER(EXTRACTPLANES, extractplanes, vf);
> REGISTER_FILTER(FADE, fade, vf);
> +REGISTER_FILTER(FFTFILT,fftfilt,vf);
> REGISTER_FILTER(FIELD, field, vf);
> REGISTER_FILTER(FIELDMATCH, fieldmatch, vf);
> REGISTER_FILTER(FIELDORDER, fieldorder, vf);
> diff --git a/libavfilter/vf_fftfilt.c b/libavfilter/vf_fftfilt.c
> new file mode 100644
> index 000..6d0a961
> --- /dev/null
> +++ b/libavfilter/vf_fftfilt.c
> @@ -0,0 +1,258 @@
> +/*
> + * Copyright (c) 2015 Arwa Arif
> + *
> + * 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
> + */
> +
> +/**
> + * @file
> + * FFT domain filtering.
> + */
> +
> +#include "libavfilter/internal.h"
> +#include "libavutil/common.h"
> +#include "libavutil/imgutils.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
> +#include "libavcodec/avfft.h"
> +#include "libavutil/eval.h"
> +
> +typedef struct {
> +const AVClass *class;
> +
> +RDFTContext *rdft;
> +int rdft_hbits;
> +int rdft_vbits;
> +size_t rdft_hlen;
> +size_t rdft_vlen;
> +FFTSample *rdft_hdata;
> +FFTSample *rdft_vdata;
> +
> +int dc;
> +char *lum_str;
> +AVExpr *lum_expr;
> +double *lum_data;
> +
> +} FFTFILTContext;
> +
> +static const char *const var_names[] = { "X", "Y", "W", "H",
> NULL};
> +enum { VAR_X, VAR_Y, VAR_W, VAR_H,
> VAR_VARS_NB };
> +
> +#define OFFSET(x) offsetof(FFTFILTContext, x)
> +#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
> +
> +static const AVOption fftfilt_options[] = {
> +{ "dc", "adjust gain", OFFSET(dc), AV_OPT_TYPE_INT,
> {.i64 = 0}, 0, 1000, FLAGS },
> +{ "lum", "set luminance expression", OFFSET(lum_str),
> AV_OPT_TYPE_STRING, {.str = "1"}, CHAR_MIN, CHAR_MAX, FLAGS },
> +{NULL},
> +};
> +
> +AVFILTER_DEFINE_CLASS(fftfilt);
> +
> +static inline double lum(void *priv, double x, double y)
> +{
> +FFTFILTContext *fftfilt = priv;
> +FFTSample *rdft_data = fftfilt->rdft_vdata;
> +size_t rdft_vlen = fftfilt->rdft_vlen;
> +
> +return rdft_data[(int)x * rdft_vlen + (int)y];
simpler
return fft->rdft_data[(int)x * fft->rdft_vlen + (int)y];
> +}
> +
> +static av_cold int initialize(AVFilterContext *ctx)
> +{
> +FFTFILTContext *fftfilt = ctx->priv;
> +int ret = 0;
> +
> +static double (*p[])(void *, double, double) = {lum};
> +const char *const func2_names[] = {"lum", NULL };
> +double (*func2[])(void *, double, double) = {lum, p[0], NULL };
[FFmpeg-devel] [PATCH] tests/fate: Add S302M test
Signed-off-by: Michael Niedermayer --- tests/fate/acodec.mak |6 ++ tests/ref/acodec/s302m |4 2 files changed, 10 insertions(+) create mode 100644 tests/ref/acodec/s302m diff --git a/tests/fate/acodec.mak b/tests/fate/acodec.mak index 691f9ff..b7e510c 100644 --- a/tests/fate/acodec.mak +++ b/tests/fate/acodec.mak @@ -140,6 +140,12 @@ fate-acodec-roqaudio: CODEC = roq_dpcm fate-acodec-roqaudio: ENCOPTS = -ar 22050 fate-acodec-roqaudio: DECOPTS = -ar 44100 +FATE_ACODEC-$(call ENCDEC, S302M, MPEGTS) += fate-acodec-s302m +fate-acodec-s302m: FMT = mpegts +fate-acodec-s302m: CODEC = s302m +fate-acodec-s302m: ENCOPTS = -ar 48000 -strict -2 +fate-acodec-s302m: DECOPTS = -ar 44100 + FATE_ACODEC-$(call ENCDEC, WAVPACK, WV) += fate-acodec-wavpack fate-acodec-wavpack: FMT = wv fate-acodec-wavpack: CODEC = wavpack -compression_level 1 diff --git a/tests/ref/acodec/s302m b/tests/ref/acodec/s302m new file mode 100644 index 000..f19eebe --- /dev/null +++ b/tests/ref/acodec/s302m @@ -0,0 +1,4 @@ +2d1494ad78292dca556fd079ec27f28d *tests/data/fate/acodec-s302m.mpegts +1589164 tests/data/fate/acodec-s302m.mpegts +f9b6528eee1aea04640ee83400c78689 *tests/data/fate/acodec-s302m.out.wav +stddev: 986.97 PSNR: 36.44 MAXDIFF:18642 bytes: 1058400/ 1056708 -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hevc_sao: use unaligned movs for sao_{band, filter} with width 8
On 01/03/15 7:04 PM, Michael Niedermayer wrote: > On Sun, Mar 01, 2015 at 06:07:23PM -0300, James Almer wrote: >> Suggested-by: Christophe Gisquet >> Signed-off-by: James Almer >> --- >> libavcodec/x86/hevc_sao.asm | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) > > LGTM Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hevc_sao: use unaligned movs for sao_{band, filter} with width 8
On Sun, Mar 01, 2015 at 06:07:23PM -0300, James Almer wrote: > Suggested-by: Christophe Gisquet > Signed-off-by: James Almer > --- > libavcodec/x86/hevc_sao.asm | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/dashenc: Update codec_str on extradata_size change
---
libavformat/dashenc.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 98036d3..25c699e 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -72,6 +72,7 @@ typedef struct OutputStream {
int bit_rate;
char bandwidth_str[64];
+int codec_str_extradata_size;
char codec_str[100];
} OutputStream;
@@ -498,8 +499,16 @@ static int write_manifest(AVFormatContext *s, int final)
for (i = 0; i < s->nb_streams; i++) {
AVStream *st = s->streams[i];
OutputStream *os = &c->streams[i];
-if (s->streams[i]->codec->codec_type != AVMEDIA_TYPE_VIDEO)
+
+if (st->codec->codec_type != AVMEDIA_TYPE_VIDEO)
continue;
+
+if (os->codec_str_extradata_size != st->codec->extradata_size) {
+memset(os->codec_str, 0, sizeof(os->codec_str));
+set_codec_str(s, st->codec, os->codec_str,
sizeof(os->codec_str));
+os->codec_str_extradata_size = st->codec->extradata_size;
+}
+
avio_printf(out, "\t\t\t\n", i,
os->codec_str, os->bandwidth_str, st->codec->width, st->codec->height);
output_segment_list(&c->streams[i], out, c);
avio_printf(out, "\t\t\t\n");
@@ -511,8 +520,16 @@ static int write_manifest(AVFormatContext *s, int final)
for (i = 0; i < s->nb_streams; i++) {
AVStream *st = s->streams[i];
OutputStream *os = &c->streams[i];
-if (s->streams[i]->codec->codec_type != AVMEDIA_TYPE_AUDIO)
+
+if (st->codec->codec_type != AVMEDIA_TYPE_AUDIO)
continue;
+
+if (os->codec_str_extradata_size != st->codec->extradata_size) {
+memset(os->codec_str, 0, sizeof(os->codec_str));
+set_codec_str(s, st->codec, os->codec_str,
sizeof(os->codec_str));
+os->codec_str_extradata_size = st->codec->extradata_size;
+}
+
avio_printf(out, "\t\t\t\n", i,
os->codec_str, os->bandwidth_str, st->codec->sample_rate);
avio_printf(out, "\t\t\t\t\n", st->codec->channels);
output_segment_list(&c->streams[i], out, c);
@@ -647,7 +664,8 @@ static int dash_write_header(AVFormatContext *s)
else if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO)
c->has_audio = 1;
-set_codec_str(s, os->ctx->streams[0]->codec, os->codec_str,
sizeof(os->codec_str));
+set_codec_str(s, s->streams[i]->codec, os->codec_str,
sizeof(os->codec_str));
+os->codec_str_extradata_size = s->streams[i]->codec->extradata_size;
os->first_pts = AV_NOPTS_VALUE;
os->max_pts = AV_NOPTS_VALUE;
os->segment_index = 1;
--
2.3.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 2.6 release
On 01/03/15 6:17 PM, Clément Bœsch wrote: > I might help writing the RELEASE_NOTES. Anything not present in the > Changelog that I should mention? Particular optimizations, area where a > large amount of fixes happened (and are not going to be backported), OPW, > or other various project changes? VP9 asm by Ronald that made the codec usable on x86_32 and also pre-ssse3 CPUs like Phenom (Even dual core Athlons can run 1080p 30fps VP9 content now). Pretty good argument to convince Google and Mozilla to use ffvp9 IMO :P. HEVC improvements could also be mentioned (C and asm performance improvements, and monochrome sequence support). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mxfenc: Adjust product name when opatom muxer is used
On Sun, Mar 1, 2015 at 4:06 AM, Robert Krüger wrote: > Currently the product name that ends up in mxf files muxed using the new op > atom muxer is "OP1A muxer" which is misleading. Attached patch changes > that. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > This will change the CRC for make fate-lavf-mxf_opatom So the regression test needs to be updated as well ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] libavformat/mxfenc: write package name metadata
---
libavformat/mxfenc.c | 88 +--
tests/ref/lavf/mxf| 6 ++--
tests/ref/lavf/mxf_d10| 2 +-
tests/ref/lavf/mxf_opatom | 2 +-
4 files changed, 82 insertions(+), 16 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index dfa647d..206fcfe 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -624,14 +624,44 @@ static void mxf_write_preface(AVFormatContext *s)
}
/*
- * Write a local tag containing an ascii string as utf-16
+ * Returns the length of the UTF-16 string, in 16-bit characters, that would
result
+ * from decoding the utf-8 string.
+ */
+static uint64_t mxf_utf16len(const char *utf8_str)
+{
+const uint8_t *q = utf8_str;
+uint64_t size = 0;
+while (*q) {
+uint32_t ch;
+GET_UTF8(ch, *q++, goto invalid;)
+if (ch < 0x1)
+size++;
+else
+size += 2;
+continue;
+invalid:
+av_log(NULL, AV_LOG_ERROR, "Invaid UTF8 sequence in mxf_utf16len\n\n");
+}
+size += 1;
+return size;
+}
+
+/*
+ * Returns the calculated length a local tag containing an utf-8 string as
utf-16
+ */
+static uint64_t mxf_utf16_local_tag_length(const char *utf8_str)
+{
+return utf8_str? 4 + mxf_utf16len(utf8_str) * 2: 0;
+}
+
+/*
+ * Write a local tag containing an utf-8 string as utf-16
*/
static void mxf_write_local_tag_utf16(AVIOContext *pb, int tag, const char
*value)
{
-int i, size = strlen(value);
+int size = mxf_utf16len(value);
mxf_write_local_tag(pb, size*2, tag);
-for (i = 0; i < size; i++)
-avio_wb16(pb, value[i]);
+avio_put_str16be(pb, value);
}
static void mxf_write_identification(AVFormatContext *s)
@@ -648,7 +678,9 @@ static void mxf_write_identification(AVFormatContext *s)
version = s->flags & AVFMT_FLAG_BITEXACT ?
"0.0.0" : AV_STRINGIFY(LIBAVFORMAT_VERSION);
-length = 84 + (strlen(company)+strlen(product)+strlen(version))*2; //
utf-16
+length = 72 + mxf_utf16_local_tag_length(company) +
+ mxf_utf16_local_tag_length(product) +
+ mxf_utf16_local_tag_length(version);
klv_encode_ber_length(pb, length);
// write uid
@@ -659,7 +691,6 @@ static void mxf_write_identification(AVFormatContext *s)
// write generation uid
mxf_write_local_tag(pb, 16, 0x3C09);
mxf_write_uuid(pb, Identification, 1);
-
mxf_write_local_tag_utf16(pb, 0x3C01, company); // Company Name
mxf_write_local_tag_utf16(pb, 0x3C02, product); // Product Name
mxf_write_local_tag_utf16(pb, 0x3C04, version); // Version String
@@ -1092,20 +1123,29 @@ static void
mxf_write_generic_sound_desc(AVFormatContext *s, AVStream *st)
mxf_write_generic_sound_common(s, st, mxf_generic_sound_descriptor_key, 0);
}
-static void mxf_write_package(AVFormatContext *s, enum MXFMetadataSetType type)
+static void mxf_write_package(AVFormatContext *s, enum MXFMetadataSetType
type, const char *package_name)
{
MXFContext *mxf = s->priv_data;
AVIOContext *pb = s->pb;
int i, track_count = s->nb_streams+1;
+uint64_t name_size = 0;
+
+if (package_name)
+name_size = mxf_utf16_local_tag_length(package_name);
+
+if (name_size >= INT16_MAX){
+av_log(s, AV_LOG_WARNING, "package name size %"PRIx64" invalid (too
large), ignoring\n", name_size);
+name_size = 0;
+}
if (type == MaterialPackage) {
mxf_write_metadata_key(pb, 0x013600);
PRINT_KEY(s, "Material Package key", pb->buf_ptr - 16);
-klv_encode_ber_length(pb, 92 + 16*track_count);
+klv_encode_ber_length(pb, 92 + name_size + (16*track_count));
} else {
mxf_write_metadata_key(pb, 0x013700);
PRINT_KEY(s, "Source Package key", pb->buf_ptr - 16);
-klv_encode_ber_length(pb, 112 + 16*track_count); // 20 bytes length
for descriptor reference
+klv_encode_ber_length(pb, 112 + name_size + (16*track_count)); // 20
bytes length for descriptor reference
}
// write uid
@@ -1119,6 +1159,10 @@ static void mxf_write_package(AVFormatContext *s, enum
MXFMetadataSetType type)
mxf_write_umid(s, type == SourcePackage);
PRINT_KEY(s, "package umid second part", pb->buf_ptr - 16);
+// package name
+if (name_size)
+mxf_write_local_tag_utf16(pb, 0x4402, package_name);
+
// package creation date
mxf_write_local_tag(pb, 8, 0x4405);
avio_wb64(pb, mxf->timestamp);
@@ -1187,11 +1231,33 @@ static int
mxf_write_essence_container_data(AVFormatContext *s)
static int mxf_write_header_metadata_sets(AVFormatContext *s)
{
+const char *material_package_name = NULL;
+const char *file_package_name = NULL;
+AVDictionaryEntry *entry = NULL;
+AVStream *st = NULL;
+int i;
+
+if (entry = av_dict_get(s->metadata, "material_package_name", NULL, 0))
+ material_package_name = entry->value;
+
+if (entry = av_dict_get(s->metadata, "
[FFmpeg-devel] [PATCH 1/2] libavformat/avio: added avio_put_str16be
---
libavformat/avio.h| 6 ++
libavformat/aviobuf.c | 50 +++---
libavformat/version.h | 2 +-
3 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/libavformat/avio.h b/libavformat/avio.h
index b9b4017..8fc7e27 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -234,6 +234,12 @@ int avio_put_str(AVIOContext *s, const char *str);
int avio_put_str16le(AVIOContext *s, const char *str);
/**
+ * Convert an UTF-8 string to UTF-16BE and write it.
+ * @return number of bytes written.
+ */
+int avio_put_str16be(AVIOContext *s, const char *str);
+
+/**
* Passing this as the "whence" parameter to a seek function causes it to
* return the filesize without seeking anywhere. Supporting this is optional.
* If it is not supported then the seek function will return <0.
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 8fd0466..8cb77b0 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -342,29 +342,33 @@ int avio_put_str(AVIOContext *s, const char *str)
return len;
}
-int avio_put_str16le(AVIOContext *s, const char *str)
-{
-const uint8_t *q = str;
-int ret = 0;
-int err = 0;
-
-while (*q) {
-uint32_t ch;
-uint16_t tmp;
-
-GET_UTF8(ch, *q++, goto invalid;)
-PUT_UTF16(ch, tmp, avio_wl16(s, tmp); ret += 2;)
-continue;
-invalid:
-av_log(s, AV_LOG_ERROR, "Invaid UTF8 sequence in avio_put_str16le\n");
-err = AVERROR(EINVAL);
-}
-avio_wl16(s, 0);
-if (err)
-return err;
-ret += 2;
-return ret;
-}
+#define PUT_STR16(type, write) \
+int avio_put_str16 ##type(AVIOContext *s, const char *str)\
+{\
+const uint8_t *q = str;\
+int ret = 0;\
+int err = 0;\
+while (*q) {\
+uint32_t ch;\
+uint16_t tmp;\
+GET_UTF8(ch, *q++, goto invalid;)\
+PUT_UTF16(ch, tmp, write(s, tmp); ret += 2;)\
+continue;\
+invalid:\
+av_log(s, AV_LOG_ERROR, "Invaid UTF8 sequence in avio_put_str16" #type
"\n");\
+err = AVERROR(EINVAL);\
+}\
+write(s, 0);\
+if (err)\
+return err;\
+ret += 2;\
+return ret;\
+}\
+
+PUT_STR16(le, avio_wl16)
+PUT_STR16(be, avio_wb16)
+
+#undef PUT_STR16
int ff_get_v_length(uint64_t val)
{
diff --git a/libavformat/version.h b/libavformat/version.h
index 248cd3c..9eddcbf 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -30,7 +30,7 @@
#include "libavutil/version.h"
#define LIBAVFORMAT_VERSION_MAJOR 56
-#define LIBAVFORMAT_VERSION_MINOR 23
+#define LIBAVFORMAT_VERSION_MINOR 24
#define LIBAVFORMAT_VERSION_MICRO 106
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
--
2.2.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/2] libavformat/mxfenc: write package name metadata
changes since v1: * split into 2 patches * added avformat minor version bump * search for file_package_name in stream metadata as well, thats where the demuxer puts the key Mark Reid (2): libavformat/avio: added avio_put_str16be libavformat/mxfenc: write package name metadata libavformat/avio.h| 6 libavformat/aviobuf.c | 50 ++- libavformat/mxfenc.c | 88 +-- libavformat/version.h | 2 +- tests/ref/lavf/mxf| 6 ++-- tests/ref/lavf/mxf_d10| 2 +- tests/ref/lavf/mxf_opatom | 2 +- 7 files changed, 116 insertions(+), 40 deletions(-) -- 2.2.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 2.6 release
On Sun, Mar 01, 2015 at 10:17:15PM +0100, Clément Bœsch wrote: > On Sun, Mar 01, 2015 at 05:53:59PM +0100, Michael Niedermayer wrote: > > Hi all > > > > its a while since FFmpeg 2.5, so its getting time to make 2.6 > > if you want something in it or something fixed, now is your last > > chance ;) > > > > About the name if noone suggests something then ill pick a random > > scientist from the list i have from past suggestions > > > > I might help writing the RELEASE_NOTES. Anything not present in the thanks! > Changelog that I should mention? Particular optimizations, area where a > large amount of fixes happened (and are not going to be backported), OPW, > or other various project changes? if i knew something i would have added it to the Changelog probably so i cant think of anything but iam sure forgetting somthing ... > > BTW, do we want to encourage occasional contributors and companies to > contribute more by mentioning them in a thanks section? Quickly skimming > through the history I see NVIDIA, Samsung, Collabora, ... What do people > think? See the bottom of http://i3wm.org/downloads/RELEASE-NOTES-4.9.txt > for an example (yeah I know it's not the first time I pick that same > model). sure, possible [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Don't use round when encoding png
On Sun, Mar 01, 2015 at 09:34:46PM +0100, wm4 wrote: > On Sun, 1 Mar 2015 20:34:57 +0100 > Michael Niedermayer wrote: > > > On Sun, Mar 01, 2015 at 07:57:56PM +0100, wm4 wrote: > > > On Sun, 1 Mar 2015 19:48:20 +0100 > > > Nicolas George wrote: > > > > > > > Le primidi 11 ventôse, an CCXXIII, wm4 a écrit : > > > > > I prefer the color of fuck broken platforms nobody uses. > > > > > > > > Well, obviously someone uses a platform where it makes a difference, > > > > otherwise nobody would have noticed. > > > > > > > > Regards, > > > > > > > > > > If they really care, get them to fix the platform (as long as our use > > > of the function is actually guaranteed by the standard). > > > > the reason why it fails is probably that the code in pngenc.c tries > > to write a double precission value by using AV_W* macros > > > > this is a bad idea and likely not what the author intended > > > > (Maybe then it shouldn't have been merged without review and without > presence on the mailing list?) I reviewed it, and i missed that bug. So has everyone else on the ML who looked at carls fix > > I'm pretty sure the author expected the values to be correctly rounded, > and that the AV_WB32() macro casts its float argument to an integer. Is > that not the case? the macro does not cast, and adding such casts could cause a slowdown as it adds a operation which compilers might fail to remove what do you suggest to solve this bug ? its easy to solve technically the hard part is finding a solution everyone likes [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 2.6 release
On Sun, Mar 01, 2015 at 05:53:59PM +0100, Michael Niedermayer wrote: > Hi all > > its a while since FFmpeg 2.5, so its getting time to make 2.6 > if you want something in it or something fixed, now is your last > chance ;) > > About the name if noone suggests something then ill pick a random > scientist from the list i have from past suggestions > I might help writing the RELEASE_NOTES. Anything not present in the Changelog that I should mention? Particular optimizations, area where a large amount of fixes happened (and are not going to be backported), OPW, or other various project changes? BTW, do we want to encourage occasional contributors and companies to contribute more by mentioning them in a thanks section? Quickly skimming through the history I see NVIDIA, Samsung, Collabora, ... What do people think? See the bottom of http://i3wm.org/downloads/RELEASE-NOTES-4.9.txt for an example (yeah I know it's not the first time I pick that same model). Last thing, anyone to have a look to FATE and see if something is relevant for fixing before the release? I see that hevc still seems to fail a test with threading for instance. Don't we want to get this fixed before the release? -- Clément B. pgp9WH1UeYAay.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86/hevc_sao: use unaligned movs for sao_{band, filter} with width 8
Suggested-by: Christophe Gisquet Signed-off-by: James Almer --- libavcodec/x86/hevc_sao.asm | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/x86/hevc_sao.asm b/libavcodec/x86/hevc_sao.asm index 8c2436b..86ef847 100644 --- a/libavcodec/x86/hevc_sao.asm +++ b/libavcodec/x86/hevc_sao.asm @@ -193,10 +193,10 @@ cglobal hevc_sao_band_filter_%2_%1, 6, 6, 15, 7*mmsize*ARCH_X86_32, dst, src, ds align 16 .loop %if %2 == 8 -mova m8, [srcq] +movu m8, [srcq] HEVC_SAO_BAND_FILTER_COMPUTE %1, m9, m8 CLIPW m8, m14, m13 -mova [dstq], m8 +movu [dstq], m8 %endif %assign i 0 @@ -537,7 +537,7 @@ align 16 HEVC_SAO_EDGE_FILTER_COMPUTE_10 CLIPW m2, m0, [pw_mask %+ %1] -mova [dstq], m2 +movu [dstq], m2 %endif %assign i 0 -- 2.3.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avformat: map T.140 RTP codec to text
On Sun, Mar 01, 2015 at 08:25:12AM +0100, Clément Bœsch wrote:
> On Sat, Feb 28, 2015 at 11:15:40PM +0100, Gilles Chanteperdrix wrote:
> > This makes more sense than mapping to AV_CODEC_ID_SUBRIP. Nothing
> > indicates that a T.140 track contains subrip sub-titles.
> >
> > Signed-off-by: Gilles Chanteperdrix
> > ---
> > libavformat/rtpdec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
> > index 8cd2f26..2227e23 100644
> > --- a/libavformat/rtpdec.c
> > +++ b/libavformat/rtpdec.c
> > @@ -59,7 +59,7 @@ static RTPDynamicProtocolHandler opus_dynamic_handler = {
> > static RTPDynamicProtocolHandler t140_dynamic_handler = { /* RFC 4103 */
> > .enc_name = "t140",
> > .codec_type = AVMEDIA_TYPE_SUBTITLE,
> > -.codec_id = AV_CODEC_ID_SUBRIP,
> > +.codec_id = AV_CODEC_ID_TEXT,
> > };
> >
>
> What do the subs look like? Is it really just plaintext or there is some
> binary or whatever markup?
The T.140 RTP payload is for transmitting plain text. What really
gets transmitted depends on what the server decides to send. I
originally chose subrip, because that is the way vlc decodes these
tracks, but really, this is not standard.
--
Gilles.
pgpEMrkTRL7X1.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Don't use round when encoding png
On Sun, 1 Mar 2015 20:34:57 +0100 Michael Niedermayer wrote: > On Sun, Mar 01, 2015 at 07:57:56PM +0100, wm4 wrote: > > On Sun, 1 Mar 2015 19:48:20 +0100 > > Nicolas George wrote: > > > > > Le primidi 11 ventôse, an CCXXIII, wm4 a écrit : > > > > I prefer the color of fuck broken platforms nobody uses. > > > > > > Well, obviously someone uses a platform where it makes a difference, > > > otherwise nobody would have noticed. > > > > > > Regards, > > > > > > > If they really care, get them to fix the platform (as long as our use > > of the function is actually guaranteed by the standard). > > the reason why it fails is probably that the code in pngenc.c tries > to write a double precission value by using AV_W* macros > > this is a bad idea and likely not what the author intended > (Maybe then it shouldn't have been merged without review and without presence on the mailing list?) I'm pretty sure the author expected the values to be correctly rounded, and that the AV_WB32() macro casts its float argument to an integer. Is that not the case? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Don't use round when encoding png
On Sun, Mar 01, 2015 at 07:57:56PM +0100, wm4 wrote: > On Sun, 1 Mar 2015 19:48:20 +0100 > Nicolas George wrote: > > > Le primidi 11 ventôse, an CCXXIII, wm4 a écrit : > > > I prefer the color of fuck broken platforms nobody uses. > > > > Well, obviously someone uses a platform where it makes a difference, > > otherwise nobody would have noticed. > > > > Regards, > > > > If they really care, get them to fix the platform (as long as our use > of the function is actually guaranteed by the standard). the reason why it fails is probably that the code in pngenc.c tries to write a double precission value by using AV_W* macros this is a bad idea and likely not what the author intended -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why is writing the colr atom not the default in the mov muxer?
Am Sonntag, 1. März 2015 schrieb Derek Buitenhuis : > On 3/1/2015 12:26 PM, Robert Krüger wrote: > > Am I reading the committed patch incorrectly or is colr still not written > > by default? I thought the argument against replacing the flag (Derek's > > first patch) was withdrawn because there has not been a release that > > contained the original flag. > > The committed patch is unrelated to this. It was to make it actually > create valid MP4 files in the first place. > > Ok, thanks for the clarification. Are you planning on submitting another one that changes the default like your first patch did? -- Robert Krüger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Don't use round when encoding png
On Sun, 1 Mar 2015 19:48:20 +0100 Nicolas George wrote: > Le primidi 11 ventôse, an CCXXIII, wm4 a écrit : > > I prefer the color of fuck broken platforms nobody uses. > > Well, obviously someone uses a platform where it makes a difference, > otherwise nobody would have noticed. > > Regards, > If they really care, get them to fix the platform (as long as our use of the function is actually guaranteed by the standard). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Don't use round when encoding png
Le primidi 11 ventôse, an CCXXIII, wm4 a écrit : > I prefer the color of fuck broken platforms nobody uses. Well, obviously someone uses a platform where it makes a difference, otherwise nobody would have noticed. 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] Why is writing the colr atom not the default in the mov muxer?
On 3/1/2015 12:26 PM, Robert Krüger wrote: > Am I reading the committed patch incorrectly or is colr still not written > by default? I thought the argument against replacing the flag (Derek's > first patch) was withdrawn because there has not been a release that > contained the original flag. The committed patch is unrelated to this. It was to make it actually create valid MP4 files in the first place. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Don't use round when encoding png
On Sun, 1 Mar 2015 16:26:20 +0100 Michael Niedermayer wrote: > On Sun, Mar 01, 2015 at 01:11:08PM +0100, wm4 wrote: > > On Sun, 1 Mar 2015 12:09:28 +0100 > > Carl Eugen Hoyos wrote: > > > > > On Sunday 01 March 2015 11:22:10 am Michael Niedermayer wrote: > > > > On Sun, Mar 01, 2015 at 09:44:30AM +0100, Carl Eugen Hoyos wrote: > > > > > Attached untested patch should fix compilation on broken platforms. > > > > > We don't use round() currently because it appears less portable than > > > > > lrintf(). > > > > > > > yes reducing float code usage should be fine, less potential to > > > > cause problems with regression tests > > > > > > New patch attached. > > > > > > Please review, Carl Eugen > > > > Seriously? You replace kind of magic, but sourced constants with > > completely magic ones? > > one could replace the round by a cast to int and a +0.5 > or figure out why it doesnt work on sunos > > iam fine with whatever color people prefer as long as it works > > [...] I prefer the color of fuck broken platforms nobody uses. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add erosion, dilation, median, deflate & inflate filter
Le primidi 11 ventôse, an CCXXIII, Paul B Mahol a écrit :
> +AVFilterContext *ctx = inlink->dst;
> +AVFilterLink *outlink = ctx->outputs[0];
> +EDContext *s = ctx->priv;
> +AVFrame *out;
> +int plane, y, x, i;
> +
> +out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
> +if (!out) {
> +av_frame_free(&in);
> +return AVERROR(ENOMEM);
> +}
> +av_frame_copy_props(out, in);
> +
> +for (plane = 0; plane < s->nb_planes; plane++) {
> +if (s->planes & (1 << plane)) {
> +const uint8_t *src = in->data[plane];
> +uint8_t *dst = out->data[plane];
> +int stride = in->linesize[plane];
> +int height = s->planeheight[plane];
> +int width = s->planewidth[plane];
> +uint8_t *p0 = s->buffer + 16;
> +uint8_t *p1 = p0 + s->planewidth[0];
> +uint8_t *p2 = p1 + s->planewidth[0];
> +uint8_t *orig = p0, *end = p2;
> +
> +
> +line_copy8(p0, src + stride, width, 1);
> +line_copy8(p1, src, width, 1);
> +
> +for (y = 0; y < height; y++) {
> +}
> +
> +p0 = p1;
> +p1 = p2;
> +p2 = (p2 == end) ? orig: p2 + s->planewidth[0];
> +dst += out->linesize[plane];
> +}
> +} else {
> +av_image_copy_plane(out->data[plane], out->linesize[plane],
> +in->data[plane], in->linesize[plane],
> +s->planewidth[plane], s->planeheight[plane]);
> +}
> +}
> +
> +av_frame_free(&in);
> +return ff_filter_frame(outlink, out);
> +}
I find that much duplicated code (can you tell from which one of the five
filters this excerpt comes from?) is a very bad idea. Better program use
functions with parameters or possibly macros than copy-paste.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] FFmpeg 2.6 release
Hi all its a while since FFmpeg 2.5, so its getting time to make 2.6 if you want something in it or something fixed, now is your last chance ;) About the name if noone suggests something then ill pick a random scientist from the list i have from past suggestions -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avutil/opt: also test av_opt_show2()
On Sat, Feb 28, 2015 at 12:11:20AM +0100, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavutil/opt.c| 47 +-- > tests/ref/fate/opt | 23 +++ > 2 files changed, 48 insertions(+), 22 deletions(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avutil/opt: Also test/compare the av_log output i the selftest
On Sat, Feb 28, 2015 at 12:11:19AM +0100, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavutil/opt.c|8 +++ > tests/ref/fate/opt | 203 > > 2 files changed, 211 insertions(+) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Don't use round when encoding png
On Sun, Mar 01, 2015 at 01:11:08PM +0100, wm4 wrote: > On Sun, 1 Mar 2015 12:09:28 +0100 > Carl Eugen Hoyos wrote: > > > On Sunday 01 March 2015 11:22:10 am Michael Niedermayer wrote: > > > On Sun, Mar 01, 2015 at 09:44:30AM +0100, Carl Eugen Hoyos wrote: > > > > Attached untested patch should fix compilation on broken platforms. > > > > We don't use round() currently because it appears less portable than > > > > lrintf(). > > > > > yes reducing float code usage should be fine, less potential to > > > cause problems with regression tests > > > > New patch attached. > > > > Please review, Carl Eugen > > Seriously? You replace kind of magic, but sourced constants with > completely magic ones? one could replace the round by a cast to int and a +0.5 or figure out why it doesnt work on sunos iam fine with whatever color people prefer as long as it works [...] -- 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
[FFmpeg-devel] [PATCH] lavfi: add erosion, dilation, median, deflate & inflate filter
Signed-off-by: Paul B Mahol
---
Changelog | 1 +
doc/filters.texi | 91 +++
libavfilter/Makefile | 5 +
libavfilter/allfilters.c | 5 +
libavfilter/vf_neighbor.c | 648 ++
5 files changed, 750 insertions(+)
create mode 100644 libavfilter/vf_neighbor.c
diff --git a/Changelog b/Changelog
index de08065..37cffb4 100644
--- a/Changelog
+++ b/Changelog
@@ -35,6 +35,7 @@ version :
- Fix stsd atom corruption in DNxHD QuickTimes
- Canopus HQX decoder
- RTP depacketization of T.140 text (RFC 4103)
+- erosion, dilation, median, deflate and inflate filters
version 2.5:
diff --git a/doc/filters.texi b/doc/filters.texi
index 0c72145..ce5bb33 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -3569,6 +3569,24 @@ Set whether or not chroma is considered in the metric
calculations. Default is
@code{1}.
@end table
+@section deflate
+
+Apply deflate effect to the video.
+
+This filter replaces the pixel by the local(3x3) average by taking into account
+only values lower than the pixel.
+
+It accepts the following options:
+
+@table @option
+@item threshold
+Allows to limit the maximum change, default is 65535.
+
+@item planes
+Flag which specifies which planes to filter. Default is 15 i.e. all four
+planes.
+@end table
+
@section dejudder
Remove judder produced by partially interlaced telecined content.
@@ -3728,6 +3746,27 @@ FFmpeg was configured with @code{--enable-opencl}.
Default value is 0.
@end table
+@section dilation
+
+Apply dilation effect to the video.
+
+This filter replaces the pixel by the local(3x3) maximum.
+
+It accepts the following options:
+
+@table @option
+@item threshold
+Allows to limit the maximum change, default is 65535.
+
+@item coordinates
+Flag which specifies the pixel to refer to. Default is 255 i.e. all eight
+pixels are used.
+
+@item planes
+Flag which specifies which planes to filter. Default is 15 i.e. all four
+planes.
+@end table
+
@section drawbox
Draw a colored box on the input image.
@@ -4437,6 +4476,27 @@ value.
@end table
+@section erosion
+
+Apply erosion effect to the video.
+
+This filter replaces the pixel by the local(3x3) minimum.
+
+It accepts the following options:
+
+@table @option
+@item threshold
+Allows to limit the maximum change, default is 65535.
+
+@item coordinates
+Flag which specifies the pixel to refer to. Default is 255 i.e. all eight
+pixels are used.
+
+@item planes
+Flag which specifies which planes to filter. Default is 15 i.e. all four
+planes.
+@end table
+
@section extractplanes
Extract color channel components from input video stream into
@@ -5908,6 +5968,24 @@ Default value is @code{none}.
Swap luma/chroma/alpha fields. Exchange even & odd lines. Default value is
@code{0}.
@end table
+@section inflate
+
+Apply inflate effect to the video.
+
+This filter replaces the pixel by the local(3x3) average by taking into account
+only values higher than the pixel.
+
+It accepts the following options:
+
+@table @option
+@item threshold
+Allows to limit the maximum change, default is 65535.
+
+@item planes
+Flag which specifies which planes to filter. Default is 15 i.e. all four
+planes.
+@end table
+
@section interlace
Simple interlacing filter from progressive contents. This interleaves upper (or
@@ -6214,6 +6292,19 @@ lutyuv=y='bitand(val, 128+64+32)'
@end example
@end itemize
+@section median
+
+Apply median effect to the video.
+
+This filter replaces the pixel by the local(3x3) median.
+
+This filter accepts the following options:
+@table @option
+@item planes
+Flag which specifies which planes to filter. Default is 15 i.e. all four
+planes.
+@end table
+
@section mergeplanes
Merge color channel components from several video streams.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 289c63b..24de476 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -109,15 +109,18 @@ OBJS-$(CONFIG_CROPDETECT_FILTER) +=
vf_cropdetect.o
OBJS-$(CONFIG_CURVES_FILTER) += vf_curves.o
OBJS-$(CONFIG_DCTDNOIZ_FILTER) += vf_dctdnoiz.o
OBJS-$(CONFIG_DECIMATE_FILTER) += vf_decimate.o
+OBJS-$(CONFIG_DEFLATE_FILTER)+= vf_neighbor.o
OBJS-$(CONFIG_DEJUDDER_FILTER) += vf_dejudder.o
OBJS-$(CONFIG_DELOGO_FILTER) += vf_delogo.o
OBJS-$(CONFIG_DESHAKE_FILTER)+= vf_deshake.o
+OBJS-$(CONFIG_DILATION_FILTER) += vf_neighbor.o
OBJS-$(CONFIG_DRAWBOX_FILTER)+= vf_drawbox.o
OBJS-$(CONFIG_DRAWGRID_FILTER) += vf_drawbox.o
OBJS-$(CONFIG_DRAWTEXT_FILTER) += vf_drawtext.o
OBJS-$(CONFIG_ELBG_FILTER) += vf_elbg.o
OBJS-$(CONFIG_EDGEDETECT_FILTER) += vf_edgedetect.o
OBJS-$(CONFIG_EQ_FILTER) += vf_eq.o
+OBJS-$(CONFIG_EROSION_FILTER)+= vf_neighbor.o
OBJS-$(CONFIG_EXTRACTPLANES_FILTER)
Re: [FFmpeg-devel] [RFC]Don't use round when encoding png
On Sun, 1 Mar 2015 12:09:28 +0100 Carl Eugen Hoyos wrote: > On Sunday 01 March 2015 11:22:10 am Michael Niedermayer wrote: > > On Sun, Mar 01, 2015 at 09:44:30AM +0100, Carl Eugen Hoyos wrote: > > > Attached untested patch should fix compilation on broken platforms. > > > We don't use round() currently because it appears less portable than > > > lrintf(). > > > yes reducing float code usage should be fine, less potential to > > cause problems with regression tests > > New patch attached. > > Please review, Carl Eugen Seriously? You replace kind of magic, but sourced constants with completely magic ones? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Don't use round when encoding png
On Sun, Mar 01, 2015 at 12:09:28PM +0100, Carl Eugen Hoyos wrote: > On Sunday 01 March 2015 11:22:10 am Michael Niedermayer wrote: > > On Sun, Mar 01, 2015 at 09:44:30AM +0100, Carl Eugen Hoyos wrote: > > > Attached untested patch should fix compilation on broken platforms. > > > We don't use round() currently because it appears less portable than > > > lrintf(). > > > yes reducing float code usage should be fine, less potential to > > cause problems with regression tests > > New patch attached. > > Please review, Carl Eugen > pngenc.c | 55 +++ > 1 file changed, 27 insertions(+), 28 deletions(-) > aaeeb2a2e860b60ec403b84980542f97091cc21b patchpnground.diff > diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c > index 9fd8eef..b6eedde 100644 should be ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- 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]Improve the intra_dc_precision API doc
On Sun, Mar 01, 2015 at 12:56:44PM +0100, Carl Eugen Hoyos wrote: > Hi! > > The mpegvideo decoder sets intra_dc_precision since forever (!). > > Please comment, Carl Eugen LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why is writing the colr atom not the default in the mov muxer?
On Tue, Feb 24, 2015 at 11:55 AM, Michael Niedermayer wrote: > On Tue, Feb 24, 2015 at 08:00:07AM +, tim nicholson wrote: > > On 21/02/15 01:34, Dave Rice wrote: > > > Hi Robert, Kevin, > > > > > >> On Feb 20, 2015, at 9:56 AM, Robert Krüger > wrote: > > >> > > >> Am Freitag, 20. Februar 2015 schrieb Kevin Wheatley : > > >> > > >>> On Fri, Feb 20, 2015 at 1:30 PM, Robert Krüger > >>> > wrote: > > if I read the code correctly, the colr atom is only written in the > mov > > muxer if the flag write_colr is specified. Was that behaviour > chosen to > > have better backward compatibility or is there another reason not to > > >>> write > > this standard atom by default? > > >>> > > >>> I chose that way to preserve the older behaviour, as it can change > how > > >>> files will be interpreted. > > >>> > > >>> I assumed that but isn't the change then a change for the better > (then > > >> maybe requiring a version bump and an entry in the release notes)? > After > > >> all Apple muxers write it by default as well and not trusting the > input > > >> metadata seems to me like something that should be opt-out rather than > > >> opt-in but that's just my 2c. > > > > > > That's also my two cents and I also wondered why users have to opt-in > to a correctly written file. The QuickTime spec says that colr is required > with some streams (such as raw uyvy422 and v210), see: > https://developer.apple.com/library/mac/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG9 > . > > > > > > I'd propose that colr be written by default. The interpretation may be > different but, since a file with a colr atom is more self-descriptive, the > interpretation is more likely to be correct. > > > > +1 > > if someone posts a patch, ill apply it > Am I reading the committed patch incorrectly or is colr still not written by default? I thought the argument against replacing the flag (Derek's first patch) was withdrawn because there has not been a release that contained the original flag. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mxfenc: Adjust product name when opatom muxer is used
Currently the product name that ends up in mxf files muxed using the new op atom muxer is "OP1A muxer" which is misleading. Attached patch changes that. mxf_opatom_product_name.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Improve the intra_dc_precision API doc
Hi!
The mpegvideo decoder sets intra_dc_precision since forever (!).
Please comment, Carl Eugen
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 575dae1..a9dbff7 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1823,7 +1823,7 @@ typedef struct AVCodecContext {
/**
* precision of the intra DC coefficient - 8
* - encoding: Set by user.
- * - decoding: unused
+ * - decoding: Set by libavcodec
*/
int intra_dc_precision;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Don't use round when encoding png
On Sunday 01 March 2015 11:22:10 am Michael Niedermayer wrote:
> On Sun, Mar 01, 2015 at 09:44:30AM +0100, Carl Eugen Hoyos wrote:
> > Attached untested patch should fix compilation on broken platforms.
> > We don't use round() currently because it appears less portable than
> > lrintf().
> yes reducing float code usage should be fine, less potential to
> cause problems with regression tests
New patch attached.
Please review, Carl Eugen
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index 9fd8eef..b6eedde 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -231,78 +231,77 @@ static int png_write_row(PNGEncContext *s, const uint8_t
*data, int size)
return 0;
}
-#define AV_WB32_PNG(buf, n) (AV_WB32(buf, round((n) * 10)))
static int png_get_chrm(enum AVColorPrimaries prim, uint8_t *buf)
{
-double rx, ry, gx, gy, bx, by, wx = 0.3127, wy = 0.3290;
+int rx, ry, gx, gy, bx, by, wx = 312700, wy = 329000;
switch (prim) {
case AVCOL_PRI_BT709:
-rx = 0.640; ry = 0.330;
-gx = 0.300; gy = 0.600;
-bx = 0.150; by = 0.060;
+rx = 64000; ry = 33000;
+gx = 3; gy = 6;
+bx = 15000; by = 6000;
break;
case AVCOL_PRI_BT470M:
-rx = 0.670; ry = 0.330;
-gx = 0.210; gy = 0.710;
-bx = 0.140; by = 0.080;
-wx = 0.310; wy = 0.316;
+rx = 67000; ry = 33000;
+gx = 21000; gy = 71000;
+bx = 14000; by = 8000;
+wx = 31000; wy = 31600;
break;
case AVCOL_PRI_BT470BG:
-rx = 0.640; ry = 0.330;
-gx = 0.290; gy = 0.600;
-bx = 0.150; by = 0.060;
+rx = 64000; ry = 33000;
+gx = 29000; gy = 6;
+bx = 15000; by = 06000;
break;
case AVCOL_PRI_SMPTE170M:
case AVCOL_PRI_SMPTE240M:
-rx = 0.630; ry = 0.340;
-gx = 0.310; gy = 0.595;
-bx = 0.155; by = 0.070;
+rx = 63000; ry = 34000;
+gx = 31000; gy = 59500;
+bx = 15500; by = 7000;
break;
case AVCOL_PRI_BT2020:
-rx = 0.708; ry = 0.292;
-gx = 0.170; gy = 0.797;
-bx = 0.131; by = 0.046;
+rx = 70800; ry = 29200;
+gx = 17000; gy = 79700;
+bx = 13100; by = 4600;
break;
default:
return 0;
}
-AV_WB32_PNG(buf , wx); AV_WB32_PNG(buf + 4 , wy);
-AV_WB32_PNG(buf + 8 , rx); AV_WB32_PNG(buf + 12, ry);
-AV_WB32_PNG(buf + 16, gx); AV_WB32_PNG(buf + 20, gy);
-AV_WB32_PNG(buf + 24, bx); AV_WB32_PNG(buf + 28, by);
+AV_WB32(buf , wx); AV_WB32(buf + 4 , wy);
+AV_WB32(buf + 8 , rx); AV_WB32(buf + 12, ry);
+AV_WB32(buf + 16, gx); AV_WB32(buf + 20, gy);
+AV_WB32(buf + 24, bx); AV_WB32(buf + 28, by);
return 1;
}
static int png_get_gama(enum AVColorTransferCharacteristic trc, uint8_t *buf)
{
-double gamma;
+int gamma;
switch (trc) {
case AVCOL_TRC_BT709:
case AVCOL_TRC_SMPTE170M:
case AVCOL_TRC_SMPTE240M:
case AVCOL_TRC_BT1361_ECG:
case AVCOL_TRC_BT2020_10:
case AVCOL_TRC_BT2020_12:
/* these share a segmented TRC, but gamma 1.961 is a close
approximation, and also more correct for decoding content */
-gamma = 1.961;
+gamma = 50994; // 10 / 1.961
break;
case AVCOL_TRC_GAMMA22:
case AVCOL_TRC_IEC61966_2_1:
-gamma = 2.2;
+gamma = 45455; // 10 / 2.2
break;
case AVCOL_TRC_GAMMA28:
-gamma = 2.8;
+gamma = 35714; // 10 / 2.8
break;
case AVCOL_TRC_LINEAR:
-gamma = 1.0;
+gamma = 10;
break;
default:
return 0;
}
-AV_WB32_PNG(buf, 1.0 / gamma);
+AV_WB32(buf, gamma);
return 1;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Don't use round when encoding png
Michael Niedermayer gmx.at> writes: > > Attached untested patch should fix compilation on > > broken platforms. We don't use round() currently > > because it appears less portable than lrintf(). > > which platform is that ? http://fate.ffmpeg.org/history.cgi?slot=x86-opensolaris-suncc5.10 Looks like one of yours... Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Improve video creation examples
On Sun, Mar 01, 2015 at 10:13:34AM +0100, Carl Eugen Hoyos wrote: > Hi! > > The examples for video creation from images drop frames > which is probably not what users expect. > > Please comment, Carl Eugen > ffmpeg.texi |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > 3e2ef09ab39df5eb9d54af4ddef424b8b1cc7c26 patchimg2framerate.diff probably ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Don't use round when encoding png
On Sun, Mar 01, 2015 at 09:44:30AM +0100, Carl Eugen Hoyos wrote: > Hi! > > Attached untested patch should fix compilation on broken platforms. > We don't use round() currently because it appears less portable than > lrintf(). which platform is that ? but yes reducing float code usage should be fine, less potential to cause problems with regression tests [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Improve video creation examples
Hi!
The examples for video creation from images drop frames
which is probably not what users expect.
Please comment, Carl Eugen
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 6772f2f..1dde682 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1469,7 +1469,7 @@ combination with -ss to start extracting from a certain
point in time.
For creating a video from many images:
@example
-ffmpeg -f image2 -i foo-%03d.jpeg -r 12 -s WxH foo.avi
+ffmpeg -f image2 -framerate 12 -i foo-%03d.jpeg -s WxH foo.avi
@end example
The syntax @code{foo-%03d.jpeg} specifies to use a decimal number
@@ -1484,7 +1484,7 @@ image2-specific @code{-pattern_type glob} option.
For example, for creating a video from filenames matching the glob pattern
@code{foo-*.jpeg}:
@example
-ffmpeg -f image2 -pattern_type glob -i 'foo-*.jpeg' -r 12 -s WxH foo.avi
+ffmpeg -f image2 -pattern_type glob -framerate 12 -i 'foo-*.jpeg' -s WxH
foo.avi
@end example
@item
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC]Don't use round when encoding png
Hi!
Attached untested patch should fix compilation on broken platforms.
We don't use round() currently because it appears less portable than
lrintf().
Please comment, Carl Eugen
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index 9fd8eef..2826f36 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -231,46 +231,45 @@ static int png_write_row(PNGEncContext *s, const uint8_t
*data, int size)
return 0;
}
-#define AV_WB32_PNG(buf, n) (AV_WB32(buf, round((n) * 10)))
static int png_get_chrm(enum AVColorPrimaries prim, uint8_t *buf)
{
-double rx, ry, gx, gy, bx, by, wx = 0.3127, wy = 0.3290;
+int rx, ry, gx, gy, bx, by, wx = 312700, wy = 329000;
switch (prim) {
case AVCOL_PRI_BT709:
-rx = 0.640; ry = 0.330;
-gx = 0.300; gy = 0.600;
-bx = 0.150; by = 0.060;
+rx = 64000; ry = 33000;
+gx = 3; gy = 6;
+bx = 15000; by = 6000;
break;
case AVCOL_PRI_BT470M:
-rx = 0.670; ry = 0.330;
-gx = 0.210; gy = 0.710;
-bx = 0.140; by = 0.080;
-wx = 0.310; wy = 0.316;
+rx = 67000; ry = 33000;
+gx = 21000; gy = 71000;
+bx = 14000; by = 8000;
+wx = 31000; wy = 31600;
break;
case AVCOL_PRI_BT470BG:
-rx = 0.640; ry = 0.330;
-gx = 0.290; gy = 0.600;
-bx = 0.150; by = 0.060;
+rx = 64000; ry = 33000;
+gx = 29000; gy = 6;
+bx = 15000; by = 06000;
break;
case AVCOL_PRI_SMPTE170M:
case AVCOL_PRI_SMPTE240M:
-rx = 0.630; ry = 0.340;
-gx = 0.310; gy = 0.595;
-bx = 0.155; by = 0.070;
+rx = 63000; ry = 34000;
+gx = 31000; gy = 59500;
+bx = 15500; by = 7000;
break;
case AVCOL_PRI_BT2020:
-rx = 0.708; ry = 0.292;
-gx = 0.170; gy = 0.797;
-bx = 0.131; by = 0.046;
+rx = 70800; ry = 29200;
+gx = 17000; gy = 79700;
+bx = 13100; by = 4600;
break;
default:
return 0;
}
-AV_WB32_PNG(buf , wx); AV_WB32_PNG(buf + 4 , wy);
-AV_WB32_PNG(buf + 8 , rx); AV_WB32_PNG(buf + 12, ry);
-AV_WB32_PNG(buf + 16, gx); AV_WB32_PNG(buf + 20, gy);
-AV_WB32_PNG(buf + 24, bx); AV_WB32_PNG(buf + 28, by);
+AV_WB32(buf , wx); AV_WB32(buf + 4 , wy);
+AV_WB32(buf + 8 , rx); AV_WB32(buf + 12, ry);
+AV_WB32(buf + 16, gx); AV_WB32(buf + 20, gy);
+AV_WB32(buf + 24, bx); AV_WB32(buf + 28, by);
return 1;
}
@@ -302,7 +301,7 @@ static int png_get_gama(enum AVColorTransferCharacteristic
trc, uint8_t *buf)
return 0;
}
-AV_WB32_PNG(buf, 1.0 / gamma);
+AV_WB32(buf, lrintf(10.0 / gamma ));
return 1;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
