Re: [FFmpeg-devel] Vertical bands with RT21 (Intel Real TimeVideo2.1) codec
> And ir21.dll ? http://www.moviecodec.com/download-video-codecs/indeo-2-319598me-30/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Revert "Merge commit '741b494fa8cd28a7d096349bac183893c236e3f9'"
On Thu, Dec 17, 2015 at 02:46:40PM +0100, Hendrik Leppkes wrote: > On Thu, Dec 17, 2015 at 2:06 PM, Michael Niedermayer wrote: > > From: Michael Niedermayer > > > > This fixes a regression of the sample from Ticket 2371 > > > > This reverts commit bc66451e5e903698ee0500faf04c1214f3dd157f, reversing > > changes made to 9d1fb9ef313e0fb709ac4c35c7bf00264963fd85. > > --- > > libavcodec/h264.h |8 +++ > > libavcodec/h264_refs.c | 57 > > ++- > > libavcodec/h264_slice.c | 17 +- > > 3 files changed, 56 insertions(+), 26 deletions(-) > > Reverting big commits to fix one sample and making future merges > harder or impossible seems not like the best option, unless it can be > shown that the entire change is flawed, and not just a small bug. > Otherwise, it should be attempted to fix regressions the usual way - > by fixing things, not reverting. > > Once reverted, the change will never come back, we all know that. > > At least thats IMHO. You are the maintainer of the H264 decoder, so if > you want to revert it, feel free. Calculatig the default ref seems to take between 800 and 4700 or so cpu cycles (messured with fate & START_TIMER) tests/data/fate/filter-paletteuse-sierra2_4a.err: 46958 decicycles in h264_initialise_ref_list, 64 runs, 0 skips tests/data/fate/h264-conformance-caba3_sony_c.err: 26963 decicycles in h264_initialise_ref_list, 256 runs, 0 skips tests/data/fate/h264-conformance-frext-hcafr4_hhi_a.err: 29306 decicycles in h264_initialise_ref_list, 15 runs, 1 skips tests/data/fate/h264-conformance-sva_cl1_e.err: 7956 decicycles in h264_initialise_ref_list, 128 runs, 0 skips ... with the default lists the time spend in Calculating them after the first slice and including the checks needed to find out if they need to be recalculated seem to be always below 500 cycles in fate tests/data/fate/h264-conformance-cvnlfi1_sony_c.err: 4196 decicycles in CMP, 256 runs, 0 skips tests/data/fate/h264-conformance-cvfi1_sony_d.err: 3976 decicycles in CMP, 128 runs, 0 skips tests/data/fate/h264-conformance-cvfi1_sony_d.err: 4142 decicycles in CMP, 256 runs, 0 skips tests/data/fate/h264-conformance-basqp1_sony_c.err:381 decicycles in CMP, 128 runs, 0 skips tests/data/fate/h264-conformance-cvnlfi2_sony_h.err: 3757 decicycles in CMP, 128 runs, 0 skips tests/data/fate/h264-conformance-cvnlfi2_sony_h.err: 3687 decicycles in CMP, 256 runs, 0 skips tests/data/fate/h264-conformance-ci1_ft_b.err: 4588 decicycles in CMP, 128 runs, 0 skips tests/data/fate/h264-conformance-ci1_ft_b.err: 4754 decicycles in CMP, 256 runs, 0 skips tests/data/fate/h264-conformance-cvfc1_sony_c.err: 4146 decicycles in CMP, 128 runs, 0 skips tests/data/fate/h264-conformance-cabaci3_sony_b.err: 2739 decicycles in CMP, 128 runs, 0 skips tests/data/fate/h264-conformance-cabaci3_sony_b.err: 2732 decicycles in CMP, 256 runs, 0 skips tests/data/fate/h264-conformance-cabaci3_sony_b.err: 2878 decicycles in CMP, 512 runs, 0 skips tests/data/fate/h264-conformance-ba1_ft_c.err: 4266 decicycles in CMP, 128 runs, 0 skips tests/data/fate/h264-conformance-ba1_ft_c.err: 4358 decicycles in CMP, 256 runs, 0 skips tests/data/fate/h264-conformance-cvfi2_sony_h.err: 4347 decicycles in CMP, 128 runs, 0 skips tests/data/fate/h264-conformance-cvfi2_sony_h.err: 4179 decicycles in CMP, 256 runs, 0 skips its possible the extra list causes harder to meassure slowdowns elsewhere of course (cache hit/miss ratio, more fields in the context, whatever) but for files with many small slices recalculating the same list for each seems a waste of time to me. i also suspect that libav had a bug in their default ref list code or at least their checks look less complete than ours prior to the removial in both trees I think the decission about which way to go here should be yours as you might (or might not) be affected by this causing extra work in the future [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- 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 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}
On Sat, Dec 19, 2015 at 03:24:17AM +0100, Michael Niedermayer wrote:
> On Fri, Dec 18, 2015 at 04:33:37PM +0100, Matthieu Bouron wrote:
> > On Fri, Dec 18, 2015 at 3:59 PM, Matthieu Bouron
> > wrote:
> >
> > > From: Matthieu Bouron
> > >
> > > ---
> > > libswscale/arm/swscale_unscaled.c | 52 +++---
> > > libswscale/arm/yuv2rgb_neon.S | 77
> > > ---
> > > 2 files changed, 118 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/libswscale/arm/swscale_unscaled.c
> > > b/libswscale/arm/swscale_unscaled.c
> > > index 8aa6432..dce987e 100644
> > > --- a/libswscale/arm/swscale_unscaled.c
> > > +++ b/libswscale/arm/swscale_unscaled.c
> > > @@ -63,6 +63,50 @@ static int rgbx_to_nv12_neon_16_wrapper(SwsContext
> > > *context, const uint8_t *src[
> > > }
> > > #endif
> > >
> > > +#define YUV_TO_RGB_TABLE(precision)
> > >\
> > > +c->yuv2rgb_v2r_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > \
> > > +c->yuv2rgb_u2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > \
> > > +c->yuv2rgb_v2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > \
> > > +c->yuv2rgb_u2b_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > \
> > > +
> > > +#define DECLARE_FF_YUV420P_TO_RGBX_FUNCS(ofmt, precision)
> > >\
> > > +int ff_yuv420p_to_##ofmt##_neon_##precision(int w, int h,
> > >\
> > > + uint8_t *dst, int linesize,
> > > \
> > > + const uint8_t *srcY, int linesizeY,
> > > \
> > > + const uint8_t *srcU, int linesizeU,
> > > \
> > > + const uint8_t *srcV, int linesizeV,
> > > \
> > > + const int16_t *table,
> > > \
> > > + int y_offset,
> > > \
> > > + int y_coeff);
> > > \
> > > +
> > > \
> > > +static int yuv420p_to_##ofmt##_neon_wrapper_##precision(SwsContext *c,
> > > const uint8_t *src[],\
> > > + int srcStride[], int
> > > srcSliceY, int srcSliceH, \
> > > + uint8_t *dst[], int
> > > dstStride[]) { \
> > > +const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE(precision) };
> > > \
> > > +
> > > \
> > > +ff_yuv420p_to_##ofmt##_neon_##precision(c->srcW, srcSliceH,
> > >\
> > > + dst[0] + srcSliceY * dstStride[0],
> > > dstStride[0], \
> > > + src[0] + srcSliceY * srcStride[0],
> > > srcStride[0], \
> > > + src[1] + (srcSliceY / 2) * srcStride[1],
> > > srcStride[1], \
> > > + src[2] + (srcSliceY / 2) * srcStride[2],
> > > srcStride[2], \
> > > + yuv2rgb_table,
> > >\
> > > + c->yuv2rgb_y_offset >> 9,
> > > \
> > > + c->yuv2rgb_y_coeff / ((precision) == 16
> > > ? 1 << 7 : 1));\
> > > +
> > > \
> > > +return 0;
> > >\
> > > +}
> > >\
> > > +
> > > +#define DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(precision)
> > >\
> > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(argb, precision)
> > >\
> > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(rgba, precision)
> > >\
> > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(abgr, precision)
> > >\
> > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(bgra, precision)
> > >\
> > > +
> > > +#define DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS
> > > \
> > > +DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(16)
> > > \
> > > +
> > > +DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS
> > > +
> > > #define DECLARE_FF_NVX_TO_RGBX_FUNCS(ifmt, ofmt, precision)
> > >\
> > > int ff_##ifmt##_to_##ofmt##_neon_##precision(int w, int h,
> > > \
> > > uint8_t *dst, int linesize,
> > > \
> > > @@ -75,12 +119,7 @@ int ff_##ifmt##_to_##ofmt##_neon_##precision(int w,
> > > int h,
> > > static int ifmt##_to_##ofmt##_neon_wrapper_##precision(SwsContext *c,
> > > const uint8_t *src[], \
> > > int srcStride[], int
> > > srcSliceY, int srcSliceH, \
> > > uint8_t *dst[], int
> > > dstStride[]) { \
> > > -const int16_t yuv2rgb_table[] = {
> > >
Re: [FFmpeg-devel] [PATCH 1/2] swscale/arm/yuv2rgb: simplify process_16px_* macro call
On Tue, Dec 15, 2015 at 10:40:13PM +0100, Michael Niedermayer wrote: > On Tue, Dec 15, 2015 at 05:46:08PM +0100, Matthieu Bouron wrote: > > From: Matthieu Bouron > > > > --- > > libswscale/arm/yuv2rgb_neon.S | 8 +--- > > 1 file changed, 1 insertion(+), 7 deletions(-) > > should be ok Pushed. Thanks. [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/scale: add nb_slices debug option
L'octidi 28 frimaire, an CCXXIV, Clement Boesch a écrit :
> +}else if (scale->nb_slices) {
> +int i;
> +const int nb_slices = FFMIN(scale->nb_slices, link->h);
> +for (i = 0; i < nb_slices; i++) {
> +const int slice_start = (link->h * i ) / nb_slices;
> +const int slice_end = (link->h * (i+1)) / nb_slices;
> +const int slice_h = slice_end - slice_start;
> +scale_slice(link, out, in, scale->sws, slice_start, slice_h, 1,
> 0);
> +}
You can do simpler and more robust by computing the boundary only once
(using av_rescale to also avoid overflows):
int i, slice_start, slice_end = slice_start;
for (i = 0; i < nb_slices; i++) {
slice_start = slice_end;
slice_end = av_rescale(link->h, i + 1, nb_slices);
...
}
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/12] lavfi/vf_idet: replace round and cast by lrint
On Fri, Dec 18, 2015 at 09:45:27PM -0800, Ganesh Ajjanagadde wrote: > lrint is faster and conveys the intent better here. It is safe as long int has > at least 32 bits. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavfilter/vf_idet.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) half_life should be checked to be within the defined range of lrint() should be ok otherwise [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- 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 05/12] lavfi/vsrc_mandelbrot: replace round by lrint
On Fri, Dec 18, 2015 at 09:45:31PM -0800, Ganesh Ajjanagadde wrote: > lrint is at least as fast, and is more accurate. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavfilter/vsrc_mandelbrot.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope 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] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}
On Sat, Dec 19, 2015 at 10:56:26AM +0100, Matthieu Bouron wrote:
> On Sat, Dec 19, 2015 at 03:24:17AM +0100, Michael Niedermayer wrote:
> > On Fri, Dec 18, 2015 at 04:33:37PM +0100, Matthieu Bouron wrote:
> > > On Fri, Dec 18, 2015 at 3:59 PM, Matthieu Bouron
> > >
> > > wrote:
> > >
> > > > From: Matthieu Bouron
> > > >
> > > > ---
> > > > libswscale/arm/swscale_unscaled.c | 52 +++---
> > > > libswscale/arm/yuv2rgb_neon.S | 77
> > > > ---
> > > > 2 files changed, 118 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/libswscale/arm/swscale_unscaled.c
> > > > b/libswscale/arm/swscale_unscaled.c
> > > > index 8aa6432..dce987e 100644
> > > > --- a/libswscale/arm/swscale_unscaled.c
> > > > +++ b/libswscale/arm/swscale_unscaled.c
> > > > @@ -63,6 +63,50 @@ static int rgbx_to_nv12_neon_16_wrapper(SwsContext
> > > > *context, const uint8_t *src[
> > > > }
> > > > #endif
> > > >
> > > > +#define YUV_TO_RGB_TABLE(precision)
> > > >\
> > > > +c->yuv2rgb_v2r_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > \
> > > > +c->yuv2rgb_u2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > \
> > > > +c->yuv2rgb_v2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > \
> > > > +c->yuv2rgb_u2b_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > \
> > > > +
> > > > +#define DECLARE_FF_YUV420P_TO_RGBX_FUNCS(ofmt, precision)
> > > >\
> > > > +int ff_yuv420p_to_##ofmt##_neon_##precision(int w, int h,
> > > >\
> > > > + uint8_t *dst, int linesize,
> > > > \
> > > > + const uint8_t *srcY, int linesizeY,
> > > > \
> > > > + const uint8_t *srcU, int linesizeU,
> > > > \
> > > > + const uint8_t *srcV, int linesizeV,
> > > > \
> > > > + const int16_t *table,
> > > > \
> > > > + int y_offset,
> > > > \
> > > > + int y_coeff);
> > > > \
> > > > +
> > > > \
> > > > +static int yuv420p_to_##ofmt##_neon_wrapper_##precision(SwsContext *c,
> > > > const uint8_t *src[],\
> > > > + int srcStride[], int
> > > > srcSliceY, int srcSliceH, \
> > > > + uint8_t *dst[], int
> > > > dstStride[]) { \
> > > > +const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE(precision) };
> > > > \
> > > > +
> > > > \
> > > > +ff_yuv420p_to_##ofmt##_neon_##precision(c->srcW, srcSliceH,
> > > >\
> > > > + dst[0] + srcSliceY *
> > > > dstStride[0],
> > > > dstStride[0], \
> > > > + src[0] + srcSliceY *
> > > > srcStride[0],
> > > > srcStride[0], \
> > > > + src[1] + (srcSliceY / 2) *
> > > > srcStride[1],
> > > > srcStride[1], \
> > > > + src[2] + (srcSliceY / 2) *
> > > > srcStride[2],
> > > > srcStride[2], \
> > > > + yuv2rgb_table,
> > > >\
> > > > + c->yuv2rgb_y_offset >> 9,
> > > > \
> > > > + c->yuv2rgb_y_coeff / ((precision) ==
> > > > 16
> > > > ? 1 << 7 : 1));\
> > > > +
> > > > \
> > > > +return 0;
> > > >\
> > > > +}
> > > >\
> > > > +
> > > > +#define DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(precision)
> > > >\
> > > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(argb, precision)
> > > >\
> > > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(rgba, precision)
> > > >\
> > > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(abgr, precision)
> > > >\
> > > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(bgra, precision)
> > > >\
> > > > +
> > > > +#define DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS
> > > > \
> > > > +DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(16)
> > > > \
> > > > +
> > > > +DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS
> > > > +
> > > > #define DECLARE_FF_NVX_TO_RGBX_FUNCS(ifmt, ofmt, precision)
> > > >\
> > > > int ff_##ifmt##_to_##ofmt##_neon_##precision(int w, int h,
> > > > \
> > > > uint8_t *dst, int linesize,
> > > > \
> > > > @@ -75,12 +119,7 @@ int ff_##ifmt##_to_##ofmt##_neon_##precision(int w,
> > > > int h,
> > > > static int ifmt##_to_##ofmt##_n
Re: [FFmpeg-devel] [libav-devel] [PATCH] xwddec: prevent overflow of lsize * avctx->height
On 19.12.2015 01:32, Michael Niedermayer wrote:
> On Fri, Dec 18, 2015 at 08:13:06PM +0100, Andreas Cadhalpun wrote:
>> xwddec.c |6 ++
>> 1 file changed, 6 insertions(+)
>> 0be27d89a669445b523bfdac99884065e3581f3c
>> 0001-xwddec-prevent-overflow-of-lsize-avctx-height.patch
>> From fb40616d7b432680b92dc3adc44a5b5d12fac55d Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun
>> Date: Fri, 18 Dec 2015 19:28:51 +0100
>> Subject: [PATCH] xwddec: prevent overflow of lsize * avctx->height
>>
>> This is used to check if the input buffer is larger enough, so if this
>> overflows it can cause a false negative leading to a segmentation fault
>> in bytestream2_get_bufferu.
>
> cant the addition overflow too in the input buffer check ?
Probably.
> if so then using 64bit in the input buffer check would avoid the
> need for a explicit check on lsize
Indeed, that's simpler. New patch attached.
Best regards,
Andreas
>From 8c0d712cfa6bc7e429826d330887be9463006534 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Fri, 18 Dec 2015 19:28:51 +0100
Subject: [PATCH] xwddec: prevent overflow of lsize * avctx->height
This is used to check if the input buffer is larger enough, so if this
overflows it can cause a false negative leading to a segmentation fault
in bytestream2_get_bufferu.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/xwddec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/xwddec.c b/libavcodec/xwddec.c
index 2febedc..64cd841 100644
--- a/libavcodec/xwddec.c
+++ b/libavcodec/xwddec.c
@@ -141,7 +141,7 @@ static int xwd_decode_frame(AVCodecContext *avctx, void *data,
return AVERROR_INVALIDDATA;
}
-if (bytestream2_get_bytes_left(&gb) < ncolors * XWD_CMAP_SIZE + avctx->height * lsize) {
+if (bytestream2_get_bytes_left(&gb) < ncolors * XWD_CMAP_SIZE + (uint64_t)avctx->height * lsize) {
av_log(avctx, AV_LOG_ERROR, "input buffer too small\n");
return AVERROR_INVALIDDATA;
}
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] nutdec: reject negative sm_size
On 19.12.2015 01:51, Michael Niedermayer wrote:
> On Fri, Dec 18, 2015 at 05:22:31PM +0100, Andreas Cadhalpun wrote:
>> If it is negative, it makes size larger than the size of the packet
>> buffer, causing invalid writes in avio_read.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/nutdec.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
>> index 286d1ee..47ae7a7 100644
>> --- a/libavformat/nutdec.c
>> +++ b/libavformat/nutdec.c
>> @@ -1146,6 +1146,11 @@ static int decode_frame(NUTContext *nut, AVPacket
>> *pkt, int frame_code)
>> goto fail;
>> }
>> sm_size = avio_tell(bc) - pkt->pos;
>> +if (sm_size < 0) {
>
> did sm_size overflow and should be 64bit ?
No.
> did the byte position (avio_tell) move backward ?
Yes.
> (this should not happen)
In that case, the check needs to be moved to read_sm_data.
Patch doing that is attached.
Best regards,
Andreas
>From bdca159087d426f5f989656a08464fec967b4bc3 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Sat, 19 Dec 2015 12:02:56 +0100
Subject: [PATCH] nutdec: reject negative value_len in read_sm_data
If it is negative, it can cause the byte position to move backwards in
avio_skip, which in turn makes sm_size negative and thus size larger
than the size of the packet buffer, causing invalid writes in avio_read.
Signed-off-by: Andreas Cadhalpun
---
libavformat/nutdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
index 286d1ee..b33b3e2 100644
--- a/libavformat/nutdec.c
+++ b/libavformat/nutdec.c
@@ -934,7 +934,7 @@ static int read_sm_data(AVFormatContext *s, AVIOContext *bc, AVPacket *pkt, int
return ret;
}
value_len = ffio_read_varlen(bc);
-if (avio_tell(bc) + value_len >= maxpos)
+if (value_len < 0 || avio_tell(bc) + value_len >= maxpos)
return AVERROR_INVALIDDATA;
if (!strcmp(name, "Palette")) {
dst = av_packet_new_side_data(pkt, AV_PKT_DATA_PALETTE, value_len);
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] nutdec: only copy the header if it exists
On 18.12.2015 23:11, Luca Barbato wrote:
> On 18/12/15 20:12, Andreas Cadhalpun wrote:
>> On 18.12.2015 20:06, Luca Barbato wrote:
>>> On 18/12/15 19:05, Andreas Cadhalpun wrote:
On 18.12.2015 18:53, Luca Barbato wrote:
> On 18/12/15 17:24, Andreas Cadhalpun wrote:
>> Fixes runtime error: null pointer passed as argument 2, which is
>> declared to never be null
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/nutdec.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
>> index 47ae7a7..3aa7a88 100644
>> --- a/libavformat/nutdec.c
>> +++ b/libavformat/nutdec.c
>> @@ -1133,7 +1133,8 @@ static int decode_frame(NUTContext *nut, AVPacket
>> *pkt, int frame_code)
>> ret = av_new_packet(pkt, size + nut->header_len[header_idx]);
>> if (ret < 0)
>> return ret;
>> -memcpy(pkt->data, nut->header[header_idx],
>> nut->header_len[header_idx]);
>> +if (nut->header[header_idx])
>> +memcpy(pkt->data, nut->header[header_idx],
>> nut->header_len[header_idx]);
>> pkt->pos = avio_tell(bc); // FIXME
>> if (stc->last_flags & FLAG_SM_DATA) {
>> int sm_size;
>>
>
> When it happens exactly?
When header_idx is 0 and thus nut->header_len[0] = 0 and nut->header[0] =
NULL.
>>>
>>> if header_len is 0 what's exactly the problem?
>>
>> gcc's undefined behavior sanitizer prints the error from the commit message.
>> That's all. See e.g. [1].
>
> Probably that should go in the commit message
I thought that including the runtime error message was clear enough, but
apparently
that's not the case. I'll use 'Fixes ubsan runtime error' in the future.
> or the header[0] could be made pointing "" to keep the code slightly tidy.
That would be an alternative fix, but I prefer keeping a pointer that should not
be used as NULL.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] nutdec: only copy the header if it exists
On 19.12.2015 01:59, Michael Niedermayer wrote: > On Fri, Dec 18, 2015 at 05:24:09PM +0100, Andreas Cadhalpun wrote: >> Fixes runtime error: null pointer passed as argument 2, which is >> declared to never be null >> >> Signed-off-by: Andreas Cadhalpun >> --- >> libavformat/nutdec.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) > > LGTM Pushed, with 'ubsan' included in the commit message. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavc/aacsbr: sbr_dequant optimization
On 18.12.2015 16:52, Ganesh Ajjanagadde wrote:
> On Tue, Dec 15, 2015 at 9:53 PM, Ganesh Ajjanagadde
> wrote:
>> This uses ff_exp2fi to get a speedup (~ 6x).
>>
>> sample benchmark (Haswell, GNU/Linux):
>> old:
>> 19102 decicycles in sbr_dequant,1023 runs, 1 skips
>> 19002 decicycles in sbr_dequant,2045 runs, 3 skips
>> 17638 decicycles in sbr_dequant,4093 runs, 3 skips
>> 15825 decicycles in sbr_dequant,8189 runs, 3 skips
>> 16404 decicycles in sbr_dequant, 16379 runs, 5 skips
>>
>> new:
>>3063 decicycles in sbr_dequant,1024 runs, 0 skips
>>3049 decicycles in sbr_dequant,2048 runs, 0 skips
>>2968 decicycles in sbr_dequant,4096 runs, 0 skips
>>2818 decicycles in sbr_dequant,8191 runs, 1 skips
>>2853 decicycles in sbr_dequant, 16383 runs, 1 skips
>>
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavcodec/aacsbr.c | 34 ++
>> 1 file changed, 22 insertions(+), 12 deletions(-)
>>
>> diff --git a/libavcodec/aacsbr.c b/libavcodec/aacsbr.c
>> index d1e3a91..15956e3 100644
>> --- a/libavcodec/aacsbr.c
>> +++ b/libavcodec/aacsbr.c
>> @@ -33,6 +33,7 @@
>> #include "aacsbrdata.h"
>> #include "aacsbr_tablegen.h"
>> #include "fft.h"
>> +#include "internal.h"
>> #include "aacps.h"
>> #include "sbrdsp.h"
>> #include "libavutil/internal.h"
>> @@ -73,15 +74,22 @@ static void sbr_dequant(SpectralBandReplication *sbr,
>> int id_aac)
>> {
>> int k, e;
>> int ch;
>> -
>> +static const double exp2_tab[2] = {1, M_SQRT2};
>> if (id_aac == TYPE_CPE && sbr->bs_coupling) {
>> -float alpha = sbr->data[0].bs_amp_res ? 1.0f : 0.5f;
>> -float pan_offset = sbr->data[0].bs_amp_res ? 12.0f : 24.0f;
>> +int pan_offset = sbr->data[0].bs_amp_res ? 12 : 24;
>> for (e = 1; e <= sbr->data[0].bs_num_env; e++) {
>> for (k = 0; k < sbr->n[sbr->data[0].bs_freq_res[e]]; k++) {
>> -float temp1 = exp2f(sbr->data[0].env_facs_q[e][k] * alpha +
>> 7.0f);
>> -float temp2 = exp2f((pan_offset -
>> sbr->data[1].env_facs_q[e][k]) * alpha);
>> -float fac;
>> +float temp1, temp2, fac;
>> +if (sbr->data[0].bs_amp_res) {
>> +temp1 = ff_exp2fi(sbr->data[0].env_facs_q[e][k] + 7);
>> +temp2 = ff_exp2fi(pan_offset -
>> sbr->data[1].env_facs_q[e][k]);
>> +}
>> +else {
>> +temp1 = ff_exp2fi((sbr->data[0].env_facs_q[e][k]>>1) +
>> 7) *
>> +exp2_tab[sbr->data[0].env_facs_q[e][k] & 1];
>> +temp2 = ff_exp2fi((pan_offset -
>> sbr->data[1].env_facs_q[e][k])>>1) *
>> +exp2_tab[(pan_offset -
>> sbr->data[1].env_facs_q[e][k]) & 1];
>> +}
>> if (temp1 > 1E20) {
>> av_log(NULL, AV_LOG_ERROR, "envelope scalefactor
>> overflow in dequant\n");
>> temp1 = 1;
>> @@ -93,8 +101,8 @@ static void sbr_dequant(SpectralBandReplication *sbr, int
>> id_aac)
>> }
>> for (e = 1; e <= sbr->data[0].bs_num_noise; e++) {
>> for (k = 0; k < sbr->n_q; k++) {
>> -float temp1 = exp2f(NOISE_FLOOR_OFFSET -
>> sbr->data[0].noise_facs_q[e][k] + 1);
>> -float temp2 = exp2f(12 - sbr->data[1].noise_facs_q[e][k]);
>> +float temp1 = ff_exp2fi(NOISE_FLOOR_OFFSET -
>> sbr->data[0].noise_facs_q[e][k] + 1);
>> +float temp2 = ff_exp2fi(12 -
>> sbr->data[1].noise_facs_q[e][k]);
>> float fac;
>> av_assert0(temp1 <= 1E20);
>> fac = temp1 / (1.0f + temp2);
>> @@ -104,11 +112,13 @@ static void sbr_dequant(SpectralBandReplication *sbr,
>> int id_aac)
>> }
>> } else { // SCE or one non-coupled CPE
>> for (ch = 0; ch < (id_aac == TYPE_CPE) + 1; ch++) {
>> -float alpha = sbr->data[ch].bs_amp_res ? 1.0f : 0.5f;
>> for (e = 1; e <= sbr->data[ch].bs_num_env; e++)
>> for (k = 0; k < sbr->n[sbr->data[ch].bs_freq_res[e]]; k++){
>> -sbr->data[ch].env_facs[e][k] =
>> -exp2f(alpha * sbr->data[ch].env_facs_q[e][k] +
>> 6.0f);
>> +if (sbr->data[ch].bs_amp_res)
>> +sbr->data[ch].env_facs[e][k] =
>> ff_exp2fi(sbr->data[ch].env_facs_q[e][k] + 6);
>> +else
>> +sbr->data[ch].env_facs[e][k] =
>> ff_exp2fi((sbr->data[ch].env_facs_q[e][k]>>1) + 6)
>> + *
>> exp2_tab[sbr->data[ch].env_facs_q[e][k] & 1];
>> if (sbr->data[ch].env_facs[e][k] > 1E20) {
>> av_log(NULL, AV_LOG_ERROR, "envelope scalefactor
>> overflow in dequant\n");
>>
Re: [FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}
On Sat, Dec 19, 2015 at 11:50:21AM +0100, Michael Niedermayer wrote:
> On Sat, Dec 19, 2015 at 10:56:26AM +0100, Matthieu Bouron wrote:
> > On Sat, Dec 19, 2015 at 03:24:17AM +0100, Michael Niedermayer wrote:
> > > On Fri, Dec 18, 2015 at 04:33:37PM +0100, Matthieu Bouron wrote:
> > > > On Fri, Dec 18, 2015 at 3:59 PM, Matthieu Bouron
> > > >
> > > > wrote:
> > > >
> > > > > From: Matthieu Bouron
> > > > >
> > > > > ---
> > > > > libswscale/arm/swscale_unscaled.c | 52 +++---
> > > > > libswscale/arm/yuv2rgb_neon.S | 77
> > > > > ---
> > > > > 2 files changed, 118 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/libswscale/arm/swscale_unscaled.c
> > > > > b/libswscale/arm/swscale_unscaled.c
> > > > > index 8aa6432..dce987e 100644
> > > > > --- a/libswscale/arm/swscale_unscaled.c
> > > > > +++ b/libswscale/arm/swscale_unscaled.c
> > > > > @@ -63,6 +63,50 @@ static int rgbx_to_nv12_neon_16_wrapper(SwsContext
> > > > > *context, const uint8_t *src[
> > > > > }
> > > > > #endif
> > > > >
> > > > > +#define YUV_TO_RGB_TABLE(precision)
> > > > >\
> > > > > +c->yuv2rgb_v2r_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > > \
> > > > > +c->yuv2rgb_u2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > > \
> > > > > +c->yuv2rgb_v2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > > \
> > > > > +c->yuv2rgb_u2b_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > > \
> > > > > +
> > > > > +#define DECLARE_FF_YUV420P_TO_RGBX_FUNCS(ofmt, precision)
> > > > >\
> > > > > +int ff_yuv420p_to_##ofmt##_neon_##precision(int w, int h,
> > > > >\
> > > > > + uint8_t *dst, int linesize,
> > > > > \
> > > > > + const uint8_t *srcY, int linesizeY,
> > > > > \
> > > > > + const uint8_t *srcU, int linesizeU,
> > > > > \
> > > > > + const uint8_t *srcV, int linesizeV,
> > > > > \
> > > > > + const int16_t *table,
> > > > > \
> > > > > + int y_offset,
> > > > > \
> > > > > + int y_coeff);
> > > > > \
> > > > > +
> > > > > \
> > > > > +static int yuv420p_to_##ofmt##_neon_wrapper_##precision(SwsContext
> > > > > *c,
> > > > > const uint8_t *src[],\
> > > > > + int srcStride[], int
> > > > > srcSliceY, int srcSliceH, \
> > > > > + uint8_t *dst[], int
> > > > > dstStride[]) { \
> > > > > +const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE(precision) };
> > > > > \
> > > > > +
> > > > > \
> > > > > +ff_yuv420p_to_##ofmt##_neon_##precision(c->srcW, srcSliceH,
> > > > >\
> > > > > + dst[0] + srcSliceY *
> > > > > dstStride[0],
> > > > > dstStride[0], \
> > > > > + src[0] + srcSliceY *
> > > > > srcStride[0],
> > > > > srcStride[0], \
> > > > > + src[1] + (srcSliceY / 2) *
> > > > > srcStride[1],
> > > > > srcStride[1], \
> > > > > + src[2] + (srcSliceY / 2) *
> > > > > srcStride[2],
> > > > > srcStride[2], \
> > > > > + yuv2rgb_table,
> > > > >\
> > > > > + c->yuv2rgb_y_offset >> 9,
> > > > > \
> > > > > + c->yuv2rgb_y_coeff / ((precision)
> > > > > == 16
> > > > > ? 1 << 7 : 1));\
> > > > > +
> > > > > \
> > > > > +return 0;
> > > > >\
> > > > > +}
> > > > >\
> > > > > +
> > > > > +#define DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(precision)
> > > > >\
> > > > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(argb, precision)
> > > > >\
> > > > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(rgba, precision)
> > > > >\
> > > > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(abgr, precision)
> > > > >\
> > > > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(bgra, precision)
> > > > >\
> > > > > +
> > > > > +#define DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS
> > > > > \
> > > > > +DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(16)
> > > > > \
> > > > > +
> > > > > +DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS
> > > > > +
> > > > > #define DECLARE_FF_NVX_TO_RGBX_FUNCS(ifmt, ofmt, precision)
> > > > >\
> > > > > int ff_##i
Re: [FFmpeg-devel] [PATCH] nutdec: reject negative sm_size
On Sat, Dec 19, 2015 at 12:19:44PM +0100, Andreas Cadhalpun wrote:
> On 19.12.2015 01:51, Michael Niedermayer wrote:
> > On Fri, Dec 18, 2015 at 05:22:31PM +0100, Andreas Cadhalpun wrote:
> >> If it is negative, it makes size larger than the size of the packet
> >> buffer, causing invalid writes in avio_read.
> >>
> >> Signed-off-by: Andreas Cadhalpun
> >> ---
> >> libavformat/nutdec.c | 5 +
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
> >> index 286d1ee..47ae7a7 100644
> >> --- a/libavformat/nutdec.c
> >> +++ b/libavformat/nutdec.c
> >> @@ -1146,6 +1146,11 @@ static int decode_frame(NUTContext *nut, AVPacket
> >> *pkt, int frame_code)
> >> goto fail;
> >> }
> >> sm_size = avio_tell(bc) - pkt->pos;
> >> +if (sm_size < 0) {
> >
> > did sm_size overflow and should be 64bit ?
>
> No.
>
> > did the byte position (avio_tell) move backward ?
>
> Yes.
>
> > (this should not happen)
>
> In that case, the check needs to be moved to read_sm_data.
> Patch doing that is attached.
>
> Best regards,
> Andreas
>
> nutdec.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 2f0ac251ee05a8a36ffbaec5a9d5346ac0ef4240
> 0001-nutdec-reject-negative-value_len-in-read_sm_data.patch
> From bdca159087d426f5f989656a08464fec967b4bc3 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun
> Date: Sat, 19 Dec 2015 12:02:56 +0100
> Subject: [PATCH] nutdec: reject negative value_len in read_sm_data
>
> If it is negative, it can cause the byte position to move backwards in
> avio_skip, which in turn makes sm_size negative and thus size larger
> than the size of the packet buffer, causing invalid writes in avio_read.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/nutdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
> index 286d1ee..b33b3e2 100644
> --- a/libavformat/nutdec.c
> +++ b/libavformat/nutdec.c
> @@ -934,7 +934,7 @@ static int read_sm_data(AVFormatContext *s, AVIOContext
> *bc, AVPacket *pkt, int
> return ret;
> }
> value_len = ffio_read_varlen(bc);
> -if (avio_tell(bc) + value_len >= maxpos)
> +if (value_len < 0 || avio_tell(bc) + value_len >= maxpos)
> return AVERROR_INVALIDDATA;
ok, also while at it please fix avio_tell(bc) + value_len, which i
belive can overflow
you could alternatively change value_len to uint64_t which might
simplify the check
[...]
--
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] [libav-devel] [PATCH] xwddec: prevent overflow of lsize * avctx->height
On Sat, Dec 19, 2015 at 12:17:42PM +0100, Andreas Cadhalpun wrote: > On 19.12.2015 01:32, Michael Niedermayer wrote: > > On Fri, Dec 18, 2015 at 08:13:06PM +0100, Andreas Cadhalpun wrote: > >> xwddec.c |6 ++ > >> 1 file changed, 6 insertions(+) > >> 0be27d89a669445b523bfdac99884065e3581f3c > >> 0001-xwddec-prevent-overflow-of-lsize-avctx-height.patch > >> From fb40616d7b432680b92dc3adc44a5b5d12fac55d Mon Sep 17 00:00:00 2001 > >> From: Andreas Cadhalpun > >> Date: Fri, 18 Dec 2015 19:28:51 +0100 > >> Subject: [PATCH] xwddec: prevent overflow of lsize * avctx->height > >> > >> This is used to check if the input buffer is larger enough, so if this > >> overflows it can cause a false negative leading to a segmentation fault > >> in bytestream2_get_bufferu. > > > > cant the addition overflow too in the input buffer check ? > > Probably. > > > if so then using 64bit in the input buffer check would avoid the > > need for a explicit check on lsize > > Indeed, that's simpler. New patch attached. LGTM thx [...] -- 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] nutdec: reject negative sm_size
On 19.12.2015 13:58, Michael Niedermayer wrote:
> On Sat, Dec 19, 2015 at 12:19:44PM +0100, Andreas Cadhalpun wrote:
>> On 19.12.2015 01:51, Michael Niedermayer wrote:
>>> On Fri, Dec 18, 2015 at 05:22:31PM +0100, Andreas Cadhalpun wrote:
If it is negative, it makes size larger than the size of the packet
buffer, causing invalid writes in avio_read.
Signed-off-by: Andreas Cadhalpun
---
libavformat/nutdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
index 286d1ee..47ae7a7 100644
--- a/libavformat/nutdec.c
+++ b/libavformat/nutdec.c
@@ -1146,6 +1146,11 @@ static int decode_frame(NUTContext *nut, AVPacket
*pkt, int frame_code)
goto fail;
}
sm_size = avio_tell(bc) - pkt->pos;
+if (sm_size < 0) {
>>>
>>> did sm_size overflow and should be 64bit ?
>>
>> No.
>>
>>> did the byte position (avio_tell) move backward ?
>>
>> Yes.
>>
>>> (this should not happen)
>>
>> In that case, the check needs to be moved to read_sm_data.
>> Patch doing that is attached.
>>
>> Best regards,
>> Andreas
>>
>
>> nutdec.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 2f0ac251ee05a8a36ffbaec5a9d5346ac0ef4240
>> 0001-nutdec-reject-negative-value_len-in-read_sm_data.patch
>> From bdca159087d426f5f989656a08464fec967b4bc3 Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun
>> Date: Sat, 19 Dec 2015 12:02:56 +0100
>> Subject: [PATCH] nutdec: reject negative value_len in read_sm_data
>>
>> If it is negative, it can cause the byte position to move backwards in
>> avio_skip, which in turn makes sm_size negative and thus size larger
>> than the size of the packet buffer, causing invalid writes in avio_read.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/nutdec.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
>> index 286d1ee..b33b3e2 100644
>> --- a/libavformat/nutdec.c
>> +++ b/libavformat/nutdec.c
>> @@ -934,7 +934,7 @@ static int read_sm_data(AVFormatContext *s, AVIOContext
>> *bc, AVPacket *pkt, int
>> return ret;
>> }
>> value_len = ffio_read_varlen(bc);
>> -if (avio_tell(bc) + value_len >= maxpos)
>> +if (value_len < 0 || avio_tell(bc) + value_len >= maxpos)
>> return AVERROR_INVALIDDATA;
>
> ok, also while at it please fix avio_tell(bc) + value_len, which i
> belive can overflow
OK, updated patch attached.
> you could alternatively change value_len to uint64_t which might
> simplify the check
It wouldn't help, because either avio_tell(bc) + value_len can be too large
or maxpos - avio_tell(bc) negative, which would be treated as a large
unsigned value, if value_len is unsigned.
Best regards,
Andreas
>From 98fc98ce850d4d7fce30ee653dd48c063f0eaae6 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Sat, 19 Dec 2015 12:02:56 +0100
Subject: [PATCH] nutdec: reject negative value_len in read_sm_data
If it is negative, it can cause the byte position to move backwards in
avio_skip, which in turn makes sm_size negative and thus size larger
than the size of the packet buffer, causing invalid writes in avio_read.
Also fix potential overflow of avio_tell(bc) + value_len.
Signed-off-by: Andreas Cadhalpun
---
libavformat/nutdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
index ef08ad9..4df6a57 100644
--- a/libavformat/nutdec.c
+++ b/libavformat/nutdec.c
@@ -934,7 +934,7 @@ static int read_sm_data(AVFormatContext *s, AVIOContext *bc, AVPacket *pkt, int
return ret;
}
value_len = ffio_read_varlen(bc);
-if (avio_tell(bc) + value_len >= maxpos)
+if (value_len < 0 || value_len >= maxpos - avio_tell(bc))
return AVERROR_INVALIDDATA;
if (!strcmp(name, "Palette")) {
dst = av_packet_new_side_data(pkt, AV_PKT_DATA_PALETTE, value_len);
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: remove existing AVPicture usage
On Fri, 18 Dec 2015, Paul B Mahol wrote: On 12/18/15, Marton Balint wrote: It is deprecated. Signed-off-by: Marton Balint --- ffplay.c | 51 +++ 1 file changed, 27 insertions(+), 24 deletions(-) lgtm Pushed. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] xwddec: prevent overflow of lsize * avctx->height
On 19.12.2015 14:23, Michael Niedermayer wrote: > On Sat, Dec 19, 2015 at 12:17:42PM +0100, Andreas Cadhalpun wrote: >> On 19.12.2015 01:32, Michael Niedermayer wrote: >>> On Fri, Dec 18, 2015 at 08:13:06PM +0100, Andreas Cadhalpun wrote: xwddec.c |6 ++ 1 file changed, 6 insertions(+) 0be27d89a669445b523bfdac99884065e3581f3c 0001-xwddec-prevent-overflow-of-lsize-avctx-height.patch From fb40616d7b432680b92dc3adc44a5b5d12fac55d Mon Sep 17 00:00:00 2001 From: Andreas Cadhalpun Date: Fri, 18 Dec 2015 19:28:51 +0100 Subject: [PATCH] xwddec: prevent overflow of lsize * avctx->height This is used to check if the input buffer is larger enough, so if this overflows it can cause a false negative leading to a segmentation fault in bytestream2_get_bufferu. >>> >>> cant the addition overflow too in the input buffer check ? >> >> Probably. >> >>> if so then using 64bit in the input buffer check would avoid the >>> need for a explicit check on lsize >> >> Indeed, that's simpler. New patch attached. > > LGTM Pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add copysign hack
Hi,
On Fri, Dec 18, 2015 at 3:47 PM, Ganesh Ajjanagadde
wrote:
> On Fri, Dec 18, 2015 at 12:41 PM, Ronald S. Bultje
> wrote:
> > Hi,
> >
> > On Fri, Dec 18, 2015 at 2:18 PM, Ganesh Ajjanagadde <
> gajjanaga...@gmail.com>
> > wrote:
> >>
> >> For systems with broken libms.
> >> Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular double x
> and
> >> combinations of these.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde
> >> ---
> >> configure| 2 +-
> >> libavutil/libm.h | 9 +
> >> 2 files changed, 10 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/configure b/configure
> >> index 123d1df..7917386 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl"
> >> delogo_filter_deps="gpl"
> >> deshake_filter_select="pixelutils"
> >> drawtext_filter_deps="libfreetype"
> >> -dynaudnorm_filter_deps="copysign erf"
> >> +dynaudnorm_filter_deps="erf"
> >> ebur128_filter_deps="gpl"
> >> eq_filter_deps="gpl"
> >> fftfilt_filter_deps="avcodec"
> >> diff --git a/libavutil/libm.h b/libavutil/libm.h
> >> index 6d8bd68..637de19 100644
> >> --- a/libavutil/libm.h
> >> +++ b/libavutil/libm.h
> >> @@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x)
> >> }
> >> #endif
> >>
> >> +#if !HAVE_COPYSIGN
> >> +static av_always_inline double copysign(double x, double y)
> >> +{
> >> +uint64_t vx = av_double2int(x);
> >> +uint64_t vy = av_double2int(y);
> >> +return av_int2double((vx & 0x7fff) | (vy &
> >> 0x8000));
> >> +}
> >> +#endif
> >
> >
> > Don't these need type suffixes (e.g. UINT64_C(val)) on some systems?
>
> I believe not, see
> http://en.cppreference.com/w/cpp/language/integer_literal
That document confirms that it is indeed legal for a compiler to read the
given literal on a 32bit or windows 64bit system as a 32bit max value, and
your literals don't fit in 32bit. Indeed, we have indeed historically seen
that UINT64_C is primarily required to silence warnings and fix problems on
earlier releases of msvc, which are still supported (although not
necessarily recommended).
and a long
> discussion at libav-devel
> https://lists.libav.org/pipermail/libav-devel/2015-October/072866.html
> and related messages.
I don't see anything in that email that suggests that we should not use
UINT64_C?
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] nutdec: reject negative sm_size
On Sat, Dec 19, 2015 at 02:25:42PM +0100, Andreas Cadhalpun wrote:
> On 19.12.2015 13:58, Michael Niedermayer wrote:
> > On Sat, Dec 19, 2015 at 12:19:44PM +0100, Andreas Cadhalpun wrote:
> >> On 19.12.2015 01:51, Michael Niedermayer wrote:
> >>> On Fri, Dec 18, 2015 at 05:22:31PM +0100, Andreas Cadhalpun wrote:
> If it is negative, it makes size larger than the size of the packet
> buffer, causing invalid writes in avio_read.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/nutdec.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
> index 286d1ee..47ae7a7 100644
> --- a/libavformat/nutdec.c
> +++ b/libavformat/nutdec.c
> @@ -1146,6 +1146,11 @@ static int decode_frame(NUTContext *nut, AVPacket
> *pkt, int frame_code)
> goto fail;
> }
> sm_size = avio_tell(bc) - pkt->pos;
> +if (sm_size < 0) {
> >>>
> >>> did sm_size overflow and should be 64bit ?
> >>
> >> No.
> >>
> >>> did the byte position (avio_tell) move backward ?
> >>
> >> Yes.
> >>
> >>> (this should not happen)
> >>
> >> In that case, the check needs to be moved to read_sm_data.
> >> Patch doing that is attached.
> >>
> >> Best regards,
> >> Andreas
> >>
> >
> >> nutdec.c |2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >> 2f0ac251ee05a8a36ffbaec5a9d5346ac0ef4240
> >> 0001-nutdec-reject-negative-value_len-in-read_sm_data.patch
> >> From bdca159087d426f5f989656a08464fec967b4bc3 Mon Sep 17 00:00:00 2001
> >> From: Andreas Cadhalpun
> >> Date: Sat, 19 Dec 2015 12:02:56 +0100
> >> Subject: [PATCH] nutdec: reject negative value_len in read_sm_data
> >>
> >> If it is negative, it can cause the byte position to move backwards in
> >> avio_skip, which in turn makes sm_size negative and thus size larger
> >> than the size of the packet buffer, causing invalid writes in avio_read.
> >>
> >> Signed-off-by: Andreas Cadhalpun
> >> ---
> >> libavformat/nutdec.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
> >> index 286d1ee..b33b3e2 100644
> >> --- a/libavformat/nutdec.c
> >> +++ b/libavformat/nutdec.c
> >> @@ -934,7 +934,7 @@ static int read_sm_data(AVFormatContext *s,
> >> AVIOContext *bc, AVPacket *pkt, int
> >> return ret;
> >> }
> >> value_len = ffio_read_varlen(bc);
> >> -if (avio_tell(bc) + value_len >= maxpos)
> >> +if (value_len < 0 || avio_tell(bc) + value_len >= maxpos)
> >> return AVERROR_INVALIDDATA;
> >
> > ok, also while at it please fix avio_tell(bc) + value_len, which i
> > belive can overflow
>
> OK, updated patch attached.
>
> > you could alternatively change value_len to uint64_t which might
> > simplify the check
>
> It wouldn't help, because either avio_tell(bc) + value_len can be too large
> or maxpos - avio_tell(bc) negative, which would be treated as a large
> unsigned value, if value_len is unsigned.
>
> Best regards,
> Andreas
>
> nutdec.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> d1813b6394c006a3f235e5e9a5fb8f5172933736
> 0001-nutdec-reject-negative-value_len-in-read_sm_data.patch
> From 98fc98ce850d4d7fce30ee653dd48c063f0eaae6 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun
> Date: Sat, 19 Dec 2015 12:02:56 +0100
> Subject: [PATCH] nutdec: reject negative value_len in read_sm_data
>
> If it is negative, it can cause the byte position to move backwards in
> avio_skip, which in turn makes sm_size negative and thus size larger
> than the size of the packet buffer, causing invalid writes in avio_read.
>
> Also fix potential overflow of avio_tell(bc) + value_len.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/nutdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
LGTM
thx
[...]
--
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 01/12] lavfi/vf_idet: replace round and cast by lrint
On Sat, Dec 19, 2015 at 2:45 AM, Michael Niedermayer wrote: > On Fri, Dec 18, 2015 at 09:45:27PM -0800, Ganesh Ajjanagadde wrote: >> lrint is faster and conveys the intent better here. It is safe as long int >> has >> at least 32 bits. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavfilter/vf_idet.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > half_life should be checked to be within the defined range of lrint() sorry, don't understand: exp2 of a negative number is always < 1, so the lrint operates on a number < PRECISION, which falls within lrint's range. > > should be ok otherwise > > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I know you won't believe me, but the highest form of Human Excellence is > to question oneself and others. -- Socrates > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add copysign hack
On Sat, Dec 19, 2015 at 6:26 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Dec 18, 2015 at 3:47 PM, Ganesh Ajjanagadde
> wrote:
>>
>> On Fri, Dec 18, 2015 at 12:41 PM, Ronald S. Bultje
>> wrote:
>> > Hi,
>> >
>> > On Fri, Dec 18, 2015 at 2:18 PM, Ganesh Ajjanagadde
>> >
>> > wrote:
>> >>
>> >> For systems with broken libms.
>> >> Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular double x
>> >> and
>> >> combinations of these.
>> >>
>> >> Signed-off-by: Ganesh Ajjanagadde
>> >> ---
>> >> configure| 2 +-
>> >> libavutil/libm.h | 9 +
>> >> 2 files changed, 10 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/configure b/configure
>> >> index 123d1df..7917386 100755
>> >> --- a/configure
>> >> +++ b/configure
>> >> @@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl"
>> >> delogo_filter_deps="gpl"
>> >> deshake_filter_select="pixelutils"
>> >> drawtext_filter_deps="libfreetype"
>> >> -dynaudnorm_filter_deps="copysign erf"
>> >> +dynaudnorm_filter_deps="erf"
>> >> ebur128_filter_deps="gpl"
>> >> eq_filter_deps="gpl"
>> >> fftfilt_filter_deps="avcodec"
>> >> diff --git a/libavutil/libm.h b/libavutil/libm.h
>> >> index 6d8bd68..637de19 100644
>> >> --- a/libavutil/libm.h
>> >> +++ b/libavutil/libm.h
>> >> @@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x)
>> >> }
>> >> #endif
>> >>
>> >> +#if !HAVE_COPYSIGN
>> >> +static av_always_inline double copysign(double x, double y)
>> >> +{
>> >> +uint64_t vx = av_double2int(x);
>> >> +uint64_t vy = av_double2int(y);
>> >> +return av_int2double((vx & 0x7fff) | (vy &
>> >> 0x8000));
>> >> +}
>> >> +#endif
>> >
>> >
>> > Don't these need type suffixes (e.g. UINT64_C(val)) on some systems?
>>
>> I believe not, see
>> http://en.cppreference.com/w/cpp/language/integer_literal
>
>
> That document confirms that it is indeed legal for a compiler to read the
> given literal on a 32bit or windows 64bit system as a 32bit max value, and
> your literals don't fit in 32bit.
How, the standard clearly says that the literal will be in the type
int < unsigned int < long int < unsigned long int < long long int <
unsigned long long int, wherever it first fits, and this is also clear
from the link I sent.
long long is at least 64 bits. I can't speak about broken
compilers/environments that lack long long.
> Indeed, we have indeed historically seen
> that UINT64_C is primarily required to silence warnings and fix problems on
> earlier releases of msvc, which are still supported (although not
> necessarily recommended).
>
>> and a long
>> discussion at libav-devel
>> https://lists.libav.org/pipermail/libav-devel/2015-October/072866.html
>> and related messages.
>
>
> I don't see anything in that email that suggests that we should not use
> UINT64_C?
Nothing wrong with it, but my whole point there was that UINT64_C
(advocated by Luca) was unnecessary - wm4's patch did not use it, Luca
claimed that was wrong, and I argued that it was fine.
>
> Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/12] lavfi/vf_idet: replace round and cast by lrint
On Sat, Dec 19, 2015 at 08:01:37AM -0800, Ganesh Ajjanagadde wrote: > On Sat, Dec 19, 2015 at 2:45 AM, Michael Niedermayer > wrote: > > On Fri, Dec 18, 2015 at 09:45:27PM -0800, Ganesh Ajjanagadde wrote: > >> lrint is faster and conveys the intent better here. It is safe as long int > >> has > >> at least 32 bits. > >> > >> Signed-off-by: Ganesh Ajjanagadde > >> --- > >> libavfilter/vf_idet.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > > half_life should be checked to be within the defined range of lrint() > > sorry, don't understand: exp2 of a negative number is always < 1, so > the lrint operates on a number < PRECISION, which falls within lrint's > range. right, sorry i misread the code the patch should be fine [...] -- 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] [PATCH 10/12] lavfi/vf_cropdetect: replace round by lrint
On Fri, Dec 18, 2015 at 09:45:36PM -0800, Ganesh Ajjanagadde wrote: > lrint is at least as fast, and more accurate. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavfilter/vf_cropdetect.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 06/12] lavf/hlsenc: replace round by lrint
On Fri, Dec 18, 2015 at 09:45:32PM -0800, Ganesh Ajjanagadde wrote: > Mainly cosmetic here. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavformat/hlsenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) 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] nutdec: reject negative sm_size
On 19.12.2015 16:25, Michael Niedermayer wrote: > On Sat, Dec 19, 2015 at 02:25:42PM +0100, Andreas Cadhalpun wrote: >> nutdec.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> d1813b6394c006a3f235e5e9a5fb8f5172933736 >> 0001-nutdec-reject-negative-value_len-in-read_sm_data.patch >> From 98fc98ce850d4d7fce30ee653dd48c063f0eaae6 Mon Sep 17 00:00:00 2001 >> From: Andreas Cadhalpun >> Date: Sat, 19 Dec 2015 12:02:56 +0100 >> Subject: [PATCH] nutdec: reject negative value_len in read_sm_data >> >> If it is negative, it can cause the byte position to move backwards in >> avio_skip, which in turn makes sm_size negative and thus size larger >> than the size of the packet buffer, causing invalid writes in avio_read. >> >> Also fix potential overflow of avio_tell(bc) + value_len. >> >> Signed-off-by: Andreas Cadhalpun >> --- >> libavformat/nutdec.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > LGTM Pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}
On Sat, Dec 19, 2015 at 01:28:06PM +0100, Matthieu Bouron wrote:
> On Sat, Dec 19, 2015 at 11:50:21AM +0100, Michael Niedermayer wrote:
> > On Sat, Dec 19, 2015 at 10:56:26AM +0100, Matthieu Bouron wrote:
> > > On Sat, Dec 19, 2015 at 03:24:17AM +0100, Michael Niedermayer wrote:
> > > > On Fri, Dec 18, 2015 at 04:33:37PM +0100, Matthieu Bouron wrote:
> > > > > On Fri, Dec 18, 2015 at 3:59 PM, Matthieu Bouron
> > > > >
> > > > > wrote:
> > > > >
> > > > > > From: Matthieu Bouron
> > > > > >
> > > > > > ---
> > > > > > libswscale/arm/swscale_unscaled.c | 52 +++---
> > > > > > libswscale/arm/yuv2rgb_neon.S | 77
> > > > > > ---
> > > > > > 2 files changed, 118 insertions(+), 11 deletions(-)
> > > > > >
> > > > > > diff --git a/libswscale/arm/swscale_unscaled.c
> > > > > > b/libswscale/arm/swscale_unscaled.c
> > > > > > index 8aa6432..dce987e 100644
> > > > > > --- a/libswscale/arm/swscale_unscaled.c
> > > > > > +++ b/libswscale/arm/swscale_unscaled.c
> > > > > > @@ -63,6 +63,50 @@ static int
> > > > > > rgbx_to_nv12_neon_16_wrapper(SwsContext
> > > > > > *context, const uint8_t *src[
> > > > > > }
> > > > > > #endif
> > > > > >
> > > > > > +#define YUV_TO_RGB_TABLE(precision)
> > > > > >\
> > > > > > +c->yuv2rgb_v2r_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > > > \
> > > > > > +c->yuv2rgb_u2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > > > \
> > > > > > +c->yuv2rgb_v2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > > > \
> > > > > > +c->yuv2rgb_u2b_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > > > \
> > > > > > +
> > > > > > +#define DECLARE_FF_YUV420P_TO_RGBX_FUNCS(ofmt, precision)
> > > > > >\
> > > > > > +int ff_yuv420p_to_##ofmt##_neon_##precision(int w, int h,
> > > > > >\
> > > > > > + uint8_t *dst, int linesize,
> > > > > > \
> > > > > > + const uint8_t *srcY, int
> > > > > > linesizeY,
> > > > > > \
> > > > > > + const uint8_t *srcU, int
> > > > > > linesizeU,
> > > > > > \
> > > > > > + const uint8_t *srcV, int
> > > > > > linesizeV,
> > > > > > \
> > > > > > + const int16_t *table,
> > > > > > \
> > > > > > + int y_offset,
> > > > > > \
> > > > > > + int y_coeff);
> > > > > > \
> > > > > > +
> > > > > > \
> > > > > > +static int yuv420p_to_##ofmt##_neon_wrapper_##precision(SwsContext
> > > > > > *c,
> > > > > > const uint8_t *src[],\
> > > > > > + int srcStride[], int
> > > > > > srcSliceY, int srcSliceH, \
> > > > > > + uint8_t *dst[], int
> > > > > > dstStride[]) { \
> > > > > > +const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE(precision)
> > > > > > };
> > > > > > \
> > > > > > +
> > > > > > \
> > > > > > +ff_yuv420p_to_##ofmt##_neon_##precision(c->srcW, srcSliceH,
> > > > > >\
> > > > > > + dst[0] + srcSliceY *
> > > > > > dstStride[0],
> > > > > > dstStride[0], \
> > > > > > + src[0] + srcSliceY *
> > > > > > srcStride[0],
> > > > > > srcStride[0], \
> > > > > > + src[1] + (srcSliceY / 2) *
> > > > > > srcStride[1],
> > > > > > srcStride[1], \
> > > > > > + src[2] + (srcSliceY / 2) *
> > > > > > srcStride[2],
> > > > > > srcStride[2], \
> > > > > > + yuv2rgb_table,
> > > > > >\
> > > > > > + c->yuv2rgb_y_offset >> 9,
> > > > > > \
> > > > > > + c->yuv2rgb_y_coeff / ((precision)
> > > > > > == 16
> > > > > > ? 1 << 7 : 1));\
> > > > > > +
> > > > > > \
> > > > > > +return 0;
> > > > > >\
> > > > > > +}
> > > > > >\
> > > > > > +
> > > > > > +#define DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(precision)
> > > > > >\
> > > > > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(argb, precision)
> > > > > >\
> > > > > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(rgba, precision)
> > > > > >\
> > > > > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(abgr, precision)
> > > > > >\
> > > > > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(bgra, precision)
> > > > > >\
> > > > > > +
> > > > > > +#define DECLARE_FF_YUV420P_TO_ALL_
[FFmpeg-devel] [PATCH] mpegvideo: validate block_last_index before dct_unquantize_intra
If it is negative, it triggers the assertion in
dct_unquantize_h263_intra.
This is somehow related to the second hunk of commit 9251942: reverting
that prevents these crashes, but breaks the sample from ticket 302.
Signed-off-by: Andreas Cadhalpun
---
Note that the sample from ticket 302 is currently broken anyway, printing
lots of "slice end not reached but screenspace end" errors.
This still works fine with ffmpeg 2.8.
---
libavcodec/mpegvideo.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 6d9e265..e8e54ff 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -2402,6 +2402,10 @@ unhandled:
static inline void put_dct(MpegEncContext *s,
int16_t *block, int i, uint8_t *dest, int
line_size, int qscale)
{
+if (s->block_last_index[i] < 0) {
+av_log(s->avctx, AV_LOG_WARNING, "Invalid block_last_index in
put_dct.\n");
+return;
+}
s->dct_unquantize_intra(s, block, i, qscale);
s->idsp.idct_put(dest, line_size, block);
}
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavc/aacsbr: sbr_dequant optimization
On Sat, Dec 19, 2015 at 4:21 AM, Andreas Cadhalpun
wrote:
> On 18.12.2015 16:52, Ganesh Ajjanagadde wrote:
>> On Tue, Dec 15, 2015 at 9:53 PM, Ganesh Ajjanagadde
>> wrote:
>>> This uses ff_exp2fi to get a speedup (~ 6x).
>>>
>>> sample benchmark (Haswell, GNU/Linux):
>>> old:
>>> 19102 decicycles in sbr_dequant,1023 runs, 1 skips
>>> 19002 decicycles in sbr_dequant,2045 runs, 3 skips
>>> 17638 decicycles in sbr_dequant,4093 runs, 3 skips
>>> 15825 decicycles in sbr_dequant,8189 runs, 3 skips
>>> 16404 decicycles in sbr_dequant, 16379 runs, 5 skips
>>>
>>> new:
>>>3063 decicycles in sbr_dequant,1024 runs, 0 skips
>>>3049 decicycles in sbr_dequant,2048 runs, 0 skips
>>>2968 decicycles in sbr_dequant,4096 runs, 0 skips
>>>2818 decicycles in sbr_dequant,8191 runs, 1 skips
>>>2853 decicycles in sbr_dequant, 16383 runs, 1 skips
>>>
>>> Signed-off-by: Ganesh Ajjanagadde
>>> ---
>>> libavcodec/aacsbr.c | 34 ++
>>> 1 file changed, 22 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/libavcodec/aacsbr.c b/libavcodec/aacsbr.c
>>> index d1e3a91..15956e3 100644
>>> --- a/libavcodec/aacsbr.c
>>> +++ b/libavcodec/aacsbr.c
>>> @@ -33,6 +33,7 @@
>>> #include "aacsbrdata.h"
>>> #include "aacsbr_tablegen.h"
>>> #include "fft.h"
>>> +#include "internal.h"
>>> #include "aacps.h"
>>> #include "sbrdsp.h"
>>> #include "libavutil/internal.h"
>>> @@ -73,15 +74,22 @@ static void sbr_dequant(SpectralBandReplication *sbr,
>>> int id_aac)
>>> {
>>> int k, e;
>>> int ch;
>>> -
>>> +static const double exp2_tab[2] = {1, M_SQRT2};
>>> if (id_aac == TYPE_CPE && sbr->bs_coupling) {
>>> -float alpha = sbr->data[0].bs_amp_res ? 1.0f : 0.5f;
>>> -float pan_offset = sbr->data[0].bs_amp_res ? 12.0f : 24.0f;
>>> +int pan_offset = sbr->data[0].bs_amp_res ? 12 : 24;
>>> for (e = 1; e <= sbr->data[0].bs_num_env; e++) {
>>> for (k = 0; k < sbr->n[sbr->data[0].bs_freq_res[e]]; k++) {
>>> -float temp1 = exp2f(sbr->data[0].env_facs_q[e][k] * alpha
>>> + 7.0f);
>>> -float temp2 = exp2f((pan_offset -
>>> sbr->data[1].env_facs_q[e][k]) * alpha);
>>> -float fac;
>>> +float temp1, temp2, fac;
>>> +if (sbr->data[0].bs_amp_res) {
>>> +temp1 = ff_exp2fi(sbr->data[0].env_facs_q[e][k] + 7);
>>> +temp2 = ff_exp2fi(pan_offset -
>>> sbr->data[1].env_facs_q[e][k]);
>>> +}
>>> +else {
>>> +temp1 = ff_exp2fi((sbr->data[0].env_facs_q[e][k]>>1) +
>>> 7) *
>>> +exp2_tab[sbr->data[0].env_facs_q[e][k] & 1];
>>> +temp2 = ff_exp2fi((pan_offset -
>>> sbr->data[1].env_facs_q[e][k])>>1) *
>>> +exp2_tab[(pan_offset -
>>> sbr->data[1].env_facs_q[e][k]) & 1];
>>> +}
>>> if (temp1 > 1E20) {
>>> av_log(NULL, AV_LOG_ERROR, "envelope scalefactor
>>> overflow in dequant\n");
>>> temp1 = 1;
>>> @@ -93,8 +101,8 @@ static void sbr_dequant(SpectralBandReplication *sbr,
>>> int id_aac)
>>> }
>>> for (e = 1; e <= sbr->data[0].bs_num_noise; e++) {
>>> for (k = 0; k < sbr->n_q; k++) {
>>> -float temp1 = exp2f(NOISE_FLOOR_OFFSET -
>>> sbr->data[0].noise_facs_q[e][k] + 1);
>>> -float temp2 = exp2f(12 - sbr->data[1].noise_facs_q[e][k]);
>>> +float temp1 = ff_exp2fi(NOISE_FLOOR_OFFSET -
>>> sbr->data[0].noise_facs_q[e][k] + 1);
>>> +float temp2 = ff_exp2fi(12 -
>>> sbr->data[1].noise_facs_q[e][k]);
>>> float fac;
>>> av_assert0(temp1 <= 1E20);
>>> fac = temp1 / (1.0f + temp2);
>>> @@ -104,11 +112,13 @@ static void sbr_dequant(SpectralBandReplication *sbr,
>>> int id_aac)
>>> }
>>> } else { // SCE or one non-coupled CPE
>>> for (ch = 0; ch < (id_aac == TYPE_CPE) + 1; ch++) {
>>> -float alpha = sbr->data[ch].bs_amp_res ? 1.0f : 0.5f;
>>> for (e = 1; e <= sbr->data[ch].bs_num_env; e++)
>>> for (k = 0; k < sbr->n[sbr->data[ch].bs_freq_res[e]]; k++){
>>> -sbr->data[ch].env_facs[e][k] =
>>> -exp2f(alpha * sbr->data[ch].env_facs_q[e][k] +
>>> 6.0f);
>>> +if (sbr->data[ch].bs_amp_res)
>>> +sbr->data[ch].env_facs[e][k] =
>>> ff_exp2fi(sbr->data[ch].env_facs_q[e][k] + 6);
>>> +else
>>> +sbr->data[ch].env_facs[e][k] =
>>> ff_exp2fi((sbr->data[ch].env_facs_q[e][k]>>1) + 6)
>>> + *
>>> exp2_tab[sbr->data[ch].env_facs_q[e][k] & 1];
>>> if
Re: [FFmpeg-devel] [PATCH 10/12] lavfi/vf_cropdetect: replace round by lrint
On Sat, Dec 19, 2015 at 8:47 AM, Michael Niedermayer wrote: > On Fri, Dec 18, 2015 at 09:45:36PM -0800, Ganesh Ajjanagadde wrote: >> lrint is at least as fast, and more accurate. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavfilter/vf_cropdetect.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > ok pushed, thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Dictatorship naturally arises out of democracy, and the most aggravated > form of tyranny and slavery out of the most extreme liberty. -- Plato > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 05/12] lavfi/vsrc_mandelbrot: replace round by lrint
On Sat, Dec 19, 2015 at 2:45 AM, Michael Niedermayer wrote: > On Fri, Dec 18, 2015 at 09:45:31PM -0800, Ganesh Ajjanagadde wrote: >> lrint is at least as fast, and is more accurate. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavfilter/vsrc_mandelbrot.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > LGTM > > thx pushed, thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 06/12] lavf/hlsenc: replace round by lrint
On Sat, Dec 19, 2015 at 8:54 AM, Michael Niedermayer wrote: > On Fri, Dec 18, 2015 at 09:45:32PM -0800, Ganesh Ajjanagadde wrote: >> Mainly cosmetic here. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavformat/hlsenc.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > should be ok pushed, thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No great genius has ever existed without some touch of madness. -- Aristotle > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/12] lavfi/vf_idet: replace round and cast by lrint
On Sat, Dec 19, 2015 at 8:24 AM, Michael Niedermayer wrote: > On Sat, Dec 19, 2015 at 08:01:37AM -0800, Ganesh Ajjanagadde wrote: >> On Sat, Dec 19, 2015 at 2:45 AM, Michael Niedermayer >> wrote: >> > On Fri, Dec 18, 2015 at 09:45:27PM -0800, Ganesh Ajjanagadde wrote: >> >> lrint is faster and conveys the intent better here. It is safe as long >> >> int has >> >> at least 32 bits. >> >> >> >> Signed-off-by: Ganesh Ajjanagadde >> >> --- >> >> libavfilter/vf_idet.c | 2 +- >> >> 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > half_life should be checked to be within the defined range of lrint() >> >> sorry, don't understand: exp2 of a negative number is always < 1, so >> the lrint operates on a number < PRECISION, which falls within lrint's >> range. > > right, sorry i misread the code > > the patch should be fine pushed, thanks > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Everything should be made as simple as possible, but not simpler. > -- Albert Einstein > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add copysign hack
On Sat, Dec 19, 2015 at 8:06 AM, Ganesh Ajjanagadde
wrote:
> On Sat, Dec 19, 2015 at 6:26 AM, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Fri, Dec 18, 2015 at 3:47 PM, Ganesh Ajjanagadde
>> wrote:
>>>
>>> On Fri, Dec 18, 2015 at 12:41 PM, Ronald S. Bultje
>>> wrote:
>>> > Hi,
>>> >
>>> > On Fri, Dec 18, 2015 at 2:18 PM, Ganesh Ajjanagadde
>>> >
>>> > wrote:
>>> >>
>>> >> For systems with broken libms.
>>> >> Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular double x
>>> >> and
>>> >> combinations of these.
>>> >>
>>> >> Signed-off-by: Ganesh Ajjanagadde
>>> >> ---
>>> >> configure| 2 +-
>>> >> libavutil/libm.h | 9 +
>>> >> 2 files changed, 10 insertions(+), 1 deletion(-)
>>> >>
>>> >> diff --git a/configure b/configure
>>> >> index 123d1df..7917386 100755
>>> >> --- a/configure
>>> >> +++ b/configure
>>> >> @@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl"
>>> >> delogo_filter_deps="gpl"
>>> >> deshake_filter_select="pixelutils"
>>> >> drawtext_filter_deps="libfreetype"
>>> >> -dynaudnorm_filter_deps="copysign erf"
>>> >> +dynaudnorm_filter_deps="erf"
>>> >> ebur128_filter_deps="gpl"
>>> >> eq_filter_deps="gpl"
>>> >> fftfilt_filter_deps="avcodec"
>>> >> diff --git a/libavutil/libm.h b/libavutil/libm.h
>>> >> index 6d8bd68..637de19 100644
>>> >> --- a/libavutil/libm.h
>>> >> +++ b/libavutil/libm.h
>>> >> @@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x)
>>> >> }
>>> >> #endif
>>> >>
>>> >> +#if !HAVE_COPYSIGN
>>> >> +static av_always_inline double copysign(double x, double y)
>>> >> +{
>>> >> +uint64_t vx = av_double2int(x);
>>> >> +uint64_t vy = av_double2int(y);
>>> >> +return av_int2double((vx & 0x7fff) | (vy &
>>> >> 0x8000));
>>> >> +}
>>> >> +#endif
>>> >
>>> >
>>> > Don't these need type suffixes (e.g. UINT64_C(val)) on some systems?
>>>
>>> I believe not, see
>>> http://en.cppreference.com/w/cpp/language/integer_literal
>>
>>
>> That document confirms that it is indeed legal for a compiler to read the
>> given literal on a 32bit or windows 64bit system as a 32bit max value, and
>> your literals don't fit in 32bit.
>
> How, the standard clearly says that the literal will be in the type
> int < unsigned int < long int < unsigned long int < long long int <
> unsigned long long int, wherever it first fits, and this is also clear
> from the link I sent.
>
> long long is at least 64 bits. I can't speak about broken
> compilers/environments that lack long long.
This turns out to be the heart of the matter; as usual, Microsoft's
toolchain is fundamentally broken:
https://stackoverflow.com/questions/25626022/how-should-a-64-bit-integer-literal-be-represented-in-c.
So later today I will push with the UINT64_C, in the absence of
further comments.
Thanks for the review.
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add copysign hack
On Sat, Dec 19, 2015 at 6:54 PM, Ganesh Ajjanagadde
wrote:
> On Sat, Dec 19, 2015 at 8:06 AM, Ganesh Ajjanagadde
> wrote:
>> On Sat, Dec 19, 2015 at 6:26 AM, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Fri, Dec 18, 2015 at 3:47 PM, Ganesh Ajjanagadde
>>> wrote:
On Fri, Dec 18, 2015 at 12:41 PM, Ronald S. Bultje
wrote:
> Hi,
>
> On Fri, Dec 18, 2015 at 2:18 PM, Ganesh Ajjanagadde
>
> wrote:
>>
>> For systems with broken libms.
>> Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular double x
>> and
>> combinations of these.
>>
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> configure| 2 +-
>> libavutil/libm.h | 9 +
>> 2 files changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index 123d1df..7917386 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl"
>> delogo_filter_deps="gpl"
>> deshake_filter_select="pixelutils"
>> drawtext_filter_deps="libfreetype"
>> -dynaudnorm_filter_deps="copysign erf"
>> +dynaudnorm_filter_deps="erf"
>> ebur128_filter_deps="gpl"
>> eq_filter_deps="gpl"
>> fftfilt_filter_deps="avcodec"
>> diff --git a/libavutil/libm.h b/libavutil/libm.h
>> index 6d8bd68..637de19 100644
>> --- a/libavutil/libm.h
>> +++ b/libavutil/libm.h
>> @@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x)
>> }
>> #endif
>>
>> +#if !HAVE_COPYSIGN
>> +static av_always_inline double copysign(double x, double y)
>> +{
>> +uint64_t vx = av_double2int(x);
>> +uint64_t vy = av_double2int(y);
>> +return av_int2double((vx & 0x7fff) | (vy &
>> 0x8000));
>> +}
>> +#endif
>
>
> Don't these need type suffixes (e.g. UINT64_C(val)) on some systems?
I believe not, see
http://en.cppreference.com/w/cpp/language/integer_literal
>>>
>>>
>>> That document confirms that it is indeed legal for a compiler to read the
>>> given literal on a 32bit or windows 64bit system as a 32bit max value, and
>>> your literals don't fit in 32bit.
>>
>> How, the standard clearly says that the literal will be in the type
>> int < unsigned int < long int < unsigned long int < long long int <
>> unsigned long long int, wherever it first fits, and this is also clear
>> from the link I sent.
>>
>> long long is at least 64 bits. I can't speak about broken
>> compilers/environments that lack long long.
>
> This turns out to be the heart of the matter; as usual, Microsoft's
> toolchain is fundamentally broken:
> https://stackoverflow.com/questions/25626022/how-should-a-64-bit-integer-literal-be-represented-in-c.
>
Its behavior would appear to be valid C90 on Windows, since long int
is 32-bit on that platform (which C90 calls for using, not long long)
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] decklink: support all valid numbers of audio channels
Am 18.12.2015 um 20:25 schrieb Matthias Hunstock: > Introduces new option. PS. I did not find any ressources on how to properly name new FFmpeg options, e.g. to be consistent. Using the existing "ac" option did not work. I would like to add some more features, like selection of video and/or audio input jack, to improve the coverage of the DeckLink API. I also have access to several different BM cards, so I can test things with real hardware. Regards Matthias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add copysign hack
On Sat, Dec 19, 2015 at 11:05 AM, Hendrik Leppkes wrote:
> On Sat, Dec 19, 2015 at 6:54 PM, Ganesh Ajjanagadde
> wrote:
>> On Sat, Dec 19, 2015 at 8:06 AM, Ganesh Ajjanagadde
>> wrote:
>>> On Sat, Dec 19, 2015 at 6:26 AM, Ronald S. Bultje
>>> wrote:
Hi,
On Fri, Dec 18, 2015 at 3:47 PM, Ganesh Ajjanagadde
wrote:
>
> On Fri, Dec 18, 2015 at 12:41 PM, Ronald S. Bultje
> wrote:
> > Hi,
> >
> > On Fri, Dec 18, 2015 at 2:18 PM, Ganesh Ajjanagadde
> >
> > wrote:
> >>
> >> For systems with broken libms.
> >> Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular double x
> >> and
> >> combinations of these.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde
> >> ---
> >> configure| 2 +-
> >> libavutil/libm.h | 9 +
> >> 2 files changed, 10 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/configure b/configure
> >> index 123d1df..7917386 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl"
> >> delogo_filter_deps="gpl"
> >> deshake_filter_select="pixelutils"
> >> drawtext_filter_deps="libfreetype"
> >> -dynaudnorm_filter_deps="copysign erf"
> >> +dynaudnorm_filter_deps="erf"
> >> ebur128_filter_deps="gpl"
> >> eq_filter_deps="gpl"
> >> fftfilt_filter_deps="avcodec"
> >> diff --git a/libavutil/libm.h b/libavutil/libm.h
> >> index 6d8bd68..637de19 100644
> >> --- a/libavutil/libm.h
> >> +++ b/libavutil/libm.h
> >> @@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x)
> >> }
> >> #endif
> >>
> >> +#if !HAVE_COPYSIGN
> >> +static av_always_inline double copysign(double x, double y)
> >> +{
> >> +uint64_t vx = av_double2int(x);
> >> +uint64_t vy = av_double2int(y);
> >> +return av_int2double((vx & 0x7fff) | (vy &
> >> 0x8000));
> >> +}
> >> +#endif
> >
> >
> > Don't these need type suffixes (e.g. UINT64_C(val)) on some systems?
>
> I believe not, see
> http://en.cppreference.com/w/cpp/language/integer_literal
That document confirms that it is indeed legal for a compiler to read the
given literal on a 32bit or windows 64bit system as a 32bit max value, and
your literals don't fit in 32bit.
>>>
>>> How, the standard clearly says that the literal will be in the type
>>> int < unsigned int < long int < unsigned long int < long long int <
>>> unsigned long long int, wherever it first fits, and this is also clear
>>> from the link I sent.
>>>
>>> long long is at least 64 bits. I can't speak about broken
>>> compilers/environments that lack long long.
>>
>> This turns out to be the heart of the matter; as usual, Microsoft's
>> toolchain is fundamentally broken:
>> https://stackoverflow.com/questions/25626022/how-should-a-64-bit-integer-literal-be-represented-in-c.
>>
>
> Its behavior would appear to be valid C90 on Windows, since long int
> is 32-bit on that platform (which C90 calls for using, not long long)
Yes, I meant broken wrt C99 (as seen in the link), which most of our
platforms have and use. Basically, I meant that their C99 support is
half-baked and broken (of course not news).
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpegvideo: validate block_last_index before dct_unquantize_intra
On Sat, Dec 19, 2015 at 06:13:37PM +0100, Andreas Cadhalpun wrote:
> If it is negative, it triggers the assertion in
> dct_unquantize_h263_intra.
>
> This is somehow related to the second hunk of commit 9251942: reverting
> that prevents these crashes, but breaks the sample from ticket 302.
>
> Signed-off-by: Andreas Cadhalpun
> ---
>
> Note that the sample from ticket 302 is currently broken anyway, printing
> lots of "slice end not reached but screenspace end" errors.
> This still works fine with ffmpeg 2.8.
>
> ---
> libavcodec/mpegvideo.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
> index 6d9e265..e8e54ff 100644
> --- a/libavcodec/mpegvideo.c
> +++ b/libavcodec/mpegvideo.c
> @@ -2402,6 +2402,10 @@ unhandled:
> static inline void put_dct(MpegEncContext *s,
> int16_t *block, int i, uint8_t *dest, int
> line_size, int qscale)
> {
> +if (s->block_last_index[i] < 0) {
> +av_log(s->avctx, AV_LOG_WARNING, "Invalid block_last_index in
> put_dct.\n");
> +return;
> +}
how does block_last_index become negative for this ?
this fix doesnt look correct put_dct() is too late to check for any
bitstream errors
[...]
--
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] [PATCH] mpegvideo: validate block_last_index before dct_unquantize_intra
On 19.12.2015 21:12, Michael Niedermayer wrote:
> On Sat, Dec 19, 2015 at 06:13:37PM +0100, Andreas Cadhalpun wrote:
>> If it is negative, it triggers the assertion in
>> dct_unquantize_h263_intra.
>>
>> This is somehow related to the second hunk of commit 9251942: reverting
>> that prevents these crashes, but breaks the sample from ticket 302.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>>
>> Note that the sample from ticket 302 is currently broken anyway, printing
>> lots of "slice end not reached but screenspace end" errors.
>> This still works fine with ffmpeg 2.8.
>>
>> ---
>> libavcodec/mpegvideo.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
>> index 6d9e265..e8e54ff 100644
>> --- a/libavcodec/mpegvideo.c
>> +++ b/libavcodec/mpegvideo.c
>> @@ -2402,6 +2402,10 @@ unhandled:
>> static inline void put_dct(MpegEncContext *s,
>> int16_t *block, int i, uint8_t *dest, int
>> line_size, int qscale)
>> {
>> +if (s->block_last_index[i] < 0) {
>> +av_log(s->avctx, AV_LOG_WARNING, "Invalid block_last_index in
>> put_dct.\n");
>> +return;
>> +}
>
> how does block_last_index become negative for this ?
It's set to -1 in mpeg4_decode_block.
> this fix doesnt look correct put_dct() is too late to check for any
> bitstream errors
Better ideas are very much welcome. :)
I can also send you a sample showing this problem.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add copysign hack
Hi,
On Sat, Dec 19, 2015 at 2:25 PM, Ganesh Ajjanagadde
wrote:
> On Sat, Dec 19, 2015 at 11:05 AM, Hendrik Leppkes
> wrote:
> > On Sat, Dec 19, 2015 at 6:54 PM, Ganesh Ajjanagadde
> > wrote:
> >> On Sat, Dec 19, 2015 at 8:06 AM, Ganesh Ajjanagadde
> >> wrote:
> >>> On Sat, Dec 19, 2015 at 6:26 AM, Ronald S. Bultje
> wrote:
> Hi,
>
> On Fri, Dec 18, 2015 at 3:47 PM, Ganesh Ajjanagadde <
> gajjanaga...@gmail.com>
> wrote:
> >
> > On Fri, Dec 18, 2015 at 12:41 PM, Ronald S. Bultje <
> rsbul...@gmail.com>
> > wrote:
> > > Hi,
> > >
> > > On Fri, Dec 18, 2015 at 2:18 PM, Ganesh Ajjanagadde
> > >
> > > wrote:
> > >>
> > >> For systems with broken libms.
> > >> Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular
> double x
> > >> and
> > >> combinations of these.
> > >>
> > >> Signed-off-by: Ganesh Ajjanagadde
> > >> ---
> > >> configure| 2 +-
> > >> libavutil/libm.h | 9 +
> > >> 2 files changed, 10 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/configure b/configure
> > >> index 123d1df..7917386 100755
> > >> --- a/configure
> > >> +++ b/configure
> > >> @@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl"
> > >> delogo_filter_deps="gpl"
> > >> deshake_filter_select="pixelutils"
> > >> drawtext_filter_deps="libfreetype"
> > >> -dynaudnorm_filter_deps="copysign erf"
> > >> +dynaudnorm_filter_deps="erf"
> > >> ebur128_filter_deps="gpl"
> > >> eq_filter_deps="gpl"
> > >> fftfilt_filter_deps="avcodec"
> > >> diff --git a/libavutil/libm.h b/libavutil/libm.h
> > >> index 6d8bd68..637de19 100644
> > >> --- a/libavutil/libm.h
> > >> +++ b/libavutil/libm.h
> > >> @@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x)
> > >> }
> > >> #endif
> > >>
> > >> +#if !HAVE_COPYSIGN
> > >> +static av_always_inline double copysign(double x, double y)
> > >> +{
> > >> +uint64_t vx = av_double2int(x);
> > >> +uint64_t vy = av_double2int(y);
> > >> +return av_int2double((vx & 0x7fff) | (vy &
> > >> 0x8000));
> > >> +}
> > >> +#endif
> > >
> > >
> > > Don't these need type suffixes (e.g. UINT64_C(val)) on some
> systems?
> >
> > I believe not, see
> > http://en.cppreference.com/w/cpp/language/integer_literal
>
>
> That document confirms that it is indeed legal for a compiler to read
> the
> given literal on a 32bit or windows 64bit system as a 32bit max
> value, and
> your literals don't fit in 32bit.
> >>>
> >>> How, the standard clearly says that the literal will be in the type
> >>> int < unsigned int < long int < unsigned long int < long long int <
> >>> unsigned long long int, wherever it first fits, and this is also clear
> >>> from the link I sent.
> >>>
> >>> long long is at least 64 bits. I can't speak about broken
> >>> compilers/environments that lack long long.
> >>
> >> This turns out to be the heart of the matter; as usual, Microsoft's
> >> toolchain is fundamentally broken:
> >>
> https://stackoverflow.com/questions/25626022/how-should-a-64-bit-integer-literal-be-represented-in-c
> .
> >>
> >
> > Its behavior would appear to be valid C90 on Windows, since long int
> > is 32-bit on that platform (which C90 calls for using, not long long)
>
> Yes, I meant broken wrt C99 (as seen in the link), which most of our
> platforms have and use. Basically, I meant that their C99 support is
> half-baked and broken (of course not news).
But FFmpeg isn't C99, see
https://ffmpeg.org/developer.html#C-language-features
"FFmpeg is programmed in the ISO C90 language with a few additional
features from ISO C99 [..]"
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/s302menc: set supported channel layouts by codec
Signed-off-by: Paul B Mahol
---
libavcodec/s302menc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/s302menc.c b/libavcodec/s302menc.c
index fbaa845..3706eba 100644
--- a/libavcodec/s302menc.c
+++ b/libavcodec/s302menc.c
@@ -175,4 +175,9 @@ AVCodec ff_s302m_encoder = {
AV_SAMPLE_FMT_NONE
},
.capabilities = AV_CODEC_CAP_VARIABLE_FRAME_SIZE |
AV_CODEC_CAP_EXPERIMENTAL,
.supported_samplerates = (const int[]) { 48000, 0 },
+.channel_layouts = (const uint64_t[]) { AV_CH_LAYOUT_STEREO,
+ AV_CH_LAYOUT_QUAD,
+ AV_CH_LAYOUT_5POINT1_BACK,
+ AV_CH_LAYOUT_5POINT1_BACK |
AV_CH_LAYOUT_STEREO_DOWNMIX,
+ 0 },
};
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpegvideo: validate block_last_index before dct_unquantize_intra
On Sat, Dec 19, 2015 at 09:19:27PM +0100, Andreas Cadhalpun wrote:
> On 19.12.2015 21:12, Michael Niedermayer wrote:
> > On Sat, Dec 19, 2015 at 06:13:37PM +0100, Andreas Cadhalpun wrote:
> >> If it is negative, it triggers the assertion in
> >> dct_unquantize_h263_intra.
> >>
> >> This is somehow related to the second hunk of commit 9251942: reverting
> >> that prevents these crashes, but breaks the sample from ticket 302.
> >>
> >> Signed-off-by: Andreas Cadhalpun
> >> ---
> >>
> >> Note that the sample from ticket 302 is currently broken anyway, printing
> >> lots of "slice end not reached but screenspace end" errors.
> >> This still works fine with ffmpeg 2.8.
> >>
> >> ---
> >> libavcodec/mpegvideo.c | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
> >> index 6d9e265..e8e54ff 100644
> >> --- a/libavcodec/mpegvideo.c
> >> +++ b/libavcodec/mpegvideo.c
> >> @@ -2402,6 +2402,10 @@ unhandled:
> >> static inline void put_dct(MpegEncContext *s,
> >> int16_t *block, int i, uint8_t *dest, int
> >> line_size, int qscale)
> >> {
> >> +if (s->block_last_index[i] < 0) {
> >> +av_log(s->avctx, AV_LOG_WARNING, "Invalid block_last_index in
> >> put_dct.\n");
> >> +return;
> >> +}
> >
> > how does block_last_index become negative for this ?
>
> It's set to -1 in mpeg4_decode_block.
>
> > this fix doesnt look correct put_dct() is too late to check for any
> > bitstream errors
>
> Better ideas are very much welcome. :)
> I can also send you a sample showing this problem.
please do
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/s302menc: check if buf_size can actually be put into 16bit size
This disallows creating unplayable audio.
Signed-off-by: Paul B Mahol
---
libavcodec/s302menc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/s302menc.c b/libavcodec/s302menc.c
index 3706eba..c703e9a 100644
--- a/libavcodec/s302menc.c
+++ b/libavcodec/s302menc.c
@@ -78,6 +78,11 @@ static int s302m_encode2_frame(AVCodecContext *avctx,
AVPacket *avpkt,
uint8_t *o;
PutBitContext pb;
+if (buf_size - AES3_HEADER_LEN > UINT16_MAX) {
+av_log(avctx, AV_LOG_ERROR, "number of samples in frame too big\n");
+return AVERROR(EINVAL);
+}
+
if ((ret = ff_alloc_packet2(avctx, avpkt, buf_size, 0)) < 0)
return ret;
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add copysign hack
On Sat, Dec 19, 2015 at 12:33 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Dec 19, 2015 at 2:25 PM, Ganesh Ajjanagadde
> wrote:
>
>> On Sat, Dec 19, 2015 at 11:05 AM, Hendrik Leppkes
>> wrote:
>> > On Sat, Dec 19, 2015 at 6:54 PM, Ganesh Ajjanagadde
>> > wrote:
>> >> On Sat, Dec 19, 2015 at 8:06 AM, Ganesh Ajjanagadde
>> >> wrote:
>> >>> On Sat, Dec 19, 2015 at 6:26 AM, Ronald S. Bultje
>> wrote:
>> Hi,
>>
>> On Fri, Dec 18, 2015 at 3:47 PM, Ganesh Ajjanagadde <
>> gajjanaga...@gmail.com>
>> wrote:
>> >
>> > On Fri, Dec 18, 2015 at 12:41 PM, Ronald S. Bultje <
>> rsbul...@gmail.com>
>> > wrote:
>> > > Hi,
>> > >
>> > > On Fri, Dec 18, 2015 at 2:18 PM, Ganesh Ajjanagadde
>> > >
>> > > wrote:
>> > >>
>> > >> For systems with broken libms.
>> > >> Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular
>> double x
>> > >> and
>> > >> combinations of these.
>> > >>
>> > >> Signed-off-by: Ganesh Ajjanagadde
>> > >> ---
>> > >> configure| 2 +-
>> > >> libavutil/libm.h | 9 +
>> > >> 2 files changed, 10 insertions(+), 1 deletion(-)
>> > >>
>> > >> diff --git a/configure b/configure
>> > >> index 123d1df..7917386 100755
>> > >> --- a/configure
>> > >> +++ b/configure
>> > >> @@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl"
>> > >> delogo_filter_deps="gpl"
>> > >> deshake_filter_select="pixelutils"
>> > >> drawtext_filter_deps="libfreetype"
>> > >> -dynaudnorm_filter_deps="copysign erf"
>> > >> +dynaudnorm_filter_deps="erf"
>> > >> ebur128_filter_deps="gpl"
>> > >> eq_filter_deps="gpl"
>> > >> fftfilt_filter_deps="avcodec"
>> > >> diff --git a/libavutil/libm.h b/libavutil/libm.h
>> > >> index 6d8bd68..637de19 100644
>> > >> --- a/libavutil/libm.h
>> > >> +++ b/libavutil/libm.h
>> > >> @@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x)
>> > >> }
>> > >> #endif
>> > >>
>> > >> +#if !HAVE_COPYSIGN
>> > >> +static av_always_inline double copysign(double x, double y)
>> > >> +{
>> > >> +uint64_t vx = av_double2int(x);
>> > >> +uint64_t vy = av_double2int(y);
>> > >> +return av_int2double((vx & 0x7fff) | (vy &
>> > >> 0x8000));
>> > >> +}
>> > >> +#endif
>> > >
>> > >
>> > > Don't these need type suffixes (e.g. UINT64_C(val)) on some
>> systems?
>> >
>> > I believe not, see
>> > http://en.cppreference.com/w/cpp/language/integer_literal
>>
>>
>> That document confirms that it is indeed legal for a compiler to read
>> the
>> given literal on a 32bit or windows 64bit system as a 32bit max
>> value, and
>> your literals don't fit in 32bit.
>> >>>
>> >>> How, the standard clearly says that the literal will be in the type
>> >>> int < unsigned int < long int < unsigned long int < long long int <
>> >>> unsigned long long int, wherever it first fits, and this is also clear
>> >>> from the link I sent.
>> >>>
>> >>> long long is at least 64 bits. I can't speak about broken
>> >>> compilers/environments that lack long long.
>> >>
>> >> This turns out to be the heart of the matter; as usual, Microsoft's
>> >> toolchain is fundamentally broken:
>> >>
>> https://stackoverflow.com/questions/25626022/how-should-a-64-bit-integer-literal-be-represented-in-c
>> .
>> >>
>> >
>> > Its behavior would appear to be valid C90 on Windows, since long int
>> > is 32-bit on that platform (which C90 calls for using, not long long)
>>
>> Yes, I meant broken wrt C99 (as seen in the link), which most of our
>> platforms have and use. Basically, I meant that their C99 support is
>> half-baked and broken (of course not news).
>
>
> But FFmpeg isn't C99, see
> https://ffmpeg.org/developer.html#C-language-features
>
> "FFmpeg is programmed in the ISO C90 language with a few additional
> features from ISO C99 [..]"
And what such features are is conveniently left vaguely specified, and
practically is dictated by the lowest common denominator, usually
MSVC...
These things really belong on IRC, as they have no bearing wrt the patch.
Whatever. Anyway, this is all off topic. I have my own opinions on
Microsoft's toolchain, they have not changed at all regardless.
Concretely, I am putting in the ridiculous UINT64_C, as I mentioned
way above in the thread, so there is no issue.
On this note, you may want to examine wm4's patch:
https://lists.libav.org/pipermail/libav-devel/2015-October/072852.html.
I know it is correct wrt proper toolchains, and I have zero interest
in whether or not it works correctly on MSVC.
>
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/f
Re: [FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}
On Sat, Dec 19, 2015 at 06:08:10PM +0100, Michael Niedermayer wrote:
> On Sat, Dec 19, 2015 at 01:28:06PM +0100, Matthieu Bouron wrote:
> > On Sat, Dec 19, 2015 at 11:50:21AM +0100, Michael Niedermayer wrote:
> > > On Sat, Dec 19, 2015 at 10:56:26AM +0100, Matthieu Bouron wrote:
> > > > On Sat, Dec 19, 2015 at 03:24:17AM +0100, Michael Niedermayer wrote:
> > > > > On Fri, Dec 18, 2015 at 04:33:37PM +0100, Matthieu Bouron wrote:
> > > > > > On Fri, Dec 18, 2015 at 3:59 PM, Matthieu Bouron
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > From: Matthieu Bouron
> > > > > > >
> > > > > > > ---
> > > > > > > libswscale/arm/swscale_unscaled.c | 52 +++---
> > > > > > > libswscale/arm/yuv2rgb_neon.S | 77
> > > > > > > ---
> > > > > > > 2 files changed, 118 insertions(+), 11 deletions(-)
> > > > > > >
> > > > > > > diff --git a/libswscale/arm/swscale_unscaled.c
> > > > > > > b/libswscale/arm/swscale_unscaled.c
> > > > > > > index 8aa6432..dce987e 100644
> > > > > > > --- a/libswscale/arm/swscale_unscaled.c
> > > > > > > +++ b/libswscale/arm/swscale_unscaled.c
> > > > > > > @@ -63,6 +63,50 @@ static int
> > > > > > > rgbx_to_nv12_neon_16_wrapper(SwsContext
> > > > > > > *context, const uint8_t *src[
> > > > > > > }
> > > > > > > #endif
> > > > > > >
> > > > > > > +#define YUV_TO_RGB_TABLE(precision)
> > > > > > >\
> > > > > > > +c->yuv2rgb_v2r_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > > > > \
> > > > > > > +c->yuv2rgb_u2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > > > > \
> > > > > > > +c->yuv2rgb_v2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > > > > \
> > > > > > > +c->yuv2rgb_u2b_coeff / ((precision) == 16 ? 1 << 7 : 1),
> > > > > > > \
> > > > > > > +
> > > > > > > +#define DECLARE_FF_YUV420P_TO_RGBX_FUNCS(ofmt, precision)
> > > > > > >\
> > > > > > > +int ff_yuv420p_to_##ofmt##_neon_##precision(int w, int h,
> > > > > > >\
> > > > > > > + uint8_t *dst, int linesize,
> > > > > > > \
> > > > > > > + const uint8_t *srcY, int
> > > > > > > linesizeY,
> > > > > > > \
> > > > > > > + const uint8_t *srcU, int
> > > > > > > linesizeU,
> > > > > > > \
> > > > > > > + const uint8_t *srcV, int
> > > > > > > linesizeV,
> > > > > > > \
> > > > > > > + const int16_t *table,
> > > > > > > \
> > > > > > > + int y_offset,
> > > > > > > \
> > > > > > > + int y_coeff);
> > > > > > > \
> > > > > > > +
> > > > > > > \
> > > > > > > +static int
> > > > > > > yuv420p_to_##ofmt##_neon_wrapper_##precision(SwsContext *c,
> > > > > > > const uint8_t *src[],\
> > > > > > > + int srcStride[], int
> > > > > > > srcSliceY, int srcSliceH, \
> > > > > > > + uint8_t *dst[], int
> > > > > > > dstStride[]) { \
> > > > > > > +const int16_t yuv2rgb_table[] = {
> > > > > > > YUV_TO_RGB_TABLE(precision) };
> > > > > > > \
> > > > > > > +
> > > > > > > \
> > > > > > > +ff_yuv420p_to_##ofmt##_neon_##precision(c->srcW, srcSliceH,
> > > > > > >\
> > > > > > > + dst[0] + srcSliceY *
> > > > > > > dstStride[0],
> > > > > > > dstStride[0], \
> > > > > > > + src[0] + srcSliceY *
> > > > > > > srcStride[0],
> > > > > > > srcStride[0], \
> > > > > > > + src[1] + (srcSliceY / 2) *
> > > > > > > srcStride[1],
> > > > > > > srcStride[1], \
> > > > > > > + src[2] + (srcSliceY / 2) *
> > > > > > > srcStride[2],
> > > > > > > srcStride[2], \
> > > > > > > + yuv2rgb_table,
> > > > > > >\
> > > > > > > + c->yuv2rgb_y_offset >> 9,
> > > > > > > \
> > > > > > > + c->yuv2rgb_y_coeff /
> > > > > > > ((precision) == 16
> > > > > > > ? 1 << 7 : 1));\
> > > > > > > +
> > > > > > > \
> > > > > > > +return 0;
> > > > > > >\
> > > > > > > +}
> > > > > > >\
> > > > > > > +
> > > > > > > +#define DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(precision)
> > > > > > >\
> > > > > > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(argb, precision)
> > > > > > >\
> > > > > > > +DECLARE_FF_YUV420P_TO_RGBX_FUNCS(rgba, precision)
> >
Re: [FFmpeg-devel] [PATCH 1/2] swscale/arm/yuv2rgb: disable neon if accurate_rnd is enabled
On Fri, Dec 18, 2015 at 03:59:45PM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> This disables the 32bit precision neon code path in favor of the
> default C one and avoids breaking fate if accurate_rnd is enabled.
> ---
> libswscale/arm/swscale_unscaled.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/libswscale/arm/swscale_unscaled.c
> b/libswscale/arm/swscale_unscaled.c
> index dbb0fb0..8aa6432 100644
> --- a/libswscale/arm/swscale_unscaled.c
> +++ b/libswscale/arm/swscale_unscaled.c
> @@ -101,7 +101,6 @@ DECLARE_FF_NVX_TO_RGBX_FUNCS(nvx, bgra, precision)
>
> #define DECLARE_FF_NVX_TO_ALL_RGBX_ALL_PRECISION_FUNCS(nvx)
>\
> DECLARE_FF_NVX_TO_ALL_RGBX_FUNCS(nvx, 16)
>\
> -DECLARE_FF_NVX_TO_ALL_RGBX_FUNCS(nvx, 32)
>\
>
> DECLARE_FF_NVX_TO_ALL_RGBX_ALL_PRECISION_FUNCS(nv12)
> DECLARE_FF_NVX_TO_ALL_RGBX_ALL_PRECISION_FUNCS(nv21)
> @@ -114,9 +113,9 @@ DECLARE_FF_NVX_TO_ALL_RGBX_ALL_PRECISION_FUNCS(nv21)
> if (c->srcFormat == AV_PIX_FMT_##IFMT
>\
> && c->dstFormat == AV_PIX_FMT_##OFMT
>\
> && !(c->srcH & 1)
>\
> -&& !(c->srcW & 15)) {
>\
> -c->swscale = (accurate_rnd) ? ifmt##_to_##ofmt##_neon_wrapper_32 :
>\
> - ifmt##_to_##ofmt##_neon_wrapper_16 ;
>\
> +&& !(c->srcW & 15)
>\
> +&& !accurate_rnd) {
>\
> +c->swscale = ifmt##_to_##ofmt##_neon_wrapper_16;
>\
> }
>\
> } while (0)
>
> --
> 2.6.4
>
Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add copysign hack
On Sat, Dec 19, 2015 at 12:33 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Dec 19, 2015 at 2:25 PM, Ganesh Ajjanagadde
> wrote:
>
>> On Sat, Dec 19, 2015 at 11:05 AM, Hendrik Leppkes
>> wrote:
>> > On Sat, Dec 19, 2015 at 6:54 PM, Ganesh Ajjanagadde
>> > wrote:
>> >> On Sat, Dec 19, 2015 at 8:06 AM, Ganesh Ajjanagadde
>> >> wrote:
>> >>> On Sat, Dec 19, 2015 at 6:26 AM, Ronald S. Bultje
>> wrote:
>> Hi,
>>
>> On Fri, Dec 18, 2015 at 3:47 PM, Ganesh Ajjanagadde <
>> gajjanaga...@gmail.com>
>> wrote:
>> >
>> > On Fri, Dec 18, 2015 at 12:41 PM, Ronald S. Bultje <
>> rsbul...@gmail.com>
>> > wrote:
>> > > Hi,
>> > >
>> > > On Fri, Dec 18, 2015 at 2:18 PM, Ganesh Ajjanagadde
>> > >
>> > > wrote:
>> > >>
>> > >> For systems with broken libms.
>> > >> Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular
>> double x
>> > >> and
>> > >> combinations of these.
>> > >>
>> > >> Signed-off-by: Ganesh Ajjanagadde
>> > >> ---
>> > >> configure| 2 +-
>> > >> libavutil/libm.h | 9 +
>> > >> 2 files changed, 10 insertions(+), 1 deletion(-)
>> > >>
>> > >> diff --git a/configure b/configure
>> > >> index 123d1df..7917386 100755
>> > >> --- a/configure
>> > >> +++ b/configure
>> > >> @@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl"
>> > >> delogo_filter_deps="gpl"
>> > >> deshake_filter_select="pixelutils"
>> > >> drawtext_filter_deps="libfreetype"
>> > >> -dynaudnorm_filter_deps="copysign erf"
>> > >> +dynaudnorm_filter_deps="erf"
>> > >> ebur128_filter_deps="gpl"
>> > >> eq_filter_deps="gpl"
>> > >> fftfilt_filter_deps="avcodec"
>> > >> diff --git a/libavutil/libm.h b/libavutil/libm.h
>> > >> index 6d8bd68..637de19 100644
>> > >> --- a/libavutil/libm.h
>> > >> +++ b/libavutil/libm.h
>> > >> @@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x)
>> > >> }
>> > >> #endif
>> > >>
>> > >> +#if !HAVE_COPYSIGN
>> > >> +static av_always_inline double copysign(double x, double y)
>> > >> +{
>> > >> +uint64_t vx = av_double2int(x);
>> > >> +uint64_t vy = av_double2int(y);
>> > >> +return av_int2double((vx & 0x7fff) | (vy &
>> > >> 0x8000));
>> > >> +}
>> > >> +#endif
>> > >
>> > >
>> > > Don't these need type suffixes (e.g. UINT64_C(val)) on some
>> systems?
>> >
>> > I believe not, see
>> > http://en.cppreference.com/w/cpp/language/integer_literal
>>
>>
>> That document confirms that it is indeed legal for a compiler to read
>> the
>> given literal on a 32bit or windows 64bit system as a 32bit max
>> value, and
>> your literals don't fit in 32bit.
>> >>>
>> >>> How, the standard clearly says that the literal will be in the type
>> >>> int < unsigned int < long int < unsigned long int < long long int <
>> >>> unsigned long long int, wherever it first fits, and this is also clear
>> >>> from the link I sent.
>> >>>
>> >>> long long is at least 64 bits. I can't speak about broken
>> >>> compilers/environments that lack long long.
>> >>
>> >> This turns out to be the heart of the matter; as usual, Microsoft's
>> >> toolchain is fundamentally broken:
>> >>
>> https://stackoverflow.com/questions/25626022/how-should-a-64-bit-integer-literal-be-represented-in-c
>> .
>> >>
>> >
>> > Its behavior would appear to be valid C90 on Windows, since long int
>> > is 32-bit on that platform (which C90 calls for using, not long long)
>>
>> Yes, I meant broken wrt C99 (as seen in the link), which most of our
>> platforms have and use. Basically, I meant that their C99 support is
>> half-baked and broken (of course not news).
>
>
> But FFmpeg isn't C99, see
> https://ffmpeg.org/developer.html#C-language-features
>
> "FFmpeg is programmed in the ISO C90 language with a few additional
> features from ISO C99 [..]"
A last comment to show the ridiculousness of it all: UINT64_C is
defined only in stdint.h, a C99 feature. Thus, if you want a "strict
C90" solution to this, there is none. In particular, using UINT64_C is
not "valid C90" on any platform.
It is just a happy accident that MSVC has UINT64_C.
>
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add copysign hack
On 12/19/15, Ganesh Ajjanagadde wrote:
> On Sat, Dec 19, 2015 at 12:33 PM, Ronald S. Bultje
> wrote:
>> Hi,
>>
>> On Sat, Dec 19, 2015 at 2:25 PM, Ganesh Ajjanagadde
>> wrote:
>>
>>> On Sat, Dec 19, 2015 at 11:05 AM, Hendrik Leppkes
>>> wrote:
>>> > On Sat, Dec 19, 2015 at 6:54 PM, Ganesh Ajjanagadde
>>> > wrote:
>>> >> On Sat, Dec 19, 2015 at 8:06 AM, Ganesh Ajjanagadde
>>> >> wrote:
>>> >>> On Sat, Dec 19, 2015 at 6:26 AM, Ronald S. Bultje
>>> >>>
>>> wrote:
>>> Hi,
>>>
>>> On Fri, Dec 18, 2015 at 3:47 PM, Ganesh Ajjanagadde <
>>> gajjanaga...@gmail.com>
>>> wrote:
>>> >
>>> > On Fri, Dec 18, 2015 at 12:41 PM, Ronald S. Bultje <
>>> rsbul...@gmail.com>
>>> > wrote:
>>> > > Hi,
>>> > >
>>> > > On Fri, Dec 18, 2015 at 2:18 PM, Ganesh Ajjanagadde
>>> > >
>>> > > wrote:
>>> > >>
>>> > >> For systems with broken libms.
>>> > >> Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular
>>> double x
>>> > >> and
>>> > >> combinations of these.
>>> > >>
>>> > >> Signed-off-by: Ganesh Ajjanagadde
>>> > >> ---
>>> > >> configure| 2 +-
>>> > >> libavutil/libm.h | 9 +
>>> > >> 2 files changed, 10 insertions(+), 1 deletion(-)
>>> > >>
>>> > >> diff --git a/configure b/configure
>>> > >> index 123d1df..7917386 100755
>>> > >> --- a/configure
>>> > >> +++ b/configure
>>> > >> @@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl"
>>> > >> delogo_filter_deps="gpl"
>>> > >> deshake_filter_select="pixelutils"
>>> > >> drawtext_filter_deps="libfreetype"
>>> > >> -dynaudnorm_filter_deps="copysign erf"
>>> > >> +dynaudnorm_filter_deps="erf"
>>> > >> ebur128_filter_deps="gpl"
>>> > >> eq_filter_deps="gpl"
>>> > >> fftfilt_filter_deps="avcodec"
>>> > >> diff --git a/libavutil/libm.h b/libavutil/libm.h
>>> > >> index 6d8bd68..637de19 100644
>>> > >> --- a/libavutil/libm.h
>>> > >> +++ b/libavutil/libm.h
>>> > >> @@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x)
>>> > >> }
>>> > >> #endif
>>> > >>
>>> > >> +#if !HAVE_COPYSIGN
>>> > >> +static av_always_inline double copysign(double x, double y)
>>> > >> +{
>>> > >> +uint64_t vx = av_double2int(x);
>>> > >> +uint64_t vy = av_double2int(y);
>>> > >> +return av_int2double((vx & 0x7fff) | (vy &
>>> > >> 0x8000));
>>> > >> +}
>>> > >> +#endif
>>> > >
>>> > >
>>> > > Don't these need type suffixes (e.g. UINT64_C(val)) on some
>>> systems?
>>> >
>>> > I believe not, see
>>> > http://en.cppreference.com/w/cpp/language/integer_literal
>>>
>>>
>>> That document confirms that it is indeed legal for a compiler to
>>> read
>>> the
>>> given literal on a 32bit or windows 64bit system as a 32bit max
>>> value, and
>>> your literals don't fit in 32bit.
>>> >>>
>>> >>> How, the standard clearly says that the literal will be in the type
>>> >>> int < unsigned int < long int < unsigned long int < long long int <
>>> >>> unsigned long long int, wherever it first fits, and this is also
>>> >>> clear
>>> >>> from the link I sent.
>>> >>>
>>> >>> long long is at least 64 bits. I can't speak about broken
>>> >>> compilers/environments that lack long long.
>>> >>
>>> >> This turns out to be the heart of the matter; as usual, Microsoft's
>>> >> toolchain is fundamentally broken:
>>> >>
>>> https://stackoverflow.com/questions/25626022/how-should-a-64-bit-integer-literal-be-represented-in-c
>>> .
>>> >>
>>> >
>>> > Its behavior would appear to be valid C90 on Windows, since long int
>>> > is 32-bit on that platform (which C90 calls for using, not long long)
>>>
>>> Yes, I meant broken wrt C99 (as seen in the link), which most of our
>>> platforms have and use. Basically, I meant that their C99 support is
>>> half-baked and broken (of course not news).
>>
>>
>> But FFmpeg isn't C99, see
>> https://ffmpeg.org/developer.html#C-language-features
>>
>> "FFmpeg is programmed in the ISO C90 language with a few additional
>> features from ISO C99 [..]"
>
> A last comment to show the ridiculousness of it all: UINT64_C is
> defined only in stdint.h, a C99 feature. Thus, if you want a "strict
> C90" solution to this, there is none. In particular, using UINT64_C is
> not "valid C90" on any platform.
>
> It is just a happy accident that MSVC has UINT64_C.
>
C90 is more than 20 years old.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add copysign hack
On Sat, Dec 19, 2015 at 10:28 PM, Ganesh Ajjanagadde wrote:
> On Sat, Dec 19, 2015 at 12:33 PM, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Sat, Dec 19, 2015 at 2:25 PM, Ganesh Ajjanagadde
>> wrote:
>>
>>> On Sat, Dec 19, 2015 at 11:05 AM, Hendrik Leppkes
>>> wrote:
>>> > On Sat, Dec 19, 2015 at 6:54 PM, Ganesh Ajjanagadde
>>> > wrote:
>>> >> On Sat, Dec 19, 2015 at 8:06 AM, Ganesh Ajjanagadde
>>> >> wrote:
>>> >>> On Sat, Dec 19, 2015 at 6:26 AM, Ronald S. Bultje
>>> wrote:
>>> Hi,
>>>
>>> On Fri, Dec 18, 2015 at 3:47 PM, Ganesh Ajjanagadde <
>>> gajjanaga...@gmail.com>
>>> wrote:
>>> >
>>> > On Fri, Dec 18, 2015 at 12:41 PM, Ronald S. Bultje <
>>> rsbul...@gmail.com>
>>> > wrote:
>>> > > Hi,
>>> > >
>>> > > On Fri, Dec 18, 2015 at 2:18 PM, Ganesh Ajjanagadde
>>> > >
>>> > > wrote:
>>> > >>
>>> > >> For systems with broken libms.
>>> > >> Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular
>>> double x
>>> > >> and
>>> > >> combinations of these.
>>> > >>
>>> > >> Signed-off-by: Ganesh Ajjanagadde
>>> > >> ---
>>> > >> configure| 2 +-
>>> > >> libavutil/libm.h | 9 +
>>> > >> 2 files changed, 10 insertions(+), 1 deletion(-)
>>> > >>
>>> > >> diff --git a/configure b/configure
>>> > >> index 123d1df..7917386 100755
>>> > >> --- a/configure
>>> > >> +++ b/configure
>>> > >> @@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl"
>>> > >> delogo_filter_deps="gpl"
>>> > >> deshake_filter_select="pixelutils"
>>> > >> drawtext_filter_deps="libfreetype"
>>> > >> -dynaudnorm_filter_deps="copysign erf"
>>> > >> +dynaudnorm_filter_deps="erf"
>>> > >> ebur128_filter_deps="gpl"
>>> > >> eq_filter_deps="gpl"
>>> > >> fftfilt_filter_deps="avcodec"
>>> > >> diff --git a/libavutil/libm.h b/libavutil/libm.h
>>> > >> index 6d8bd68..637de19 100644
>>> > >> --- a/libavutil/libm.h
>>> > >> +++ b/libavutil/libm.h
>>> > >> @@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x)
>>> > >> }
>>> > >> #endif
>>> > >>
>>> > >> +#if !HAVE_COPYSIGN
>>> > >> +static av_always_inline double copysign(double x, double y)
>>> > >> +{
>>> > >> +uint64_t vx = av_double2int(x);
>>> > >> +uint64_t vy = av_double2int(y);
>>> > >> +return av_int2double((vx & 0x7fff) | (vy &
>>> > >> 0x8000));
>>> > >> +}
>>> > >> +#endif
>>> > >
>>> > >
>>> > > Don't these need type suffixes (e.g. UINT64_C(val)) on some
>>> systems?
>>> >
>>> > I believe not, see
>>> > http://en.cppreference.com/w/cpp/language/integer_literal
>>>
>>>
>>> That document confirms that it is indeed legal for a compiler to read
>>> the
>>> given literal on a 32bit or windows 64bit system as a 32bit max
>>> value, and
>>> your literals don't fit in 32bit.
>>> >>>
>>> >>> How, the standard clearly says that the literal will be in the type
>>> >>> int < unsigned int < long int < unsigned long int < long long int <
>>> >>> unsigned long long int, wherever it first fits, and this is also clear
>>> >>> from the link I sent.
>>> >>>
>>> >>> long long is at least 64 bits. I can't speak about broken
>>> >>> compilers/environments that lack long long.
>>> >>
>>> >> This turns out to be the heart of the matter; as usual, Microsoft's
>>> >> toolchain is fundamentally broken:
>>> >>
>>> https://stackoverflow.com/questions/25626022/how-should-a-64-bit-integer-literal-be-represented-in-c
>>> .
>>> >>
>>> >
>>> > Its behavior would appear to be valid C90 on Windows, since long int
>>> > is 32-bit on that platform (which C90 calls for using, not long long)
>>>
>>> Yes, I meant broken wrt C99 (as seen in the link), which most of our
>>> platforms have and use. Basically, I meant that their C99 support is
>>> half-baked and broken (of course not news).
>>
>>
>> But FFmpeg isn't C99, see
>> https://ffmpeg.org/developer.html#C-language-features
>>
>> "FFmpeg is programmed in the ISO C90 language with a few additional
>> features from ISO C99 [..]"
>
> A last comment to show the ridiculousness of it all: UINT64_C is
> defined only in stdint.h, a C99 feature. Thus, if you want a "strict
> C90" solution to this, there is none. In particular, using UINT64_C is
> not "valid C90" on any platform.
>
> It is just a happy accident that MSVC has UINT64_C.
>
stdint.h was POSIX long before it became C99.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add copysign hack
On Sat, Dec 19, 2015 at 1:33 PM, Hendrik Leppkes wrote:
> On Sat, Dec 19, 2015 at 10:28 PM, Ganesh Ajjanagadde wrote:
>> On Sat, Dec 19, 2015 at 12:33 PM, Ronald S. Bultje
>> wrote:
>>> Hi,
>>>
>>> On Sat, Dec 19, 2015 at 2:25 PM, Ganesh Ajjanagadde
>>> wrote:
>>>
On Sat, Dec 19, 2015 at 11:05 AM, Hendrik Leppkes
wrote:
> On Sat, Dec 19, 2015 at 6:54 PM, Ganesh Ajjanagadde
> wrote:
>> On Sat, Dec 19, 2015 at 8:06 AM, Ganesh Ajjanagadde
>> wrote:
>>> On Sat, Dec 19, 2015 at 6:26 AM, Ronald S. Bultje
wrote:
Hi,
On Fri, Dec 18, 2015 at 3:47 PM, Ganesh Ajjanagadde <
gajjanaga...@gmail.com>
wrote:
>
> On Fri, Dec 18, 2015 at 12:41 PM, Ronald S. Bultje <
rsbul...@gmail.com>
> wrote:
> > Hi,
> >
> > On Fri, Dec 18, 2015 at 2:18 PM, Ganesh Ajjanagadde
> >
> > wrote:
> >>
> >> For systems with broken libms.
> >> Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular
double x
> >> and
> >> combinations of these.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde
> >> ---
> >> configure| 2 +-
> >> libavutil/libm.h | 9 +
> >> 2 files changed, 10 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/configure b/configure
> >> index 123d1df..7917386 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl"
> >> delogo_filter_deps="gpl"
> >> deshake_filter_select="pixelutils"
> >> drawtext_filter_deps="libfreetype"
> >> -dynaudnorm_filter_deps="copysign erf"
> >> +dynaudnorm_filter_deps="erf"
> >> ebur128_filter_deps="gpl"
> >> eq_filter_deps="gpl"
> >> fftfilt_filter_deps="avcodec"
> >> diff --git a/libavutil/libm.h b/libavutil/libm.h
> >> index 6d8bd68..637de19 100644
> >> --- a/libavutil/libm.h
> >> +++ b/libavutil/libm.h
> >> @@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x)
> >> }
> >> #endif
> >>
> >> +#if !HAVE_COPYSIGN
> >> +static av_always_inline double copysign(double x, double y)
> >> +{
> >> +uint64_t vx = av_double2int(x);
> >> +uint64_t vy = av_double2int(y);
> >> +return av_int2double((vx & 0x7fff) | (vy &
> >> 0x8000));
> >> +}
> >> +#endif
> >
> >
> > Don't these need type suffixes (e.g. UINT64_C(val)) on some
systems?
>
> I believe not, see
> http://en.cppreference.com/w/cpp/language/integer_literal
That document confirms that it is indeed legal for a compiler to read
the
given literal on a 32bit or windows 64bit system as a 32bit max
value, and
your literals don't fit in 32bit.
>>>
>>> How, the standard clearly says that the literal will be in the type
>>> int < unsigned int < long int < unsigned long int < long long int <
>>> unsigned long long int, wherever it first fits, and this is also clear
>>> from the link I sent.
>>>
>>> long long is at least 64 bits. I can't speak about broken
>>> compilers/environments that lack long long.
>>
>> This turns out to be the heart of the matter; as usual, Microsoft's
>> toolchain is fundamentally broken:
>>
https://stackoverflow.com/questions/25626022/how-should-a-64-bit-integer-literal-be-represented-in-c
.
>>
>
> Its behavior would appear to be valid C90 on Windows, since long int
> is 32-bit on that platform (which C90 calls for using, not long long)
Yes, I meant broken wrt C99 (as seen in the link), which most of our
platforms have and use. Basically, I meant that their C99 support is
half-baked and broken (of course not news).
>>>
>>>
>>> But FFmpeg isn't C99, see
>>> https://ffmpeg.org/developer.html#C-language-features
>>>
>>> "FFmpeg is programmed in the ISO C90 language with a few additional
>>> features from ISO C99 [..]"
>>
>> A last comment to show the ridiculousness of it all: UINT64_C is
>> defined only in stdint.h, a C99 feature. Thus, if you want a "strict
>> C90" solution to this, there is none. In particular, using UINT64_C is
>> not "valid C90" on any platform.
>>
>> It is just a happy accident that MSVC has UINT64_C.
>>
>
> stdint.h was POSIX long before it became C99.
and since when has MS actually cared about POSIX? This statement does
not change the fact that it is just an accident that we have a
solution here.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo
Re: [FFmpeg-devel] [PATCH] lavu/libm: add copysign hack
On Sat, Dec 19, 2015 at 1:31 PM, Paul B Mahol wrote: [...] > C90 is more than 20 years old. Of course, but this was raised by Hendrik and Ronald regarding compliance and FFmpeg's coding guidelines. This also highlights how ludicruous it is in 2015, soon to be 2016. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add copysign hack
On Sat, Dec 19, 2015 at 1:56 PM, Ganesh Ajjanagadde wrote: > On Sat, Dec 19, 2015 at 1:31 PM, Paul B Mahol wrote: > [...] >> C90 is more than 20 years old. > > Of course, but this was raised by Hendrik and Ronald regarding > compliance and FFmpeg's coding guidelines. > This also highlights how ludicruous it is in 2015, soon to be 2016. > >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Pushed, thanks all. Discussion was enlightening wrt the degree of brokenness of certain platforms, noted for the future. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/intmath: add faster clz support
On Thu, Dec 17, 2015 at 9:29 AM, Ganesh Ajjanagadde wrote:
> On Thu, Dec 17, 2015 at 9:25 AM, Clément Bœsch wrote:
>> On Thu, Dec 17, 2015 at 09:23:53AM -0800, Ganesh Ajjanagadde wrote:
>>> On Thu, Dec 17, 2015 at 9:20 AM, Kieran Kunhya wrote:
>>> >>> +static av_always_inline av_const unsigned ff_clz_c(unsigned v)
>>> >>> +{
>>> >>> +unsigned i = sizeof(x) * 8;
>>> >>> +
>>> >>> +while (x) {
>>> >>> +x >>= 1;
>>> >>> +i--;
>>> >>> +}
>>> >>> +
>>> >>> +return i;
>>> >>> +}
>>> >>> +#endif
>>> >>> +
>>> >
>>> > erm, does even work?
>>>
>>> you mean in what sense? I literally copy/pasted it from
>>> avfilter/af_sofalizer.
>>> If you mean building correctly, I don't know as I have the built-in.
>>> But then this patch does not actually use it yet; merely adds it to
>>> the header.
>>
>> v → x in arg
>
> oops, fixed, along with the signature locally.
forgot to mention that it has been pushed, thanks
>
>>
>> --
>> Clément B.
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] decklink: support all valid numbers of audio channels
Hi, On Sat, Dec 19, 2015 at 11:23 AM Matthias Hunstock < matthias.hunst...@tu-ilmenau.de> wrote: > Am 18.12.2015 um 20:25 schrieb Matthias Hunstock: > > Introduces new option. > > PS. I did not find any ressources on how to properly name new FFmpeg > options, e.g. to be consistent. Using the existing "ac" option did not > work. > In this situation, it is always good to check what others are using :) In this case, all the input devices seem to use "channels": https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/alsa_dec.c#L146 https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/dshow.c#L1269 Indeed, -ac is actually mapped to "channels" within the ffmpeg program: https://github.com/FFmpeg/FFmpeg/blob/master/ffmpeg_opt.c#L900 > I would like to add some more features, like selection of video and/or > audio input jack, to improve the coverage of the DeckLink API. > > I also have access to several different BM cards, so I can test things > with real hardware. > Great! Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vaapi: Add VP9 hwaccell support
Signed-off-by: Timo Rothenpieler
---
Changelog | 1 +
configure | 3 +
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/vaapi_vp9.c | 168 +
libavcodec/version.h | 2 +-
libavcodec/vp9.c | 5 +-
7 files changed, 179 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/vaapi_vp9.c
diff --git a/Changelog b/Changelog
index a3d44b4..2b46ddb 100644
--- a/Changelog
+++ b/Changelog
@@ -46,6 +46,7 @@ version :
- mips64r6 option has been removed
- DXVA2-accelerated VP9 decoding
- SOFAlizer: virtual binaural acoustics filter
+- VAAPI VP9 hwaccel
version 2.8:
diff --git a/configure b/configure
index dc1d2eb..df7ce96 100755
--- a/configure
+++ b/configure
@@ -2577,6 +2577,8 @@ vp9_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_VP9"
vp9_d3d11va_hwaccel_select="vp9_decoder"
vp9_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_VP9"
vp9_dxva2_hwaccel_select="vp9_decoder"
+vp9_vaapi_hwaccel_deps="vaapi VADecPictureParameterBufferVP9"
+vp9_vaapi_hwaccel_select="vp9_decoder"
wmv3_crystalhd_decoder_select="crystalhd"
wmv3_d3d11va_hwaccel_select="vc1_d3d11va_hwaccel"
wmv3_dxva2_hwaccel_select="vc1_dxva2_hwaccel"
@@ -5320,6 +5322,7 @@ check_type "windows.h d3d11.h" "ID3D11VideoContext"
check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602
check_type "va/va.h" "VAPictureParameterBufferHEVC"
+check_type "va/va.h" "VADecPictureParameterBufferVP9"
check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 44b199e..50772bd 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -750,6 +750,7 @@ OBJS-$(CONFIG_VC1_VAAPI_HWACCEL) += vaapi_vc1.o
OBJS-$(CONFIG_VC1_VDPAU_HWACCEL) += vdpau_vc1.o
OBJS-$(CONFIG_VP9_D3D11VA_HWACCEL)+= dxva2_vp9.o
OBJS-$(CONFIG_VP9_DXVA2_HWACCEL) += dxva2_vp9.o
+OBJS-$(CONFIG_VP9_VAAPI_HWACCEL) += vaapi_vp9.o
# libavformat dependencies
OBJS-$(CONFIG_ADTS_MUXER) += mpeg4audio.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 245332e..7585f04 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -112,6 +112,7 @@ void avcodec_register_all(void)
REGISTER_HWACCEL(VC1_QSV, vc1_qsv);
REGISTER_HWACCEL(VP9_D3D11VA, vp9_d3d11va);
REGISTER_HWACCEL(VP9_DXVA2, vp9_dxva2);
+REGISTER_HWACCEL(VP9_VAAPI, vp9_vaapi);
REGISTER_HWACCEL(WMV3_D3D11VA, wmv3_d3d11va);
REGISTER_HWACCEL(WMV3_DXVA2,wmv3_dxva2);
REGISTER_HWACCEL(WMV3_VAAPI,wmv3_vaapi);
diff --git a/libavcodec/vaapi_vp9.c b/libavcodec/vaapi_vp9.c
new file mode 100644
index 000..b360dcb
--- /dev/null
+++ b/libavcodec/vaapi_vp9.c
@@ -0,0 +1,168 @@
+/*
+ * VP9 HW decode acceleration through VA API
+ *
+ * Copyright (C) 2015 Timo Rothenpieler
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/pixdesc.h"
+#include "vaapi_internal.h"
+#include "vp9.h"
+
+static void fill_picture_parameters(AVCodecContext *avctx,
+const VP9SharedContext *h,
+VADecPictureParameterBufferVP9 *pp)
+{
+const AVPixFmtDescriptor *pixdesc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
+int i;
+
+pp->frame_width = avctx->width;
+pp->frame_height = avctx->height;
+
+pp->frame_header_length_in_bytes = h->h.uncompressed_header_size;
+pp->first_partition_size = h->h.compressed_header_size;
+
+pp->profile = h->h.profile;
+
+pp->filter_level = h->h.filter.level;
+pp->sharpness_level = h->h.filter.sharpness;
+pp->log2_tile_rows = h->h.tiling.log2_tile_rows;
+pp->log2_tile_columns = h->h.tiling.log2_tile_cols;
+
+pp->pic_fields.bits.subsampling_x = pixdesc->log2_chroma_w;
+pp->pic_fields.bits.subsampling_y = pixdesc->log2_chroma_h;
+pp->pic_fields.bits.frame_type = !h->h.keyframe;
+pp->pic_fields.bits.show_frame = !h->h.invisible;
+pp->pic_fields.bits.error_resilient_mode = h->h.errorres;
+pp->pic_fields.bits.intra_only = h->h.intraonly;
+pp->pic_fields.bits.allow_high_precision_mv = h->h.keyframe ? 0 :
h->h.hig
[FFmpeg-devel] [PATCH 1/3] mlvdec: check that index_entries exist
This fixes NULL pointer dereferencing.
Signed-off-by: Andreas Cadhalpun
---
libavformat/mlvdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mlvdec.c b/libavformat/mlvdec.c
index 48a429e..4b3bdc1 100644
--- a/libavformat/mlvdec.c
+++ b/libavformat/mlvdec.c
@@ -365,6 +365,11 @@ static int read_header(AVFormatContext *avctx)
if (ast)
ast->duration = ast->nb_index_entries;
+if ((vst && !vst->nb_index_entries) || (ast && !ast->nb_index_entries)) {
+av_log(avctx, AV_LOG_ERROR, "no index entries found\n");
+return AVERROR_INVALIDDATA;
+}
+
if (vst && ast)
avio_seek(pb, FFMIN(vst->index_entries[0].pos,
ast->index_entries[0].pos), SEEK_SET);
else if (vst)
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] mlvdec: validate bits_per_coded_sample
A negative bits_per_coded_sample doesn't make sense.
If it is too large, the size calculation for av_get_packet overflows,
resulting in allocation of a too small buffer.
Signed-off-by: Andreas Cadhalpun
---
libavformat/mlvdec.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavformat/mlvdec.c b/libavformat/mlvdec.c
index 4b3bdc1..2e57aae 100644
--- a/libavformat/mlvdec.c
+++ b/libavformat/mlvdec.c
@@ -135,6 +135,15 @@ static int scan_file(AVFormatContext *avctx, AVStream
*vst, AVStream *ast, int f
avpriv_request_sample(avctx, "raw api version");
avio_skip(pb, 20); // pointer, width, height, pitch, frame_size
vst->codec->bits_per_coded_sample = avio_rl32(pb);
+if (vst->codec->bits_per_coded_sample < 0 ||
+(vst->codec->width && vst->codec->height &&
+vst->codec->bits_per_coded_sample > (INT_MAX - 7) /
(vst->codec->width * vst->codec->height))) {
+av_log(avctx, AV_LOG_ERROR,
+ "invalid bits_per_coded_sample %d (size: %dx%d)\n",
+ vst->codec->bits_per_coded_sample,
+ vst->codec->width, vst->codec->height);
+return AVERROR_INVALIDDATA;
+}
avio_skip(pb, 8 + 16 + 24); // black_level, white_level, xywh,
active_area, exposure_bias
if (avio_rl32(pb) != 0x2010100) /* RGGB */
avpriv_request_sample(avctx, "cfa_pattern");
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] rawdec: only exempt BIT0 with need_copy from buffer sanity check
Otherwise the too samll buffer is directly used in the frame, causing
segmentation faults, when trying to use the frame.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/rawdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 611178f..50cee39 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -257,7 +257,7 @@ static int raw_decode(AVCodecContext *avctx, void *data,
int *got_frame,
buf += buf_size - context->frame_size;
len = context->frame_size - (avctx->pix_fmt==AV_PIX_FMT_PAL8 ?
AVPALETTE_SIZE : 0);
-if (buf_size < len && (avctx->codec_tag & 0xFF) != MKTAG('B','I','T',
0)) {
+if (buf_size < len && ((avctx->codec_tag & 0xFF) != MKTAG('B','I','T',
0) || !need_copy)) {
av_log(avctx, AV_LOG_ERROR, "Invalid buffer size, packet size %d <
expected frame_size %d\n", buf_size, len);
av_buffer_unref(&frame->buf[0]);
return AVERROR(EINVAL);
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vaapi: Add VP9 hwaccell support
Hi, On Sat, Dec 19, 2015 at 5:43 PM, Timo Rothenpieler wrote: > Signed-off-by: Timo Rothenpieler > --- > Changelog | 1 + > configure | 3 + > libavcodec/Makefile| 1 + > libavcodec/allcodecs.c | 1 + > libavcodec/vaapi_vp9.c | 168 > + > libavcodec/version.h | 2 +- > libavcodec/vp9.c | 5 +- > 7 files changed, 179 insertions(+), 2 deletions(-) > create mode 100644 libavcodec/vaapi_vp9.c OK for the vp9-related portions. I can't really say anything sensible w.r.t. the hw portions, but it looks roughly OK to me. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] mlvdec: check that index_entries exist
On Sat, Dec 19, 2015 at 11:47:54PM +0100, Andreas Cadhalpun wrote: > This fixes NULL pointer dereferencing. > > Signed-off-by: Andreas Cadhalpun > --- > libavformat/mlvdec.c | 5 + > 1 file changed, 5 insertions(+) iam not maintainer of this but probably ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is 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 2/3] mlvdec: validate bits_per_coded_sample
On Sat, Dec 19, 2015 at 11:49:02PM +0100, Andreas Cadhalpun wrote:
> A negative bits_per_coded_sample doesn't make sense.
> If it is too large, the size calculation for av_get_packet overflows,
> resulting in allocation of a too small buffer.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/mlvdec.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/libavformat/mlvdec.c b/libavformat/mlvdec.c
> index 4b3bdc1..2e57aae 100644
> --- a/libavformat/mlvdec.c
> +++ b/libavformat/mlvdec.c
> @@ -135,6 +135,15 @@ static int scan_file(AVFormatContext *avctx, AVStream
> *vst, AVStream *ast, int f
> avpriv_request_sample(avctx, "raw api version");
> avio_skip(pb, 20); // pointer, width, height, pitch, frame_size
> vst->codec->bits_per_coded_sample = avio_rl32(pb);
> +if (vst->codec->bits_per_coded_sample < 0 ||
> +(vst->codec->width && vst->codec->height &&
> +vst->codec->bits_per_coded_sample > (INT_MAX - 7) /
> (vst->codec->width * vst->codec->height))) {
w*h can overflow
might be easier to calculate it in unsigned 64bit and then check
the value also could be reused to ensure it wont get out of sync with
the allocation
> +av_log(avctx, AV_LOG_ERROR,
> + "invalid bits_per_coded_sample %d (size: %dx%d)\n",
> + vst->codec->bits_per_coded_sample,
> + vst->codec->width, vst->codec->height);
> +return AVERROR_INVALIDDATA;
> +}
> avio_skip(pb, 8 + 16 + 24); // black_level, white_level, xywh,
> active_area, exposure_bias
> if (avio_rl32(pb) != 0x2010100) /* RGGB */
> avpriv_request_sample(avctx, "cfa_pattern");
> --
> 2.6.2
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
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] rawdec: only exempt BIT0 with need_copy from buffer sanity check
On Sat, Dec 19, 2015 at 11:49:14PM +0100, Andreas Cadhalpun wrote:
> Otherwise the too samll buffer is directly used in the frame, causing
> segmentation faults, when trying to use the frame.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/rawdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
> index 611178f..50cee39 100644
> --- a/libavcodec/rawdec.c
> +++ b/libavcodec/rawdec.c
> @@ -257,7 +257,7 @@ static int raw_decode(AVCodecContext *avctx, void *data,
> int *got_frame,
> buf += buf_size - context->frame_size;
>
> len = context->frame_size - (avctx->pix_fmt==AV_PIX_FMT_PAL8 ?
> AVPALETTE_SIZE : 0);
> -if (buf_size < len && (avctx->codec_tag & 0xFF) !=
> MKTAG('B','I','T', 0)) {
> +if (buf_size < len && ((avctx->codec_tag & 0xFF) !=
> MKTAG('B','I','T', 0) || !need_copy)) {
> av_log(avctx, AV_LOG_ERROR, "Invalid buffer size, packet size %d <
> expected frame_size %d\n", buf_size, len);
> av_buffer_unref(&frame->buf[0]);
> return AVERROR(EINVAL);
should be ok, alterantively you could also force need_copy in these
cases
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/s302menc: set supported channel layouts by codec
On Sat, Dec 19, 2015 at 09:35:19PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/s302menc.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/s302menc.c b/libavcodec/s302menc.c
> index fbaa845..3706eba 100644
> --- a/libavcodec/s302menc.c
> +++ b/libavcodec/s302menc.c
> @@ -175,4 +175,9 @@ AVCodec ff_s302m_encoder = {
>
> AV_SAMPLE_FMT_NONE },
> .capabilities = AV_CODEC_CAP_VARIABLE_FRAME_SIZE |
> AV_CODEC_CAP_EXPERIMENTAL,
> .supported_samplerates = (const int[]) { 48000, 0 },
> +.channel_layouts = (const uint64_t[]) { AV_CH_LAYOUT_STEREO,
> + AV_CH_LAYOUT_QUAD,
> + AV_CH_LAYOUT_5POINT1_BACK,
> + AV_CH_LAYOUT_5POINT1_BACK
> | AV_CH_LAYOUT_STEREO_DOWNMIX,
> + 0 },
assuming the list is correct, the patch LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] rawdec: only exempt BIT0 with need_copy from buffer sanity check
On Sat, Dec 19, 2015 at 2:49 PM, Andreas Cadhalpun wrote: > Otherwise the too samll buffer is directly used in the frame, causing samll-> small sorry, can't review further. [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavu/libm: add erf hack
Source code is from Boost:
http://www.boost.org/doc/libs/1_46_1/boost/math/special_functions/erf.hpp
with appropriate modifications for FFmpeg.
Tested on interval -6 to 6 (beyond which it saturates), +/-NAN, +/-INFINITY
under -fsanitize=undefined on clang to test for possible undefined behavior.
(Below will be trimmed for actual commit, given for completeness here)
Note that this will remove the erf dependency for dynaudnorm, making it
universally available for clients. I have not done this in this patch;
may be easily done once this is tested on a broken libm and reviewed.
This function turns out to actually be more accurate and faster than the
libm (GNU/BSD's/Mac OS X), and I can think of 3 reasons why upstream
does not use this:
1. They are not aware of it.
2. They are concerned about licensing - this applies especially to GNU
libm.
3. They do not know and/or appreciate the benefits of rational
approximations over polynomial approximations. Boost uses them to great
effect, see e.g swr/resample for bessel derived from them, which is also
similarly superior to libm variants.
First, performance.
sample benchmark (clang -O3, Haswell, GNU/Linux):
3e8 values evenly spaced from 0 to 6
time (libm):
./test 13.39s user 0.00s system 100% cpu 13.376 total
time (boost based):
./test 9.20s user 0.00s system 100% cpu 9.190 total
Second, accuracy.
1e8 eval pts from 0 to 6
maxdiff (absolute): 2.2204460492503131e-16
illustration:
erf(0.6):
libm : 0.60385609084792602
boost : 0.60385609084792591
real : 0.60385609084792591
i.e libm is actually incorrectly rounded. Note that this is clear from:
https://github.com/JuliaLang/openlibm/blob/master/src/s_erf.c (the Sun
implementation used by both BSD and GNU libm's), where only 1 ulp is
guaranteed.
I suspect Boost's is correctly rounded (0.5 ulp), based on their error
analysis but have not checked or verified formally that this is the
case.
Signed-off-by: Ganesh Ajjanagadde
---
libavutil/libm.h | 198 +++
1 file changed, 198 insertions(+)
diff --git a/libavutil/libm.h b/libavutil/libm.h
index 37b8e86..2c05b00 100644
--- a/libavutil/libm.h
+++ b/libavutil/libm.h
@@ -1,4 +1,5 @@
/*
+ * erf function: Copyright (c) 2006 John Maddock
* This file is part of FFmpeg.
*
* FFmpeg is free software; you can redistribute it and/or
@@ -76,6 +77,203 @@ static av_always_inline double copysign(double x, double y)
#define cosf(x) ((float)cos(x))
#endif
+#if !HAVE_ERF
+static inline double eval_poly(const double *coeff, int size, double x) {
+double sum = coeff[size-1];
+int i;
+for (i = size-2; i >= 0; --i) {
+sum *= x;
+sum += coeff[i];
+}
+return sum;
+}
+
+/**
+ * erf function
+ * Algorithm taken from the Boost project, source:
+ * http://www.boost.org/doc/libs/1_46_1/boost/math/special_functions/erf.hpp
+ * Use, modification and distribution are subject to the
+ * Boost Software License, Version 1.0 (see notice below).
+ * Boost Software License - Version 1.0 - August 17th, 2003
+Permission is hereby granted, free of charge, to any person or organization
+obtaining a copy of the software and accompanying documentation covered by
+this license (the "Software") to use, reproduce, display, distribute,
+execute, and transmit the Software, and to prepare derivative works of the
+Software, and to permit third-parties to whom the Software is furnished to
+do so, all subject to the following:
+
+The copyright notices in the Software and this entire statement, including
+the above license grant, this restriction and the following disclaimer,
+must be included in all copies of the Software, in whole or in part, and
+all derivative works of the Software, unless such copies or derivative
+works are solely in the form of machine-executable object code generated by
+a source language processor.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
+SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
+FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
+ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+ */
+static inline double erf(double z)
+{
+double result;
+
+/* handle the symmetry: erf(-x) = -erf(x) */
+if (z < 0)
+return -ff_erf(-z);
+
+/* branch based on range of z, and pick appropriate approximation */
+if (z == 0)
+return 0;
+else if (z < 1e-10)
+return z * 1.125 + z * 0.003379167095512573896158903121545171688;
+else if (z < 0.5) {
+// Maximum Deviation Found: 1.561e-17
+// Expected Error Term: 1.561e-17
+// Maximum Relative Change in Control Points: 1.155e-04
+// Max Error found at double p
Re: [FFmpeg-devel] [PATCH] lavu/libm: add erf hack
On 12/19/2015 11:34 PM, Ganesh Ajjanagadde wrote: > +/** > + * erf function > + * Algorithm taken from the Boost project, source: > + * http://www.boost.org/doc/libs/1_46_1/boost/math/special_functions/erf.hpp > + * Use, modification and distribution are subject to the > + * Boost Software License, Version 1.0 (see notice below). > + * Boost Software License - Version 1.0 - August 17th, 2003 > +Permission is hereby granted, free of charge, to any person or organization > +obtaining a copy of the software and accompanying documentation covered by > +this license (the "Software") to use, reproduce, display, distribute, > +execute, and transmit the Software, and to prepare derivative works of the > +Software, and to permit third-parties to whom the Software is furnished to > +do so, all subject to the following: > + > +The copyright notices in the Software and this entire statement, including > +the above license grant, this restriction and the following disclaimer, > +must be included in all copies of the Software, in whole or in part, and > +all derivative works of the Software, unless such copies or derivative > +works are solely in the form of machine-executable object code generated by > +a source language processor. > + > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > +FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT > +SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE > +FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, > +ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > +DEALINGS IN THE SOFTWARE. > + */ Unrelated to the actual patch, but how about instead doing what the FAQ section of http://www.boost.org/users/license.html mentions and adding the Boost license in a separate file? That way, only the short four line snippet mentioned there would be needed here and in swr/resample.c ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add erf hack
On 12/19/2015 11:34 PM, Ganesh Ajjanagadde wrote: > +/* handle the nan case, but don't use isnan for max portability */ > +else if (z != z) > +return z; Didn't check, but this sounds like it would probably trigger warnings with -Wtautological-compare (GCC 6). That aside, libm.h has an isnan() fallback for systems where it's not available. Portability shouldn't be a problem. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add erf hack
On Sat, Dec 19, 2015 at 7:06 PM, James Almer wrote: > On 12/19/2015 11:34 PM, Ganesh Ajjanagadde wrote: >> +/** >> + * erf function >> + * Algorithm taken from the Boost project, source: >> + * http://www.boost.org/doc/libs/1_46_1/boost/math/special_functions/erf.hpp >> + * Use, modification and distribution are subject to the >> + * Boost Software License, Version 1.0 (see notice below). >> + * Boost Software License - Version 1.0 - August 17th, 2003 >> +Permission is hereby granted, free of charge, to any person or organization >> +obtaining a copy of the software and accompanying documentation covered by >> +this license (the "Software") to use, reproduce, display, distribute, >> +execute, and transmit the Software, and to prepare derivative works of the >> +Software, and to permit third-parties to whom the Software is furnished to >> +do so, all subject to the following: >> + >> +The copyright notices in the Software and this entire statement, including >> +the above license grant, this restriction and the following disclaimer, >> +must be included in all copies of the Software, in whole or in part, and >> +all derivative works of the Software, unless such copies or derivative >> +works are solely in the form of machine-executable object code generated by >> +a source language processor. >> + >> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR >> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, >> +FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT >> +SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE >> +FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, >> +ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER >> +DEALINGS IN THE SOFTWARE. >> + */ > > Unrelated to the actual patch, but how about instead doing what the FAQ > section > of http://www.boost.org/users/license.html mentions and adding the Boost > license > in a separate file? > That way, only the short four line snippet mentioned there would be needed > here > and in swr/resample.c I had numerous back and forths with Carl regarding licensing. The short summary is: I am not a lawyer, and I like to play it safe. Thus, I think it belongs to a separate patch, and I would not do it myself as I don't have the needed expertise. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add erf hack
On Sat, Dec 19, 2015 at 9:58 PM, James Almer wrote: > On 12/19/2015 11:34 PM, Ganesh Ajjanagadde wrote: >> +/* handle the nan case, but don't use isnan for max portability */ >> +else if (z != z) >> +return z; > > Didn't check, but this sounds like it would probably trigger warnings with > -Wtautological-compare (GCC 6). > That aside, libm.h has an isnan() fallback for systems where it's not > available. Portability shouldn't be a problem. Yes, but then this will need to be placed below breaking the alphabetical order for minimal gain and I can't be as confident that it works. if (z != z) is perfectly valid C code that does its job. It is a reasonably common idiom for nan checks. I believe (have not confirmed) that even some libm's use it in some places. Lastly, I have tested with clang 3.7.0-6 (on Arch) with -Weverything. Only warning is for z == 0 test (Wfloat-equal). Anyway, this I am not as reluctant to change as compared to the licensing/copyright (wrt this patch). > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/libm: add erf hack
On Sat, Dec 19, 2015 at 10:40 PM, Ganesh Ajjanagadde wrote: > On Sat, Dec 19, 2015 at 9:58 PM, James Almer wrote: >> On 12/19/2015 11:34 PM, Ganesh Ajjanagadde wrote: >>> +/* handle the nan case, but don't use isnan for max portability */ >>> +else if (z != z) >>> +return z; >> >> Didn't check, but this sounds like it would probably trigger warnings with >> -Wtautological-compare (GCC 6). Maybe of relevance: https://patchwork.ozlabs.org/patch/498775/, seems like they will take care of this case. [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] mlvdec: validate bits_per_coded_sample
On Sat, Dec 19, 2015 at 11:49:02PM +0100, Andreas Cadhalpun wrote:
> A negative bits_per_coded_sample doesn't make sense.
> If it is too large, the size calculation for av_get_packet overflows,
> resulting in allocation of a too small buffer.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/mlvdec.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/libavformat/mlvdec.c b/libavformat/mlvdec.c
> index 4b3bdc1..2e57aae 100644
> --- a/libavformat/mlvdec.c
> +++ b/libavformat/mlvdec.c
> @@ -135,6 +135,15 @@ static int scan_file(AVFormatContext *avctx, AVStream
> *vst, AVStream *ast, int f
> avpriv_request_sample(avctx, "raw api version");
> avio_skip(pb, 20); // pointer, width, height, pitch, frame_size
> vst->codec->bits_per_coded_sample = avio_rl32(pb);
> +if (vst->codec->bits_per_coded_sample < 0 ||
> +(vst->codec->width && vst->codec->height &&
> +vst->codec->bits_per_coded_sample > (INT_MAX - 7) /
> (vst->codec->width * vst->codec->height))) {
> +av_log(avctx, AV_LOG_ERROR,
> + "invalid bits_per_coded_sample %d (size: %dx%d)\n",
> + vst->codec->bits_per_coded_sample,
> + vst->codec->width, vst->codec->height);
> +return AVERROR_INVALIDDATA;
> +}
> avio_skip(pb, 8 + 16 + 24); // black_level, white_level, xywh,
> active_area, exposure_bias
> if (avio_rl32(pb) != 0x2010100) /* RGGB */
> avpriv_request_sample(avctx, "cfa_pattern");
> --
> 2.6.2
Looks good.
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vaapi: Add VP9 hwaccell support
On 20.12.2015 06:43, Timo Rothenpieler wrote:
Signed-off-by: Timo Rothenpieler
---
Changelog | 1 +
configure | 3 +
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/vaapi_vp9.c | 168
+
libavcodec/version.h | 2 +-
libavcodec/vp9.c | 5 +-
7 files changed, 179 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/vaapi_vp9.c
Looks credible.
--phil
diff --git a/Changelog b/Changelog
index a3d44b4..2b46ddb 100644
--- a/Changelog
+++ b/Changelog
@@ -46,6 +46,7 @@ version :
- mips64r6 option has been removed
- DXVA2-accelerated VP9 decoding
- SOFAlizer: virtual binaural acoustics filter
+- VAAPI VP9 hwaccel
version 2.8:
diff --git a/configure b/configure
index dc1d2eb..df7ce96 100755
--- a/configure
+++ b/configure
@@ -2577,6 +2577,8 @@ vp9_d3d11va_hwaccel_deps="d3d11va
DXVA_PicParams_VP9"
vp9_d3d11va_hwaccel_select="vp9_decoder"
vp9_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_VP9"
vp9_dxva2_hwaccel_select="vp9_decoder"
+vp9_vaapi_hwaccel_deps="vaapi VADecPictureParameterBufferVP9"
+vp9_vaapi_hwaccel_select="vp9_decoder"
wmv3_crystalhd_decoder_select="crystalhd"
wmv3_d3d11va_hwaccel_select="vc1_d3d11va_hwaccel"
wmv3_dxva2_hwaccel_select="vc1_dxva2_hwaccel"
@@ -5320,6 +5322,7 @@ check_type "windows.h d3d11.h"
"ID3D11VideoContext"
check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode
-D_WIN32_WINNT=0x0602
check_type "va/va.h" "VAPictureParameterBufferHEVC"
+check_type "va/va.h" "VADecPictureParameterBufferVP9"
check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 44b199e..50772bd 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -750,6 +750,7 @@ OBJS-$(CONFIG_VC1_VAAPI_HWACCEL) +=
vaapi_vc1.o
OBJS-$(CONFIG_VC1_VDPAU_HWACCEL) += vdpau_vc1.o
OBJS-$(CONFIG_VP9_D3D11VA_HWACCEL)+= dxva2_vp9.o
OBJS-$(CONFIG_VP9_DXVA2_HWACCEL) += dxva2_vp9.o
+OBJS-$(CONFIG_VP9_VAAPI_HWACCEL) += vaapi_vp9.o
# libavformat dependencies
OBJS-$(CONFIG_ADTS_MUXER) += mpeg4audio.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 245332e..7585f04 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -112,6 +112,7 @@ void avcodec_register_all(void)
REGISTER_HWACCEL(VC1_QSV, vc1_qsv);
REGISTER_HWACCEL(VP9_D3D11VA, vp9_d3d11va);
REGISTER_HWACCEL(VP9_DXVA2, vp9_dxva2);
+REGISTER_HWACCEL(VP9_VAAPI, vp9_vaapi);
REGISTER_HWACCEL(WMV3_D3D11VA, wmv3_d3d11va);
REGISTER_HWACCEL(WMV3_DXVA2,wmv3_dxva2);
REGISTER_HWACCEL(WMV3_VAAPI,wmv3_vaapi);
diff --git a/libavcodec/vaapi_vp9.c b/libavcodec/vaapi_vp9.c
new file mode 100644
index 000..b360dcb
--- /dev/null
+++ b/libavcodec/vaapi_vp9.c
@@ -0,0 +1,168 @@
+/*
+ * VP9 HW decode acceleration through VA API
+ *
+ * Copyright (C) 2015 Timo Rothenpieler
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA
+ */
+
+#include "libavutil/pixdesc.h"
+#include "vaapi_internal.h"
+#include "vp9.h"
+
+static void fill_picture_parameters(AVCodecContext
*avctx,
+const VP9SharedContext *h,
+VADecPictureParameterBufferVP9
*pp)
+{
+const AVPixFmtDescriptor *pixdesc =
av_pix_fmt_desc_get(avctx->sw_pix_fmt);
+int i;
+
+pp->frame_width = avctx->width;
+pp->frame_height = avctx->height;
+
+pp->frame_header_length_in_bytes = h->h.uncompressed_header_size;
+pp->first_partition_size = h->h.compressed_header_size;
+
+pp->profile = h->h.profile;
+
+pp->filter_level = h->h.filter.level;
+pp->sharpness_level = h->h.filter.sharpness;
+pp->log2_tile_rows = h->h.tiling.log2_tile_rows;
+pp->log2_tile_columns = h->h.tiling.log2_tile_cols;
+
+pp->pic_fields.bits.subsampling_x = pixdesc->log2_chroma_w;
+pp->pic_fields.bits.subsampling_y = pixdesc->log2_chroma_h;
+pp->pic_fields.bits.frame_type = !h->h.keyframe;
+pp->pic_fields.bits.show_frame = !h->h.invisible;
+pp->pic_fields.bits.error_resilient_mode = h->h.errorres;
+pp->pic_fields.bits.intra_only = h->h.intra
