Re: [FFmpeg-devel] [PATCH 6/6] lavc/flacdsp: document limitations of the LPC encoder
Hi,
2014-08-12 23:22 GMT+02:00 James Darnley :
> ---
> libavcodec/flacdsp.h |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/libavcodec/flacdsp.h b/libavcodec/flacdsp.h
> index 272cf2a..36cd904 100644
> --- a/libavcodec/flacdsp.h
> +++ b/libavcodec/flacdsp.h
> @@ -27,6 +27,13 @@ typedef struct FLACDSPContext {
> int len, int shift);
> void (*lpc)(int32_t *samples, const int coeffs[32], int order,
> int qlevel, int len);
> +/**
> + * This function has some limitations with various configurations:
> + * - when CONFIG_SMALL is 0 there is an unrolled loop which assumes the
> + * maximum value of order is 32.
> + * - when SSE4 (or newer) is available on x86 there is an unrolled copy
> + * which also assumes the maximum value of order is 0.
> + */
> void (*lpc_encode)(int32_t *res, const int32_t *smp, int len, int order,
> const int32_t *coefs, int shift);
> } FLACDSPContext;
Some comments:
- The decoder passes int coeffs[32]; I don't see how order > 32 would then work
- Why not do the same for lpc_encode, and document that maximum order
value is 32
- The decoder actually reads the order (see decode_subframe and
flacdec.c:366) on 6 bits (there's a type >= 32 check though but I
don't see what I'm missing)
- The encoder has min and max bounds in (min,max)_prediction_order in
arrays (see flacenc.c:312) that are below 32 so the encoder should
never use an order above 32 (as seen with again the coding on 6bits on
1126)
I guess some of your comments in the asm and here could be dropped then ?
--
Christophe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] added ULs for demuxing avid media composer mxf files
Mark Reid gmail.com> writes: > UL values from libMXF No! I mean: Those values are not copyrightable but since you found them in ffmbc it is (imo!) a matter of courtesy to mention the source. Please mention both if you want. Sorry, I am on a journey and didn't sleep, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] dpx: use aligned line starts
Hi,
the attached patch improves the decoding of ticket #3692 by following
S268M-2003.
Unfortunately, that probably means ffmpeg's dpx encoder is not
compliant to these specifications.
--
Christophe
From 4ba2ec15c9a111fb4e20523d5a8fa337bedee92d Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Wed, 13 Aug 2014 00:37:00 +0200
Subject: [PATCH 1/3] dpx: use aligned line starts
SMPTE 268M-2003 specifies that each line starts at a 4-bytes boundary.
Therefore, modify correspondingly the input buffer strides and size.
Partially fixes ticket #3692: DLAD_8b_3c_big.dpx still has inverted
colors, which might be related to endianness.
---
libavcodec/dpx.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 5f05cd8..2fa549c 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -77,7 +77,7 @@ static int decode_frame(AVCodecContext *avctx,
unsigned int offset;
int magic_num, endian;
-int x, y, i, ret;
+int x, y, stride, i, ret;
int w, h, bits_per_color, descriptor, elements, packing, total_size;
int encoding;
@@ -175,24 +175,24 @@ static int decode_frame(AVCodecContext *avctx,
switch (bits_per_color) {
case 8:
-total_size = avctx->width * avctx->height * elements;
+stride = avctx->width * elements;
break;
case 10:
if (!packing) {
av_log(avctx, AV_LOG_ERROR, "Packing to 32bit required\n");
return -1;
}
-total_size = (avctx->width * elements + 2) / 3 * 4 * avctx->height;
+stride = (avctx->width * elements + 2) / 3 * 4;
break;
case 12:
if (!packing) {
av_log(avctx, AV_LOG_ERROR, "Packing to 16bit required\n");
return -1;
}
-total_size = 2 * avctx->width * avctx->height * elements;
+stride = 2 * avctx->width * elements;
break;
case 16:
-total_size = 2 * avctx->width * avctx->height * elements;
+stride = 2 * avctx->width * elements;
break;
case 1:
case 32:
@@ -203,6 +203,11 @@ static int decode_frame(AVCodecContext *avctx,
return AVERROR_INVALIDDATA;
}
+// Table 3c: Runs will always break at scan line boundaries. Packing
+// will always break to the next 32-bit word at scan-line boundaries.
+stride = FFALIGN(stride, 4);
+total_size = stride*avctx->height;
+
switch (1000 * descriptor + 10 * bits_per_color + endian) {
case 6081:
case 6080:
@@ -308,6 +313,8 @@ static int decode_frame(AVCodecContext *avctx,
// For 12 bit, ignore alpha
if (elements == 4)
buf += 2;
+// Jump to next aligned position
+buf += stride - 6*avctx->width;
}
for (i = 0; i < 3; i++)
ptr[i] += p->linesize[i];
@@ -317,7 +324,7 @@ static int decode_frame(AVCodecContext *avctx,
elements *= 2;
case 8:
av_image_copy_plane(ptr[0], p->linesize[0],
-buf, elements * avctx->width,
+buf, stride,
elements * avctx->width, avctx->height);
break;
}
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] dpx: use aligned line starts
2014-08-13 9:48 GMT+02:00 Christophe Gisquet : > Unfortunately, that probably means ffmpeg's dpx encoder is not > compliant to these specifications. And indeed the decoder is then no longer able to decode a file produced by the encoder when number of bytes per line is not a multiple of 4... Let's drop that patch for now? -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] lavc/flacdsp: document limitations of the LPC encoder
On 2014-08-13 04:50, Michael Niedermayer wrote:
> On Tue, Aug 12, 2014 at 11:22:07PM +0200, James Darnley wrote:
>> ---
>> libavcodec/flacdsp.h |7 +++
>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/libavcodec/flacdsp.h b/libavcodec/flacdsp.h
>> index 272cf2a..36cd904 100644
>> --- a/libavcodec/flacdsp.h
>> +++ b/libavcodec/flacdsp.h
>> @@ -27,6 +27,13 @@ typedef struct FLACDSPContext {
>> int len, int shift);
>> void (*lpc)(int32_t *samples, const int coeffs[32], int order,
>> int qlevel, int len);
>> +/**
>> + * This function has some limitations with various configurations:
>> + * - when CONFIG_SMALL is 0 there is an unrolled loop which assumes the
>> + * maximum value of order is 32.
>> + * - when SSE4 (or newer) is available on x86 there is an unrolled copy
>> + * which also assumes the maximum value of order is 0.
>> + */
>
> sounds like
>
> printf()
> on fridays with SSE4 this is limited to 27 characters
>
> a function either should have a limit or not have one, it should
> not depend on other factors
>
> People using this function must be able to tell in what cases they
> can use it
>
> and People optimizing the function need to know which cases their
> optimized code must support
>
> the API defines both
I don't get it. FLAC only allows upto 32-order LPC. This was,
apprarently, an acceptable assumption to make for the unrolled C code
yet somehow I can't make the same assumption for assembly.
>> + * which also assumes the maximum value of order is 0.
^^^
Is it this bit that is confusing? Because I only now see that typo. Of
course that should say "32".
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfitler/vf_perspective: support slice threading
On Tue, Aug 12, 2014 at 05:12:43PM +0200, Paul B Mahol wrote:
> On 8/12/14, Clement Boesch wrote:
> > On Tue, Aug 12, 2014 at 11:32:20AM +, Paul B Mahol wrote:
> >> Signed-off-by: Paul B Mahol
> >> ---
> >> libavfilter/vf_perspective.c | 69
> >> +---
> >> 1 file changed, 52 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/libavfilter/vf_perspective.c b/libavfilter/vf_perspective.c
> >> index f433226..c5471b0 100644
> >> --- a/libavfilter/vf_perspective.c
> >> +++ b/libavfilter/vf_perspective.c
> >> @@ -47,10 +47,8 @@ typedef struct PerspectiveContext {
> >> int hsub, vsub;
> >> int nb_planes;
> >>
> >> -void (*perspective)(struct PerspectiveContext *s,
> >> -uint8_t *dst, int dst_linesize,
> >> -uint8_t *src, int src_linesize,
> >> -int w, int h, int hsub, int vsub);
> >> +int (*perspective)(AVFilterContext *ctx,
> >> + void *arg, int job, int nb_jobs);
> >> } PerspectiveContext;
> >>
> >> #define OFFSET(x) offsetof(PerspectiveContext, x)
> >> @@ -193,15 +191,34 @@ static int config_input(AVFilterLink *inlink)
> >> return 0;
> >> }
> >>
> >> -static void resample_cubic(PerspectiveContext *s,
> >> - uint8_t *dst, int dst_linesize,
> >> - uint8_t *src, int src_linesize,
> >> - int w, int h, int hsub, int vsub)
> >> +typedef struct ThreadData {
> >> +uint8_t *dst;
> >> +int dst_linesize;
> >> +uint8_t *src;
> >> +int src_linesize;
> >> +int w, h;
> >> +int hsub, vsub;
> >> +} ThreadData;
> >> +
> >> +static int resample_cubic(AVFilterContext *ctx, void *arg,
> >> + int job, int nb_jobs)
> >> {
> >> +PerspectiveContext *s = ctx->priv;
> >> +ThreadData *td = arg;
> >> +uint8_t *dst = td->dst;
> >> +int dst_linesize = td->dst_linesize;
> >> +uint8_t *src = td->src;
> >> +int src_linesize = td->src_linesize;
> >> +int w = td->w;
> >> +int h = td->h;
> >> +int hsub = td->hsub;
> >> +int vsub = td->vsub;
> >> +int start = (h * job) / nb_jobs;
> >> +int end = (h * (job+1)) / nb_jobs;
> >
> > I would guess this doesn't work unless you src += start * src_linesize
> > (same for dst)
> I do not think so. You can try it.
Ah you're right, my bad. I didn't realize the destination was computed in
absolute according to y at every loop.
Patch LGTM with the flags change.
Thanks,
--
Clément B.
pgpdu1M01BD6e.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/4] Various fixes for DPX
Those fixes are intended around ticket #3692. The core of the issues is that line starts must be aligned on a 4-byte boundary. Christophe Gisquet (4): dpx: use aligned line starts dpxenc: enforce alignment requirement dpx: abort if encrypted dpx: fix endianess for RGB 8bits libavcodec/dpx.c| 45 ++--- libavcodec/dpxenc.c | 44 +--- 2 files changed, 71 insertions(+), 18 deletions(-) -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] dpx: use aligned line starts
SMPTE 268M-2003 specifies that each line starts at a 4-bytes boundary.
Therefore, modify correspondingly the input buffer strides and size.
Partially fixes ticket #3692: DLAD_8b_3c_big.dpx still has inverted
colors, which might be related to endianness.
---
libavcodec/dpx.c | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 5f05cd8..8cd7d73 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -77,8 +77,8 @@ static int decode_frame(AVCodecContext *avctx,
unsigned int offset;
int magic_num, endian;
-int x, y, i, ret;
-int w, h, bits_per_color, descriptor, elements, packing, total_size;
+int x, y, stride, i, ret;
+int w, h, bits_per_color, descriptor, elements, packing;
int encoding;
unsigned int rgbBuffer = 0;
@@ -175,24 +175,24 @@ static int decode_frame(AVCodecContext *avctx,
switch (bits_per_color) {
case 8:
-total_size = avctx->width * avctx->height * elements;
+stride = avctx->width * elements;
break;
case 10:
if (!packing) {
av_log(avctx, AV_LOG_ERROR, "Packing to 32bit required\n");
return -1;
}
-total_size = (avctx->width * elements + 2) / 3 * 4 * avctx->height;
+stride = (avctx->width * elements + 2) / 3 * 4;
break;
case 12:
if (!packing) {
av_log(avctx, AV_LOG_ERROR, "Packing to 16bit required\n");
return -1;
}
-total_size = 2 * avctx->width * avctx->height * elements;
+stride = 2 * avctx->width * elements;
break;
case 16:
-total_size = 2 * avctx->width * avctx->height * elements;
+stride = 2 * avctx->width * elements;
break;
case 1:
case 32:
@@ -203,6 +203,20 @@ static int decode_frame(AVCodecContext *avctx,
return AVERROR_INVALIDDATA;
}
+// Table 3c: Runs will always break at scan line boundaries. Packing
+// will always break to the next 32-bit word at scan-line boundaries.
+// Unfortunately, the encoder produced invalid files, so attempt
+// to detect it
+if (FFALIGN(stride, 4)*avctx->height + (int64_t)offset > avpkt->size) {
+// Alignment seems unappliable, try without
+if (stride*avctx->height + (int64_t)offset > avpkt->size) {
+av_log(avctx, AV_LOG_ERROR, "Overread buffer. Invalid header?\n");
+return AVERROR_INVALIDDATA;
+}
+} else {
+stride = FFALIGN(stride, 4);
+}
+
switch (1000 * descriptor + 10 * bits_per_color + endian) {
case 6081:
case 6080:
@@ -266,10 +280,6 @@ static int decode_frame(AVCodecContext *avctx,
for (i=0; idata[i];
-if (total_size + (int64_t)offset > avpkt->size) {
-av_log(avctx, AV_LOG_ERROR, "Overread buffer. Invalid header?\n");
-return AVERROR_INVALIDDATA;
-}
switch (bits_per_color) {
case 10:
for (x = 0; x < avctx->height; x++) {
@@ -308,6 +318,8 @@ static int decode_frame(AVCodecContext *avctx,
// For 12 bit, ignore alpha
if (elements == 4)
buf += 2;
+// Jump to next aligned position
+buf += stride - 6*avctx->width;
}
for (i = 0; i < 3; i++)
ptr[i] += p->linesize[i];
@@ -317,7 +329,7 @@ static int decode_frame(AVCodecContext *avctx,
elements *= 2;
case 8:
av_image_copy_plane(ptr[0], p->linesize[0],
-buf, elements * avctx->width,
+buf, stride,
elements * avctx->width, avctx->height);
break;
}
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] dpxenc: enforce alignment requirement
S268M-2003 specifies that each line start is aligned on a 4-byte boundary.
---
libavcodec/dpxenc.c | 44 +---
1 file changed, 37 insertions(+), 7 deletions(-)
diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
index 0eb1297..059d8c6 100644
--- a/libavcodec/dpxenc.c
+++ b/libavcodec/dpxenc.c
@@ -28,6 +28,7 @@
typedef struct DPXContext {
int big_endian;
int bits_per_component;
+int num_components;
int descriptor;
int planar;
} DPXContext;
@@ -39,6 +40,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
s->big_endian = !!(desc->flags & AV_PIX_FMT_FLAG_BE);
s->bits_per_component = desc->comp[0].depth_minus1 + 1;
+s->num_components = desc->nb_components;
s->descriptor = (desc->flags & AV_PIX_FMT_FLAG_ALPHA) ? 51 : 50;
s->planar = !!(desc->flags & AV_PIX_FMT_FLAG_PLANAR);
@@ -142,7 +144,9 @@ static void encode_gbrp12(AVCodecContext *avctx, const
AVPicture *pic, uint16_t
const uint16_t *src[3] = {(uint16_t*)pic->data[0],
(uint16_t*)pic->data[1],
(uint16_t*)pic->data[2]};
-int x, y, i;
+int x, y, i, pad;
+pad = avctx->width*6;
+pad = (FFALIGN(pad, 4) - pad) >> 1;
for (y = 0; y < avctx->height; y++) {
for (x = 0; x < avctx->width; x++) {
uint16_t value[3];
@@ -155,6 +159,8 @@ static void encode_gbrp12(AVCodecContext *avctx, const
AVPicture *pic, uint16_t
value[2] = AV_RL16(src[1] + x) << 4;
value[0] = AV_RL16(src[2] + x) << 4;
}
+for (i = 0; i < pad; i++)
+*dst++ = 0;
for (i = 0; i < 3; i++)
write16(dst++, value[i]);
}
@@ -167,14 +173,25 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
const AVFrame *frame, int *got_packet)
{
DPXContext *s = avctx->priv_data;
-int size, ret;
+int size, ret, need_align, len;
uint8_t *buf;
#define HEADER_SIZE 1664 /* DPX Generic header */
if (s->bits_per_component == 10)
size = avctx->height * avctx->width * 4;
-else
-size = avpicture_get_size(avctx->pix_fmt, avctx->width, avctx->height);
+else if (s->bits_per_component == 12) {
+// 3 components, 12 bits put on 16 bits
+len = avctx->width*6;
+size = FFALIGN(len, 4);
+need_align = size - len;
+size *= avctx->height;
+} else {
+// N components, M bits
+len = avctx->width * s->num_components * s->bits_per_component >> 3;
+size = FFALIGN(len, 4);
+need_align = size - len;
+size *= avctx->height;
+}
if ((ret = ff_alloc_packet2(avctx, pkt, size + HEADER_SIZE)) < 0)
return ret;
buf = pkt->data;
@@ -211,9 +228,22 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
switch(s->bits_per_component) {
case 8:
case 16:
-size = avpicture_layout((const AVPicture*)frame, avctx->pix_fmt,
-avctx->width, avctx->height,
-buf + HEADER_SIZE, pkt->size - HEADER_SIZE);
+if (need_align) {
+int j;
+const uint8_t *src = frame->data[0];
+uint8_t *dst = pkt->data + HEADER_SIZE;
+size = (len + need_align) * avctx->height;
+for (j=0; jheight; j++) {
+memcpy(dst, src, len);
+memset(dst + len, 0, need_align);
+dst += len + need_align;
+src += frame->linesize[0];
+}
+} else {
+size = avpicture_layout((const AVPicture*)frame, avctx->pix_fmt,
+avctx->width, avctx->height,
+buf + HEADER_SIZE, pkt->size -
HEADER_SIZE);
+}
if (size < 0)
return size;
break;
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] dpx: fix endianess for RGB 8bits
Fixes DLAD_8b_3c_big.dpx from ticket #3692 --- libavcodec/dpx.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c index 2ad7527..d4d6833 100644 --- a/libavcodec/dpx.c +++ b/libavcodec/dpx.c @@ -232,6 +232,8 @@ static int decode_frame(AVCodecContext *avctx, avctx->pix_fmt = AV_PIX_FMT_GRAY8; break; case 50081: +avctx->pix_fmt = AV_PIX_FMT_BGR24; +break; case 50080: avctx->pix_fmt = AV_PIX_FMT_RGB24; break; -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] dpx: abort if encrypted
---
libavcodec/dpx.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 8cd7d73..2ad7527 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -108,6 +108,15 @@ static int decode_frame(AVCodecContext *avctx,
av_log(avctx, AV_LOG_ERROR, "Invalid data start offset\n");
return AVERROR_INVALIDDATA;
}
+
+// Check encryption
+buf = avpkt->data + 660;
+ret = read32(&buf, endian);
+if (ret != 0x) {
+avpriv_report_missing_feature(avctx, "Encryption");
+return AVERROR_PATCHWELCOME;
+}
+
// Need to end in 0x304 offset from start of file
buf = avpkt->data + 0x304;
w = read32(&buf, endian);
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: ignore reference segmentation map if error_resilience flag is set.
Hi,
On Wed, Aug 13, 2014 at 2:25 AM, Hendrik Leppkes
wrote:
> On Wed, Aug 13, 2014 at 12:11 AM, Ronald S. Bultje
> wrote:
> > Fixes ffvp9_fails_where_libvpx.succeeds.webm from ticket 3849.
> > ---
> > libavcodec/vp9.c | 26 +++---
> > 1 file changed, 15 insertions(+), 11 deletions(-)
> >
> > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > index 56975bd..186aec1 100644
> > --- a/libavcodec/vp9.c
> > +++ b/libavcodec/vp9.c
> > @@ -278,7 +278,7 @@ static int vp9_alloc_frame(AVCodecContext *ctx,
> VP9Frame *f)
> >
> > // retain segmentation map if it doesn't update
> > if (s->segmentation.enabled && !s->segmentation.update_map &&
> > -!s->intraonly && !s->keyframe) {
> > +!s->intraonly && !s->keyframe && !s->errorres) {
> > memcpy(f->segmentation_map,
> s->frames[LAST_FRAME].segmentation_map, sz);
> > }
> >
> > @@ -1344,16 +1344,20 @@ static void decode_mode(AVCodecContext *ctx)
> > vp56_rac_get_prob_branchy(&s->c,
> > s->prob.segpred[s->above_segpred_ctx[col] +
> > s->left_segpred_ctx[row7]]))) {
> > -int pred = 8, x;
> > -uint8_t *refsegmap = s->frames[LAST_FRAME].segmentation_map;
> > -
> > -if (!s->last_uses_2pass)
> > -ff_thread_await_progress(&s->frames[LAST_FRAME].tf, row >>
> 3, 0);
> > -for (y = 0; y < h4; y++)
> > -for (x = 0; x < w4; x++)
> > -pred = FFMIN(pred, refsegmap[(y + row) * 8 * s->sb_cols
> + x + col]);
> > -av_assert1(pred < 8);
> > -b->seg_id = pred;
> > +if (!s->errorres) {
> > +int pred = 8, x;
> > +uint8_t *refsegmap = s->frames[LAST_FRAME].segmentation_map;
> > +
> > +if (!s->last_uses_2pass)
> > +ff_thread_await_progress(&s->frames[LAST_FRAME].tf, row
> >> 3, 0);
> > +for (y = 0; y < h4; y++)
> > +for (x = 0; x < w4; x++)
> > +pred = FFMIN(pred, refsegmap[(y + row) * 8 *
> s->sb_cols + x + col]);
> > +av_assert1(pred < 8);
> > +b->seg_id = pred;
> > +} else {
> > +b->seg_id = 0;
> > +}
> >
> > memset(&s->above_segpred_ctx[col], 1, w4);
> > memset(&s->left_segpred_ctx[row7], 1, h4);
> > --
> > 1.8.5.5
> >
>
> Might it be useful to add some of those special samples to fate?
Probably. The first 10 frames of the sample in this ticket would show this
already, is anyone good with webm file cutting/remuxing? If not, I can try
to add it this weekend.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] added ULs for demuxing avid media composer mxf files
On Tue, Aug 12, 2014 at 07:15:11PM -0700, Mark Reid wrote: > On Tue, Aug 12, 2014 at 6:44 PM, Timothy Gu wrote: > > > On Aug 12, 2014 6:29 PM, "Mark Reid" wrote: > > > > > I didn't realize FFmbc was licensed differently :s. I don't know if it > > > helps, (IANAL either) > > > but the same ULs can be found in libMXF project, as well as the AAF SDK. > > > I'm not sure how to proceed, should I just drop the patch? > > > > Just mention libMXF then, as the values are the same and libMXF is under > > LGPL or BSD depending on the version. > > > Okay, I'll submit a new patch and do that then, thanks! also make sure you dont copy any comments or formating from GPL code. Or well, ask the author for permission to use it under LGPL [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/dnxhd: ff_dnxhd_cid_table is not exported
On Wed, Aug 13, 2014 at 08:23:17AM +0200, Hendrik Leppkes wrote:
> On Wed, Aug 13, 2014 at 5:34 AM, James Almer wrote:
> > Signed-off-by: James Almer
> > ---
> > libavcodec/dnxhddata.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/dnxhddata.h b/libavcodec/dnxhddata.h
> > index 8166ee8..d5629e2 100644
> > --- a/libavcodec/dnxhddata.h
> > +++ b/libavcodec/dnxhddata.h
> > @@ -46,7 +46,7 @@ typedef struct CIDEntry {
> > AVRational frame_rates[5];
> > } CIDEntry;
> >
> > -extern av_export const CIDEntry ff_dnxhd_cid_table[];
> > +extern const CIDEntry ff_dnxhd_cid_table[];
> >
> > int ff_dnxhd_get_cid_table(int cid);
> > int ff_dnxhd_find_cid(AVCodecContext *avctx, int bit_depth);
> > --
> > 1.8.5.5
> >
>
>
> LGTM, its not used anywhere outside of avcodec.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] dpx: fix endianess for RGB 8bits
On 8/13/14, Christophe Gisquet wrote: > Fixes DLAD_8b_3c_big.dpx from ticket #3692 > --- > libavcodec/dpx.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c > index 2ad7527..d4d6833 100644 > --- a/libavcodec/dpx.c > +++ b/libavcodec/dpx.c > @@ -232,6 +232,8 @@ static int decode_frame(AVCodecContext *avctx, > avctx->pix_fmt = AV_PIX_FMT_GRAY8; > break; > case 50081: > +avctx->pix_fmt = AV_PIX_FMT_BGR24; > +break; > case 50080: > avctx->pix_fmt = AV_PIX_FMT_RGB24; > break; > -- > 1.9.2.msysgit.0 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] dpx: abort if encrypted
On 8/13/14, Christophe Gisquet wrote:
> ---
> libavcodec/dpx.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
> index 8cd7d73..2ad7527 100644
> --- a/libavcodec/dpx.c
> +++ b/libavcodec/dpx.c
> @@ -108,6 +108,15 @@ static int decode_frame(AVCodecContext *avctx,
> av_log(avctx, AV_LOG_ERROR, "Invalid data start offset\n");
> return AVERROR_INVALIDDATA;
> }
> +
> +// Check encryption
> +buf = avpkt->data + 660;
> +ret = read32(&buf, endian);
> +if (ret != 0x) {
> +avpriv_report_missing_feature(avctx, "Encryption");
> +return AVERROR_PATCHWELCOME;
> +}
> +
> // Need to end in 0x304 offset from start of file
> buf = avpkt->data + 0x304;
> w = read32(&buf, endian);
> --
> 1.9.2.msysgit.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Does dpx encoder needs modification too?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] dpxenc: enforce alignment requirement
On 8/13/14, Christophe Gisquet wrote: > S268M-2003 specifies that each line start is aligned on a 4-byte boundary. > --- > libavcodec/dpxenc.c | 44 +--- > 1 file changed, 37 insertions(+), 7 deletions(-) > probably ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] dict.c: Free non-strduped av_dict_set arguments on error.
On Mon, Aug 11, 2014 at 09:17:18PM +0200, Reimar Döffinger wrote: > Unfortunately this was not explicitly documented and thus > might be very risky. yes maybe a AV_DICT_FREE_ARGS_ON_ERROR could be used, but its not as convenient as getting the behavior by default [...] -- 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 4/4] dict.c: empty dictionaries should be a NULL pointer.
On Mon, Aug 11, 2014 at 09:17:19PM +0200, Reimar Döffinger wrote: > Ensure this is even the case if they are empty because > we failed adding the first entry. > > Signed-off-by: Reimar Döffinger > --- > libavutil/dict.c | 4 > 1 file changed, 4 insertions(+) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] lavc/flacdsp: document limitations of the LPC encoder
On Wed, Aug 13, 2014 at 10:46:45AM +0200, James Darnley wrote:
> On 2014-08-13 04:50, Michael Niedermayer wrote:
> > On Tue, Aug 12, 2014 at 11:22:07PM +0200, James Darnley wrote:
> >> ---
> >> libavcodec/flacdsp.h |7 +++
> >> 1 files changed, 7 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/libavcodec/flacdsp.h b/libavcodec/flacdsp.h
> >> index 272cf2a..36cd904 100644
> >> --- a/libavcodec/flacdsp.h
> >> +++ b/libavcodec/flacdsp.h
> >> @@ -27,6 +27,13 @@ typedef struct FLACDSPContext {
> >> int len, int shift);
> >> void (*lpc)(int32_t *samples, const int coeffs[32], int order,
> >> int qlevel, int len);
> >> +/**
> >> + * This function has some limitations with various configurations:
> >> + * - when CONFIG_SMALL is 0 there is an unrolled loop which assumes
> >> the
> >> + * maximum value of order is 32.
> >> + * - when SSE4 (or newer) is available on x86 there is an unrolled
> >> copy
> >> + * which also assumes the maximum value of order is 0.
> >> + */
> >
> > sounds like
> >
> > printf()
> > on fridays with SSE4 this is limited to 27 characters
> >
> > a function either should have a limit or not have one, it should
> > not depend on other factors
> >
> > People using this function must be able to tell in what cases they
> > can use it
> >
> > and People optimizing the function need to know which cases their
> > optimized code must support
> >
> > the API defines both
>
> I don't get it. FLAC only allows upto 32-order LPC. This was,
> apprarently, an acceptable assumption to make for the unrolled C code
> yet somehow I can't make the same assumption for assembly.
theres some kind of misunderatanding here
its perfectly fine to say
/**
* This function supports upto a order of 32
*/
what i think is a really bad idea is to make the API conditional
on cpu features and build flags.
What if someone wants to add a SSE2 optimization that works just up
to order 32 ? he cannot do it without changing the API and checking
that all uses of the API are safe with the new limitation
>
> >> + * which also assumes the maximum value of order is 0.
> ^^^
> Is it this bit that is confusing? Because I only now see that typo. Of
> course that should say "32".
that too
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are best at talking, realize last or never when they are wrong.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] lavc/flacdsp: document limitations of the LPC encoder
On 2014-08-13 09:21, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-12 23:22 GMT+02:00 James Darnley :
>> ---
>> libavcodec/flacdsp.h |7 +++
>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/libavcodec/flacdsp.h b/libavcodec/flacdsp.h
>> index 272cf2a..36cd904 100644
>> --- a/libavcodec/flacdsp.h
>> +++ b/libavcodec/flacdsp.h
>> @@ -27,6 +27,13 @@ typedef struct FLACDSPContext {
>> int len, int shift);
>> void (*lpc)(int32_t *samples, const int coeffs[32], int order,
>> int qlevel, int len);
>> +/**
>> + * This function has some limitations with various configurations:
>> + * - when CONFIG_SMALL is 0 there is an unrolled loop which assumes the
>> + * maximum value of order is 32.
>> + * - when SSE4 (or newer) is available on x86 there is an unrolled copy
>> + * which also assumes the maximum value of order is 0.
>> + */
>> void (*lpc_encode)(int32_t *res, const int32_t *smp, int len, int order,
>> const int32_t *coefs, int shift);
>> } FLACDSPContext;
>
> Some comments:
> - The decoder passes int coeffs[32]; I don't see how order > 32 would then
> work
> - Why not do the same for lpc_encode, and document that maximum order
> value is 32
> - The decoder actually reads the order (see decode_subframe and
> flacdec.c:366) on 6 bits (there's a type >= 32 check though but I
> don't see what I'm missing)
> - The encoder has min and max bounds in (min,max)_prediction_order in
> arrays (see flacenc.c:312) that are below 32 so the encoder should
> never use an order above 32 (as seen with again the coding on 6bits on
> 1126)
>
> I guess some of your comments in the asm and here could be dropped then ?
You are correct on these points. Please read my reply to Michael to see
what I was thinking.
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] lavc/flacdsp: document limitations of the LPC encoder
On 2014-08-13 14:05, Michael Niedermayer wrote:
> On Wed, Aug 13, 2014 at 10:46:45AM +0200, James Darnley wrote:
>> On 2014-08-13 04:50, Michael Niedermayer wrote:
>>> On Tue, Aug 12, 2014 at 11:22:07PM +0200, James Darnley wrote:
---
libavcodec/flacdsp.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/libavcodec/flacdsp.h b/libavcodec/flacdsp.h
index 272cf2a..36cd904 100644
--- a/libavcodec/flacdsp.h
+++ b/libavcodec/flacdsp.h
@@ -27,6 +27,13 @@ typedef struct FLACDSPContext {
int len, int shift);
void (*lpc)(int32_t *samples, const int coeffs[32], int order,
int qlevel, int len);
+/**
+ * This function has some limitations with various configurations:
+ * - when CONFIG_SMALL is 0 there is an unrolled loop which assumes
the
+ * maximum value of order is 32.
+ * - when SSE4 (or newer) is available on x86 there is an unrolled
copy
+ * which also assumes the maximum value of order is 0.
+ */
>>>
>>> sounds like
>>>
>>> printf()
>>> on fridays with SSE4 this is limited to 27 characters
>>>
>>> a function either should have a limit or not have one, it should
>>> not depend on other factors
>>>
>>> People using this function must be able to tell in what cases they
>>> can use it
>>>
>>> and People optimizing the function need to know which cases their
>>> optimized code must support
>>>
>>> the API defines both
>>
>> I don't get it. FLAC only allows upto 32-order LPC. This was,
>> apprarently, an acceptable assumption to make for the unrolled C code
>> yet somehow I can't make the same assumption for assembly.
>
> theres some kind of misunderatanding here
>
> its perfectly fine to say
>
> /**
> * This function supports upto a order of 32
> */
>
> what i think is a really bad idea is to make the API conditional
> on cpu features and build flags.
> What if someone wants to add a SSE2 optimization that works just up
> to order 32 ? he cannot do it without changing the API and checking
> that all uses of the API are safe with the new limitation
Okay I understand that.
I thought that if someone wanted to re-use the function in some other
encoder which might allow 64 order (for example), I should document
where the limitations are.
I can change the patch to state that it supports up to 32 but should I
also still mention where that is assumed?
What about Christophe's suggestion of changing the function definition
by using "int coeffs[32]"?
Personally I am in favour of something more verbose that just stating
one limit.
+ * which also assumes the maximum value of order is 0.
>> ^^^
>> Is it this bit that is confusing? Because I only now see that typo. Of
>> course that should say "32".
>
> that too
Sorry about that.
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil: turn arm setend into a cpuflag
On Thu, Aug 07, 2014 at 06:49:55PM +0200, Michael Niedermayer wrote: > this allows disabling and enabling it > it also prevents crashes if vfpv3 and neon are disabled which previously > would have enabled the flag > > Signed-off-by: Michael Niedermayer > --- > configure |3 +++ > libavutil/arm/cpu.c |9 - > libavutil/arm/cpu.h |7 +-- > libavutil/cpu.c |2 ++ > libavutil/cpu.h |1 + > 5 files changed, 15 insertions(+), 7 deletions(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] lavc/flacdsp: document limitations of the LPC encoder
On Wed, Aug 13, 2014 at 02:30:20PM +0200, James Darnley wrote:
> On 2014-08-13 14:05, Michael Niedermayer wrote:
> > On Wed, Aug 13, 2014 at 10:46:45AM +0200, James Darnley wrote:
> >> On 2014-08-13 04:50, Michael Niedermayer wrote:
> >>> On Tue, Aug 12, 2014 at 11:22:07PM +0200, James Darnley wrote:
> ---
> libavcodec/flacdsp.h |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/libavcodec/flacdsp.h b/libavcodec/flacdsp.h
> index 272cf2a..36cd904 100644
> --- a/libavcodec/flacdsp.h
> +++ b/libavcodec/flacdsp.h
> @@ -27,6 +27,13 @@ typedef struct FLACDSPContext {
> int len, int shift);
> void (*lpc)(int32_t *samples, const int coeffs[32], int order,
> int qlevel, int len);
> +/**
> + * This function has some limitations with various configurations:
> + * - when CONFIG_SMALL is 0 there is an unrolled loop which assumes
> the
> + * maximum value of order is 32.
> + * - when SSE4 (or newer) is available on x86 there is an unrolled
> copy
> + * which also assumes the maximum value of order is 0.
> + */
> >>>
> >>> sounds like
> >>>
> >>> printf()
> >>> on fridays with SSE4 this is limited to 27 characters
> >>>
> >>> a function either should have a limit or not have one, it should
> >>> not depend on other factors
> >>>
> >>> People using this function must be able to tell in what cases they
> >>> can use it
> >>>
> >>> and People optimizing the function need to know which cases their
> >>> optimized code must support
> >>>
> >>> the API defines both
> >>
> >> I don't get it. FLAC only allows upto 32-order LPC. This was,
> >> apprarently, an acceptable assumption to make for the unrolled C code
> >> yet somehow I can't make the same assumption for assembly.
> >
> > theres some kind of misunderatanding here
> >
> > its perfectly fine to say
> >
> > /**
> > * This function supports upto a order of 32
> > */
> >
> > what i think is a really bad idea is to make the API conditional
> > on cpu features and build flags.
> > What if someone wants to add a SSE2 optimization that works just up
> > to order 32 ? he cannot do it without changing the API and checking
> > that all uses of the API are safe with the new limitation
>
> Okay I understand that.
>
> I thought that if someone wanted to re-use the function in some other
> encoder which might allow 64 order (for example), I should document
> where the limitations are.
>
> I can change the patch to state that it supports up to 32 but should I
> also still mention where that is assumed?
Its ok to mention but the difference between
API = interface specification
and interface implementation should be clear
>
> What about Christophe's suggestion of changing the function definition
> by using "int coeffs[32]"?
thats a good idea too
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] opts: add list device sources/sinks options
On Thu, Aug 07, 2014 at 01:58:57AM +0200, Lukasz Marek wrote:
> Allows to list sources/sinks of the devices that implement
> that functionality.
>
[...]
> +int show_sinks(void *optctx, const char *opt, const char *arg)
> +{
> +#if CONFIG_AVDEVICE
> +AVDeviceInfoList *device_list = NULL;
> +AVFormatContext *dev = NULL;
> +AVOutputFormat *fmt;
> +int ret, i;
> +
> +if (!arg) {
> +printf("Device name is missing.\n");
> +return AVERROR(EINVAL);
> +}
shouldnt a plain "-sinks" list all available sinks ?
similar for sources
[...]
--
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] avfilter/dctdnoiz: add slice threading
On Sun, Aug 10, 2014 at 10:09:02PM +0200, Clément Bœsch wrote: > --- > I have one or two little things to cleanup after this but I think I'm mostly > done. The filter is now usable from a performance point of view (not for > real-time, but it doesn't decades to process a normal sized image anymore): > > Stream #0:0: Video: png, rgb24, 1445x1080, 25 tbr, 25 tbn, 25 tbc > > ./ffmpeg-2.3 -i in.png -vf dctdnoiz=15 -f null - 38.34s user 0.01s system > 98% cpu 39.124 total > ./ffmpeg -i in.png -vf dctdnoiz=15 -f null - 5.06s user 0.02s system 621% > cpu 0.817 total > > I will mention this stuff in the Changelog when this is accepted. > > Ideally, I'd really love to have a FATE test, but I see no such thing as > "threshold" video tests for avfilter in FATE in order to support float-based > filters. Another solution as already is to make dctdnoiz integer-only but I'm > not planing to do that anytime soon. > --- > libavfilter/vf_dctdnoiz.c | 114 > ++ > 1 file changed, 84 insertions(+), 30 deletions(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Wed, 13 Aug 2014 00:30:05 +0200 Michael Niedermayer wrote: > I never understood why people who once where friends > became mutually so hostile You should know that better than anyone else! You still claim to be my friend, yet you said and did things that i have not seen from my enemies, let alone from my friends. To this day, after 3 years, i still get accused by random people of thing i supposedly have done against FFmpeg and the spirit of open source. After 3 years i still have to defend myself against these baseless attacks! If you trully want to mend ways, then you and your fellow FFmpeg developers should stop this constant spreading of lies, this defamation campaing against libav and its developers that has been going on for the last 3 and a half years and show at least the minimum respect you would show to a stranger you meet on the street. Until you do this, i see very little chance for a healthy cooperation. That said, i invite all FFmpeg developers to come to VDD next month and sit together with everyone. So that we can have a healthy discussion once again. Drink beer, hot chocolate and have fun together. Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavdevice/v4l2: fix of crash caused by assert
From: Dmitry Volyntsev
s->buffers_queued constantly decremented and not incremented
in case of (s->frame_size > 0 && buf.bytesused != s->frame_size)
condition (caught on long run capture of Logitech C310)
---
libavdevice/v4l2.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index 64df0c7..25be95e 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -510,9 +510,6 @@ static int mmap_read_frame(AVFormatContext *ctx, AVPacket
*pkt)
av_log(ctx, AV_LOG_ERROR, "Invalid buffer index received.\n");
return AVERROR(EINVAL);
}
-avpriv_atomic_int_add_and_fetch(&s->buffers_queued, -1);
-// always keep at least one buffer queued
-av_assert0(avpriv_atomic_int_get(&s->buffers_queued) >= 1);
/* CPIA is a compressed format and we don't know the exact number of bytes
* used by a frame, so set it here as the driver announces it.
@@ -527,6 +524,10 @@ static int mmap_read_frame(AVFormatContext *ctx, AVPacket
*pkt)
return AVERROR_INVALIDDATA;
}
+avpriv_atomic_int_add_and_fetch(&s->buffers_queued, -1);
+// always keep at least one buffer queued
+av_assert0(avpriv_atomic_int_get(&s->buffers_queued) >= 1);
+
/* Image is at s->buff_start[buf.index] */
if (avpriv_atomic_int_get(&s->buffers_queued) == FFMAX(s->buffers / 8, 1))
{
/* when we start getting low on queued buffers, fall back on copying
data */
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/filters: correct confusing statements about *showinfo shown values
Fix trac issue #3850.
---
doc/filters.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index c5caa77..0e3dfc7 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -862,7 +862,7 @@ The input audio is not modified.
The shown line contains a sequence of key/value pairs of the form
@var{key}:@var{value}.
-It accepts the following parameters:
+The following values are shown in the output:
@table @option
@item n
@@ -7541,7 +7541,7 @@ The input video is not modified.
The shown line contains a sequence of key/value pairs of the form
@var{key}:@var{value}.
-It accepts the following parameters:
+The following values are shown in the output:
@table @option
@item n
--
1.8.3.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/filters: correct confusing statements about *showinfo shown values
On Aug 13, 2014 8:58 AM, "Stefano Sabatini" wrote: > > Fix trac issue #3850. > --- OK. [...] Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/filters: correct confusing statements about *showinfo shown values
On Wed, Aug 13, 2014 at 05:58:34PM +0200, Stefano Sabatini wrote: > Fix trac issue #3850. > --- > doc/filters.texi | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) LGTM [...] -- 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] Invitation to VDD and registration
On date Sunday 2014-07-20 18:16:52 +0200, Jean-Baptiste Kempf encoded: > My dear friends of the FFmpeg community, > > I'd like to invite you to the VideoLAN Dev Days 2014, the 3rd week-end > of September, in Dublin, Ireland. Google is providing the hosting. > > This technical conference about open source multimedia, will see > developers from VLC, libav, FFmpeg, x26*, Phonon, DVBlast, PulseAudio, > KDE, Gnome, Xiph, handbrake, tomahawk and other projects gather to > discuss about open source development of multimedia projects. > This is a developer conference, so topics will be technical. > > The registration is now open here: http://goo.gl/NiCInJ > Please register as soon as possible, to help us organize the conference. [...] Hi, anybody is planning to go there? I remember that the registration will close on August 20 (that is, the next week Wednesday), bye. -- FFmpeg = Fiendish and Fabulous Minimalistic Philosofic Eretic Game ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] dpx: abort if encrypted
On 13.08.2014, at 13:48, Paul B Mahol wrote:
> On 8/13/14, Christophe Gisquet wrote:
>> ---
>> libavcodec/dpx.c | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
>> index 8cd7d73..2ad7527 100644
>> --- a/libavcodec/dpx.c
>> +++ b/libavcodec/dpx.c
>> @@ -108,6 +108,15 @@ static int decode_frame(AVCodecContext *avctx,
>> av_log(avctx, AV_LOG_ERROR, "Invalid data start offset\n");
>> return AVERROR_INVALIDDATA;
>> }
>> +
>> +// Check encryption
>> +buf = avpkt->data + 660;
>> +ret = read32(&buf, endian);
>> +if (ret != 0x) {
>> +avpriv_report_missing_feature(avctx, "Encryption");
>> +return AVERROR_PATCHWELCOME;
>> +}
>> +
>> // Need to end in 0x304 offset from start of file
>> buf = avpkt->data + 0x304;
>> w = read32(&buf, endian);
>
> Does dpx encoder needs modification too?
More specifically: how certain is it this value is always correct?
Failing to play an unencrypted file just because of a wrong flag (or even a
single-bit corruption!) seems worse to me than trying to play an encrypted file.
I.e. shouldn't this rather just be a warning than hard failure?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Invitation to VDD and registration
On 13.08.2014, at 18:42, Stefano Sabatini wrote: > On date Sunday 2014-07-20 18:16:52 +0200, Jean-Baptiste Kempf encoded: >> My dear friends of the FFmpeg community, >> >> I'd like to invite you to the VideoLAN Dev Days 2014, the 3rd week-end >> of September, in Dublin, Ireland. Google is providing the hosting. >> >> This technical conference about open source multimedia, will see >> developers from VLC, libav, FFmpeg, x26*, Phonon, DVBlast, PulseAudio, >> KDE, Gnome, Xiph, handbrake, tomahawk and other projects gather to >> discuss about open source development of multimedia projects. >> This is a developer conference, so topics will be technical. >> >> The registration is now open here: http://goo.gl/NiCInJ >> Please register as soon as possible, to help us organize the conference. > [...] > > Hi, > > anybody is planning to go there? I remember that the registration will > close on August 20 (that is, the next week Wednesday), bye. I already registered and booked flights ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] dpx: abort if encrypted
Hi, 2014-08-13 18:46 GMT+02:00 Reimar Döffinger : > More specifically: how certain is it this value is always correct? > Failing to play an unencrypted file just because of a wrong flag (or even a > single-bit corruption!) seems worse to me than trying to play an encrypted > file. > I.e. shouldn't this rather just be a warning than hard failure? True. So, should I also add a warning message, or remove the missing feature warning? They are not entirely duplicate. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: ignore reference segmentation map if error_resilience flag is set.
On 13.08.2014, at 12:48, "Ronald S. Bultje" wrote: > >> >> Might it be useful to add some of those special samples to fate? > > > Probably. The first 10 frames of the sample in this ticket would show this > already, is anyone good with webm file cutting/remuxing? If not, I can try > to add it this weekend. Since webm is used for streaming I'd strongly hope that dd should be a perfectly adequate cutting tool to get only the start. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: ignore reference segmentation map if error_resilience flag is set.
On 13/08/14 1:52 PM, Reimar Döffinger wrote: > On 13.08.2014, at 12:48, "Ronald S. Bultje" wrote: >> >>> >>> Might it be useful to add some of those special samples to fate? >> >> >> Probably. The first 10 frames of the sample in this ticket would show this >> already, is anyone good with webm file cutting/remuxing? If not, I can try >> to add it this weekend. > > Since webm is used for streaming I'd strongly hope that dd should be a > perfectly adequate cutting tool to get only the start. "ffmpeg -i ffvp9_fails_where_libvpx.succeeds.webm -c:v copy -vframes 10 cut.webm" should do it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] dpx: abort if encrypted
On Wed, Aug 13, 2014 at 06:51:00PM +0200, Christophe Gisquet wrote: > Hi, > > 2014-08-13 18:46 GMT+02:00 Reimar Döffinger : > > More specifically: how certain is it this value is always correct? > > Failing to play an unencrypted file just because of a wrong flag (or even a > > single-bit corruption!) seems worse to me than trying to play an encrypted > > file. > > I.e. shouldn't this rather just be a warning than hard failure? > > True. So, should I also add a warning message, or remove the missing > feature warning? They are not entirely duplicate. I'd be more than happy to let you decide. Personally I'd probably go with the missing feature and a warning message on top instead of the return. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/dctdnoiz: add slice threading
On Wed, Aug 13, 2014 at 04:02:57PM +0200, Michael Niedermayer wrote: > On Sun, Aug 10, 2014 at 10:09:02PM +0200, Clément Bœsch wrote: > > --- > > I have one or two little things to cleanup after this but I think I'm mostly > > done. The filter is now usable from a performance point of view (not for > > real-time, but it doesn't decades to process a normal sized image anymore): > > > > Stream #0:0: Video: png, rgb24, 1445x1080, 25 tbr, 25 tbn, 25 tbc > > > > ./ffmpeg-2.3 -i in.png -vf dctdnoiz=15 -f null - 38.34s user 0.01s system > > 98% cpu 39.124 total > > ./ffmpeg -i in.png -vf dctdnoiz=15 -f null - 5.06s user 0.02s system 621% > > cpu 0.817 total > > > > I will mention this stuff in the Changelog when this is accepted. > > > > Ideally, I'd really love to have a FATE test, but I see no such thing as > > "threshold" video tests for avfilter in FATE in order to support float-based > > filters. Another solution as already is to make dctdnoiz integer-only but > > I'm > > not planing to do that anytime soon. > > --- > > libavfilter/vf_dctdnoiz.c | 114 > > ++ > > 1 file changed, 84 insertions(+), 30 deletions(-) > > LGTM > Thanks, applied -- Clément B. pgpZreMmG9N9w.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] added ULs for demuxing avid media composer mxf files
On Wed, Aug 13, 2014 at 12:37 AM, Carl Eugen Hoyos wrote: > Mark Reid gmail.com> writes: > > > UL values from libMXF > > No! > > I mean: Those values are not copyrightable > but since you found them in ffmbc it is (imo!) > a matter of courtesy to mention the source. > Please mention both if you want. > > Sorry, I am on a journey and didn't sleep, > Carl Eugen > > > okay I'll fixed this, and resend a new patch, I'll mention both. thanks > ___ > 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] [RFC][PATCH] Allow include files to be installed into subdirectory
On 8/12/14, Andreas Cadhalpun wrote: > Hi, > > On 12.08.2014 02:21, Ivan Kalvachev wrote: >> On 8/11/14, Andreas Cadhalpun wrote: >>> Assuming it would be possible to install development packages for both >>> at the same time, which one should be used, when building a program? >> >> It would be decided by the gcc -I inclusion option. > > But this path has to come from the pkg-config files. Yes, pkg-config or programs specificly checking for that path. >> It modifies the search paths for header files, so that it checks these >> paths before the system/default ones (When using `#include >> "libavcodec/avcodec.h" `) >> >> Libav headers are probably going to remain in the default /usr/include/ . >> Usually this should not be a problem, unless a program uses `#include >> ` that should be used for system headers (aka >> checks the system/default paths first). > > But a lot of programs use '#include '. That's problem. Fortunately we don't have to solve this one right now. >> There might still be problems if there are explicit -I/usr/include >> inserted by other libraries that mix the inclusion order. >> >> To avoid hard to debug compiling problems, that the -dev packages may >> still be marked as conflicting, even though no files are overwritten. >> >> This final conflict however cannot be resolved on FFmpeg side. > > Yes, they still have to conflict. IMHO, we should do what we can on our side. The change is reflected in the pkgconfig files too. Since applications that link to libraries with addition suffixes should be using pkgconfig, they would be using the correct header includes automatically. >>> >>> If that's to be determined via pkg-config files, then the obvious >>> problem is that both install these files in the same location, and if >>> one doesn't, programs can't find the library. >> >> The problem is not that they are installed in the same location, but >> that they have same names. >> >> However I just checked and when you define library suffix (e.g. >> --build-suffix="_ffmpeg"), it also adds the same suffix to the .pc >> files. So you have >> /usr/lib/share/pkgconfig/libavcodec_ffmpeg.pc >> /usr/lib/libavcodec_ffmpeg.so > > Yes, but I patched that out in the Debian package [1], because otherwise > the programs wouldn't find the pkg-config files. Oh, this is problem. IMHO, having the same names is wrong. Isn't it simpler to have the libavcodec_ffmpeg.pc and a symlink libavcodec.pc pointing to it? The idea here is the future. If program prefers to build with ffmpeg it should be able to explicitly specify that it wants the ffmpeg (libavcodec-ffmpeg.pc). If program doesn't care, then it uses the generic symlink (libavcodec.pc). Is there some long debian documentation about symlinks, alernatives, etc, that you want to avoid? ;) >> In short, assuming if Libav doesn't change their library names and >> pkgconfig files, >> the programs that are looking for 'libavcodec.pc' would get the Libav >> one, >> the programs that are looking for 'libavcodec_ffmpeg.pc' would get >> FFmpeg. > > The problem is that programs only look for libavcodec.pc. Since Libav breaks API/ABI regularly, all applications require manual maintenance. They could change if there is correct alternative. >> I believe that you should already be using --build-suffix, so that >> should already be in the package. >> >> Is there something else I'm missing? > > Probably, that the pkg-config files in the FFmpeg package for Debian are > still libavcodec.pc etc.. Covered above. I did just a rudimentary test and I couldn't spot anything wrong. Please test it before inclusion. >>> >>> The patch seems to be alright, but it doesn't make it possible to make >>> the development packages of FFmpeg and Libav co-installable. >> >> Unfortunately not. >> But without the patch the problem is entirely in how FFmpeg installs its >> header. >> With it, it is entirely Libav problem for using system/common >> directory. Then, if Debian wants to resolve the conflict, Libav header >> files could be moved in their own directory. The patch should be >> trivial to port. > > I still don't see what the benefit would be, as the *-dev packages still > have to conflict. It is the future. If both projects separated headers, libraries and pkgconfigs, there would be no conflicts. At the moment we can only change FFmpeg to do the right thing. As for the future, it might be good idea next major release (e.g. 3.0) to have the $prefix/include/ffmpeg as default include path (for non-comapt build). >>> >>> So this would also not help. >> >> At the moment FFmpeg is trying to mimic 100% Libav API/ABI, and to be >> perfect drop-in replacement. This means using the same library names, >> locations and header files. >> This is what I call compat build. It is 100% compatible with Libav >> from application/program point of view. >> >> When using --build-suffix, you obviously want to differentiate from >> Libav, so I call tha
Re: [FFmpeg-devel] [RFC][PATCH] Allow include files to be installed into subdirectory
On 12.08.2014, at 02:21, Ivan Kalvachev wrote: > It would be decided by the gcc -I inclusion option. > It modifies the search paths for header files, so that it checks these > paths before the system/default ones (When using `#include > "libavcodec/avcodec.h" `) > > Libav headers are probably going to remain in the default /usr/include/ . > Usually this should not be a problem, unless a program uses `#include > ` that should be used for system headers (aka > checks the system/default paths first). Huh? The only difference between "" and <> is that "" also searches relative to the file's directory (and that first). -I applies equally to all. Anyone adding -I/usr/include explicitly deserves some beating. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] reset and complete RELEASE_NOTES for the next version
--- RELEASE_NOTES | 162 +++--- 1 file changed, 19 insertions(+), 143 deletions(-) diff --git a/RELEASE_NOTES b/RELEASE_NOTES index 1e6289b..eb73e88 100644 --- a/RELEASE_NOTES +++ b/RELEASE_NOTES @@ -1,175 +1,51 @@ ┌───┐ - │ RELEASE NOTES for FFmpeg 2.3 "Mandelbrot" │ + │ RELEASE NOTES for FFmpeg "FIXME" │ └───┘ - The FFmpeg Project proudly presents FFmpeg 2.3 "Mandelbrot", a major - release with all the great features committed during the three-month period - since the release of FFmpeg 2.2. - - In this release, there are lots of internal overhauls that make FFmpeg a - more accessible project for new developers. Many important new features - like QTKit and AVFoundation input devices are committed. Contributions done - by Libav such as a new native Opus decoder are also merged. - - Because of the increasing difficulty to maintain and lack of maintainers, - we are very sorry to say that we have removed all Blackfin and SPARC - architecture assembly optimizations with the cleanups done. If you are - interested in maintaining optimization for these two architecture, feel - free to contact us and we will restore the code! - - Since this release, the traditional Changelog file is upgraded to this - modern-looking release note. Old changelogs are moved to doc/Changelog.old. - - Enjoy! + The FFmpeg Project proudly presents FFmpeg "FIXME", ... ┌┐ │ * API Information │ └┘ - FFmpeg 2.3 is completely source-compatible to the FFmpeg 2.2 series. There - are however some API deprecations that you need to take care of. Use `git - diff n2.2 n2.3 doc/APIchanges` to show the list of added and deprecated - APIs. FFmpeg 2.3 includes the following library versions: + FFmpeg includes the following library versions: - • libavutil 52.92.100 - • libavcodec 55.69.100 - • libavformat55.47.100 - • libavdevice55.13.102 - • libavfilter 4.10.100 - • libswscale 2. 6.100 - • libswresample 0.19.100 - • libpostproc52. 3.100 + • libavutil xx.yy.1zz + • libavcodec xx.yy.1zz + • libavformatxx.yy.1zz + • libavdevicexx.yy.1zz + • libavfilterxx.yy.1zz + • libswscale xx.yy.1zz + • libswresample xx.yy.1zz + • libpostprocxx.yy.1zz Please refer to the doc/APIChanges file for more information. - ┌┐ - │ New Optimization │ - └┘ - - We are excited to announce that we have committed new x86 assembly - optimization for HEVC, and FFmpeg's audio resampler libswresample. ARM - users will get a boost in MLP/TrueHD decoding thanks to new optimization. - Decoding Huffyuv also got a major boost from optimization on the C code. - - Of special interest for Microsoft Visual Studio users, we have also - converted some preexisting x86 assembly to NASM/Yasm format compatible - with MSVC setup, especially in the area of audio resampling. - - Another major feature in this release is the introduction of AArch64 - (ARMv8) assembly optimization. AArch64 is another name for the first - 64-bit ARM architecture, used by Apple A7 SoC inside iPhone 5S. Some - 32-bit ARM assembly has already been ported to AArch64, but more work is - underway. - - ┌┐ - │ Native Opus decoder│ - └┘ - - Opus is an open audio format jointly developed by Xiph.Org, Mozilla, - Skype/Microsoft, and Broadcom. It combines the features of the Skype Cilk - speech codec and the Xiph.Org CELT music codec into one low-latency - codec. Decoding Opus is already possible since FFmpeg 1.0 using the - libopus library, but the new Opus native decoder brings a higher level of - stability and speed. - - ┌┐ - │ QTKit and AVFoundation │ - └┘ - - For OS X users, the new QTKit and AVFoundation devices allow you to use - the integrated camera on Macs. AVFoundation is a newer API only available - on OS X 10.7 "Lion" or newer. For users with older OS X systems, the - QTKit device using the older OS X API is for you. - - ┌┐ - │ API Additions │ - └┘ - - In this release, stream side data are introduced as AVStream.side_data as - a way to store miscellaneous stream-wide information. The format is - similar to the previously anonymous structure AVPacket.side_data (now - named as AVPacketSideData). With this change, audio ReplayGain - information and video rotation matrix are now exported through this API, -
Re: [FFmpeg-devel] [PATCH] vp9: ignore reference segmentation map if error_resilience flag is set.
On Tue, Aug 12, 2014 at 06:11:05PM -0400, Ronald S. Bultje wrote: > Fixes ffvp9_fails_where_libvpx.succeeds.webm from ticket 3849. > --- > libavcodec/vp9.c | 26 +++--- > 1 file changed, 15 insertions(+), 11 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] reset and complete RELEASE_NOTES for the next version
On Wed, Aug 13, 2014 at 08:51:05PM +0200, Clément Bœsch wrote: > --- > RELEASE_NOTES | 162 > +++--- > 1 file changed, 19 insertions(+), 143 deletions(-) ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] reset and complete RELEASE_NOTES for the next version
On Wed, Aug 13, 2014 at 09:00:38PM +0200, Michael Niedermayer wrote: > On Wed, Aug 13, 2014 at 08:51:05PM +0200, Clément Bœsch wrote: > > --- > > RELEASE_NOTES | 162 > > +++--- > > 1 file changed, 19 insertions(+), 143 deletions(-) > > ok > thanks, pushed. -- Clément B. pgpC2tZ8zorsa.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] build: rely on pkg-config for libx264 probing
On Thu, Jun 19, 2014 at 06:59:48PM +0200, Clément Bœsch wrote: > On Thu, Jun 19, 2014 at 04:23:55PM +, Carl Eugen Hoyos wrote: > > Clément Bœsch pkh.me> writes: > > > > > > If your patch is really what everybody wants, please > > > > add a fallback that allows to try the current > > > > way of building if pkg-config returns that the > > > > library is missing. > > > > > > How am I supposed to do that? > > > > > > add a --enable-manual-detection-libx264? > > > > Sorry, I meant the variant that you proposed last week: > > http://ffmpeg.org/pipermail/ffmpeg-devel/2014-June/158707.html > > > > enabled libx264 && require_pkg_config x264 || > >require libx264 x264.h ... > > > > In that case, I probably need to add a libx264 exception in > require_pkg_config, because after patch 3 it will die if pkg-config is not > found. That's going to be pretty ugly. > > Is everyone fine with that? > Carl, do you want the fallback to work just when pkg-config is not available or do you actually want a real fallback when it is present but didn't succeed? (the second solution is way uglier to solve) -- Clément B. pgpA1X4yR8Vt4.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] dpx: abort if encrypted
2014-08-13 21:35 GMT+02:00 Reimar Döffinger :
> Personally I'd probably go with the missing feature and a warning
> message on top instead of the return.
Same opinion, here's an updated patch.
From 47f363c96c3dd15e7e36267ccdb338b102d40078 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Wed, 13 Aug 2014 01:44:40 +0200
Subject: [PATCH 3/4] dpx: warn if encrypted
---
libavcodec/dpx.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 8cd7d73..6c4951b 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -108,6 +108,16 @@ static int decode_frame(AVCodecContext *avctx,
av_log(avctx, AV_LOG_ERROR, "Invalid data start offset\n");
return AVERROR_INVALIDDATA;
}
+
+// Check encryption
+buf = avpkt->data + 660;
+ret = read32(&buf, endian);
+if (ret != 0x) {
+avpriv_report_missing_feature(avctx, "Encryption");
+av_log(avctx, AV_LOG_WARNING, "The image is encrypted and may "
+ "not properly decode.\n");
+}
+
// Need to end in 0x304 offset from start of file
buf = avpkt->data + 0x304;
w = read32(&buf, endian);
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Invitation to VDD and registration
On Wed, 13 Aug 2014 18:48:38 +0200 Reimar Döffinger wrote: > On 13.08.2014, at 18:42, Stefano Sabatini wrote: > > On date Sunday 2014-07-20 18:16:52 +0200, Jean-Baptiste Kempf > > encoded: > >> My dear friends of the FFmpeg community, > >> > >> I'd like to invite you to the VideoLAN Dev Days 2014, the 3rd > >> week-end of September, in Dublin, Ireland. Google is providing the > >> hosting. > >> > >> This technical conference about open source multimedia, will see > >> developers from VLC, libav, FFmpeg, x26*, Phonon, DVBlast, > >> PulseAudio, KDE, Gnome, Xiph, handbrake, tomahawk and other > >> projects gather to discuss about open source development of > >> multimedia projects. This is a developer conference, so topics > >> will be technical. > >> > >> The registration is now open here: http://goo.gl/NiCInJ > >> Please register as soon as possible, to help us organize the > >> conference. > > [...] > > > > Hi, > > > > anybody is planning to go there? I remember that the registration > > will close on August 20 (that is, the next week Wednesday), bye. > > I already registered and booked flights anyone who has been reading in #videolan knows that i was viciously lied to about the duration of the train trip from london to dublin... flights booked and i'm looking forward to meeting reimar and seeing google up close. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] NULL-check Matroska chapters when reading header
I have a Matroska file that contains a broken chapter (end time is before
start time) that caused any ffmpeg-linked program to crash when accessing
it. I've attached a patch that fixes the crash. Also, here is the backtrace
of the crash for reference:
(gdb) backtrace
#0 av_dict_set (pm=0x20, key=0x70bd14ef "title", value=0x7fffd80107e0
"The End", flags=0) at libavutil/dict.c:71
#1 0x70b0e220 in matroska_read_header (s=0x20) at
libavformat/matroskadec.c:2164
#2 0x70b9b233 in avformat_open_input (ps=0x7fffe00c1a08,
filename=, fmt=, options=0x0) at
libavformat/utils.c:599
#3 0x75fc9c32 in
ffmpegthumbnailer::MovieDecoder::initialize(std::string const&) () from
/usr/lib/libffmpegthumbnailer.so.4
#4 0x75fcd50f in
ffmpegthumbnailer::VideoThumbnailer::generateThumbnail(std::string const&,
ffmpegthumbnailer::ImageWriter&, AVFormatContext*) ()
from /usr/lib/libffmpegthumbnailer.so.4
#5 0x75fcd911 in
ffmpegthumbnailer::VideoThumbnailer::generateThumbnail(std::string const&,
ThumbnailerImageTypeEnum, std::string const&, AVFormatContext*) ()
from /usr/lib/libffmpegthumbnailer.so.4
#6 0x75fce636 in video_thumbnailer_generate_thumbnail_to_file ()
from /usr/lib/libffmpegthumbnailer.so.4
#7 0x004314e5 in ?? ()
#8 0x004319a0 in ?? ()
#9 0x0042221f in ?? ()
#10 0x004310bb in ?? ()
#11 0x00430dd0 in ?? ()
#12 0x7644ec95 in ?? () from /usr/lib/libglib-2.0.so.0
#13 0x75766124 in start_thread () from /usr/lib/libpthread.so.0
#14 0x7549a4bd in clone () from /usr/lib/libc.so.6
Thanks,
Justin
From 14c4bcd96e6677c93b730faf0b4bf296e12bfd79 Mon Sep 17 00:00:00 2001
From: Justin Jacobs
Date: Wed, 6 Aug 2014 20:04:38 -0400
Subject: [PATCH] NULL-check Matroska chapters when reading header
---
libavformat/matroskadec.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 50b75e7..10969de 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2161,8 +2161,10 @@ static int matroska_read_header(AVFormatContext *s)
(AVRational) { 1, 10 },
chapters[i].start, chapters[i].end,
chapters[i].title);
-av_dict_set(&chapters[i].chapter->metadata,
-"title", chapters[i].title, 0);
+if (chapters[i].chapter) {
+av_dict_set(&chapters[i].chapter->metadata,
+"title", chapters[i].title, 0);
+}
max_start = chapters[i].start;
}
--
2.0.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][PATCH] Allow include files to be installed into subdirectory
On 8/13/14, Reimar Döffinger wrote: > On 12.08.2014, at 02:21, Ivan Kalvachev wrote: >> It would be decided by the gcc -I inclusion option. >> It modifies the search paths for header files, so that it checks these >> paths before the system/default ones (When using `#include >> "libavcodec/avcodec.h" `) >> >> Libav headers are probably going to remain in the default /usr/include/ . >> Usually this should not be a problem, unless a program uses `#include >> ` that should be used for system headers (aka >> checks the system/default paths first). > > Huh? The only difference between "" and <> is that "" also searches relative > to the file's directory (and that first). > -I applies equally to all. My bad, I must have combined wrongly two separate peaces of information. Reading this http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html also says I'm wrong about the -I/usr/include . Since it is a system directory the option would be removed/ignored, to ensure the system headers are included last. So basically there is no problem at all with the header files. We could have non-conflicting -dev packages. > Anyone adding -I/usr/include explicitly deserves some beating. I think that FFmpeg/Libav pkgconfig files do this, if installed in --prefix=/usr . ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] NULL-check Matroska chapters when reading header
On Wed, Aug 13, 2014 at 08:13:31PM -0400, Justin Jacobs wrote: > I have a Matroska file that contains a broken chapter (end time is before > start time) that caused any ffmpeg-linked program to crash when accessing > it. I've attached a patch that fixes the crash. Also, here is the backtrace > of the crash for reference: this patch has already been applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire 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/4] dpx: use aligned line starts
On Wed, Aug 13, 2014 at 10:21:51AM +, Christophe Gisquet wrote: > SMPTE 268M-2003 specifies that each line starts at a 4-bytes boundary. > Therefore, modify correspondingly the input buffer strides and size. > > Partially fixes ticket #3692: DLAD_8b_3c_big.dpx still has inverted > colors, which might be related to endianness. > --- > libavcodec/dpx.c | 34 +++--- > 1 file changed, 23 insertions(+), 11 deletions(-) causes ./ffmpeg -icheckerboard_1080p_nuke_bigendian_12bit_alpha.dpx -f null - to segfault see http://samples.ffmpeg.org/image-samples/dpx_samples.zip -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato 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/4] dpxenc: enforce alignment requirement
On Wed, Aug 13, 2014 at 01:51:42PM +0200, Paul B Mahol wrote: > On 8/13/14, Christophe Gisquet wrote: > > S268M-2003 specifies that each line start is aligned on a 4-byte boundary. > > --- > > libavcodec/dpxenc.c | 44 +--- > > 1 file changed, 37 insertions(+), 7 deletions(-) > > > > probably ok applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] dpx: abort if encrypted
On Wed, Aug 13, 2014 at 10:27:22PM +0200, Christophe Gisquet wrote: > 2014-08-13 21:35 GMT+02:00 Reimar Döffinger : > > Personally I'd probably go with the missing feature and a warning > > message on top instead of the return. > > Same opinion, here's an updated patch. > dpx.c | 10 ++ > 1 file changed, 10 insertions(+) > 7dbd3f3308cf80279722c919d7fc357a0270ba3f 0003-dpx-warn-if-encrypted.patch > From 47f363c96c3dd15e7e36267ccdb338b102d40078 Mon Sep 17 00:00:00 2001 > From: Christophe Gisquet > Date: Wed, 13 Aug 2014 01:44:40 +0200 > Subject: [PATCH 3/4] dpx: warn if encrypted > > --- > libavcodec/dpx.c | 10 ++ > 1 file changed, 10 insertions(+) applied thanks [...] -- 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] [PATCH] NULL-check Matroska chapters when reading header
Sorry, I didn't realize this had been responded to. I wasn't subbed to the mailing list, so I sent the patch again without realizing. Just disregard that message. The problematic file was the final episode of the anime Nichijou. I think the group that added English subtitles to it auto-created the chapters. Each episode ends with a chapter for the next episode preview. However, the last episode doesn't have this preview, so the chapter time must have been messed up. Unfortunately, since the show is copyrighted material, I don't think I should redistribute it. Justin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] dpx: fix endianess for RGB 8bits
On Wed, Aug 13, 2014 at 10:21:54AM +, Christophe Gisquet wrote: > Fixes DLAD_8b_3c_big.dpx from ticket #3692 > --- > libavcodec/dpx.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c > index 2ad7527..d4d6833 100644 > --- a/libavcodec/dpx.c > +++ b/libavcodec/dpx.c > @@ -232,6 +232,8 @@ static int decode_frame(AVCodecContext *avctx, > avctx->pix_fmt = AV_PIX_FMT_GRAY8; > break; > case 50081: > +avctx->pix_fmt = AV_PIX_FMT_BGR24; > +break; this possibly breaks decoding of checkerboard_1080p_nuke_bigendian_8bit_noalpha.dpx the cross in the middle is displayed as cyan while the other samples have it yellow [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/oggparsevp8: use ff_vorbis_stream_comment()
commit db68ef89 did not update the vp8 parser Signed-off-by: James Almer --- libavformat/oggparsevp8.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/oggparsevp8.c b/libavformat/oggparsevp8.c index b3dd7ab..5959d32 100644 --- a/libavformat/oggparsevp8.c +++ b/libavformat/oggparsevp8.c @@ -64,7 +64,7 @@ static int vp8_header(AVFormatContext *s, int idx) case 0x02: if (p[6] != 0x20) return AVERROR_INVALIDDATA; -ff_vorbis_comment(s, &st->metadata, p + 7, os->psize - 7, 1); +ff_vorbis_stream_comment(s, st, p + 7, os->psize - 7); break; default: av_log(s, AV_LOG_ERROR, "Unknown VP8 header type 0x%02X\n", p[5]); -- 1.8.5.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/fic: Check if a frame is available before using it
Fixes null pointer dereference
Fixes: ficvf.avi
Found-by: Piotr Bandurski
Signed-off-by: Michael Niedermayer
---
libavcodec/fic.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/fic.c b/libavcodec/fic.c
index d08d240..5615e69 100644
--- a/libavcodec/fic.c
+++ b/libavcodec/fic.c
@@ -282,8 +282,13 @@ static int fic_decode_frame(AVCodecContext *avctx, void
*data,
av_log(avctx, AV_LOG_WARNING, "Invalid FIC Header.\n");
/* Is it a skip frame? */
-if (src[17])
+if (src[17]) {
+if (!ctx->final_frame) {
+av_log(avctx, AV_LOG_WARNING, "Initial frame is skipped\n");
+return AVERROR_INVALIDDATA;
+}
goto skip;
+}
nslices = src[13];
if (!nslices) {
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/oggparsevp8: use ff_vorbis_stream_comment()
On Thu, Aug 14, 2014 at 12:31:00AM -0300, James Almer wrote: > commit db68ef89 did not update the vp8 parser > > Signed-off-by: James Almer > --- > libavformat/oggparsevp8.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
