Re: [FFmpeg-devel] [RFC] avformat/mxfenc: stop encoding if unfilled video packet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/10/15 13:07, Tomas Härdin wrote: > On Mon, 2015-09-28 at 15:11 +0200, Tobias Rapp wrote: >> On 19.09.2015 22:49, Tomas Härdin wrote: >>> On Wed, 2015-09-16 at 14:33 +0200, Tobias Rapp wrote: Hi, attached patch fixes ticket #4759 but I guess it is a bit too hasty to always abort transcoding if a single frame cannot be written. I gue ss it would be better to check for some "exit_on_error" like flag set but couldn't find out how to achieve that. Any comments would be appreciated. Regards, Tobias >>> >>> From 7d6f8de2a411817c970a19d8766e69b6eb604132 Mon Sep 17 00:00:00 2001 From: Tobias Rapp Date: Mon, 14 Sep 2015 12:06:22 +0200 Subject: [PATCH] avformat/mxfenc: stop encoding if unfilled video p acket occurs Fixes ticket #4759. --- libavformat/mxfenc.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) >> [...] >>> >>> Is this really better than not writing anything? >>> >>> /Tomas >> >> (Sorry for the long delay in answering, I was caught by a flu last we ek.) >> >> I want to transcode thousands of files and want to get some indicatio n >> from ffmpeg if the transcoding has been successful (all frames have b een >> transcoded) or not. Currently I am using the process exit code to ver ify >> that. >> >> There are two different user stories when using ffmpeg: >> a) "process the input data and exit with error as early as possible i n >> case of errors/problems" >> b) "process the input data and avoid exit with error as long as possi ble >> in case of error/problems" >> >> If I understand correctly I can basically switch between (a) and (b) >> mode by passing the "-xerror" option to ffmpeg or not. So my plan is to >> transcode all my files with "-xerror" and assume that >99% of the fil es >> will pass. The small amount of failing ones can then be analyzed for >> problems manually and possibly have a re-run without "-xerror". >> >> Unfortunately the "-xerror" option affects only ffmpeg but not the >> libraries, so I cannot use it do decide if "mxf_write_packet" should >> return with an error when the video packet size doesn't match the CBR >> constraints. > > For me the most important thing is that anything dealing with MXF shou ld > never write invalid files. +1 for sure. > I'm not sure whether the current code is > broken per se, but it does look suspicious. Perhaps someone else has a > better idea? > Truncate/pad mis sized frames to allow muxing to continue, and issue a warning (as at present)? > /Tomas > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > - -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWEiJtAAoJEAwL/ESLC/yDGQAIAJmqWRatBPd/2SXuzyFGWqB2 sg/FBpbzRqFGxr8dOfqfSkwLWu+EUL66UZKu5liVKkeksiUgx4sPtj6DFGFX7ozV g2DbJxvsFG18ES9C8OHc3qRDsgF4Z+F4GuScWMPrVcyvimSdHeajVkS8slrZlg2Y tMGQSin5jLwzv1pGIhCOdQLEndrr+PzwajPI837UBW2e7znWDb1uNHBy1yiPzcf+ 0pyZluyhkqW6IBzgO34Dc39DfQdGrtDWlzyUacT7nQz/4W5q2KAAhUhBTNtqTabK KCtSUfpqWgu6P2xxNvi87F9acqYprS80RC/ovrdgsXiXTNGSbYVscY748xg8mgA= =Clgr -END PGP SIGNATURE- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] dnxhddec: replace some 0s by DNXHD_VARIABLE
Hi, 2015-10-05 8:44 GMT+02:00 tim nicholson : > On 02/10/15 20:00, Christophe Gisquet wrote: >> A series of 0 in a table can be confusing, and the corresponding checks >> strange, so using a macro instead of that magic is more readable. >> --- >> libavcodec/dnxhddata.c | 10 +- >> libavcodec/dnxhddata.h | 3 +++ >> libavcodec/dnxhddec.c | 6 -- >> 3 files changed, 12 insertions(+), 7 deletions(-) >> >> [..] >> +/** Indicate that a CIDEntry value must be read in the bitstream */ >> +#define DNXHD_VARIABLE 0 >> + > > I'm all for more readable, presumably atm its only ever 0 but may change > in the future, in which case some idea of what it represents may be > useful, I am sure the spec has more than one variable ;) Actually, it's a convenience value, that we put there after noticing new samples. We don't have access to the DNxHR specs, but it seems a "profile" can have differing bitdepths. I haven't yet verified, but the frame header probably allows to distinguish them (DNXHD_VARIABLE applies to the HR version). I have, down the line, things that may need to split the HR versions. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: gdigrab work for DPI in windows
On 30 September 2015 at 02:48, wm4 wrote:
> On Wed, 23 Sep 2015 12:04:43 -0600
> Roger Pack wrote:
>
> > From 6a972dda58bd5ab31524cd4e5326b4bcdeaeaa8c Mon Sep 17 00:00:00 2001
> > From: rogerdpack
> > Date: Wed, 23 Sep 2015 12:03:27 -0600
> > Subject: [PATCH] gdigrab: grab right desktop size if DPI in use, based on
> > patch from Alexander Brotzge
> >
> > Signed-off-by: rogerdpack
> > ---
> > libavdevice/gdigrab.c | 44 +---
> > 1 file changed, 29 insertions(+), 15 deletions(-)
> >
> > diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
> > index 9a185d4..b0faf45 100644
> > --- a/libavdevice/gdigrab.c
> > +++ b/libavdevice/gdigrab.c
> > @@ -235,6 +235,9 @@ gdigrab_read_header(AVFormatContext *s1)
> > AVStream *st = NULL;
> >
> > int bpp;
> > +int vertres;
> > +int desktopvertres;
> > +float scale;
> > RECT virtual_rect;
> > RECT clip_rect;
> > BITMAP bmp;
> > @@ -263,14 +266,34 @@ gdigrab_read_header(AVFormatContext *s1)
> > goto error;
> > }
> >
> > -if (hwnd) {
> > -GetClientRect(hwnd, &virtual_rect);
> > -} else {
> > +/* This will get the device context for the selected window, or if
> > + * none, the primary screen */
> > +source_hdc = GetDC(hwnd);
> > +if (!source_hdc) {
> > +WIN32_API_ERROR("Couldn't get window device context");
> > +ret = AVERROR(EIO);
> > +goto error;
> > +}
> > +bpp = GetDeviceCaps(source_hdc, BITSPIXEL);
> > +
> > +scale = 1.0;
> > +if (hwnd == NULL) {
> > + /* desktop -- get the right height and width for scaling DPI */
> > + vertres = GetDeviceCaps(source_hdc, VERTRES);
> > + desktopvertres = GetDeviceCaps(source_hdc, DESKTOPVERTRES);
> > + scale = (float) desktopvertres / (float) vertres;
> > +}
>
This seems a little redundant as scale is only being set when hwnd is null
however in the below lines its then being used in the opposite conditional.
Since this checks for hwnd essentially being non null then scale is always
going to be the inital value of 1.
> > + if (hwnd) {
> > + GetClientRect(hwnd, &virtual_rect);
> > + virtual_rect.right = virtual_rect.right * scale;
> > + virtual_rect.bottom = virtual_rect.bottom * scale;
> > + } else {
> > virtual_rect.left = GetSystemMetrics(SM_XVIRTUALSCREEN);
> > virtual_rect.top = GetSystemMetrics(SM_YVIRTUALSCREEN);
> > -virtual_rect.right = virtual_rect.left +
> GetSystemMetrics(SM_CXVIRTUALSCREEN);
> > -virtual_rect.bottom = virtual_rect.top +
> GetSystemMetrics(SM_CYVIRTUALSCREEN);
> > -}
> > +virtual_rect.right = (virtual_rect.left +
> GetSystemMetrics(SM_CXVIRTUALSCREEN)) * scale;
> > +virtual_rect.bottom = (virtual_rect.top +
> GetSystemMetrics(SM_CYVIRTUALSCREEN)) * scale;
> > + }
>
This if else could be combined with the above if as scale is only a value
different to 1 in the 'else' case. Also as wm4 said it would probably be
better to keep the scale factors as ints.
> >
> > /* If no width or height set, use full screen/window area */
> > if (!gdigrab->width || !gdigrab->height) {
> > @@ -299,15 +322,6 @@ gdigrab_read_header(AVFormatContext *s1)
> > goto error;
> > }
> >
> > -/* This will get the device context for the selected window, or if
> > - * none, the primary screen */
> > -source_hdc = GetDC(hwnd);
> > -if (!source_hdc) {
> > -WIN32_API_ERROR("Couldn't get window device context");
> > -ret = AVERROR(EIO);
> > -goto error;
> > -}
> > -bpp = GetDeviceCaps(source_hdc, BITSPIXEL);
> >
> > if (name) {
> > av_log(s1, AV_LOG_INFO,
However I think the basic dpi scaling technique is correct. However I would
think it should be more along the lines of the modifications Ive attached.
0001-gdigrab-grab-right-desktop-size-if-DPI-in-use-based-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: 16bpp tm/dc/h/v intra pred simd (mostly sse2) functions.
On 3 October 2015 at 21:05, Ronald S. Bultje wrote:
> ---
> libavcodec/x86/Makefile | 1 +
> libavcodec/x86/constants.c | 4 +
> libavcodec/x86/constants.h | 2 +
> libavcodec/x86/h264_idct_10bit.asm | 5 +-
> libavcodec/x86/h264_intrapred_10bit.asm | 2 +-
> libavcodec/x86/vp9dsp_init.h| 23 ++
> libavcodec/x86/vp9dsp_init_16bpp.c | 15 +
> libavcodec/x86/vp9dsp_init_16bpp_template.c | 7 +
> libavcodec/x86/vp9intrapred_16bpp.asm | 615
>
> 9 files changed, 669 insertions(+), 5 deletions(-)
> create mode 100644 libavcodec/x86/vp9intrapred_16bpp.asm
>
> diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
> index 01e5f18..5ff3a77 100644
> --- a/libavcodec/x86/Makefile
> +++ b/libavcodec/x86/Makefile
> @@ -158,6 +158,7 @@ YASM-OBJS-$(CONFIG_VC1_DECODER)+= x86/vc1dsp.o
> YASM-OBJS-$(CONFIG_VORBIS_DECODER) += x86/vorbisdsp.o
> YASM-OBJS-$(CONFIG_VP6_DECODER)+= x86/vp6dsp.o
> YASM-OBJS-$(CONFIG_VP9_DECODER)+= x86/vp9intrapred.o\
> + x86/vp9intrapred_16bpp.o \
>x86/vp9itxfm.o\
>x86/vp9lpf.o \
>x86/vp9lpf_16bpp.o\
> diff --git a/libavcodec/x86/constants.c b/libavcodec/x86/constants.c
> index 9f3c8b4..19345f5 100644
> --- a/libavcodec/x86/constants.c
> +++ b/libavcodec/x86/constants.c
> @@ -81,3 +81,7 @@ DECLARE_ALIGNED(16, const xmm_reg, ff_ps_neg) = {
> 0x80008000ULL, 0x800
>
> DECLARE_ALIGNED(32, const ymm_reg, ff_pd_1)= {
> 0x00010001ULL, 0x00010001ULL,
>
> 0x00010001ULL, 0x00010001ULL };
> +DECLARE_ALIGNED(32, const ymm_reg, ff_pd_16) = {
> 0x00100010ULL, 0x00100010ULL,
> +
> 0x00100010ULL, 0x00100010ULL };
> +DECLARE_ALIGNED(32, const ymm_reg, ff_pd_32) = {
> 0x00200020ULL, 0x00200020ULL,
> +
> 0x00200020ULL, 0x00200020ULL };
> diff --git a/libavcodec/x86/constants.h b/libavcodec/x86/constants.h
> index 37a1869..4a2451d 100644
> --- a/libavcodec/x86/constants.h
> +++ b/libavcodec/x86/constants.h
> @@ -63,5 +63,7 @@ extern const uint64_t ff_pb_FC;
> extern const xmm_reg ff_ps_neg;
>
> extern const ymm_reg ff_pd_1;
> +extern const ymm_reg ff_pd_16;
> +extern const ymm_reg ff_pd_32;
>
> #endif /* AVCODEC_X86_CONSTANTS_H */
> diff --git a/libavcodec/x86/h264_idct_10bit.asm
> b/libavcodec/x86/h264_idct_10bit.asm
> index cc115b0..f1c2c81 100644
> --- a/libavcodec/x86/h264_idct_10bit.asm
> +++ b/libavcodec/x86/h264_idct_10bit.asm
> @@ -24,14 +24,11 @@
>
> %include "libavutil/x86/x86util.asm"
>
> -SECTION_RODATA
> -
> -pd_32:times 4 dd 32
> -
> SECTION .text
>
> cextern pw_1023
> %define pw_pixel_max pw_1023
> +cextern pd_32
>
>
>
> ;-
> ; void ff_h264_idct_add_10(pixel *dst, int16_t *block, int stride)
> diff --git a/libavcodec/x86/h264_intrapred_10bit.asm
> b/libavcodec/x86/h264_intrapred_10bit.asm
> index 9aeb702..9e40cfe 100644
> --- a/libavcodec/x86/h264_intrapred_10bit.asm
> +++ b/libavcodec/x86/h264_intrapred_10bit.asm
> @@ -34,11 +34,11 @@ cextern pw_8
> cextern pw_4
> cextern pw_2
> cextern pw_1
> +cextern pd_16
>
> pw_m32101234: dw -3, -2, -1, 0, 1, 2, 3, 4
> pw_m3:times 8 dw -3
> pd_17:times 4 dd 17
> -pd_16:times 4 dd 16
>
> SECTION .text
>
> diff --git a/libavcodec/x86/vp9dsp_init.h b/libavcodec/x86/vp9dsp_init.h
> index d1a9514..47d2246 100644
> --- a/libavcodec/x86/vp9dsp_init.h
> +++ b/libavcodec/x86/vp9dsp_init.h
> @@ -41,6 +41,18 @@ decl_mc_func(avg, sz, h, opt, type, fsz, bpp); \
> decl_mc_func(put, sz, v, opt, type, fsz, bpp); \
> decl_mc_func(avg, sz, v, opt, type, fsz, bpp)
>
> +#define decl_ipred_fn(type, sz, bpp, opt) \
> +void ff_vp9_ipred_##type##_##sz##x##sz##_##bpp##_##opt(uint8_t *dst, \
> + ptrdiff_t stride, \
> + const uint8_t *l, \
> + const uint8_t *a)
> +
> +#define decl_ipred_fns(type, bpp, opt4, opt8_16_32) \
> +decl_ipred_fn(type, 4, bpp, opt4); \
> +decl_ipred_fn(type, 8, bpp, opt8_16_32); \
> +decl_ipred_fn(type, 16, bpp, opt8_16_32); \
> +decl_ipred_fn(type, 32, bpp, opt8_16_32)
> +
> #define mc_rep_func(avg, sz, hsz, hszb, dir, opt, type, f_sz, bpp) \
> static av_always_inline void \
> ff_vp9_##avg##_8tap_1d_##dir##_##sz##_##bpp##_##opt(uint8_t *dst,
> ptrdiff_t dst_stride, \
> @@ -142,6 +154,17 @@ filters_8tap_2d_fn(op, 4, align, bpp, bytes, opt4,
> f_opt)
> init_subpel3_8to64(idx, type, bpp, opt); \
> init_subpel2(4, idx, 4, type, bpp, opt)
Re: [FFmpeg-devel] [PATCH 5/5] dnxhddec: replace some 0s by DNXHD_VARIABLE
On 05/10/15 08:51, Christophe Gisquet wrote: > Hi, > > 2015-10-05 8:44 GMT+02:00 tim nicholson : >> On 02/10/15 20:00, Christophe Gisquet wrote: >>> A series of 0 in a table can be confusing, and the corresponding checks >>> strange, so using a macro instead of that magic is more readable. >>> --- >>> libavcodec/dnxhddata.c | 10 +- >>> libavcodec/dnxhddata.h | 3 +++ >>> libavcodec/dnxhddec.c | 6 -- >>> 3 files changed, 12 insertions(+), 7 deletions(-) >>> >>> [..] >>> +/** Indicate that a CIDEntry value must be read in the bitstream */ >>> +#define DNXHD_VARIABLE 0 >>> + >> >> I'm all for more readable, presumably atm its only ever 0 but may change >> in the future, in which case some idea of what it represents may be >> useful, I am sure the spec has more than one variable ;) > > Actually, it's a convenience value, that we put there after noticing > new samples. > > We don't have access to the DNxHR specs, but it seems a "profile" can > have differing bitdepths. I haven't yet verified, but the frame header > probably allows to distinguish them (DNXHD_VARIABLE applies to the HR > version). > That's fine, I just thought there ought to be a better name for it. Just calling it VARIABLE begs the question "what is variable?" If you are trying to make the code clearer, give some clue as to what it relates to. However if atm you aren't quite sure but think it might be handy later, then I can see that that becomes a bit difficult. I thought JJ had got hold of a copy of the specs... > I have, down the line, things that may need to split the HR versions. > -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: gdigrab work for DPI in windows
On 5 October 2015 at 19:29, Matt Oliver wrote:
> On 30 September 2015 at 02:48, wm4 wrote:
>
>> On Wed, 23 Sep 2015 12:04:43 -0600
>> Roger Pack wrote:
>>
>> > From 6a972dda58bd5ab31524cd4e5326b4bcdeaeaa8c Mon Sep 17 00:00:00 2001
>> > From: rogerdpack
>> > Date: Wed, 23 Sep 2015 12:03:27 -0600
>> > Subject: [PATCH] gdigrab: grab right desktop size if DPI in use, based
>> on
>> > patch from Alexander Brotzge
>> >
>> > Signed-off-by: rogerdpack
>> > ---
>> > libavdevice/gdigrab.c | 44 +---
>> > 1 file changed, 29 insertions(+), 15 deletions(-)
>> >
>> > diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
>> > index 9a185d4..b0faf45 100644
>> > --- a/libavdevice/gdigrab.c
>> > +++ b/libavdevice/gdigrab.c
>> > @@ -235,6 +235,9 @@ gdigrab_read_header(AVFormatContext *s1)
>> > AVStream *st = NULL;
>> >
>> > int bpp;
>> > +int vertres;
>> > +int desktopvertres;
>> > +float scale;
>> > RECT virtual_rect;
>> > RECT clip_rect;
>> > BITMAP bmp;
>> > @@ -263,14 +266,34 @@ gdigrab_read_header(AVFormatContext *s1)
>> > goto error;
>> > }
>> >
>> > -if (hwnd) {
>> > -GetClientRect(hwnd, &virtual_rect);
>> > -} else {
>> > +/* This will get the device context for the selected window, or if
>> > + * none, the primary screen */
>> > +source_hdc = GetDC(hwnd);
>> > +if (!source_hdc) {
>> > +WIN32_API_ERROR("Couldn't get window device context");
>> > +ret = AVERROR(EIO);
>> > +goto error;
>> > +}
>> > +bpp = GetDeviceCaps(source_hdc, BITSPIXEL);
>> > +
>> > +scale = 1.0;
>> > +if (hwnd == NULL) {
>> > + /* desktop -- get the right height and width for scaling DPI */
>> > + vertres = GetDeviceCaps(source_hdc, VERTRES);
>> > + desktopvertres = GetDeviceCaps(source_hdc, DESKTOPVERTRES);
>> > + scale = (float) desktopvertres / (float) vertres;
>> > +}
>>
>
> This seems a little redundant as scale is only being set when hwnd is null
> however in the below lines its then being used in the opposite conditional.
> Since this checks for hwnd essentially being non null then scale is always
> going to be the inital value of 1.
>
>
>> > + if (hwnd) {
>> > + GetClientRect(hwnd, &virtual_rect);
>> > + virtual_rect.right = virtual_rect.right * scale;
>> > + virtual_rect.bottom = virtual_rect.bottom * scale;
>> > + } else {
>> > virtual_rect.left = GetSystemMetrics(SM_XVIRTUALSCREEN);
>> > virtual_rect.top = GetSystemMetrics(SM_YVIRTUALSCREEN);
>> > -virtual_rect.right = virtual_rect.left +
>> GetSystemMetrics(SM_CXVIRTUALSCREEN);
>> > -virtual_rect.bottom = virtual_rect.top +
>> GetSystemMetrics(SM_CYVIRTUALSCREEN);
>> > -}
>> > +virtual_rect.right = (virtual_rect.left +
>> GetSystemMetrics(SM_CXVIRTUALSCREEN)) * scale;
>> > +virtual_rect.bottom = (virtual_rect.top +
>> GetSystemMetrics(SM_CYVIRTUALSCREEN)) * scale;
>> > + }
>>
>
> This if else could be combined with the above if as scale is only a value
> different to 1 in the 'else' case. Also as wm4 said it would probably be
> better to keep the scale factors as ints.
>
>
>> >
>> > /* If no width or height set, use full screen/window area */
>> > if (!gdigrab->width || !gdigrab->height) {
>> > @@ -299,15 +322,6 @@ gdigrab_read_header(AVFormatContext *s1)
>> > goto error;
>> > }
>> >
>> > -/* This will get the device context for the selected window, or if
>> > - * none, the primary screen */
>> > -source_hdc = GetDC(hwnd);
>> > -if (!source_hdc) {
>> > -WIN32_API_ERROR("Couldn't get window device context");
>> > -ret = AVERROR(EIO);
>> > -goto error;
>> > -}
>> > -bpp = GetDeviceCaps(source_hdc, BITSPIXEL);
>> >
>> > if (name) {
>> > av_log(s1, AV_LOG_INFO,
>
>
> However I think the basic dpi scaling technique is correct. However I
> would think it should be more along the lines of the modifications Ive
> attached.
>
Woops, allow me to try that again without windows messing up the patches
line endings.
0001-gdigrab-grab-right-desktop-size-if-DPI-in-use-based-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: add x86 SIMD for anaglyph outputs
Signed-off-by: Paul B Mahol
---
libavfilter/stereo3d.h | 36
libavfilter/vf_stereo3d.c | 70 +++---
libavfilter/x86/Makefile | 2 +
libavfilter/x86/vf_stereo3d.asm| 184 +
libavfilter/x86/vf_stereo3d_init.c | 37
5 files changed, 297 insertions(+), 32 deletions(-)
create mode 100644 libavfilter/stereo3d.h
create mode 100644 libavfilter/x86/vf_stereo3d.asm
create mode 100644 libavfilter/x86/vf_stereo3d_init.c
diff --git a/libavfilter/stereo3d.h b/libavfilter/stereo3d.h
new file mode 100644
index 000..e7a8456
--- /dev/null
+++ b/libavfilter/stereo3d.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef LIBAVFILTER_STEREO3D_H
+#define LIBAVFILTER_STEREO3D_H
+
+#include
+#include
+
+typedef struct Stereo3DDSPContext {
+void (*anaglyph)(uint8_t *dst, uint8_t *lsrc, uint8_t *rsrc,
+ ptrdiff_t dst_linesize, ptrdiff_t l_linesize, ptrdiff_t
r_linesize,
+ int width, int height,
+ const int *ana_matrix_r, const int *ana_matrix_g, const
int *ana_matrix_b);
+} Stereo3DDSPContext;
+
+void ff_stereo3d_init_x86(Stereo3DDSPContext *dsp);
+
+#endif /* LIBAVFILTER_STEREO3D_H */
diff --git a/libavfilter/vf_stereo3d.c b/libavfilter/vf_stereo3d.c
index f9d344a..8e9cc83 100644
--- a/libavfilter/vf_stereo3d.c
+++ b/libavfilter/vf_stereo3d.c
@@ -30,6 +30,7 @@
#include "formats.h"
#include "internal.h"
#include "video.h"
+#include "stereo3d.h"
enum StereoCode {
ANAGLYPH_RC_GRAY, // anaglyph red/cyan gray
@@ -150,6 +151,7 @@ typedef struct Stereo3DContext {
double ts_unit;
int blanks;
int in_off_left[4], in_off_right[4];
+Stereo3DDSPContext dsp;
} Stereo3DContext;
#define OFFSET(x) offsetof(Stereo3DContext, x)
@@ -300,6 +302,37 @@ static int query_formats(AVFilterContext *ctx)
return ff_set_common_formats(ctx, fmts_list);
}
+static inline uint8_t ana_convert(const int *coeff, const uint8_t *left, const
uint8_t *right)
+{
+int sum;
+
+sum = coeff[0] * left[0] + coeff[3] * right[0]; //red in
+sum += coeff[1] * left[1] + coeff[4] * right[1]; //green in
+sum += coeff[2] * left[2] + coeff[5] * right[2]; //blue in
+
+return av_clip_uint8(sum >> 16);
+}
+
+static void anaglyph(uint8_t *dst, uint8_t *lsrc, uint8_t *rsrc,
+ ptrdiff_t dst_linesize, ptrdiff_t l_linesize, ptrdiff_t
r_linesize,
+ int width, int height,
+ const int *ana_matrix_r, const int *ana_matrix_g, const
int *ana_matrix_b)
+{
+int x, y, o;
+
+for (y = 0; y < height; y++) {
+for (o = 0, x = 0; x < width; x++, o+= 3) {
+dst[o] = ana_convert(ana_matrix_r, lsrc + o, rsrc + o);
+dst[o + 1] = ana_convert(ana_matrix_g, lsrc + o, rsrc + o);
+dst[o + 2] = ana_convert(ana_matrix_b, lsrc + o, rsrc + o);
+}
+
+dst += dst_linesize;
+lsrc += l_linesize;
+rsrc += r_linesize;
+}
+}
+
static int config_output(AVFilterLink *outlink)
{
AVFilterContext *ctx = outlink->src;
@@ -517,38 +550,11 @@ static int config_output(AVFilterLink *outlink)
s->hsub = desc->log2_chroma_w;
s->vsub = desc->log2_chroma_h;
-return 0;
-}
-
-static inline uint8_t ana_convert(const int *coeff, const uint8_t *left, const
uint8_t *right)
-{
-int sum;
-
-sum = coeff[0] * left[0] + coeff[3] * right[0]; //red in
-sum += coeff[1] * left[1] + coeff[4] * right[1]; //green in
-sum += coeff[2] * left[2] + coeff[5] * right[2]; //blue in
-
-return av_clip_uint8(sum >> 16);
-}
+s->dsp.anaglyph = anaglyph;
+if (ARCH_X86)
+ff_stereo3d_init_x86(&s->dsp);
-static void anaglyph(uint8_t *dst, uint8_t *lsrc, uint8_t *rsrc,
- ptrdiff_t dst_linesize, ptrdiff_t l_linesize, ptrdiff_t
r_linesize,
- int width, int height,
- const int *ana_matrix_r, const int *ana_matrix_g, const
int *ana_matrix_b)
-{
-int x, y, o;
-
-for (y = 0; y < height; y++) {
-for (o = 0, x = 0; x < width; x++, o+= 3) {
-dst[o] = ana_convert(a
Re: [FFmpeg-devel] [PATCH] vp9: 16bpp tm/dc/h/v intra pred simd (mostly sse2) functions.
On Mon, Oct 5, 2015 at 10:55 AM, Matt Oliver wrote: > This patch has broken the 32bit msvc builds: > http://fate.ffmpeg.org/report.cgi?time=20151005065109&slot=x86_32-msvc12-windows-native > > I had a look through the code but couldnt find the cause. The error message > just points to the code line for a macro instantiation and I'm not familiar > enough with the code to be able to work out where within the macro the > error is actually occurring and why. So ill leave this one to someone more > familiar with the code. I see where the problem is. Using stack space in cglobal requires an extra register if the stack alignment is less than mmsize (32-bit msvc only has 4-byte stack alignment), and if the function already utilizes all available registers that will result in failure. The fix is either to reduce the number of registers used by the function or to only enable the function on x86-32 if the stack is at least 16-byte aligned. x86inc has the variable STACK_ALIGNMENT which can be tested for this, in C there's the HAVE_ALIGNED_STACK define which is set if the stack is 16-byte aligned. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] dnxhddec: replace some 0s by DNXHD_VARIABLE
Hi, 2015-10-05 10:57 GMT+02:00 tim nicholson : > I thought JJ had got hold of a copy of the specs... He was quick to notice the 2014 ones do not cover DNxHR. But the bitstream doesn't seem to depart that much from the old stuff, and ffmpeg's output after this patch series seems adequate. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/9] dnxhddec: cleanup frame header parsing
On Sun, Oct 04, 2015 at 10:25:57AM +0200, Christophe Gisquet wrote: > Hi, > > 2015-10-03 19:50 GMT+02:00 Carl Eugen Hoyos : > > Looks unintended... > > Indeed. Patch updated. > > -- > Christophe > dnxhddec.c | 54 +++--- > 1 file changed, 27 insertions(+), 27 deletions(-) > b69c1b0e102f770f4eb64f8417ea638ea2637679 > 0001-dnxhddec-cleanup-frame-header-parsing.patch > From 122919f117fd02597d7d341f94c3d5214a2a8b39 Mon Sep 17 00:00:00 2001 > From: Christophe Gisquet > Date: Fri, 2 Oct 2015 21:00:44 +0200 > Subject: [PATCH 1/8] dnxhddec: cleanup frame header parsing > > Rely more on the actual syntax from the specs (also seen in the > encoder code). applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/9] dnxhd: profile flags
On Sat, Oct 03, 2015 at 06:59:15PM +0200, Christophe Gisquet wrote: > Move the 'interlaced' flag to this element (arbitrarily set to 16bits). > This should allow better detection/selection of profiles. > --- > libavcodec/dnxhddata.c | 49 - > libavcodec/dnxhddata.h | 6 +- > 2 files changed, 37 insertions(+), 18 deletions(-) applied thanks [...] -- 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 3/9] dnxhdenc: do not select 4:4:4 profiles
On Sat, Oct 03, 2015 at 06:59:16PM +0200, Christophe Gisquet wrote: > The encoder can only deal with 4:2:2. > --- > libavcodec/dnxhddata.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/9] dnxhddec: Introduce DNXHD_VARIABLE
On Sat, Oct 03, 2015 at 06:59:17PM +0200, Christophe Gisquet wrote: > Currently not used, but will be used to indicate that a CIDEntry field > is not set, because it is variable, and that checks should be adapted. > --- > libavcodec/dnxhddata.h | 3 +++ > libavcodec/dnxhddec.c | 6 -- > 2 files changed, 7 insertions(+), 2 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/9] dnxhd: add decoder support for DNxHR
On Sat, Oct 03, 2015 at 06:59:19PM +0200, Christophe Gisquet wrote: > From: Jeremy James > > Signed-off-by: Christophe Gisquet > --- > libavcodec/dnxhddata.c | 8 > libavcodec/dnxhddec.c | 3 ++- > 2 files changed, 10 insertions(+), 1 deletion(-) applied thanks [...] -- 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 5/9] isom: add support for DNxHR codec family
On Sat, Oct 03, 2015 at 06:59:18PM +0200, Christophe Gisquet wrote: > This is actually similar to DNxHD. > --- > libavformat/isom.c | 1 + > 1 file changed, 1 insertion(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 7/9] dnxhd: add CID 1270
On Sat, Oct 03, 2015 at 06:59:20PM +0200, Christophe Gisquet wrote: > This a 4:4:4 10 bits profile, where image size is not fixed by the > profile, and which strays a bit outside the old frame header parsing > code. > > Fixes ticket #4581 (DNxHR is not stricly supported, but that sequence is). > --- > libavcodec/dnxhddata.c | 24 > libavcodec/dnxhddec.c | 2 +- > 2 files changed, 17 insertions(+), 9 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 8/9] dnxhd: add better support for CIDs 1270 to 1274
On Sun, Oct 04, 2015 at 10:30:08AM +0200, Christophe Gisquet wrote: > 2015-10-03 18:59 GMT+02:00 Christophe Gisquet : > [SNIP] > > There was a blank space in there (I think). > > Patch updated > > -- > Christophe > dnxhddata.c | 64 ++--- > dnxhddec.c | 92 > ++-- > 2 files changed, 118 insertions(+), 38 deletions(-) > ff9107f35d53c0842c01dae4902818e94da5aecc > 0008-dnxhd-add-better-support-for-CIDs-1270-to-1274.patch > From bd07892dd122f30e7a7ed88231deab0ade04161e Mon Sep 17 00:00:00 2001 > From: Jeremy James > Date: Mon, 28 Sep 2015 16:28:12 +0100 > Subject: [PATCH 8/8] dnxhd: add better support for CIDs 1270 to 1274 applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/9] Initial support for DNxHR, v2
On Sat, Oct 03, 2015 at 06:59:13PM +0200, Christophe Gisquet wrote: > Cleaned up version of v1, with the first patches fixing bugs exacerbated > by the following new code, in general improving the current code so as to > introduce DNxHR. > > DNxHR is then added progressively, in particular the extended handling > needed. > > Christophe Gisquet (7): > dnxhddec: cleanup frame header parsing > dnxhd: profile flags > dnxhdenc: do not select 4:4:4 profiles > dnxhddec: Introduce DNXHD_VARIABLE > isom: add support for DNxHR codec family > dnxhd: add CID 1270 do you have any testcases you can share for these ? thanks [...] -- 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] vp9: 16bpp tm/dc/h/v intra pred simd (mostly sse2) functions.
Hi, On Mon, Oct 5, 2015 at 5:54 AM, Henrik Gramner wrote: > On Mon, Oct 5, 2015 at 10:55 AM, Matt Oliver wrote: > > This patch has broken the 32bit msvc builds: > > > http://fate.ffmpeg.org/report.cgi?time=20151005065109&slot=x86_32-msvc12-windows-native > > > > I had a look through the code but couldnt find the cause. The error > message > > just points to the code line for a macro instantiation and I'm not > familiar > > enough with the code to be able to work out where within the macro the > > error is actually occurring and why. So ill leave this one to someone > more > > familiar with the code. > > I see where the problem is. > > Using stack space in cglobal requires an extra register if the stack > alignment is less than mmsize (32-bit msvc only has 4-byte stack > alignment), and if the function already utilizes all available > registers that will result in failure. > > The fix is either to reduce the number of registers used by the > function or to only enable the function on x86-32 if the stack is at > least 16-byte aligned. x86inc has the variable STACK_ALIGNMENT which > can be tested for this, in C there's the HAVE_ALIGNED_STACK define > which is set if the stack is 16-byte aligned. Yeah, it should use 6 regs, I'll send a patch. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vp9: fix msvc build by using 6 GPRs on 32bit if stack!=aligned.
--- libavcodec/x86/vp9intrapred_16bpp.asm | 10 ++ 1 file changed, 10 insertions(+) diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm b/libavcodec/x86/vp9intrapred_16bpp.asm index 0dca645..3653469 100644 --- a/libavcodec/x86/vp9intrapred_16bpp.asm +++ b/libavcodec/x86/vp9intrapred_16bpp.asm @@ -1634,8 +1634,13 @@ cglobal vp9_ipred_hu_16x16_16, 3, 4, 6 + notcpuflag(ssse3), dst, stride, l, a jg .loop RET +%if ARCH_X86_64 || HAVE_ALIGNED_STACK cglobal vp9_ipred_hu_32x32_16, 3, 7, 10 + notcpuflag(ssse3), \ %1 * mmsize * ARCH_X86_32, dst, stride, l, a +%else +cglobal vp9_ipred_hu_32x32_16, 3, 6, 10 + notcpuflag(ssse3), \ + %1 * mmsize * ARCH_X86_32, dst, stride, l, a +%endif movam2, [lq+mmsize*0+0] movum1, [lq+mmsize*0+2] movum0, [lq+mmsize*0+4] @@ -1666,7 +1671,12 @@ cglobal vp9_ipred_hu_32x32_16, 3, 7, 10 + notcpuflag(ssse3), \ SBUTTERFLY wd, 7, 6, 0 pshufd m1, m1, q UNSCRATCH0, 9, rsp+1*mmsize +%if ARCH_X86_64 || HAVE_ALIGNED_STACK DEFINE_ARGS dst, stride, cnt, stride3, stride4, stride20, stride28 +%else +DEFINE_ARGS dst, stride, stride3, stride4, stride20, stride28 +%define cntd dword r0m +%endif lea stride3q, [strideq*3] lea stride4q, [strideq*4] lea stride28q, [stride4q*8] -- 2.1.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 9/9] dnxhdenc: fix scan used for bitstream generation
Hi, 2015-10-04 4:14 GMT+02:00 Michael Niedermayer : > ./ffmpeg -f lavfi -i testsrc=s=1440x1080 -vframes 1 -pix_fmt yuv422p -vcodec > dnxhd -vb 80M -flags +ildct file.mov btw this afaik uses CID 1260 which has a particular feature, MBAFF-like. While we do handle it since a few revision, I suspect we shouldn't validate the encoder output against our decoder. CID 1260 should be blacklisted (it's planned, but...). It does not invalidate the experiment (checking interlaced handling in the encoder) that has to be made, though. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/9] Initial support for DNxHR, v2
Hi, 2015-10-05 13:18 GMT+02:00 Michael Niedermayer : > do you have any testcases you can share for these ? I was provided some but that I assume not redistributable. I asked the same question but got no reply. There's this one sequence here that I assume to be redistributable: https://trac.ffmpeg.org/ticket/4581 which is CID1270 but according to the little info here: http://avid.force.com/pkb/articles/en_US/White_Paper/DNxHR-Codec-Bandwidth-Specifications it might be out of specs (but we do support it), so not the best example. https://trac.ffmpeg.org/ticket/4876 might be interesting because it exposed a previously unsupported feature (MBAFF like) in profile CID 1260. Not HR, but still useful. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] avformat/mxfenc: stop encoding if unfilled video packet
On 05.10.2015 09:10, tim nicholson wrote: On 04/10/15 13:07, Tomas Härdin wrote: On Mon, 2015-09-28 at 15:11 +0200, Tobias Rapp wrote: [...] For me the most important thing is that anything dealing with MXF should never write invalid files. +1 for sure. To overstate your point: So it would be OK to skip most input frames and replace them with black frames as long as the output file is valid MXF? I think there are different requirements for determining what makes an "error" depending on the use-case. If I try to recover video frames from an broken hard disk, for example, I probably won't mind some lost frames. If I try to encode a video file from a presumably healthy input file I likely care about lost frames. I'm not sure whether the current code is broken per se, but it does look suspicious. Perhaps someone else has a better idea? Truncate/pad mis sized frames to allow muxing to continue, and issue a warning (as at present)? It is currently quite difficult to ensure that all frames have been transcoded if there is only a warning in the log message because AFAIK the only generic way to separate a info log message from a warning is to parse terminal color code sequences. The other solution would be to maintain a RegEx black-list of log output messages in the parent process. Wouldn't it be helpful to introduce some flag option like "-flags +xerror" on avformat level to toggle between "recover as much as possible" mode and "encode all or fail" mode? Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov: add support for sidx fragment indexes
On Sat, 3 Oct 2015 11:57:03 -0500
Rodger Combs wrote:
> Fixes trac #3842
> ---
> libavformat/isom.h | 2 +
> libavformat/mov.c | 250
> -
> 2 files changed, 213 insertions(+), 39 deletions(-)
>
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index aee9d6e..6e921c0 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -103,6 +103,7 @@ typedef struct MOVSbgp {
> typedef struct MOVFragmentIndexItem {
> int64_t moof_offset;
> int64_t time;
> +int headers_read;
> } MOVFragmentIndexItem;
>
> typedef struct MOVFragmentIndex {
> @@ -197,6 +198,7 @@ typedef struct MOVContext {
> int has_looked_for_mfra;
> MOVFragmentIndex** fragment_index_data;
> unsigned fragment_index_count;
> +int fragment_index_complete;
> int atom_depth;
> unsigned int aax_mode; ///< 'aax' file has been detected
> uint8_t file_key[20];
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index da170a6..5aa7491 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3349,7 +3349,7 @@ static int mov_read_tfhd(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> MOVFragment *frag = &c->fragment;
> MOVTrackExt *trex = NULL;
> MOVFragmentIndex* index = NULL;
> -int flags, track_id, i;
> +int flags, track_id, i, found = 0;
>
> avio_r8(pb); /* version */
> flags = avio_rb24(pb);
> @@ -3367,15 +3367,6 @@ static int mov_read_tfhd(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> av_log(c->fc, AV_LOG_ERROR, "could not find corresponding trex\n");
> return AVERROR_INVALIDDATA;
> }
> -for (i = 0; i < c->fragment_index_count; i++) {
> -MOVFragmentIndex* candidate = c->fragment_index_data[i];
> -if (candidate->track_id == frag->track_id) {
> -av_log(c->fc, AV_LOG_DEBUG,
> - "found fragment index for track %u\n", frag->track_id);
> -index = candidate;
> -break;
> -}
> -}
>
> frag->base_data_offset = flags & MOV_TFHD_BASE_DATA_OFFSET ?
> avio_rb64(pb) : flags &
> MOV_TFHD_DEFAULT_BASE_IS_MOOF ?
> @@ -3389,23 +3380,32 @@ static int mov_read_tfhd(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> frag->flags= flags & MOV_TFHD_DEFAULT_FLAGS ?
> avio_rb32(pb) : trex->flags;
> frag->time = AV_NOPTS_VALUE;
> -if (index) {
> -int i, found = 0;
> -for (i = index->current_item; i < index->item_count; i++) {
> -if (frag->implicit_offset == index->items[i].moof_offset) {
> -av_log(c->fc, AV_LOG_DEBUG, "found fragment index entry "
> -"for track %u and moof_offset %"PRId64"\n",
> -frag->track_id, index->items[i].moof_offset);
> -frag->time = index->items[i].time;
> -index->current_item = i + 1;
> -found = 1;
> +for (i = 0; i < c->fragment_index_count; i++) {
> +int j;
> +MOVFragmentIndex* candidate = c->fragment_index_data[i];
> +if (candidate->track_id == frag->track_id) {
> +av_log(c->fc, AV_LOG_DEBUG,
> + "found fragment index for track %u\n", frag->track_id);
> +index = candidate;
> +for (j = index->current_item; j < index->item_count; j++) {
> +if (frag->implicit_offset == index->items[j].moof_offset) {
> +av_log(c->fc, AV_LOG_DEBUG, "found fragment index entry "
> +"for track %u and moof_offset %"PRId64"\n",
> +frag->track_id, index->items[j].moof_offset);
> +frag->time = index->items[j].time;
> +index->current_item = j + 1;
> +found = 1;
> +break;
> +}
> }
> +if (found)
> +break;
> }
> -if (!found) {
> -av_log(c->fc, AV_LOG_WARNING, "track %u has a fragment index "
> - "but it doesn't have an (in-order) entry for moof_offset "
> - "%"PRId64"\n", frag->track_id, frag->implicit_offset);
> -}
> +}
> +if (index && !found) {
> +av_log(c->fc, AV_LOG_DEBUG, "track %u has a fragment index but "
> + "it doesn't have an (in-order) entry for moof_offset "
> + "%"PRId64"\n", frag->track_id, frag->implicit_offset);
> }
> av_log(c->fc, AV_LOG_TRACE, "frag flags 0x%x\n", frag->flags);
> return 0;
> @@ -3596,7 +3596,99 @@ static int mov_read_trun(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> return AVERROR_EOF;
>
> frag->implicit_offset = offset;
> -st->duration = sc->track_end = dts + sc->time_offset;
> +
> +sc->track_end = dts + sc->time_offset;
> +if (st->duration < sc->track_end)
> +st->duration = s
Re: [FFmpeg-devel] [PATCH] lavf/mov: add support for sidx fragment indexes
2015-10-04 1:57 GMT+09:00 Rodger Combs :
> Fixes trac #3842
> ---
> libavformat/isom.h | 2 +
> libavformat/mov.c | 250
> -
> 2 files changed, 213 insertions(+), 39 deletions(-)
>
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index aee9d6e..6e921c0 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -103,6 +103,7 @@ typedef struct MOVSbgp {
> typedef struct MOVFragmentIndexItem {
> int64_t moof_offset;
> int64_t time;
> +int headers_read;
> } MOVFragmentIndexItem;
>
> typedef struct MOVFragmentIndex {
> @@ -197,6 +198,7 @@ typedef struct MOVContext {
> int has_looked_for_mfra;
> MOVFragmentIndex** fragment_index_data;
> unsigned fragment_index_count;
> +int fragment_index_complete;
> int atom_depth;
> unsigned int aax_mode; ///< 'aax' file has been detected
> uint8_t file_key[20];
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index da170a6..5aa7491 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3349,7 +3349,7 @@ static int mov_read_tfhd(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> MOVFragment *frag = &c->fragment;
> MOVTrackExt *trex = NULL;
> MOVFragmentIndex* index = NULL;
> -int flags, track_id, i;
> +int flags, track_id, i, found = 0;
>
> avio_r8(pb); /* version */
> flags = avio_rb24(pb);
> @@ -3367,15 +3367,6 @@ static int mov_read_tfhd(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> av_log(c->fc, AV_LOG_ERROR, "could not find corresponding
> trex\n");
> return AVERROR_INVALIDDATA;
> }
> -for (i = 0; i < c->fragment_index_count; i++) {
> -MOVFragmentIndex* candidate = c->fragment_index_data[i];
> -if (candidate->track_id == frag->track_id) {
> -av_log(c->fc, AV_LOG_DEBUG,
> - "found fragment index for track %u\n", frag->track_id);
> -index = candidate;
> -break;
> -}
> -}
>
> frag->base_data_offset = flags & MOV_TFHD_BASE_DATA_OFFSET ?
> avio_rb64(pb) : flags &
> MOV_TFHD_DEFAULT_BASE_IS_MOOF ?
> @@ -3389,23 +3380,32 @@ static int mov_read_tfhd(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
> frag->flags= flags & MOV_TFHD_DEFAULT_FLAGS ?
> avio_rb32(pb) : trex->flags;
> frag->time = AV_NOPTS_VALUE;
> -if (index) {
> -int i, found = 0;
> -for (i = index->current_item; i < index->item_count; i++) {
> -if (frag->implicit_offset == index->items[i].moof_offset) {
> -av_log(c->fc, AV_LOG_DEBUG, "found fragment index entry "
> -"for track %u and moof_offset %"PRId64"\n",
> -frag->track_id, index->items[i].moof_offset);
> -frag->time = index->items[i].time;
> -index->current_item = i + 1;
> -found = 1;
> +for (i = 0; i < c->fragment_index_count; i++) {
> +int j;
> +MOVFragmentIndex* candidate = c->fragment_index_data[i];
> +if (candidate->track_id == frag->track_id) {
> +av_log(c->fc, AV_LOG_DEBUG,
> + "found fragment index for track %u\n", frag->track_id);
> +index = candidate;
> +for (j = index->current_item; j < index->item_count; j++) {
> +if (frag->implicit_offset == index->items[j].moof_offset)
> {
> +av_log(c->fc, AV_LOG_DEBUG, "found fragment index
> entry "
> +"for track %u and moof_offset %"PRId64"\n",
> +frag->track_id, index->items[j].moof_offset);
> +frag->time = index->items[j].time;
> +index->current_item = j + 1;
> +found = 1;
> +break;
> +}
> }
> +if (found)
> +break;
> }
> -if (!found) {
> -av_log(c->fc, AV_LOG_WARNING, "track %u has a fragment index "
> - "but it doesn't have an (in-order) entry for
> moof_offset "
> - "%"PRId64"\n", frag->track_id, frag->implicit_offset);
> -}
> +}
> +if (index && !found) {
> +av_log(c->fc, AV_LOG_DEBUG, "track %u has a fragment index but "
> + "it doesn't have an (in-order) entry for moof_offset "
> + "%"PRId64"\n", frag->track_id, frag->implicit_offset);
> }
> av_log(c->fc, AV_LOG_TRACE, "frag flags 0x%x\n", frag->flags);
> return 0;
> @@ -3596,7 +3596,99 @@ static int mov_read_trun(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> return AVERROR_EOF;
>
> frag->implicit_offset = offset;
> -st->duration = sc->track_end = dts + sc->time_offset;
> +
> +sc->track_end = dts + sc->time_offset;
> +if (st->duration < sc->track_end)
> +st->duration = sc->track_end;
> +
> +
Re: [FFmpeg-devel] [PATCH] vp9: fix msvc build by using 6 GPRs on 32bit if stack!=aligned.
On Mon, Oct 5, 2015 at 1:39 PM, Ronald S. Bultje wrote: > --- > libavcodec/x86/vp9intrapred_16bpp.asm | 10 ++ > 1 file changed, 10 insertions(+) Lgtm. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: add x86 SIMD for anaglyph outputs
On 10/5/2015 6:49 AM, Paul B Mahol wrote: > diff --git a/libavfilter/x86/vf_stereo3d.asm b/libavfilter/x86/vf_stereo3d.asm > new file mode 100644 > index 000..269004b > --- /dev/null > +++ b/libavfilter/x86/vf_stereo3d.asm > @@ -0,0 +1,184 @@ > +;* > +;* x86-optimized functions for stereo3d filter > +;* > +;* Copyright (C) 2015 Paul B Mahol > +;* > +;* This file is part of FFmpeg. > +;* > +;* FFmpeg is free software; you can redistribute it and/or > +;* modify it under the terms of the GNU Lesser General Public > +;* License as published by the Free Software Foundation; either > +;* version 2.1 of the License, or (at your option) any later version. > +;* > +;* FFmpeg is distributed in the hope that it will be useful, > +;* but WITHOUT ANY WARRANTY; without even the implied warranty of > +;* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > +;* Lesser General Public License for more details. > +;* > +;* You should have received a copy of the GNU Lesser General Public > +;* License along with FFmpeg; if not, write to the Free Software > +;* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 > USA > +;* > + > +%include "libavutil/x86/x86util.asm" > + > +%if ARCH_X86_64 > + > +SECTION_RODATA > + > +; rgbrgbrgbrgb > +; > + > +shuf: db 0, 4, 8, 1,5, 9, 2, 6,10,3, 7,11,-1,-1,-1,-1 > +ex_r: db 0,-1,-1,-1,3,-1,-1,-1,6,-1,-1,-1, 9,-1,-1,-1 > +ex_g: db 1,-1,-1,-1,4,-1,-1,-1,7,-1,-1,-1,10,-1,-1,-1 > +ex_b: db 2,-1,-1,-1,5,-1,-1,-1,8,-1,-1,-1,11,-1,-1,-1 > + > +SECTION .text > + > +INIT_XMM sse4 > +cglobal anaglyph, 11, 13, 16, 3*6*mmsize, dst, lsrc, rsrc, dst_linesize, > l_linesize, r_linesize, width, height, ana_matrix_r, ana_matrix_g, > ana_matrix_b > +movd m10, [ana_matrix_rq+ 0] > +movd m11, [ana_matrix_rq+ 4] > +movd m12, [ana_matrix_rq+ 8] > +movd m13, [ana_matrix_rq+12] > +movd m14, [ana_matrix_rq+16] > +movd m15, [ana_matrix_rq+20] > +pshufd m10, m10, q > +pshufd m11, m11, q > +pshufd m12, m12, q > +pshufd m13, m13, q > +pshufd m14, m14, q > +pshufd m15, m15, q mova m13, [ana_matrix_rq + 0] movq m15, [ana_matrix_rq + 16] pshufd m10, m13, q pshufd m11, m13, q pshufd m12, m13, q pshufd m13, m13, q pshufd m14, m15, q pshufd m15, m15, q Will probably be faster. Also, you're not using m7 anywhere, and m13, m14 and m15 remain unused after the init code. You could keep four of the coeffs in them instead of using stack. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/attributes: add av_warn_unused_result
On Mon, Oct 05, 2015 at 01:45:12AM -0400, Ganesh Ajjanagadde wrote: > GCC 3.4 introduced an attribute warn_unused_result to warn when a programmer > discards the return value. Applying this judiciously across the codebase can > help > in fixing a lot of problems. At a high level, functions which return error > codes > should always be checked. More concretely, consider the functions > ff_add_format > and the like in avfilter/formats.h. A quick examination shows that a large > portion > of libavfilter fails to handle the associated errors, usually AVERROR(ENOMEM). > The above example was where I observed the utility of this, but it should be > useful in many places across the code base. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavutil/attributes.h | 6 ++ > 1 file changed, 6 insertions(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/3] Miscellaneous improvements
Fixing different issues occurring when playing around encoder and decoder. Christophe Gisquet (3): dnxhddec: better support for 4:4:4 dnxhddata: introduce and use MBAFF flag dnxhdenc: mark CID 1260 encoder experimental libavcodec/dnxhddata.c | 7 - libavcodec/dnxhddata.h | 3 +- libavcodec/dnxhddec.c | 82 ++ 3 files changed, 70 insertions(+), 22 deletions(-) -- 2.5.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] dnxhddec: better support for 4:4:4
Profiles 1256 & 1270 (currently) signal at the frame header and MB
levels the colorspace used, either RGB or YUV. While a MB-level
varying colorspace is not supported, whether it is constant can be
tracked so as to determine the exact colorspace.
It is not tested against a true RGB sequence, though.
---
libavcodec/dnxhddec.c | 82 ++-
1 file changed, 62 insertions(+), 20 deletions(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index fec9aac..52fd334 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -43,6 +43,8 @@ typedef struct RowContext {
int last_dc[3];
int last_qscale;
int errors;
+/** -1:not set yet 0:off=RGB 1:on=YUV 2:variable */
+int format;
} RowContext;
typedef struct DNXHDContext {
@@ -202,6 +204,18 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame
*frame,
}
ctx->avctx->bits_per_raw_sample = ctx->bit_depth;
+cid = AV_RB32(buf + 0x28);
+if ((ret = dnxhd_init_vlc(ctx, cid)) < 0)
+return ret;
+if (ctx->mbaff && ctx->cid_table->cid != 1260)
+av_log(ctx->avctx, AV_LOG_WARNING,
+ "Adaptive MB interlace flag in an unsupported profile.\n");
+
+ctx->act = buf[0x2C] & 7;
+if (ctx->act && ctx->cid_table->cid != 1256 && ctx->cid_table->cid != 1270)
+av_log(ctx->avctx, AV_LOG_WARNING,
+ "Adaptive color transform in an unsupported profile.\n");
+
ctx->is_444 = (buf[0x2C] >> 6) & 1;
if (ctx->is_444) {
if (ctx->bit_depth == 8) {
@@ -209,10 +223,12 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame
*frame,
return AVERROR_INVALIDDATA;
} else if (ctx->bit_depth == 10) {
ctx->decode_dct_block = dnxhd_decode_dct_block_10_444;
-ctx->pix_fmt = AV_PIX_FMT_YUV444P10;
+ctx->pix_fmt = ctx->act ? AV_PIX_FMT_YUV444P10
+: AV_PIX_FMT_GBRP10;
} else {
ctx->decode_dct_block = dnxhd_decode_dct_block_12_444;
-ctx->pix_fmt = AV_PIX_FMT_YUV444P12;
+ctx->pix_fmt = ctx->act ? AV_PIX_FMT_YUV444P12
+: AV_PIX_FMT_GBRP12;
}
} else if (ctx->bit_depth == 12) {
ctx->decode_dct_block = dnxhd_decode_dct_block_12;
@@ -231,19 +247,6 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame
*frame,
ff_zigzag_direct);
}
-cid = AV_RB32(buf + 0x28);
-
-if ((ret = dnxhd_init_vlc(ctx, cid)) < 0)
-return ret;
-if (ctx->mbaff && ctx->cid_table->cid != 1260)
-av_log(ctx->avctx, AV_LOG_WARNING,
- "Adaptive MB interlace flag in an unsupported profile.\n");
-
-ctx->act = buf[0x2C] & 7;
-if (ctx->act && ctx->cid_table->cid != 1256 && ctx->cid_table->cid != 1270)
-av_log(ctx->avctx, AV_LOG_WARNING,
- "Adaptive color transform in an unsupported profile.\n");
-
// make sure profile size constraints are respected
// DNx100 allows 1920->1440 and 1280->960 subsampling
if (ctx->width != ctx->cid_table->width &&
@@ -462,11 +465,17 @@ static int dnxhd_decode_macroblock(const DNXHDContext
*ctx, RowContext *row,
}
act = get_bits1(&row->gb);
if (act) {
-static int warned = 0;
-if (!warned) {
-warned = 1;
-av_log(ctx->avctx, AV_LOG_ERROR,
- "Unsupported adaptive color transform, patch welcome.\n");
+if (!ctx->act) {
+static int act_warned = 0;
+if (!act_warned) {
+act_warned = 1;
+av_log(ctx->avctx, AV_LOG_ERROR,
+ "ACT flag set, in violation of frame header.\n");
+}
+} else if (row->format == -1) {
+row->format = act;
+} else if (row->format != act) {
+row->format = 2; // Variable
}
}
@@ -577,6 +586,9 @@ static int dnxhd_decode_frame(AVCodecContext *avctx, void
*data,
ff_dlog(avctx, "frame size %d\n", buf_size);
+for (i = 0; i < avctx->thread_count; i++)
+ctx->rows[i].format = -1;
+
decode_coding_unit:
if ((ret = dnxhd_decode_header(ctx, picture, buf, buf_size, first_field))
< 0)
return ret;
@@ -622,6 +634,36 @@ decode_coding_unit:
ctx->rows[i].errors = 0;
}
+if (ctx->act) {
+static int act_warned = 0;
+int format = ctx->rows[0].format;
+for (i = 1; i < avctx->thread_count; i++) {
+if (ctx->rows[i].format != format &&
+ctx->rows[i].format != -1 /* not run */) {
+format = 2;
+break;
+}
+}
+switch (format) {
+case -1:
+case 2:
+if (!act_warned) {
+act_warned = 1;
+av_log(ctx->avctx, AV_LOG_ERROR,
+ "Unsupported: variable ACT flag.\n");
+
[FFmpeg-devel] [PATCH 3/3] dnxhdenc: mark CID 1260 encoder experimental
The MBAFF handling recently introduced on the decoder side shows that
the encoder does not support it correctly. Therefore, make the related
profile experimental.
Furthermore, current encoder logic treats it as unable to encode as
progressive, which isn't the case.
---
libavcodec/dnxhddata.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
index ffc8018..d8027b5 100644
--- a/libavcodec/dnxhddata.c
+++ b/libavcodec/dnxhddata.c
@@ -1158,6 +1158,11 @@ int ff_dnxhd_find_cid(AVCodecContext *avctx, int
bit_depth)
if (cid->width == avctx->width && cid->height == avctx->height &&
interlaced == !!(avctx->flags & AV_CODEC_FLAG_INTERLACED_DCT) &&
!(cid->flags & DNXHD_444) && cid->bit_depth == bit_depth) {
+if (avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL &&
+cid->flags & DNXHD_MBAFF) {
+av_log(avctx, AV_LOG_WARNING, "Profile selected is
experimental");
+continue;
+}
for (j = 0; j < FF_ARRAY_ELEMS(cid->bit_rates); j++) {
if (cid->bit_rates[j] == mbs)
return cid->cid;
--
2.5.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] dnxhddata: introduce and use MBAFF flag
MBAFF-like handling of interlaced content in CID 1260 is different from
the other CIDs, and in particular doesn't use the same syntax.
---
libavcodec/dnxhddata.c | 2 +-
libavcodec/dnxhddata.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
index 241ce23..ffc8018 100644
--- a/libavcodec/dnxhddata.c
+++ b/libavcodec/dnxhddata.c
@@ -1072,7 +1072,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
dnxhd_1237_run_codes, dnxhd_1237_run_bits, dnxhd_1237_run,
{ 63, 84, 100, 110 } },
{ 1260, 1440, 1080, 835584, 417792,
- DNXHD_INTERLACED, 4, 8, 3,
+ DNXHD_INTERLACED | DNXHD_MBAFF, 4, 8, 3,
dnxhd_1260_luma_weight, dnxhd_1260_chroma_weight,
dnxhd_1237_dc_codes, dnxhd_1237_dc_bits,
dnxhd_1237_ac_codes, dnxhd_1237_ac_bits, dnxhd_1237_ac_level,
diff --git a/libavcodec/dnxhddata.h b/libavcodec/dnxhddata.h
index e960fc9..a1fcf06 100644
--- a/libavcodec/dnxhddata.h
+++ b/libavcodec/dnxhddata.h
@@ -28,7 +28,8 @@
/** Additional profile info flags */
#define DNXHD_INTERLACED (1<<0)
-#define DNXHD_444 (1<<1)
+#define DNXHD_MBAFF(1<<1)
+#define DNXHD_444 (1<<2)
/** Indicate that a CIDEntry value must be read in the bitstream */
#define DNXHD_VARIABLE 0
--
2.5.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avfilter/formats: add av_warn_unused_result to function prototypes
This uses the av_warn_unused_result attribute liberally to catch some forms of
improper
usage of functions defined in avfilter/formats.h.
Signed-off-by: Ganesh Ajjanagadde
---
libavfilter/formats.h | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/libavfilter/formats.h b/libavfilter/formats.h
index 5a8ee5e..e01be4a 100644
--- a/libavfilter/formats.h
+++ b/libavfilter/formats.h
@@ -116,25 +116,25 @@ typedef struct AVFilterChannelLayouts {
* If a and b do not share any common elements, neither is modified, and NULL
* is returned.
*/
-AVFilterChannelLayouts *ff_merge_channel_layouts(AVFilterChannelLayouts *a,
+av_warn_unused_result AVFilterChannelLayouts
*ff_merge_channel_layouts(AVFilterChannelLayouts *a,
AVFilterChannelLayouts *b);
-AVFilterFormats *ff_merge_samplerates(AVFilterFormats *a,
+av_warn_unused_result AVFilterFormats *ff_merge_samplerates(AVFilterFormats *a,
AVFilterFormats *b);
/**
* Construct an empty AVFilterChannelLayouts/AVFilterFormats struct --
* representing any channel layout (with known disposition)/sample rate.
*/
-AVFilterChannelLayouts *ff_all_channel_layouts(void);
-AVFilterFormats *ff_all_samplerates(void);
+av_warn_unused_result AVFilterChannelLayouts *ff_all_channel_layouts(void);
+av_warn_unused_result AVFilterFormats *ff_all_samplerates(void);
/**
* Construct an AVFilterChannelLayouts coding for any channel layout, with
* known or unknown disposition.
*/
-AVFilterChannelLayouts *ff_all_channel_counts(void);
+av_warn_unused_result AVFilterChannelLayouts *ff_all_channel_counts(void);
-AVFilterChannelLayouts *avfilter_make_format64_list(const int64_t *fmts);
+av_warn_unused_result AVFilterChannelLayouts
*avfilter_make_format64_list(const int64_t *fmts);
/**
@@ -142,9 +142,9 @@ AVFilterChannelLayouts *avfilter_make_format64_list(const
int64_t *fmts);
* layouts/sample rates. If there are no links hooked to this filter, the list
* is freed.
*/
-int ff_set_common_channel_layouts(AVFilterContext *ctx,
+av_warn_unused_result int ff_set_common_channel_layouts(AVFilterContext *ctx,
AVFilterChannelLayouts *layouts);
-int ff_set_common_samplerates(AVFilterContext *ctx,
+av_warn_unused_result int ff_set_common_samplerates(AVFilterContext *ctx,
AVFilterFormats *samplerates);
/**
@@ -152,14 +152,14 @@ int ff_set_common_samplerates(AVFilterContext *ctx,
* formats. If there are no links hooked to this filter, the list of formats is
* freed.
*/
-int ff_set_common_formats(AVFilterContext *ctx, AVFilterFormats *formats);
+av_warn_unused_result int ff_set_common_formats(AVFilterContext *ctx,
AVFilterFormats *formats);
-int ff_add_channel_layout(AVFilterChannelLayouts **l, uint64_t channel_layout);
+av_warn_unused_result int ff_add_channel_layout(AVFilterChannelLayouts **l,
uint64_t channel_layout);
/**
* Add *ref as a new reference to f.
*/
-int ff_channel_layouts_ref(AVFilterChannelLayouts *f,
+av_warn_unused_result int ff_channel_layouts_ref(AVFilterChannelLayouts *f,
AVFilterChannelLayouts **ref);
/**
@@ -170,7 +170,7 @@ void ff_channel_layouts_unref(AVFilterChannelLayouts **ref);
void ff_channel_layouts_changeref(AVFilterChannelLayouts **oldref,
AVFilterChannelLayouts **newref);
-int ff_default_query_formats(AVFilterContext *ctx);
+av_warn_unused_result int ff_default_query_formats(AVFilterContext *ctx);
/**
* Set the formats list to all existing formats.
@@ -178,7 +178,7 @@ int ff_default_query_formats(AVFilterContext *ctx);
* accepts channel layouts with unknown disposition. It should only be used
* with audio filters.
*/
-int ff_query_formats_all(AVFilterContext *ctx);
+av_warn_unused_result int ff_query_formats_all(AVFilterContext *ctx);
/**
@@ -188,7 +188,7 @@ int ff_query_formats_all(AVFilterContext *ctx);
* @param fmts list of media formats, terminated by -1
* @return the format list, with no existing references
*/
-AVFilterFormats *ff_make_format_list(const int *fmts);
+av_warn_unused_result AVFilterFormats *ff_make_format_list(const int *fmts);
/**
* Add fmt to the list of media formats contained in *avff.
@@ -198,17 +198,17 @@ AVFilterFormats *ff_make_format_list(const int *fmts);
* @return a non negative value in case of success, or a negative
* value corresponding to an AVERROR code in case of error
*/
-int ff_add_format(AVFilterFormats **avff, int64_t fmt);
+av_warn_unused_result int ff_add_format(AVFilterFormats **avff, int64_t fmt);
/**
* Return a list of all formats supported by FFmpeg for the given media type.
*/
-AVFilterFormats *ff_all_formats(enum AVMediaType type);
+av_warn_unused_result AVFilterFormats *ff_all_formats(enum AVMediaType type);
/**
* Construct a formats list containing all pl
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/formats: add av_warn_unused_result to function prototypes
On Mon, Oct 5, 2015 at 3:20 PM, Ganesh Ajjanagadde
wrote:
> This uses the av_warn_unused_result attribute liberally to catch some forms
> of improper
> usage of functions defined in avfilter/formats.h.
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavfilter/formats.h | 38 +++---
> 1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/libavfilter/formats.h b/libavfilter/formats.h
> index 5a8ee5e..e01be4a 100644
> --- a/libavfilter/formats.h
> +++ b/libavfilter/formats.h
> @@ -116,25 +116,25 @@ typedef struct AVFilterChannelLayouts {
> * If a and b do not share any common elements, neither is modified, and NULL
> * is returned.
> */
> -AVFilterChannelLayouts *ff_merge_channel_layouts(AVFilterChannelLayouts *a,
> +av_warn_unused_result AVFilterChannelLayouts
> *ff_merge_channel_layouts(AVFilterChannelLayouts *a,
> AVFilterChannelLayouts *b);
> -AVFilterFormats *ff_merge_samplerates(AVFilterFormats *a,
> +av_warn_unused_result AVFilterFormats *ff_merge_samplerates(AVFilterFormats
> *a,
>AVFilterFormats *b);
>
> /**
> * Construct an empty AVFilterChannelLayouts/AVFilterFormats struct --
> * representing any channel layout (with known disposition)/sample rate.
> */
> -AVFilterChannelLayouts *ff_all_channel_layouts(void);
> -AVFilterFormats *ff_all_samplerates(void);
> +av_warn_unused_result AVFilterChannelLayouts *ff_all_channel_layouts(void);
> +av_warn_unused_result AVFilterFormats *ff_all_samplerates(void);
>
> /**
> * Construct an AVFilterChannelLayouts coding for any channel layout, with
> * known or unknown disposition.
> */
> -AVFilterChannelLayouts *ff_all_channel_counts(void);
> +av_warn_unused_result AVFilterChannelLayouts *ff_all_channel_counts(void);
>
> -AVFilterChannelLayouts *avfilter_make_format64_list(const int64_t *fmts);
> +av_warn_unused_result AVFilterChannelLayouts
> *avfilter_make_format64_list(const int64_t *fmts);
>
>
> /**
> @@ -142,9 +142,9 @@ AVFilterChannelLayouts *avfilter_make_format64_list(const
> int64_t *fmts);
> * layouts/sample rates. If there are no links hooked to this filter, the
> list
> * is freed.
> */
> -int ff_set_common_channel_layouts(AVFilterContext *ctx,
> +av_warn_unused_result int ff_set_common_channel_layouts(AVFilterContext *ctx,
>AVFilterChannelLayouts *layouts);
> -int ff_set_common_samplerates(AVFilterContext *ctx,
> +av_warn_unused_result int ff_set_common_samplerates(AVFilterContext *ctx,
>AVFilterFormats *samplerates);
>
> /**
> @@ -152,14 +152,14 @@ int ff_set_common_samplerates(AVFilterContext *ctx,
> * formats. If there are no links hooked to this filter, the list of formats
> is
> * freed.
> */
> -int ff_set_common_formats(AVFilterContext *ctx, AVFilterFormats *formats);
> +av_warn_unused_result int ff_set_common_formats(AVFilterContext *ctx,
> AVFilterFormats *formats);
>
> -int ff_add_channel_layout(AVFilterChannelLayouts **l, uint64_t
> channel_layout);
> +av_warn_unused_result int ff_add_channel_layout(AVFilterChannelLayouts **l,
> uint64_t channel_layout);
>
> /**
> * Add *ref as a new reference to f.
> */
> -int ff_channel_layouts_ref(AVFilterChannelLayouts *f,
> +av_warn_unused_result int ff_channel_layouts_ref(AVFilterChannelLayouts *f,
> AVFilterChannelLayouts **ref);
>
> /**
> @@ -170,7 +170,7 @@ void ff_channel_layouts_unref(AVFilterChannelLayouts
> **ref);
> void ff_channel_layouts_changeref(AVFilterChannelLayouts **oldref,
>AVFilterChannelLayouts **newref);
>
> -int ff_default_query_formats(AVFilterContext *ctx);
> +av_warn_unused_result int ff_default_query_formats(AVFilterContext *ctx);
>
> /**
> * Set the formats list to all existing formats.
> @@ -178,7 +178,7 @@ int ff_default_query_formats(AVFilterContext *ctx);
> * accepts channel layouts with unknown disposition. It should only be used
> * with audio filters.
> */
> -int ff_query_formats_all(AVFilterContext *ctx);
> +av_warn_unused_result int ff_query_formats_all(AVFilterContext *ctx);
>
>
> /**
> @@ -188,7 +188,7 @@ int ff_query_formats_all(AVFilterContext *ctx);
> * @param fmts list of media formats, terminated by -1
> * @return the format list, with no existing references
> */
> -AVFilterFormats *ff_make_format_list(const int *fmts);
> +av_warn_unused_result AVFilterFormats *ff_make_format_list(const int *fmts);
>
> /**
> * Add fmt to the list of media formats contained in *avff.
> @@ -198,17 +198,17 @@ AVFilterFormats *ff_make_format_list(const int *fmts);
> * @return a non negative value in case of success, or a negative
> * value corresponding to an AVERROR code in case of error
> */
> -int ff_add_format(AVFilterFormats **avff, int64_t fmt);
> +av_warn_unused_result int ff_add_format(AVFilterFormats **avff, int64_t fmt);
>
> /**
>
[FFmpeg-devel] [PATCH 1/2] avfilter/all: propagate errors of functions from avfilter/formats
Hi, I have attached the patch. Thanks, Ganesh From 990253559e14d9075ab6a29cab0991ea2fe4fc3b Mon Sep 17 00:00:00 2001 From: Ganesh Ajjanagadde Date: Sun, 4 Oct 2015 23:39:25 -0400 Subject: [PATCH 1/2] avfilter/all: propagate errors of functions from avfilter/formats Many of the functions from avfilter/formats can return errors, usually AVERROR(ENOMEM). This propagates the return values. All of these were found by using av_warn_unused_result, demonstrating its utility. The second patch in this series adds av_warn_unused_result to avfilter/formats. There are two reasons for this ordering: 1. Applying the other patch first will result in a huge number of noisy warnings. This patch first corrects the behavior, so that the second patch does not trigger any "warning regressions". 2. I have currently used av_warn_unused_result liberally in the second patch, since I see no loss and only benefits as outlined in its justification. However, a policy should be adopted regarding when to use av_warn_unused_result, and consensus may be difficult to achieve. Tested with FATE. I am least sure of the changes to avfilter/filtergraph, since I don't know what/how reduce_format is intended to behave and how it should react to errors. Signed-off-by: Ganesh Ajjanagadde --- libavfilter/aeval.c| 33 --- libavfilter/af_aformat.c | 14 +++- libavfilter/af_agate.c | 3 ++- libavfilter/af_amerge.c| 33 --- libavfilter/af_amix.c | 8 +-- libavfilter/af_aresample.c | 35 - libavfilter/af_astreamsync.c | 25 +++-- libavfilter/af_channelmap.c| 21 - libavfilter/af_channelsplit.c | 21 +++-- libavfilter/af_earwax.c| 20 - libavfilter/af_extrastereo.c | 17 ++ libavfilter/af_join.c | 20 - libavfilter/af_pan.c | 26 - libavfilter/af_replaygain.c| 29 +--- libavfilter/af_resample.c | 46 -- libavfilter/af_sidechaincompress.c | 19 libavfilter/af_stereotools.c | 17 ++ libavfilter/af_stereowiden.c | 16 + libavfilter/asrc_anullsrc.c| 8 --- libavfilter/asrc_flite.c | 23 ++- libavfilter/avf_aphasemeter.c | 24 +++- libavfilter/avf_avectorscope.c | 23 ++- libavfilter/avf_concat.c | 32 +- libavfilter/avf_showcqt.c | 21 + libavfilter/avf_showfreqs.c| 21 + libavfilter/avf_showspectrum.c | 21 + libavfilter/avf_showvolume.c | 21 + libavfilter/avf_showwaves.c| 21 + libavfilter/avfiltergraph.c| 29 +--- libavfilter/buffersink.c | 21 - libavfilter/buffersrc.c| 33 +++ libavfilter/drawutils.c| 6 +++-- libavfilter/f_drawgraph.c | 6 - libavfilter/f_ebur128.c| 27 -- libavfilter/formats.c | 15 ++--- libavfilter/src_movie.c| 16 - libavfilter/vf_alphamerge.c| 23 ++- libavfilter/vf_boxblur.c | 13 +++ libavfilter/vf_crop.c | 13 +++ libavfilter/vf_detelecine.c| 13 +++ libavfilter/vf_displace.c | 4 +++- libavfilter/vf_elbg.c | 6 +++-- libavfilter/vf_extractplanes.c | 8 --- libavfilter/vf_fieldorder.c| 7 -- libavfilter/vf_frei0r.c| 12 +++--- libavfilter/vf_hflip.c | 13 +++ libavfilter/vf_histogram.c | 7 -- libavfilter/vf_il.c| 14 libavfilter/vf_maskedmerge.c | 3 +-- libavfilter/vf_mergeplanes.c | 22 +- libavfilter/vf_neighbor.c | 3 +-- libavfilter/vf_noise.c | 11 ++--- libavfilter/vf_overlay.c | 36 - libavfilter/vf_palettegen.c| 11 +++-- libavfilter/vf_paletteuse.c| 16 ++--- libavfilter/vf_scale.c | 9 ++-- libavfilter/vf_showpalette.c | 11 +++-- libavfilter/vf_stack.c | 13 +++ libavfilter/vf_swapuv.c| 12 ++ libavfilter/vf_telecine.c | 13 +++ libavfilter/vf_transpose.c | 13 +++ libavfilter/vf_vectorscope.c | 8 --- libavfilter/vsrc_life.c| 6 - 63 files changed, 812 insertions(+), 279 deletions(-) diff --git a/libavfilter/aeval.c b/libavfilter/aeval.c index b6c420a..c10e2af 100644 --- a/libavfilter/aeval.c ++
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/formats: add av_warn_unused_result to function prototypes
On Mon, Oct 5, 2015 at 3:23 PM, Ganesh Ajjanagadde
wrote:
> On Mon, Oct 5, 2015 at 3:20 PM, Ganesh Ajjanagadde
> wrote:
>> This uses the av_warn_unused_result attribute liberally to catch some forms
>> of improper
>> usage of functions defined in avfilter/formats.h.
>>
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavfilter/formats.h | 38 +++---
>> 1 file changed, 19 insertions(+), 19 deletions(-)
>>
>> diff --git a/libavfilter/formats.h b/libavfilter/formats.h
>> index 5a8ee5e..e01be4a 100644
>> --- a/libavfilter/formats.h
>> +++ b/libavfilter/formats.h
>> @@ -116,25 +116,25 @@ typedef struct AVFilterChannelLayouts {
>> * If a and b do not share any common elements, neither is modified, and
>> NULL
>> * is returned.
>> */
>> -AVFilterChannelLayouts *ff_merge_channel_layouts(AVFilterChannelLayouts *a,
>> +av_warn_unused_result AVFilterChannelLayouts
>> *ff_merge_channel_layouts(AVFilterChannelLayouts *a,
>> AVFilterChannelLayouts *b);
>> -AVFilterFormats *ff_merge_samplerates(AVFilterFormats *a,
>> +av_warn_unused_result AVFilterFormats *ff_merge_samplerates(AVFilterFormats
>> *a,
>>AVFilterFormats *b);
>>
>> /**
>> * Construct an empty AVFilterChannelLayouts/AVFilterFormats struct --
>> * representing any channel layout (with known disposition)/sample rate.
>> */
>> -AVFilterChannelLayouts *ff_all_channel_layouts(void);
>> -AVFilterFormats *ff_all_samplerates(void);
>> +av_warn_unused_result AVFilterChannelLayouts *ff_all_channel_layouts(void);
>> +av_warn_unused_result AVFilterFormats *ff_all_samplerates(void);
>>
>> /**
>> * Construct an AVFilterChannelLayouts coding for any channel layout, with
>> * known or unknown disposition.
>> */
>> -AVFilterChannelLayouts *ff_all_channel_counts(void);
>> +av_warn_unused_result AVFilterChannelLayouts *ff_all_channel_counts(void);
>>
>> -AVFilterChannelLayouts *avfilter_make_format64_list(const int64_t *fmts);
>> +av_warn_unused_result AVFilterChannelLayouts
>> *avfilter_make_format64_list(const int64_t *fmts);
>>
>>
>> /**
>> @@ -142,9 +142,9 @@ AVFilterChannelLayouts
>> *avfilter_make_format64_list(const int64_t *fmts);
>> * layouts/sample rates. If there are no links hooked to this filter, the
>> list
>> * is freed.
>> */
>> -int ff_set_common_channel_layouts(AVFilterContext *ctx,
>> +av_warn_unused_result int ff_set_common_channel_layouts(AVFilterContext
>> *ctx,
>>AVFilterChannelLayouts *layouts);
>> -int ff_set_common_samplerates(AVFilterContext *ctx,
>> +av_warn_unused_result int ff_set_common_samplerates(AVFilterContext *ctx,
>>AVFilterFormats *samplerates);
>>
>> /**
>> @@ -152,14 +152,14 @@ int ff_set_common_samplerates(AVFilterContext *ctx,
>> * formats. If there are no links hooked to this filter, the list of
>> formats is
>> * freed.
>> */
>> -int ff_set_common_formats(AVFilterContext *ctx, AVFilterFormats *formats);
>> +av_warn_unused_result int ff_set_common_formats(AVFilterContext *ctx,
>> AVFilterFormats *formats);
>>
>> -int ff_add_channel_layout(AVFilterChannelLayouts **l, uint64_t
>> channel_layout);
>> +av_warn_unused_result int ff_add_channel_layout(AVFilterChannelLayouts **l,
>> uint64_t channel_layout);
>>
>> /**
>> * Add *ref as a new reference to f.
>> */
>> -int ff_channel_layouts_ref(AVFilterChannelLayouts *f,
>> +av_warn_unused_result int ff_channel_layouts_ref(AVFilterChannelLayouts *f,
>> AVFilterChannelLayouts **ref);
>>
>> /**
>> @@ -170,7 +170,7 @@ void ff_channel_layouts_unref(AVFilterChannelLayouts
>> **ref);
>> void ff_channel_layouts_changeref(AVFilterChannelLayouts **oldref,
>>AVFilterChannelLayouts **newref);
>>
>> -int ff_default_query_formats(AVFilterContext *ctx);
>> +av_warn_unused_result int ff_default_query_formats(AVFilterContext *ctx);
>>
>> /**
>> * Set the formats list to all existing formats.
>> @@ -178,7 +178,7 @@ int ff_default_query_formats(AVFilterContext *ctx);
>> * accepts channel layouts with unknown disposition. It should only be used
>> * with audio filters.
>> */
>> -int ff_query_formats_all(AVFilterContext *ctx);
>> +av_warn_unused_result int ff_query_formats_all(AVFilterContext *ctx);
>>
>>
>> /**
>> @@ -188,7 +188,7 @@ int ff_query_formats_all(AVFilterContext *ctx);
>> * @param fmts list of media formats, terminated by -1
>> * @return the format list, with no existing references
>> */
>> -AVFilterFormats *ff_make_format_list(const int *fmts);
>> +av_warn_unused_result AVFilterFormats *ff_make_format_list(const int *fmts);
>>
>> /**
>> * Add fmt to the list of media formats contained in *avff.
>> @@ -198,17 +198,17 @@ AVFilterFormats *ff_make_format_list(const int *fmts);
>> * @return a non negative value in case of success, or a negative
>> * value corresponding to an A
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/formats: add av_warn_unused_result to function prototypes
Hi,
On Mon, Oct 5, 2015 at 3:20 PM, Ganesh Ajjanagadde
wrote:
> This uses the av_warn_unused_result attribute liberally to catch some
> forms of improper
> usage of functions defined in avfilter/formats.h.
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavfilter/formats.h | 38 +++---
> 1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/libavfilter/formats.h b/libavfilter/formats.h
> index 5a8ee5e..e01be4a 100644
> --- a/libavfilter/formats.h
> +++ b/libavfilter/formats.h
> @@ -116,25 +116,25 @@ typedef struct AVFilterChannelLayouts {
> * If a and b do not share any common elements, neither is modified, and
> NULL
> * is returned.
> */
> -AVFilterChannelLayouts *ff_merge_channel_layouts(AVFilterChannelLayouts
> *a,
> +av_warn_unused_result AVFilterChannelLayouts
> *ff_merge_channel_layouts(AVFilterChannelLayouts *a,
> AVFilterChannelLayouts
> *b);
> -AVFilterFormats *ff_merge_samplerates(AVFilterFormats *a,
> +av_warn_unused_result AVFilterFormats
> *ff_merge_samplerates(AVFilterFormats *a,
>AVFilterFormats *b);
I'm not sure this is the intention of warn_unused_result. My understanding
is that you use this for strict error reporting only, i.e. "you need to
check this return code for errors because it may fail!", not for "if you
don't store the result of this call, you're not using my API correctly".
The thing is, if I use ff_merge_samplerates() and I don't store the result,
my application cannot possibly function correctly. It's not possible for it
to function correctly. Imagine the following application:
int main() {
malloc(2);
return 0;
}
My application cannot possibly function as intended without storing the
result of malloc(). Yet I don't think anyone is seriously considering
marking malloc with warn_unused_result. Likewise, we should only use
warn_unused_result for cases where your application probably works
correctly without checking a return value, but you should check the return
value anyway because in real usage, the value may indicate problems that
the application should be aware of before continuing its operations, e.g.
avformat_open_input() or something like that.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] checkasm: add alacdsp tests
On Mon, Oct 5, 2015 at 12:50 AM, James Almer wrote: > Signed-off-by: James Almer > --- > tests/checkasm/Makefile | 1 + > tests/checkasm/alacdsp.c | 119 > ++ > tests/checkasm/checkasm.c | 3 ++ > tests/checkasm/checkasm.h | 1 + > 4 files changed, 124 insertions(+) > create mode 100644 tests/checkasm/alacdsp.c Lgtm. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/formats: add av_warn_unused_result to function prototypes
Hi,
On Mon, Oct 5, 2015 at 4:00 PM, Ganesh Ajjanagadde
wrote:
> On Mon, Oct 5, 2015 at 3:45 PM, Ronald S. Bultje
> wrote:
> > Hi,
> >
> > On Mon, Oct 5, 2015 at 3:20 PM, Ganesh Ajjanagadde <
> gajjanaga...@gmail.com>
> > wrote:
> >>
> >> This uses the av_warn_unused_result attribute liberally to catch some
> >> forms of improper
> >> usage of functions defined in avfilter/formats.h.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde
> >> ---
> >> libavfilter/formats.h | 38 +++---
> >> 1 file changed, 19 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/libavfilter/formats.h b/libavfilter/formats.h
> >> index 5a8ee5e..e01be4a 100644
> >> --- a/libavfilter/formats.h
> >> +++ b/libavfilter/formats.h
> >> @@ -116,25 +116,25 @@ typedef struct AVFilterChannelLayouts {
> >> * If a and b do not share any common elements, neither is modified,
> and
> >> NULL
> >> * is returned.
> >> */
> >> -AVFilterChannelLayouts *ff_merge_channel_layouts(AVFilterChannelLayouts
> >> *a,
> >> +av_warn_unused_result AVFilterChannelLayouts
> >> *ff_merge_channel_layouts(AVFilterChannelLayouts *a,
> >> AVFilterChannelLayouts
> >> *b);
> >> -AVFilterFormats *ff_merge_samplerates(AVFilterFormats *a,
> >> +av_warn_unused_result AVFilterFormats
> >> *ff_merge_samplerates(AVFilterFormats *a,
> >>AVFilterFormats *b);
> >
> >
> > I'm not sure this is the intention of warn_unused_result. My
> understanding
> > is that you use this for strict error reporting only, i.e. "you need to
> > check this return code for errors because it may fail!", not for "if you
> > don't store the result of this call, you're not using my API correctly".
> >
> > The thing is, if I use ff_merge_samplerates() and I don't store the
> result,
> > my application cannot possibly function correctly. It's not possible for
> it
> > to function correctly. Imagine the following application:
> >
> > int main() {
> > malloc(2);
> > return 0;
> > }
> >
> > My application cannot possibly function as intended without storing the
> > result of malloc(). Yet I don't think anyone is seriously considering
> > marking malloc with warn_unused_result. Likewise, we should only use
> > warn_unused_result for cases where your application probably works
> correctly
> > without checking a return value, but you should check the return value
> > anyway because in real usage, the value may indicate problems that the
> > application should be aware of before continuing its operations, e.g.
> > avformat_open_input() or something like that.
>
> Personally, I don't mind either way - I do know the original intent
> which is along the lines of what you wrote here, but I see no harm in
> extending to things like malloc, or in our case av_malloc. Of course
> the utility is greatly reduced, since as you point out essentially
> anyone who writes that kind of code (malloc(2), return 0) has no
> business writing C in general. Nevertheless, I don't understand the
> concrete harm - they are never false positives with things like
> malloc, and the only negative side effect is the more verbose
> declaration.
>
> In fact, it is this verbosity that makes me ambivalent between
> applying this liberally versus the standard, more cautious approach -
> otherwise I am all in favor of placing this pretty much all over.
I think we typically prefer to apply a policy/approach where one of the
goals is to write code (including interfaces in header files) that are as
small as possible. If we litter all our header files with all kind of
extraneous stuff that isn't really doing anything, they become somewhat
unreadable.
(I obviously am not claiming that adding one word to one line in one header
file is the difference between highly readable and unreadable, but it
suggests a general approach of trending towards smaller source code can be
one helpful argument in coming up with a proper decision here.)
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/formats: add av_warn_unused_result to function prototypes
On Mon, Oct 5, 2015 at 4:04 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Oct 5, 2015 at 4:00 PM, Ganesh Ajjanagadde
> wrote:
>>
>> On Mon, Oct 5, 2015 at 3:45 PM, Ronald S. Bultje
>> wrote:
>> > Hi,
>> >
>> > On Mon, Oct 5, 2015 at 3:20 PM, Ganesh Ajjanagadde
>> >
>> > wrote:
>> >>
>> >> This uses the av_warn_unused_result attribute liberally to catch some
>> >> forms of improper
>> >> usage of functions defined in avfilter/formats.h.
>> >>
>> >> Signed-off-by: Ganesh Ajjanagadde
>> >> ---
>> >> libavfilter/formats.h | 38 +++---
>> >> 1 file changed, 19 insertions(+), 19 deletions(-)
>> >>
>> >> diff --git a/libavfilter/formats.h b/libavfilter/formats.h
>> >> index 5a8ee5e..e01be4a 100644
>> >> --- a/libavfilter/formats.h
>> >> +++ b/libavfilter/formats.h
>> >> @@ -116,25 +116,25 @@ typedef struct AVFilterChannelLayouts {
>> >> * If a and b do not share any common elements, neither is modified,
>> >> and
>> >> NULL
>> >> * is returned.
>> >> */
>> >> -AVFilterChannelLayouts
>> >> *ff_merge_channel_layouts(AVFilterChannelLayouts
>> >> *a,
>> >> +av_warn_unused_result AVFilterChannelLayouts
>> >> *ff_merge_channel_layouts(AVFilterChannelLayouts *a,
>> >>
>> >> AVFilterChannelLayouts
>> >> *b);
>> >> -AVFilterFormats *ff_merge_samplerates(AVFilterFormats *a,
>> >> +av_warn_unused_result AVFilterFormats
>> >> *ff_merge_samplerates(AVFilterFormats *a,
>> >>AVFilterFormats *b);
>> >
>> >
>> > I'm not sure this is the intention of warn_unused_result. My
>> > understanding
>> > is that you use this for strict error reporting only, i.e. "you need to
>> > check this return code for errors because it may fail!", not for "if you
>> > don't store the result of this call, you're not using my API correctly".
>> >
>> > The thing is, if I use ff_merge_samplerates() and I don't store the
>> > result,
>> > my application cannot possibly function correctly. It's not possible for
>> > it
>> > to function correctly. Imagine the following application:
>> >
>> > int main() {
>> > malloc(2);
>> > return 0;
>> > }
>> >
>> > My application cannot possibly function as intended without storing the
>> > result of malloc(). Yet I don't think anyone is seriously considering
>> > marking malloc with warn_unused_result. Likewise, we should only use
>> > warn_unused_result for cases where your application probably works
>> > correctly
>> > without checking a return value, but you should check the return value
>> > anyway because in real usage, the value may indicate problems that the
>> > application should be aware of before continuing its operations, e.g.
>> > avformat_open_input() or something like that.
>>
>> Personally, I don't mind either way - I do know the original intent
>> which is along the lines of what you wrote here, but I see no harm in
>> extending to things like malloc, or in our case av_malloc. Of course
>> the utility is greatly reduced, since as you point out essentially
>> anyone who writes that kind of code (malloc(2), return 0) has no
>> business writing C in general. Nevertheless, I don't understand the
>> concrete harm - they are never false positives with things like
>> malloc, and the only negative side effect is the more verbose
>> declaration.
>>
>> In fact, it is this verbosity that makes me ambivalent between
>> applying this liberally versus the standard, more cautious approach -
>> otherwise I am all in favor of placing this pretty much all over.
>
>
> I think we typically prefer to apply a policy/approach where one of the
> goals is to write code (including interfaces in header files) that are as
> small as possible. If we litter all our header files with all kind of
> extraneous stuff that isn't really doing anything, they become somewhat
> unreadable.
Thanks for clarifying this.
>
> (I obviously am not claiming that adding one word to one line in one header
> file is the difference between highly readable and unreadable, but it
> suggests a general approach of trending towards smaller source code can be
> one helpful argument in coming up with a proper decision here.)
I can create a patch with the "minimal" set of attributes, namely the
ones I found helpful for the libavfilter cleanup. I will adopt this
approach and post a patch after leaving some more time for discussion.
>
> Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/formats: add av_warn_unused_result to function prototypes
On Mon, Oct 5, 2015 at 3:45 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Oct 5, 2015 at 3:20 PM, Ganesh Ajjanagadde
> wrote:
>>
>> This uses the av_warn_unused_result attribute liberally to catch some
>> forms of improper
>> usage of functions defined in avfilter/formats.h.
>>
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavfilter/formats.h | 38 +++---
>> 1 file changed, 19 insertions(+), 19 deletions(-)
>>
>> diff --git a/libavfilter/formats.h b/libavfilter/formats.h
>> index 5a8ee5e..e01be4a 100644
>> --- a/libavfilter/formats.h
>> +++ b/libavfilter/formats.h
>> @@ -116,25 +116,25 @@ typedef struct AVFilterChannelLayouts {
>> * If a and b do not share any common elements, neither is modified, and
>> NULL
>> * is returned.
>> */
>> -AVFilterChannelLayouts *ff_merge_channel_layouts(AVFilterChannelLayouts
>> *a,
>> +av_warn_unused_result AVFilterChannelLayouts
>> *ff_merge_channel_layouts(AVFilterChannelLayouts *a,
>> AVFilterChannelLayouts
>> *b);
>> -AVFilterFormats *ff_merge_samplerates(AVFilterFormats *a,
>> +av_warn_unused_result AVFilterFormats
>> *ff_merge_samplerates(AVFilterFormats *a,
>>AVFilterFormats *b);
>
>
> I'm not sure this is the intention of warn_unused_result. My understanding
> is that you use this for strict error reporting only, i.e. "you need to
> check this return code for errors because it may fail!", not for "if you
> don't store the result of this call, you're not using my API correctly".
>
> The thing is, if I use ff_merge_samplerates() and I don't store the result,
> my application cannot possibly function correctly. It's not possible for it
> to function correctly. Imagine the following application:
>
> int main() {
> malloc(2);
> return 0;
> }
>
> My application cannot possibly function as intended without storing the
> result of malloc(). Yet I don't think anyone is seriously considering
> marking malloc with warn_unused_result. Likewise, we should only use
> warn_unused_result for cases where your application probably works correctly
> without checking a return value, but you should check the return value
> anyway because in real usage, the value may indicate problems that the
> application should be aware of before continuing its operations, e.g.
> avformat_open_input() or something like that.
Personally, I don't mind either way - I do know the original intent
which is along the lines of what you wrote here, but I see no harm in
extending to things like malloc, or in our case av_malloc. Of course
the utility is greatly reduced, since as you point out essentially
anyone who writes that kind of code (malloc(2), return 0) has no
business writing C in general. Nevertheless, I don't understand the
concrete harm - they are never false positives with things like
malloc, and the only negative side effect is the more verbose
declaration.
In fact, it is this verbosity that makes me ambivalent between
applying this liberally versus the standard, more cautious approach -
otherwise I am all in favor of placing this pretty much all over.
>
> Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/formats: add av_warn_unused_result to function prototypes
On Mon, Oct 5, 2015 at 4:09 PM, Ganesh Ajjanagadde
wrote:
> On Mon, Oct 5, 2015 at 4:04 PM, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Mon, Oct 5, 2015 at 4:00 PM, Ganesh Ajjanagadde
>> wrote:
>>>
>>> On Mon, Oct 5, 2015 at 3:45 PM, Ronald S. Bultje
>>> wrote:
>>> > Hi,
>>> >
>>> > On Mon, Oct 5, 2015 at 3:20 PM, Ganesh Ajjanagadde
>>> >
>>> > wrote:
>>> >>
>>> >> This uses the av_warn_unused_result attribute liberally to catch some
>>> >> forms of improper
>>> >> usage of functions defined in avfilter/formats.h.
>>> >>
>>> >> Signed-off-by: Ganesh Ajjanagadde
>>> >> ---
>>> >> libavfilter/formats.h | 38 +++---
>>> >> 1 file changed, 19 insertions(+), 19 deletions(-)
>>> >>
>>> >> diff --git a/libavfilter/formats.h b/libavfilter/formats.h
>>> >> index 5a8ee5e..e01be4a 100644
>>> >> --- a/libavfilter/formats.h
>>> >> +++ b/libavfilter/formats.h
>>> >> @@ -116,25 +116,25 @@ typedef struct AVFilterChannelLayouts {
>>> >> * If a and b do not share any common elements, neither is modified,
>>> >> and
>>> >> NULL
>>> >> * is returned.
>>> >> */
>>> >> -AVFilterChannelLayouts
>>> >> *ff_merge_channel_layouts(AVFilterChannelLayouts
>>> >> *a,
>>> >> +av_warn_unused_result AVFilterChannelLayouts
>>> >> *ff_merge_channel_layouts(AVFilterChannelLayouts *a,
>>> >>
>>> >> AVFilterChannelLayouts
>>> >> *b);
>>> >> -AVFilterFormats *ff_merge_samplerates(AVFilterFormats *a,
>>> >> +av_warn_unused_result AVFilterFormats
>>> >> *ff_merge_samplerates(AVFilterFormats *a,
>>> >>AVFilterFormats *b);
>>> >
>>> >
>>> > I'm not sure this is the intention of warn_unused_result. My
>>> > understanding
>>> > is that you use this for strict error reporting only, i.e. "you need to
>>> > check this return code for errors because it may fail!", not for "if you
>>> > don't store the result of this call, you're not using my API correctly".
>>> >
>>> > The thing is, if I use ff_merge_samplerates() and I don't store the
>>> > result,
>>> > my application cannot possibly function correctly. It's not possible for
>>> > it
>>> > to function correctly. Imagine the following application:
>>> >
>>> > int main() {
>>> > malloc(2);
>>> > return 0;
>>> > }
>>> >
>>> > My application cannot possibly function as intended without storing the
>>> > result of malloc(). Yet I don't think anyone is seriously considering
>>> > marking malloc with warn_unused_result. Likewise, we should only use
>>> > warn_unused_result for cases where your application probably works
>>> > correctly
>>> > without checking a return value, but you should check the return value
>>> > anyway because in real usage, the value may indicate problems that the
>>> > application should be aware of before continuing its operations, e.g.
>>> > avformat_open_input() or something like that.
>>>
>>> Personally, I don't mind either way - I do know the original intent
>>> which is along the lines of what you wrote here, but I see no harm in
>>> extending to things like malloc, or in our case av_malloc. Of course
>>> the utility is greatly reduced, since as you point out essentially
>>> anyone who writes that kind of code (malloc(2), return 0) has no
>>> business writing C in general. Nevertheless, I don't understand the
>>> concrete harm - they are never false positives with things like
>>> malloc, and the only negative side effect is the more verbose
>>> declaration.
>>>
>>> In fact, it is this verbosity that makes me ambivalent between
>>> applying this liberally versus the standard, more cautious approach -
>>> otherwise I am all in favor of placing this pretty much all over.
>>
>>
>> I think we typically prefer to apply a policy/approach where one of the
>> goals is to write code (including interfaces in header files) that are as
>> small as possible. If we litter all our header files with all kind of
>> extraneous stuff that isn't really doing anything, they become somewhat
>> unreadable.
>
> Thanks for clarifying this.
>
>>
>> (I obviously am not claiming that adding one word to one line in one header
>> file is the difference between highly readable and unreadable, but it
>> suggests a general approach of trending towards smaller source code can be
>> one helpful argument in coming up with a proper decision here.)
>
> I can create a patch with the "minimal" set of attributes, namely the
> ones I found helpful for the libavfilter cleanup. I will adopt this
> approach and post a patch after leaving some more time for discussion.
It maybe helpful if there is a comparison. I have thus created a patch
for avfilter/buffersrc that uses this attribute in a useful, minimal
way.
>
>>
>> Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] ffplay: log SDL error messages
On Sun, 4 Oct 2015, Ganesh Ajjanagadde wrote: This logs the SDL error messages on failure of creation of SDL_CreateMutex, SDL_CreateCond, and SDL_CreateThread. Signed-off-by: Ganesh Ajjanagadde --- ffplay.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) Applied all three patches in the series. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/buffersrc: add av_warn_unused_result attributes
This adds av_warn_unused_result whenever it is relevant. Signed-off-by: Ganesh Ajjanagadde --- libavfilter/buffersrc.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavfilter/buffersrc.h b/libavfilter/buffersrc.h index cd3d95f..b1b2669 100644 --- a/libavfilter/buffersrc.h +++ b/libavfilter/buffersrc.h @@ -78,7 +78,7 @@ unsigned av_buffersrc_get_nb_failed_requests(AVFilterContext *buffer_src); * This function is equivalent to av_buffersrc_add_frame_flags() with the * AV_BUFFERSRC_FLAG_KEEP_REF flag. */ -int av_buffersrc_write_frame(AVFilterContext *ctx, const AVFrame *frame); +av_warn_unused_result int av_buffersrc_write_frame(AVFilterContext *ctx, const AVFrame *frame); /** * Add a frame to the buffer source. @@ -98,7 +98,7 @@ int av_buffersrc_write_frame(AVFilterContext *ctx, const AVFrame *frame); * This function is equivalent to av_buffersrc_add_frame_flags() without the * AV_BUFFERSRC_FLAG_KEEP_REF flag. */ -int av_buffersrc_add_frame(AVFilterContext *ctx, AVFrame *frame); +av_warn_unused_result int av_buffersrc_add_frame(AVFilterContext *ctx, AVFrame *frame); /** * Add a frame to the buffer source. @@ -115,7 +115,7 @@ int av_buffersrc_add_frame(AVFilterContext *ctx, AVFrame *frame); * @return>= 0 in case of success, a negative AVERROR code *in case of failure */ -int av_buffersrc_add_frame_flags(AVFilterContext *buffer_src, +av_warn_unused_result int av_buffersrc_add_frame_flags(AVFilterContext *buffer_src, AVFrame *frame, int flags); -- 2.6.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: 16bpp tm/dc/h/v intra pred simd (mostly sse2) functions.
Hi, On Mon, Oct 5, 2015 at 7:39 AM, Ronald S. Bultje wrote: > Hi, > > On Mon, Oct 5, 2015 at 5:54 AM, Henrik Gramner wrote: > >> On Mon, Oct 5, 2015 at 10:55 AM, Matt Oliver >> wrote: >> > This patch has broken the 32bit msvc builds: >> > >> http://fate.ffmpeg.org/report.cgi?time=20151005065109&slot=x86_32-msvc12-windows-native >> > >> > I had a look through the code but couldnt find the cause. The error >> message >> > just points to the code line for a macro instantiation and I'm not >> familiar >> > enough with the code to be able to work out where within the macro the >> > error is actually occurring and why. So ill leave this one to someone >> more >> > familiar with the code. >> >> I see where the problem is. >> >> Using stack space in cglobal requires an extra register if the stack >> alignment is less than mmsize (32-bit msvc only has 4-byte stack >> alignment), and if the function already utilizes all available >> registers that will result in failure. >> >> The fix is either to reduce the number of registers used by the >> function or to only enable the function on x86-32 if the stack is at >> least 16-byte aligned. x86inc has the variable STACK_ALIGNMENT which >> can be tested for this, in C there's the HAVE_ALIGNED_STACK define >> which is set if the stack is 16-byte aligned. > > > Yeah, it should use 6 regs, I'll send a patch. > Should be fixed now, apologies for the breakage. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/takdec: add x86 SIMD for rest of decorrelation modes
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 2 +-
libavcodec/takdec.c | 44 +
libavcodec/takdsp.c | 82 ++
libavcodec/takdsp.h | 34
libavcodec/x86/Makefile | 2 +
libavcodec/x86/takdsp.asm| 94
libavcodec/x86/takdsp_init.c | 45 +
7 files changed, 277 insertions(+), 26 deletions(-)
create mode 100644 libavcodec/takdsp.c
create mode 100644 libavcodec/takdsp.h
create mode 100644 libavcodec/x86/takdsp.asm
create mode 100644 libavcodec/x86/takdsp_init.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 153c3f8..dcd3828 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -490,7 +490,7 @@ OBJS-$(CONFIG_SVQ1_ENCODER)+= svq1enc.o svq1.o
\
h263.o ituh263enc.o
OBJS-$(CONFIG_SVQ3_DECODER)+= svq3.o svq13.o mpegutils.o
OBJS-$(CONFIG_TEXT_DECODER)+= textdec.o ass.o
-OBJS-$(CONFIG_TAK_DECODER) += takdec.o tak.o
+OBJS-$(CONFIG_TAK_DECODER) += takdec.o tak.o takdsp.o
OBJS-$(CONFIG_TARGA_DECODER) += targa.o
OBJS-$(CONFIG_TARGA_ENCODER) += targaenc.o rle.o
OBJS-$(CONFIG_TARGA_Y216_DECODER) += targa_y216dec.o
diff --git a/libavcodec/takdec.c b/libavcodec/takdec.c
index 5395596..e5c0723 100644
--- a/libavcodec/takdec.c
+++ b/libavcodec/takdec.c
@@ -28,6 +28,7 @@
#include "libavutil/internal.h"
#include "libavutil/samplefmt.h"
#include "tak.h"
+#include "takdsp.h"
#include "audiodsp.h"
#include "thread.h"
#include "avcodec.h"
@@ -47,6 +48,7 @@ typedef struct MCDParam {
typedef struct TAKDecContext {
AVCodecContext *avctx; ///< parent AVCodecContext
AudioDSPContext adsp;
+TAKDSPContext tdsp;
TAKStreamInfo ti;
GetBitContext gb; ///< bitstream reader
initialized to start at the current frame
@@ -172,6 +174,7 @@ static av_cold int tak_decode_init(AVCodecContext *avctx)
TAKDecContext *s = avctx->priv_data;
ff_audiodsp_init(&s->adsp);
+ff_takdsp_init(&s->tdsp);
s->avctx = avctx;
avctx->bits_per_raw_sample = avctx->bits_per_coded_sample;
@@ -541,46 +544,32 @@ static int decode_channel(TAKDecContext *s, int chan)
static int decorrelate(TAKDecContext *s, int c1, int c2, int length)
{
GetBitContext *gb = &s->gb;
-int32_t *p1 = s->decoded[c1] + 1;
-int32_t *p2 = s->decoded[c2] + 1;
+int32_t *p1 = s->decoded[c1] + (s->dmode > 5);
+int32_t *p2 = s->decoded[c2] + (s->dmode > 5);
+int32_t bp1 = p1[0];
+int32_t bp2 = p2[0];
int i;
int dshift, dfactor;
+length += s->dmode < 6;
+
switch (s->dmode) {
case 1: /* left/side */
-for (i = 0; i < length; i++) {
-int32_t a = p1[i];
-int32_t b = p2[i];
-p2[i] = a + b;
-}
+s->tdsp.decorrelate_ls(p1, p2, length);
break;
case 2: /* side/right */
-for (i = 0; i < length; i++) {
-int32_t a = p1[i];
-int32_t b = p2[i];
-p1[i] = b - a;
-}
+s->tdsp.decorrelate_sr(p1, p2, length);
break;
case 3: /* side/mid */
-for (i = 0; i < length; i++) {
-int32_t a = p1[i];
-int32_t b = p2[i];
-a-= b >> 1;
-p1[i] = a;
-p2[i] = a + b;
-}
+s->tdsp.decorrelate_sm(p1, p2, length);
break;
case 4: /* side/left with scale factor */
FFSWAP(int32_t*, p1, p2);
+FFSWAP(int32_t, bp1, bp2);
case 5: /* side/right with scale factor */
dshift = get_bits_esc4(gb);
dfactor = get_sbits(gb, 10);
-for (i = 0; i < length; i++) {
-int32_t a = p1[i];
-int32_t b = p2[i];
-b = dfactor * (b >> dshift) + 128 >> 8 << dshift;
-p1[i] = b - a;
-}
+s->tdsp.decorrelate_sf(p1, p2, length, dshift, dfactor);
break;
case 6:
FFSWAP(int32_t*, p1, p2);
@@ -664,6 +653,11 @@ static int decorrelate(TAKDecContext *s, int c1, int c2,
int length)
}
}
+if (s->dmode > 0 && s->dmode < 6) {
+p1[0] = bp1;
+p2[0] = bp2;
+}
+
return 0;
}
diff --git a/libavcodec/takdsp.c b/libavcodec/takdsp.c
new file mode 100644
index 000..2441c2b
--- /dev/null
+++ b/libavcodec/takdsp.c
@@ -0,0 +1,82 @@
+/*
+ * TAK decoder
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is dis
Re: [FFmpeg-devel] [PATCH 2/2] x86/alacdsp: add simd optimized functions
On 10/4/15, James Almer wrote: > Signed-off-by: James Almer > --- > libavcodec/alacdsp.c | 3 + > libavcodec/alacdsp.h | 1 + > libavcodec/x86/Makefile | 2 + > libavcodec/x86/alacdsp.asm| 133 > ++ > libavcodec/x86/alacdsp_init.c | 44 ++ > 5 files changed, 183 insertions(+) > create mode 100644 libavcodec/x86/alacdsp.asm > create mode 100644 libavcodec/x86/alacdsp_init.c > Have you measured speed gain? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/takdec: add x86 SIMD for rest of decorrelation modes
On 10/5/2015 6:34 PM, Paul B Mahol wrote: > diff --git a/libavcodec/x86/takdsp.asm b/libavcodec/x86/takdsp.asm > new file mode 100644 > index 000..0158d4d > --- /dev/null > +++ b/libavcodec/x86/takdsp.asm > @@ -0,0 +1,94 @@ > +;** > +;* TAK DSP SIMD optimizations > +;* > +;* Copyright (C) 2015 Paul B Mahol > +;* > +;* This file is part of FFmpeg. > +;* > +;* FFmpeg is free software; you can redistribute it and/or > +;* modify it under the terms of the GNU Lesser General Public > +;* License as published by the Free Software Foundation; either > +;* version 2.1 of the License, or (at your option) any later version. > +;* > +;* FFmpeg is distributed in the hope that it will be useful, > +;* but WITHOUT ANY WARRANTY; without even the implied warranty of > +;* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > +;* Lesser General Public License for more details. > +;* > +;* You should have received a copy of the GNU Lesser General Public > +;* License along with FFmpeg; if not, write to the Free Software > +;* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 > USA > +;** > + > +%include "libavutil/x86/x86util.asm" > + > +SECTION_RODATA > + > +pd_128: dd 128 > + > +SECTION .text > + > +INIT_XMM sse2 > +cglobal tak_decorrelate_ls, 3, 3, 2, p1, p2, length > +.loop: > +mova m0, [p1q] > +mova m1, [p2q] > +padddm0, m1 paddd m0, [p2q] > +mova [p2q], m0 > +add p1q, mmsize > +add p2q, mmsize > +sub lengthd, mmsize/4 Do the neg trick Hendrik told you about for the maskedmerge filter. That way you will only need to do an add on the length register per loop. Also, if the buffer is properly padded you could do 32 bytes at a time instead of 16. Same applies to the other functions. > +jg .loop > +REP_RET > + > +cglobal tak_decorrelate_sr, 3, 3, 2, p1, p2, length > +.loop: > +mova m0, [p1q] > +mova m1, [p2q] > +psubdm1, m0 > +mova [p1q], m0 > +add p1q, mmsize > +add p2q, mmsize > +sub lengthd, mmsize/4 > +jg .loop > +REP_RET > + > +cglobal tak_decorrelate_sm, 3, 3, 3, p1, p2, length > +.loop: > +mova m0, [p1q] > +mova m1, [p2q] > +mova m2, m1 > +psrldm2, 1 > +psubdm0, m2 > +padddm1, m0 > +mova [p1q], m0 > +mova [p2q], m1 > +add p1q, mmsize > +add p2q, mmsize > +sub lengthd, mmsize/4 > +jg .loop > +REP_RET > + > +INIT_XMM sse4 > +cglobal tak_decorrelate_sf, 5, 5, 5, p1, p2, length, dshift, dfactor > +movd m2, dshiftm > +movd m3, dfactorm Change the cglobal line to 3, 3, 5. On x86_32 it will prevent the unnecessary load of the last two arguments on gprs. > +pshufd m3, m3, 0 > +movd m4, [pd_128] Change the pd_128 constant in Rodata to "times 4 dd 128" then just do a mova m4, [pd_128]. It will save you the pshufd below. > +pshufd m4, m4, 0 > + > +.loop: > +mova m0, [p1q] > +mova m1, [p2q] > +psrldm1, m2 > +pmulld m1, m3 > +padddm1, m4 > +psrldm1, 8 > +pslldm1, m2 > +psubdm1, m0 > +mova [p1q], m1 > +add p1q, mmsize > +add p2q, mmsize > +sub lengthd, mmsize/4 > +jg .loop > +REP_RET ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] x86/alacdsp: add simd optimized functions
On 10/5/2015 6:48 PM, Paul B Mahol wrote: > On 10/4/15, James Almer wrote: >> Signed-off-by: James Almer >> --- >> libavcodec/alacdsp.c | 3 + >> libavcodec/alacdsp.h | 1 + >> libavcodec/x86/Makefile | 2 + >> libavcodec/x86/alacdsp.asm| 133 >> ++ >> libavcodec/x86/alacdsp_init.c | 44 ++ >> 5 files changed, 183 insertions(+) >> create mode 100644 libavcodec/x86/alacdsp.asm >> create mode 100644 libavcodec/x86/alacdsp_init.c >> > > Have you measured speed gain? About three to four times faster than c. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/takdec: add x86 SIMD for rest of decorrelation modes
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 2 +-
libavcodec/takdec.c | 44 --
libavcodec/takdsp.c | 82 +
libavcodec/takdsp.h | 34 ++
libavcodec/x86/Makefile | 2 +
libavcodec/x86/takdsp.asm| 105 +++
libavcodec/x86/takdsp_init.c | 45 +++
7 files changed, 288 insertions(+), 26 deletions(-)
create mode 100644 libavcodec/takdsp.c
create mode 100644 libavcodec/takdsp.h
create mode 100644 libavcodec/x86/takdsp.asm
create mode 100644 libavcodec/x86/takdsp_init.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 9075077..60491ce 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -491,7 +491,7 @@ OBJS-$(CONFIG_SVQ1_ENCODER)+= svq1enc.o svq1.o
\
h263.o ituh263enc.o
OBJS-$(CONFIG_SVQ3_DECODER)+= svq3.o svq13.o mpegutils.o
OBJS-$(CONFIG_TEXT_DECODER)+= textdec.o ass.o
-OBJS-$(CONFIG_TAK_DECODER) += takdec.o tak.o
+OBJS-$(CONFIG_TAK_DECODER) += takdec.o tak.o takdsp.o
OBJS-$(CONFIG_TARGA_DECODER) += targa.o
OBJS-$(CONFIG_TARGA_ENCODER) += targaenc.o rle.o
OBJS-$(CONFIG_TARGA_Y216_DECODER) += targa_y216dec.o
diff --git a/libavcodec/takdec.c b/libavcodec/takdec.c
index 5395596..e5c0723 100644
--- a/libavcodec/takdec.c
+++ b/libavcodec/takdec.c
@@ -28,6 +28,7 @@
#include "libavutil/internal.h"
#include "libavutil/samplefmt.h"
#include "tak.h"
+#include "takdsp.h"
#include "audiodsp.h"
#include "thread.h"
#include "avcodec.h"
@@ -47,6 +48,7 @@ typedef struct MCDParam {
typedef struct TAKDecContext {
AVCodecContext *avctx; ///< parent AVCodecContext
AudioDSPContext adsp;
+TAKDSPContext tdsp;
TAKStreamInfo ti;
GetBitContext gb; ///< bitstream reader
initialized to start at the current frame
@@ -172,6 +174,7 @@ static av_cold int tak_decode_init(AVCodecContext *avctx)
TAKDecContext *s = avctx->priv_data;
ff_audiodsp_init(&s->adsp);
+ff_takdsp_init(&s->tdsp);
s->avctx = avctx;
avctx->bits_per_raw_sample = avctx->bits_per_coded_sample;
@@ -541,46 +544,32 @@ static int decode_channel(TAKDecContext *s, int chan)
static int decorrelate(TAKDecContext *s, int c1, int c2, int length)
{
GetBitContext *gb = &s->gb;
-int32_t *p1 = s->decoded[c1] + 1;
-int32_t *p2 = s->decoded[c2] + 1;
+int32_t *p1 = s->decoded[c1] + (s->dmode > 5);
+int32_t *p2 = s->decoded[c2] + (s->dmode > 5);
+int32_t bp1 = p1[0];
+int32_t bp2 = p2[0];
int i;
int dshift, dfactor;
+length += s->dmode < 6;
+
switch (s->dmode) {
case 1: /* left/side */
-for (i = 0; i < length; i++) {
-int32_t a = p1[i];
-int32_t b = p2[i];
-p2[i] = a + b;
-}
+s->tdsp.decorrelate_ls(p1, p2, length);
break;
case 2: /* side/right */
-for (i = 0; i < length; i++) {
-int32_t a = p1[i];
-int32_t b = p2[i];
-p1[i] = b - a;
-}
+s->tdsp.decorrelate_sr(p1, p2, length);
break;
case 3: /* side/mid */
-for (i = 0; i < length; i++) {
-int32_t a = p1[i];
-int32_t b = p2[i];
-a-= b >> 1;
-p1[i] = a;
-p2[i] = a + b;
-}
+s->tdsp.decorrelate_sm(p1, p2, length);
break;
case 4: /* side/left with scale factor */
FFSWAP(int32_t*, p1, p2);
+FFSWAP(int32_t, bp1, bp2);
case 5: /* side/right with scale factor */
dshift = get_bits_esc4(gb);
dfactor = get_sbits(gb, 10);
-for (i = 0; i < length; i++) {
-int32_t a = p1[i];
-int32_t b = p2[i];
-b = dfactor * (b >> dshift) + 128 >> 8 << dshift;
-p1[i] = b - a;
-}
+s->tdsp.decorrelate_sf(p1, p2, length, dshift, dfactor);
break;
case 6:
FFSWAP(int32_t*, p1, p2);
@@ -664,6 +653,11 @@ static int decorrelate(TAKDecContext *s, int c1, int c2,
int length)
}
}
+if (s->dmode > 0 && s->dmode < 6) {
+p1[0] = bp1;
+p2[0] = bp2;
+}
+
return 0;
}
diff --git a/libavcodec/takdsp.c b/libavcodec/takdsp.c
new file mode 100644
index 000..2441c2b
--- /dev/null
+++ b/libavcodec/takdsp.c
@@ -0,0 +1,82 @@
+/*
+ * TAK decoder
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distribut
[FFmpeg-devel] [PATCH] add CONTRIBUTING.md
For the Github users to ignore. Signed-off-by: Lou Logan --- CONTRIBUTING.md | 36 1 file changed, 36 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 000..4bccf25 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,36 @@ +# Contributing to FFmpeg + +FFmpeg is a big project, but we like seeing patches from new contributors. +You can get started by reading the [Developer Documentation] +(https://ffmpeg.org/developer.html). + +## A note to Github users + +**FFmpeg development, including patch reviews, occurs on the ffmpeg-devel +mailing list, so most developers do not view Github pull requests. +Therefore, Github pull requests should be avoided because they will +likely be not be noticed.** + +## Submitting patches + +Patches should be sent to the [ffmpeg-devel mailing list] +(https://ffmpeg.org/contact.html). + +Patches created with `git send-email` are preferred, but using +`git format-patch` is also acceptable. See [Submitting Patches] +(http://ffmpeg.org/developer.html#Submitting-patches-1) and +[Using Git to Develop FFmpeg](https://ffmpeg.org/git-howto.html). + +## Bug reports + +Bug reports and feature requests should be submitted to our +[bug tracker](https://trac.ffmpeg.org/). For more information refer to +[Submitting a Bug Report](https://ffmpeg.org/bugreports.html). + +Please do not send bug reports to the ffmpeg-devel mailing list unless +you are also sending a patch to fix the bug. + +## If you need help + +Visit the #ffmpeg IRC channel, or send a message to one of the +appropriate [mailing lists](https://ffmpeg.org/contact.html). -- 2.5.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add CONTRIBUTING.md
On Mon, Oct 5, 2015 at 7:26 PM, Lou Logan wrote: > For the Github users to ignore. > > Signed-off-by: Lou Logan > --- > CONTRIBUTING.md | 36 > 1 file changed, 36 insertions(+) > create mode 100644 CONTRIBUTING.md > > diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md > new file mode 100644 > index 000..4bccf25 > --- /dev/null > +++ b/CONTRIBUTING.md > @@ -0,0 +1,36 @@ > +# Contributing to FFmpeg > + > +FFmpeg is a big project, but we like seeing patches from new contributors. > +You can get started by reading the [Developer Documentation] > +(https://ffmpeg.org/developer.html). > + > +## A note to Github users > + > +**FFmpeg development, including patch reviews, occurs on the ffmpeg-devel > +mailing list, so most developers do not view Github pull requests. > +Therefore, Github pull requests should be avoided because they will > +likely be not be noticed.** Unless you have a good reason for this, please change the paragraph to be much more similar/identical with README.md. > + > +## Submitting patches > + > +Patches should be sent to the [ffmpeg-devel mailing list] > +(https://ffmpeg.org/contact.html). > + > +Patches created with `git send-email` are preferred, but using > +`git format-patch` is also acceptable. See [Submitting Patches] > +(http://ffmpeg.org/developer.html#Submitting-patches-1) and > +[Using Git to Develop FFmpeg](https://ffmpeg.org/git-howto.html). > + > +## Bug reports > + > +Bug reports and feature requests should be submitted to our > +[bug tracker](https://trac.ffmpeg.org/). For more information refer to > +[Submitting a Bug Report](https://ffmpeg.org/bugreports.html). > + > +Please do not send bug reports to the ffmpeg-devel mailing list unless > +you are also sending a patch to fix the bug. > + > +## If you need help > + > +Visit the #ffmpeg IRC channel, or send a message to one of the > +appropriate [mailing lists](https://ffmpeg.org/contact.html). > -- > 2.5.0 > > ___ > 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] avcodec/takdec: add x86 SIMD for rest of decorrelation modes
On 10/5/2015 8:04 PM, Paul B Mahol wrote:
> diff --git a/libavcodec/x86/takdsp.asm b/libavcodec/x86/takdsp.asm
> new file mode 100644
> index 000..bc881bf
> --- /dev/null
> +++ b/libavcodec/x86/takdsp.asm
> @@ -0,0 +1,105 @@
> +;**
> +;* TAK DSP SIMD optimizations
> +;*
> +;* Copyright (C) 2015 Paul B Mahol
> +;*
> +;* This file is part of FFmpeg.
> +;*
> +;* FFmpeg is free software; you can redistribute it and/or
> +;* modify it under the terms of the GNU Lesser General Public
> +;* License as published by the Free Software Foundation; either
> +;* version 2.1 of the License, or (at your option) any later version.
> +;*
> +;* FFmpeg is distributed in the hope that it will be useful,
> +;* but WITHOUT ANY WARRANTY; without even the implied warranty of
> +;* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> +;* Lesser General Public License for more details.
> +;*
> +;* You should have received a copy of the GNU Lesser General Public
> +;* License along with FFmpeg; if not, write to the Free Software
> +;* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> +;**
> +
> +%include "libavutil/x86/x86util.asm"
> +
> +SECTION_RODATA
> +
> +pd_128: times 4 dd 128
> +
> +SECTION .text
> +
> +INIT_XMM sse2
> +cglobal tak_decorrelate_ls, 3, 3, 2, p1, p2, length
As i said before:
shl lengthd, 2 ; length *= sizeof(int32)
add p1q, lengthq
add p2q, lengthq
neg lengthq
> +.loop:
> +mova m0, [p1q+mmsize*0]
> +mova m1, [p1q+mmsize*1]
> +padddm0, [p2q+mmsize*0]
> +padddm1, [p2q+mmsize*1]
> +mova [p2q+mmsize*0], m0
> +mova [p2q+mmsize*1], m1
p{1,2}q+lengthq+mmsize
> +add p1q, mmsize*2
> +add p2q, mmsize*2
> +sub lengthd, mmsize/2
> +jg .loop
add lengthq, mmsize*2
jl .loop
Same for every other function.
Should be ok to commit after those changes if nobody else comments.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add CONTRIBUTING.md
On Mon, Oct 5, 2015, at 05:46 PM, Ganesh Ajjanagadde wrote: > Unless you have a good reason for this, please change the paragraph to > be much more similar/identical with README.md. Why would that matter? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] README: replace http with https
Signed-off-by: Ganesh Ajjanagadde --- README.md | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index f0a47c7..2419191 100644 --- a/README.md +++ b/README.md @@ -16,12 +16,12 @@ such as audio, video, subtitles and related metadata. ## Tools -* [ffmpeg](http://ffmpeg.org/ffmpeg.html) is a command line toolbox to +* [ffmpeg](https://ffmpeg.org/ffmpeg.html) is a command line toolbox to manipulate, convert and stream multimedia content. -* [ffplay](http://ffmpeg.org/ffplay.html) is a minimalistic multimedia player. -* [ffprobe](http://ffmpeg.org/ffprobe.html) is a simple analysis tool to inspect +* [ffplay](https://ffmpeg.org/ffplay.html) is a minimalistic multimedia player. +* [ffprobe](https://ffmpeg.org/ffprobe.html) is a simple analysis tool to inspect multimedia content. -* [ffserver](http://ffmpeg.org/ffserver.html) is a multimedia streaming server +* [ffserver](https://ffmpeg.org/ffserver.html) is a multimedia streaming server for live broadcasts. * Additional small tools such as `aviocat`, `ismindex` and `qt-faststart`. @@ -29,8 +29,8 @@ such as audio, video, subtitles and related metadata. The offline documentation is available in the **doc/** directory. -The online documentation is available in the main [website](http://ffmpeg.org) -and in the [wiki](http://trac.ffmpeg.org). +The online documentation is available in the main [website](https://ffmpeg.org) +and in the [wiki](https://trac.ffmpeg.org). ### Examples -- 2.6.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add CONTRIBUTING.md
On 15-10-05 at 15:26, Lou Logan wrote: [..] > + > +**FFmpeg development, including patch reviews, occurs on the ffmpeg-devel > +mailing list, so most developers do not view Github pull requests. > +Therefore, Github pull requests should be avoided because they will > +likely be not be noticed.** likely not be noticed. [..] -- Simon Thelen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add CONTRIBUTING.md
On Mon, Oct 5, 2015 at 11:17 PM, Lou Logan wrote: > On Mon, Oct 5, 2015, at 05:46 PM, Ganesh Ajjanagadde wrote: >> Unless you have a good reason for this, please change the paragraph to >> be much more similar/identical with README.md. > > Why would that matter? It is just a minor nit; users/developers should not get the impression that we are inconsistent in our stance towards pull requests. The two paragraphs are sufficiently similar that I am willing to let this slide. > ___ > 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] vp9: 16bpp tm/dc/h/v intra pred simd (mostly sse2) functions.
On 6 October 2015 at 07:51, Ronald S. Bultje wrote: > Hi, > > On Mon, Oct 5, 2015 at 7:39 AM, Ronald S. Bultje > wrote: > > > Hi, > > > > On Mon, Oct 5, 2015 at 5:54 AM, Henrik Gramner > wrote: > > > >> On Mon, Oct 5, 2015 at 10:55 AM, Matt Oliver > >> wrote: > >> > This patch has broken the 32bit msvc builds: > >> > > >> > http://fate.ffmpeg.org/report.cgi?time=20151005065109&slot=x86_32-msvc12-windows-native > >> > > >> > I had a look through the code but couldnt find the cause. The error > >> message > >> > just points to the code line for a macro instantiation and I'm not > >> familiar > >> > enough with the code to be able to work out where within the macro the > >> > error is actually occurring and why. So ill leave this one to someone > >> more > >> > familiar with the code. > >> > >> I see where the problem is. > >> > >> Using stack space in cglobal requires an extra register if the stack > >> alignment is less than mmsize (32-bit msvc only has 4-byte stack > >> alignment), and if the function already utilizes all available > >> registers that will result in failure. > >> > >> The fix is either to reduce the number of registers used by the > >> function or to only enable the function on x86-32 if the stack is at > >> least 16-byte aligned. x86inc has the variable STACK_ALIGNMENT which > >> can be tested for this, in C there's the HAVE_ALIGNED_STACK define > >> which is set if the stack is 16-byte aligned. > > > > > > Yeah, it should use 6 regs, I'll send a patch. > > > > Should be fixed now, apologies for the breakage. > > Yep, looks all good now, thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
