Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove (a)fifo filters

[Muhammad Faiz]

On Sat, Mar 9, 2024 at 6:11 PM Paul B Mahol  wrote:

> On Sat, Mar 9, 2024 at 2:09 AM Muhammad Faiz  wrote:
>
> > On Fri, Mar 8, 2024 at 10:30 PM Paul B Mahol  wrote:
> >
> > > On Fri, Mar 8, 2024 at 4:18 PM Muhammad Faiz  wrote:
> > >
> > > > On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt <
> > > > andreas.rheinha...@outlook.com> wrote:
> > > >
> > > > > Muhammad Faiz:
> > > > > > On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt <
> > > > > > andreas.rheinha...@outlook.com> wrote:
> > > > > >
> > > > > >> Andreas Rheinhardt:
> > > > > >>> Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f.
> > > > > >>>
> > > > > >>> Signed-off-by: Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com>
> > > > > >>> ---
> > > > > >>>  doc/filters.texi |   9 ---
> > > > > >>>  libavfilter/Makefile |   1 -
> > > > > >>>  libavfilter/allfilters.c |   2 -
> > > > > >>>  libavfilter/fifo.c   | 165
> > > > ---
> > > > > >>>  4 files changed, 177 deletions(-)
> > > > > >>>  delete mode 100644 libavfilter/fifo.c
> > > > > >>>
> > > > > >>
> > > > > >> Will apply in a few days unless there are objections.
> > > > > >>
> > > > > >> - Andreas
> > > > > >>
> > > > > >>
> > > > > > This breaks backward compatibility.
> > > > > >
> > > > > > Please revert.
> > > > > >
> > > > > > Thank's.
> > > > >
> > > > > What breaks that can't simply be fixed by removing the (a)fifo
> filter
> > > > > from the filterchain?
> > > > >
> > > > > - Andreas
> > > > >
> > > > >
> > > > I use afifo to optimize memory usage.
> > > >
> > >
> > > That statement sync with reality is questionable, fifo filters were
> > mainly
> > > used before .activate was added,
> > > for cases filters used >1 inputs. Now they should be irrelevant, unless
> > > there are bugs in code than this filters just hide more bugs.
> > >
> >
> > Yes, I've used it before .activate was added, and it worked, and still
> > works.
> > Although maybe the bugs have been fixed by .activate, what's wrong if
> > (a)fifo still exist?
> >
>
> As already wrote, lets repeat it again, hiding real bugs. Hiding is not
> correct word,
> it just adds yet another layer in filtergraph to accumulate memory/frames,
> with extra allocations per each frame for linking between prev and next
> frame.
> Which is pointless, as libavfilter internal code already have own queue
> mechanism.
> Check for which filters used after afifo, afifo count of queued frames
> reach > 1 than
> such filters needs fixing. Personally, my mpv visualizer modified script is
> not using afifo filters, and it works fine.
>
>
OK

Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove (a)fifo filters

[Muhammad Faiz]

On Sat, Mar 9, 2024 at 6:59 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Muhammad Faiz:
> > On Fri, Mar 8, 2024 at 10:46 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> >> Muhammad Faiz:
> >>> On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt <
> >>> andreas.rheinha...@outlook.com> wrote:
> >>>
> >>>> Muhammad Faiz:
> >>>>> On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt <
> >>>>> andreas.rheinha...@outlook.com> wrote:
> >>>>>
> >>>>>> Andreas Rheinhardt:
> >>>>>>> Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f.
> >>>>>>>
> >>>>>>> Signed-off-by: Andreas Rheinhardt 
> >>>>>>> ---
> >>>>>>>  doc/filters.texi |   9 ---
> >>>>>>>  libavfilter/Makefile |   1 -
> >>>>>>>  libavfilter/allfilters.c |   2 -
> >>>>>>>  libavfilter/fifo.c   | 165
> >> ---
> >>>>>>>  4 files changed, 177 deletions(-)
> >>>>>>>  delete mode 100644 libavfilter/fifo.c
> >>>>>>>
> >>>>>>
> >>>>>> Will apply in a few days unless there are objections.
> >>>>>>
> >>>>>> - Andreas
> >>>>>>
> >>>>>>
> >>>>> This breaks backward compatibility.
> >>>>>
> >>>>> Please revert.
> >>>>>
> >>>>> Thank's.
> >>>>
> >>>> What breaks that can't simply be fixed by removing the (a)fifo filter
> >>>> from the filterchain?
> >>>>
> >>>> - Andreas
> >>>>
> >>>>
> >>> I use afifo to optimize memory usage.
> >>> And backward incompatible change should only be allowed with
> deprecation
> >>> periods and major version bump.
> >>>
> >>
> >> Deprecation periods etc. are only common for API breaks; we do not
> >> guarantee that any particular filter etc. stays available and therefore
> >> occasionally remove them without deprecation. Examples of this are the
> >> removal of libopenjpeg in 60ccb3fe787, the removal of libwavpackenc in
> >> 45070eec4c or the removal of the XvMC hardware acceleration in
> >> be95df12bb06 (the last commit was accompanied by cefa595361db9 and
> >> b648ece34b6f which deprecated the parts of XvMC that were part of the
> >> public API and therefore subject to the API stability contract).
> >>
> >> - Andreas
> >>
> >>
> > It seems that all of them are external dependent components. So, I think
> > that non external dependent components should be treated differently.
> > Also, what is the urgency of (a)fifo removal?
> >
>
> The reason for removing these features is that they have outlived their
> usefulness; so have the (a)fifo filters.
>
> - Andreas
>

OK

Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove (a)fifo filters

[Muhammad Faiz]

On Fri, Mar 8, 2024 at 10:30 PM Paul B Mahol  wrote:

> On Fri, Mar 8, 2024 at 4:18 PM Muhammad Faiz  wrote:
>
> > On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> > > Muhammad Faiz:
> > > > On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt <
> > > > andreas.rheinha...@outlook.com> wrote:
> > > >
> > > >> Andreas Rheinhardt:
> > > >>> Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f.
> > > >>>
> > > >>> Signed-off-by: Andreas Rheinhardt 
> > > >>> ---
> > > >>>  doc/filters.texi |   9 ---
> > > >>>  libavfilter/Makefile |   1 -
> > > >>>  libavfilter/allfilters.c |   2 -
> > > >>>  libavfilter/fifo.c   | 165
> > ---
> > > >>>  4 files changed, 177 deletions(-)
> > > >>>  delete mode 100644 libavfilter/fifo.c
> > > >>>
> > > >>
> > > >> Will apply in a few days unless there are objections.
> > > >>
> > > >> - Andreas
> > > >>
> > > >>
> > > > This breaks backward compatibility.
> > > >
> > > > Please revert.
> > > >
> > > > Thank's.
> > >
> > > What breaks that can't simply be fixed by removing the (a)fifo filter
> > > from the filterchain?
> > >
> > > - Andreas
> > >
> > >
> > I use afifo to optimize memory usage.
> >
>
> That statement sync with reality is questionable, fifo filters were mainly
> used before .activate was added,
> for cases filters used >1 inputs. Now they should be irrelevant, unless
> there are bugs in code than this filters just hide more bugs.
>

Yes, I've used it before .activate was added, and it worked, and still
works.
Although maybe the bugs have been fixed by .activate, what's wrong if
(a)fifo still exist?

Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove (a)fifo filters

[Muhammad Faiz]

On Fri, Mar 8, 2024 at 10:46 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Muhammad Faiz:
> > On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> >> Muhammad Faiz:
> >>> On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt <
> >>> andreas.rheinha...@outlook.com> wrote:
> >>>
> >>>> Andreas Rheinhardt:
> >>>>> Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f.
> >>>>>
> >>>>> Signed-off-by: Andreas Rheinhardt 
> >>>>> ---
> >>>>>  doc/filters.texi |   9 ---
> >>>>>  libavfilter/Makefile |   1 -
> >>>>>  libavfilter/allfilters.c |   2 -
> >>>>>  libavfilter/fifo.c   | 165
> ---
> >>>>>  4 files changed, 177 deletions(-)
> >>>>>  delete mode 100644 libavfilter/fifo.c
> >>>>>
> >>>>
> >>>> Will apply in a few days unless there are objections.
> >>>>
> >>>> - Andreas
> >>>>
> >>>>
> >>> This breaks backward compatibility.
> >>>
> >>> Please revert.
> >>>
> >>> Thank's.
> >>
> >> What breaks that can't simply be fixed by removing the (a)fifo filter
> >> from the filterchain?
> >>
> >> - Andreas
> >>
> >>
> > I use afifo to optimize memory usage.
> > And backward incompatible change should only be allowed with deprecation
> > periods and major version bump.
> >
>
> Deprecation periods etc. are only common for API breaks; we do not
> guarantee that any particular filter etc. stays available and therefore
> occasionally remove them without deprecation. Examples of this are the
> removal of libopenjpeg in 60ccb3fe787, the removal of libwavpackenc in
> 45070eec4c or the removal of the XvMC hardware acceleration in
> be95df12bb06 (the last commit was accompanied by cefa595361db9 and
> b648ece34b6f which deprecated the parts of XvMC that were part of the
> public API and therefore subject to the API stability contract).
>
> - Andreas
>
>
It seems that all of them are external dependent components. So, I think
that non external dependent components should be treated differently.
Also, what is the urgency of (a)fifo removal?

Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove (a)fifo filters

[Muhammad Faiz]

On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Muhammad Faiz:
> > On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> >> Andreas Rheinhardt:
> >>> Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f.
> >>>
> >>> Signed-off-by: Andreas Rheinhardt 
> >>> ---
> >>>  doc/filters.texi |   9 ---
> >>>  libavfilter/Makefile |   1 -
> >>>  libavfilter/allfilters.c |   2 -
> >>>  libavfilter/fifo.c   | 165 ---
> >>>  4 files changed, 177 deletions(-)
> >>>  delete mode 100644 libavfilter/fifo.c
> >>>
> >>
> >> Will apply in a few days unless there are objections.
> >>
> >> - Andreas
> >>
> >>
> > This breaks backward compatibility.
> >
> > Please revert.
> >
> > Thank's.
>
> What breaks that can't simply be fixed by removing the (a)fifo filter
> from the filterchain?
>
> - Andreas
>
>
I use afifo to optimize memory usage.
And backward incompatible change should only be allowed with deprecation
periods and major version bump.

Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove (a)fifo filters

[Muhammad Faiz]

On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Andreas Rheinhardt:
> > Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f.
> >
> > Signed-off-by: Andreas Rheinhardt 
> > ---
> >  doc/filters.texi |   9 ---
> >  libavfilter/Makefile |   1 -
> >  libavfilter/allfilters.c |   2 -
> >  libavfilter/fifo.c   | 165 ---
> >  4 files changed, 177 deletions(-)
> >  delete mode 100644 libavfilter/fifo.c
> >
>
> Will apply in a few days unless there are objections.
>
> - Andreas
>
>
This breaks backward compatibility.

Please revert.

Thank's.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 2/5] swscale/swscale_unscaled: add missing gbrap10 on ff_get_unscaled_swscale

[Muhammad Faiz]

On Tue, Jan 29, 2019 at 5:14 AM Michael Niedermayer
 wrote:
>
> On Mon, Jan 28, 2019 at 05:07:38PM +0700, Muhammad Faiz wrote:
> > Fix inconsistent checksums between gbrap10be and gbrap10le
> > on fate-filter-pixfmts.
> >
> > Signed-off-by: Muhammad Faiz 
> > ---
> >  libswscale/swscale_unscaled.c| 3 +++
> >  tests/ref/fate/filter-pixfmts-copy   | 2 +-
> >  tests/ref/fate/filter-pixfmts-crop   | 2 +-
> >  tests/ref/fate/filter-pixfmts-field  | 2 +-
> >  tests/ref/fate/filter-pixfmts-fieldorder | 2 +-
> >  tests/ref/fate/filter-pixfmts-hflip  | 2 +-
> >  tests/ref/fate/filter-pixfmts-il | 2 +-
> >  tests/ref/fate/filter-pixfmts-null   | 2 +-
> >  tests/ref/fate/filter-pixfmts-scale  | 2 +-
> >  tests/ref/fate/filter-pixfmts-transpose  | 2 +-
> >  tests/ref/fate/filter-pixfmts-vflip  | 2 +-
> >  11 files changed, 13 insertions(+), 10 deletions(-)
> >
> > diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
> > index 058f2b94db..734a527e68 100644
> > --- a/libswscale/swscale_unscaled.c
> > +++ b/libswscale/swscale_unscaled.c
> > @@ -1942,6 +1942,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
> >   dstFormat == AV_PIX_FMT_GBRP12LE || dstFormat == 
> > AV_PIX_FMT_GBRP12BE ||
> >   dstFormat == AV_PIX_FMT_GBRP14LE || dstFormat == 
> > AV_PIX_FMT_GBRP14BE ||
> >   dstFormat == AV_PIX_FMT_GBRP16LE || dstFormat == 
> > AV_PIX_FMT_GBRP16BE ||
> > + dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == 
> > AV_PIX_FMT_GBRAP10BE ||
> >   dstFormat == AV_PIX_FMT_GBRAP12LE || dstFormat == 
> > AV_PIX_FMT_GBRAP12BE ||
> >   dstFormat == AV_PIX_FMT_GBRAP16LE || dstFormat == 
> > AV_PIX_FMT_GBRAP16BE ))
> >  c->swscale = Rgb16ToPlanarRgb16Wrapper;
> > @@ -1951,6 +1952,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
> >   srcFormat == AV_PIX_FMT_GBRP10LE || srcFormat == 
> > AV_PIX_FMT_GBRP10BE ||
> >   srcFormat == AV_PIX_FMT_GBRP12LE || srcFormat == 
> > AV_PIX_FMT_GBRP12BE ||
> >   srcFormat == AV_PIX_FMT_GBRP14LE || srcFormat == 
> > AV_PIX_FMT_GBRP14BE ||
> > + srcFormat == AV_PIX_FMT_GBRAP10LE || srcFormat == 
> > AV_PIX_FMT_GBRAP10BE ||
> >   srcFormat == AV_PIX_FMT_GBRAP12LE || srcFormat == 
> > AV_PIX_FMT_GBRAP12BE ||
> >   srcFormat == AV_PIX_FMT_GBRAP16LE || srcFormat == 
> > AV_PIX_FMT_GBRAP16BE) &&
> >  (dstFormat == AV_PIX_FMT_RGB48LE  || dstFormat == 
> > AV_PIX_FMT_RGB48BE  ||
> > @@ -1997,6 +1999,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
> >  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP12) ||
> >  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP14) ||
> >  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP16) ||
> > +IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP10) ||
> >  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP12) ||
> >  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP16) ||
> >  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_RGB444) ||
>
> have you tested these ?
> iam asking as the previous iteration had a bug which was missed in testing

fate-filter-pixfmts only covers gbrap10le <-> gbrap10be conversion.
Actually the first two changes fix gbrap10 <-> rgb(a)(64/48) conversions.

This is a simple test:
FFMPEG=./ffmpeg

$FFMPEG -loglevel quiet -filter_complex "allyuv=d=0.01" -pix_fmt
gbrap10le -f rawvideo -y in.rgb

for fmt in rgba64be bgra64be rgba64le bgra64be gbrap10be; do
$FFMPEG -loglevel quiet -s 4096x4096 -pix_fmt gbrap10le -f
rawvideo -i in.rgb -vf format=$fmt -pix_fmt gbrap10le -f rawvideo -y
out-$fmt.rgb
if cmp in.rgb out-$fmt.rgb; then
echo "in.rgb out-$fmt.rgb are equal"
fi
done

> also adding a test or tests to fate which would cover that codepath that was
> missed could be a good idea

As I suggested in 1/5, adding a test that covers all lossless
conversions (not only gbrap10 case) is a good idea.
But that is beyond of this patch.

(Also note that p010 and p016 problems haven't yet been fixed.)

>
> the change itself looks fine i think but i have not tested it beyond seeing
> that it changes the output for some files
>
> Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 3/5] avfilter/vf_super2xsai: fix big-endian writing

[Muhammad Faiz]

Fix mismatched checksum on fate-filter-pixfmts-super2xsai.

Signed-off-by: Muhammad Faiz 
---
 libavfilter/vf_super2xsai.c  |  4 ++--
 tests/ref/fate/filter-pixfmts-super2xsai | 16 
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/libavfilter/vf_super2xsai.c b/libavfilter/vf_super2xsai.c
index 87eec04da8..4901e03e23 100644
--- a/libavfilter/vf_super2xsai.c
+++ b/libavfilter/vf_super2xsai.c
@@ -180,8 +180,8 @@ static void super2xsai(AVFilterContext *ctx,
 break;
 default: // bpp = 2
 if (s->is_be) {
-AV_WB32(dst_line[0] + x * 4, product1a | (product1b << 
16));
-AV_WB32(dst_line[1] + x * 4, product2a | (product2b << 
16));
+AV_WB32(dst_line[0] + x * 4, (product1a << 16) | 
product1b);
+AV_WB32(dst_line[1] + x * 4, (product2a << 16) | 
product2b);
 } else {
 AV_WL32(dst_line[0] + x * 4, product1a | (product1b << 
16));
 AV_WL32(dst_line[1] + x * 4, product2a | (product2b << 
16));
diff --git a/tests/ref/fate/filter-pixfmts-super2xsai 
b/tests/ref/fate/filter-pixfmts-super2xsai
index 04cf00dae4..6e9e1144d3 100644
--- a/tests/ref/fate/filter-pixfmts-super2xsai
+++ b/tests/ref/fate/filter-pixfmts-super2xsai
@@ -1,18 +1,18 @@
 abgre21be14b5fe9d7a29740a418c325b17e
 argb563489534663cb2b32beed2b41370c37
 bgr24   a933eac9bb53c3ce3c33950b229996b5
-bgr555bed6d14ec3ae9ed3006a253e9b9a9a
-bgr555be(le)d69e39a24027afcb28feaabb46f0948d
+bgr555bea293b0b4c6747b5b3f8fd4f9c4907ed1
+bgr555be(le)70b819425f79f823356229b90b41cc84
 bgr555le70b819425f79f823356229b90b41cc84
-bgr565be4ffcc26e740622ffd3314fe251e97804
-bgr565be(le)78f3b43ddcc1f8558444c97d249a6123
+bgr565beaa4a030327932a2c72dff315bf4d7385
+bgr565be(le)6fb9dc50a81b853800ba65d5ec6b8417
 bgr565le6fb9dc50a81b853800ba65d5ec6b8417
 bgrae9cc6644e2f35103c241094ab4bb8fec
 rgb24   3fd7653f414f350ddb0c0a236ce0c809
-rgb555be0f34c006142babd10065d90b8c2ce3d6
-rgb555be(le)f2f9f30e8be582729f12a03331e3c635
+rgb555be35860f8ca6c7e314dc3f658be6bb44ca
+rgb555be(le)53325a20c913826566880eb25d1d2946
 rgb555le53325a20c913826566880eb25d1d2946
-rgb565be9889faf1a636161f3049b78e92db7d89
-rgb565be(le)340ffed3645809f68346280764ca3de6
+rgb565be2c5adfea1c3843ca04355b0ccd293783
+rgb565be(le)14fe550f449a7539d9f1e99e85cf40f1
 rgb565le14fe550f449a7539d9f1e99e85cf40f1
 rgba7041184d35c316e73e849504b64bc4f6
-- 
2.17.2

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

[FFmpeg-devel] [PATCH v2 4/5] avfilter/vf_lut: support native-endian instead of little-endian

[Muhammad Faiz]

This should make code run faster on big-endian platform.
Change fate to use native-endian mode.

Signed-off-by: Muhammad Faiz 
---
 libavfilter/vf_lut.c  | 123 ++
 tests/fate/filter-video.mak   |   2 +-
 tests/ref/fate/filter-pixfmts-lut | 105 -
 3 files changed, 127 insertions(+), 103 deletions(-)

diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
index c815ddc194..c2bddfaaab 100644
--- a/libavfilter/vf_lut.c
+++ b/libavfilter/vf_lut.c
@@ -110,34 +110,34 @@ static av_cold void uninit(AVFilterContext *ctx)
 }
 }
 
-#define YUV_FORMATS \
-AV_PIX_FMT_YUV444P,  AV_PIX_FMT_YUV422P,  AV_PIX_FMT_YUV420P,\
-AV_PIX_FMT_YUV411P,  AV_PIX_FMT_YUV410P,  AV_PIX_FMT_YUV440P,\
-AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA444P,   \
-AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P,   \
-AV_PIX_FMT_YUVJ440P, \
-AV_PIX_FMT_YUV444P9LE, AV_PIX_FMT_YUV422P9LE, AV_PIX_FMT_YUV420P9LE, \
-AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUV422P10LE, AV_PIX_FMT_YUV420P10LE, 
AV_PIX_FMT_YUV440P10LE, \
-AV_PIX_FMT_YUV444P12LE, AV_PIX_FMT_YUV422P12LE, AV_PIX_FMT_YUV420P12LE, 
AV_PIX_FMT_YUV440P12LE, \
-AV_PIX_FMT_YUV444P14LE, AV_PIX_FMT_YUV422P14LE, AV_PIX_FMT_YUV420P14LE, \
-AV_PIX_FMT_YUV444P16LE, AV_PIX_FMT_YUV422P16LE, AV_PIX_FMT_YUV420P16LE, \
-AV_PIX_FMT_YUVA444P16LE, AV_PIX_FMT_YUVA422P16LE, AV_PIX_FMT_YUVA420P16LE
-
-#define RGB_FORMATS \
-AV_PIX_FMT_ARGB, AV_PIX_FMT_RGBA, \
-AV_PIX_FMT_ABGR, AV_PIX_FMT_BGRA, \
-AV_PIX_FMT_RGB24,AV_PIX_FMT_BGR24,\
-AV_PIX_FMT_RGB48LE,  AV_PIX_FMT_RGBA64LE, \
-AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,\
-AV_PIX_FMT_GBRP9LE,  AV_PIX_FMT_GBRP10LE, \
-AV_PIX_FMT_GBRAP10LE, \
-AV_PIX_FMT_GBRP12LE, AV_PIX_FMT_GBRP14LE, \
-AV_PIX_FMT_GBRP16LE, AV_PIX_FMT_GBRAP12LE,\
-AV_PIX_FMT_GBRAP16LE
-
-#define GRAY_FORMATS\
-AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY9LE, AV_PIX_FMT_GRAY10LE, \
-AV_PIX_FMT_GRAY12LE, AV_PIX_FMT_GRAY14LE, AV_PIX_FMT_GRAY16LE
+#define YUV_FORMATS
 \
+AV_PIX_FMT_YUV444P,AV_PIX_FMT_YUV422P,AV_PIX_FMT_YUV420P,  
 \
+AV_PIX_FMT_YUV411P,AV_PIX_FMT_YUV410P,AV_PIX_FMT_YUV440P,  
 \
+AV_PIX_FMT_YUVA420P,   AV_PIX_FMT_YUVA422P,   AV_PIX_FMT_YUVA444P, 
 \
+AV_PIX_FMT_YUVJ444P,   AV_PIX_FMT_YUVJ422P,   AV_PIX_FMT_YUVJ420P, 
 \
+AV_PIX_FMT_YUVJ440P,   
 \
+AV_PIX_FMT_YUV444P9,   AV_PIX_FMT_YUV422P9,   AV_PIX_FMT_YUV420P9, 
 \
+AV_PIX_FMT_YUV444P10,  AV_PIX_FMT_YUV422P10,  AV_PIX_FMT_YUV420P10, 
AV_PIX_FMT_YUV440P10, \
+AV_PIX_FMT_YUV444P12,  AV_PIX_FMT_YUV422P12,  AV_PIX_FMT_YUV420P12, 
AV_PIX_FMT_YUV440P12, \
+AV_PIX_FMT_YUV444P14,  AV_PIX_FMT_YUV422P14,  AV_PIX_FMT_YUV420P14,
 \
+AV_PIX_FMT_YUV444P16,  AV_PIX_FMT_YUV422P16,  AV_PIX_FMT_YUV420P16,
 \
+AV_PIX_FMT_YUVA444P16, AV_PIX_FMT_YUVA422P16, AV_PIX_FMT_YUVA420P16
+
+#define RGB_FORMATS \
+AV_PIX_FMT_ARGB,AV_PIX_FMT_RGBA,\
+AV_PIX_FMT_ABGR,AV_PIX_FMT_BGRA,\
+AV_PIX_FMT_RGB24,   AV_PIX_FMT_BGR24,   \
+AV_PIX_FMT_RGB48,   AV_PIX_FMT_RGBA64,  \
+AV_PIX_FMT_GBRP,AV_PIX_FMT_GBRAP,   \
+AV_PIX_FMT_GBRP9,   AV_PIX_FMT_GBRP10,  \
+AV_PIX_FMT_GBRAP10, \
+AV_PIX_FMT_GBRP12,  AV_PIX_FMT_GBRP14,  \
+AV_PIX_FMT_GBRP16,  AV_PIX_FMT_GBRAP12, \
+AV_PIX_FMT_GBRAP16
+
+#define GRAY_FORMATS \
+AV_PIX_FMT_GRAY8,  AV_PIX_FMT_GRAY9,  AV_PIX_FMT_GRAY10, \
+AV_PIX_FMT_GRAY12, AV_PIX_FMT_GRAY14, AV_PIX_FMT_GRAY16
 
 static const enum AVPixelFormat yuv_pix_fmts[] = { YUV_FORMATS, 
AV_PIX_FMT_NONE };
 static const enum AVPixelFormat rgb_pix_fmts[] = { RGB_FORMATS, 
AV_PIX_FMT_NONE };
@@ -237,32 +237,32 @@ static int config_props(AVFilterLink *inlink)
 case AV_PIX_FMT_YUVA420P:
 case AV_PIX_FMT_YUVA422P:
 case AV_PIX_FMT_YUVA444P:
-case AV_PIX_FMT_YUV420P9LE:
-case AV_PIX_FMT_YUV422P9LE:
-case AV_PIX_FMT_YUV444P9LE:
-case AV_PIX_FMT_YUVA420P9LE:
-case AV_PIX_FMT_YUVA422P9LE:
-case AV_PIX_FMT_YUVA444P9LE:
-case AV_PIX_FMT_YUV420P10LE:
-case AV_PIX_FMT_YUV422P10LE:
-case AV_PIX_FMT_YUV440P10LE:
-case AV_PIX_FMT_YUV444P10LE:
-case AV_PIX_FMT_YUVA420P10LE:
-case AV_PIX_FMT_YUVA422P10LE:
-case AV_PIX_FMT_YUVA444P10LE:
-case AV_PIX_FMT_YUV420P12LE:
-case AV_PIX_FMT_YUV422P12LE:
-case AV_PIX_FMT_YUV440P12LE:
-case AV_PIX_FMT_YUV444P12LE:
-case AV_PIX_FMT_YUV420P14LE:
-case

[FFmpeg-devel] [PATCH v2 5/5] avfilter/drawutils: support native-endian instead of little-endian

[Muhammad Faiz]

This should make code run faster on big-endian platform.
Change fate to use native-endian mode.

Signed-off-by: Muhammad Faiz 
---
 libavfilter/drawutils.c   |  36 +++--
 libavfilter/vf_rotate.c   |  26 ++--
 libavfilter/vf_tinterlace.c   |  30 ++--
 tests/fate/filter-video.mak   |  12 +-
 tests/ref/fate/filter-pixfmts-pad | 129 --
 tests/ref/fate/filter-pixfmts-rotate  |  42 --
 .../ref/fate/filter-pixfmts-tinterlace_cvlpf  |  33 +++--
 .../ref/fate/filter-pixfmts-tinterlace_merge  |  33 +++--
 tests/ref/fate/filter-pixfmts-tinterlace_pad  |  33 +++--
 tests/ref/fate/filter-pixfmts-tinterlace_vlpf |  33 +++--
 10 files changed, 251 insertions(+), 156 deletions(-)

diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
index 5f4cb548f0..7a8ace2c74 100644
--- a/libavfilter/drawutils.c
+++ b/libavfilter/drawutils.c
@@ -185,7 +185,7 @@ int ff_draw_init(FFDrawContext *draw, enum AVPixelFormat 
format, unsigned flags)
 
 if (!desc || !desc->name)
 return AVERROR(EINVAL);
-if (desc->flags & ~(AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_RGB | 
FF_PSEUDOPAL | AV_PIX_FMT_FLAG_ALPHA))
+if (desc->flags & ~(AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_RGB | 
FF_PSEUDOPAL | AV_PIX_FMT_FLAG_ALPHA | AV_PIX_FMT_FLAG_BE))
 return AVERROR(ENOSYS);
 if (format == AV_PIX_FMT_P010LE || format == AV_PIX_FMT_P010BE || format 
== AV_PIX_FMT_P016LE || format == AV_PIX_FMT_P016BE)
 return AVERROR(ENOSYS);
@@ -197,7 +197,8 @@ int ff_draw_init(FFDrawContext *draw, enum AVPixelFormat 
format, unsigned flags)
 /* for now, only 8-16 bits formats */
 if (c->depth < 8 || c->depth > 16)
 return AVERROR(ENOSYS);
-if (desc->flags & AV_PIX_FMT_FLAG_BE)
+/* native-endian only */
+if (c->depth + c->shift > 8 && !(desc->flags & AV_PIX_FMT_FLAG_BE) == 
HAVE_BIGENDIAN)
 return AVERROR(ENOSYS);
 if (c->plane >= MAX_PLANES)
 return AVERROR(ENOSYS);
@@ -268,11 +269,11 @@ void ff_draw_color(FFDrawContext *draw, FFDrawColor 
*color, const uint8_t rgba[4
 EXPAND(1);
 EXPAND(0);
 } else if (draw->format == AV_PIX_FMT_GRAY8 || draw->format == 
AV_PIX_FMT_GRAY8A ||
-   draw->format == AV_PIX_FMT_GRAY16LE || draw->format == 
AV_PIX_FMT_YA16LE ||
-   draw->format == AV_PIX_FMT_GRAY9LE  ||
-   draw->format == AV_PIX_FMT_GRAY10LE ||
-   draw->format == AV_PIX_FMT_GRAY12LE ||
-   draw->format == AV_PIX_FMT_GRAY14LE) {
+   draw->format == AV_PIX_FMT_GRAY16 || draw->format == 
AV_PIX_FMT_YA16 ||
+   draw->format == AV_PIX_FMT_GRAY9  ||
+   draw->format == AV_PIX_FMT_GRAY10 ||
+   draw->format == AV_PIX_FMT_GRAY12 ||
+   draw->format == AV_PIX_FMT_GRAY14) {
 const AVPixFmtDescriptor *desc = draw->desc;
 color->comp[0].u8[0] = RGB_TO_Y_CCIR(rgba[0], rgba[1], rgba[2]);
 EXPAND(0);
@@ -331,11 +332,6 @@ void ff_fill_rectangle(FFDrawContext *draw, FFDrawColor 
*color,
 return;
 p = p0;
 
-if (HAVE_BIGENDIAN && draw->desc->comp[0].depth > 8) {
-for (x = 0; 2*x < draw->pixelstep[plane]; x++)
-color_tmp.comp[plane].u16[x] = 
av_bswap16(color_tmp.comp[plane].u16[x]);
-}
-
 /* copy first line from color */
 for (x = 0; x < wp; x++) {
 memcpy(p, color_tmp.comp[plane].u8, draw->pixelstep[plane]);
@@ -426,19 +422,19 @@ static void blend_line16(uint8_t *dst, unsigned src, 
unsigned alpha,
 
 if (left) {
 unsigned suba = (left * alpha) >> hsub;
-uint16_t value = AV_RL16(dst);
-AV_WL16(dst, (value * (0x10001 - suba) + src * suba) >> 16);
+uint16_t value = AV_RN16A(dst);
+AV_WN16A(dst, (value * (0x10001 - suba) + src * suba) >> 16);
 dst += dx;
 }
 for (x = 0; x < w; x++) {
-uint16_t value = AV_RL16(dst);
-AV_WL16(dst, (value * tau + asrc) >> 16);
+uint16_t value = AV_RN16A(dst);
+AV_WN16A(dst, (value * tau + asrc) >> 16);
 dst += dx;
 }
 if (right) {
 unsigned suba = (right * alpha) >> hsub;
-uint16_t value = AV_RL16(dst);
-AV_WL16(dst, (value * (0x10001 - suba) + src * suba) >> 16);
+uint16_t value = AV_RN16A(dst);
+AV_WN16A(dst, (value * (0x10001 - suba) + src * suba) >> 16);
 }
 }
 
@@ -531,7 +527,7 @@ static void blend_pixel16(uint8_t *dst, unsigned src, 
unsigned alpha,
 unsigned xmmod = 7 >> l2depth;
 unsigned mbits = (1 << (1 << l2depth)) - 1;
 unsigned mmult = 255 / mbits;
-uint16_t value = AV_RL16(dst)

[FFmpeg-devel] [PATCH v2 2/5] swscale/swscale_unscaled: add missing gbrap10 on ff_get_unscaled_swscale

[Muhammad Faiz]

Fix inconsistent checksums between gbrap10be and gbrap10le
on fate-filter-pixfmts.

Signed-off-by: Muhammad Faiz 
---
 libswscale/swscale_unscaled.c| 3 +++
 tests/ref/fate/filter-pixfmts-copy   | 2 +-
 tests/ref/fate/filter-pixfmts-crop   | 2 +-
 tests/ref/fate/filter-pixfmts-field  | 2 +-
 tests/ref/fate/filter-pixfmts-fieldorder | 2 +-
 tests/ref/fate/filter-pixfmts-hflip  | 2 +-
 tests/ref/fate/filter-pixfmts-il | 2 +-
 tests/ref/fate/filter-pixfmts-null   | 2 +-
 tests/ref/fate/filter-pixfmts-scale  | 2 +-
 tests/ref/fate/filter-pixfmts-transpose  | 2 +-
 tests/ref/fate/filter-pixfmts-vflip  | 2 +-
 11 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 058f2b94db..734a527e68 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -1942,6 +1942,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
  dstFormat == AV_PIX_FMT_GBRP12LE || dstFormat == AV_PIX_FMT_GBRP12BE 
||
  dstFormat == AV_PIX_FMT_GBRP14LE || dstFormat == AV_PIX_FMT_GBRP14BE 
||
  dstFormat == AV_PIX_FMT_GBRP16LE || dstFormat == AV_PIX_FMT_GBRP16BE 
||
+ dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == 
AV_PIX_FMT_GBRAP10BE ||
  dstFormat == AV_PIX_FMT_GBRAP12LE || dstFormat == 
AV_PIX_FMT_GBRAP12BE ||
  dstFormat == AV_PIX_FMT_GBRAP16LE || dstFormat == 
AV_PIX_FMT_GBRAP16BE ))
 c->swscale = Rgb16ToPlanarRgb16Wrapper;
@@ -1951,6 +1952,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
  srcFormat == AV_PIX_FMT_GBRP10LE || srcFormat == AV_PIX_FMT_GBRP10BE 
||
  srcFormat == AV_PIX_FMT_GBRP12LE || srcFormat == AV_PIX_FMT_GBRP12BE 
||
  srcFormat == AV_PIX_FMT_GBRP14LE || srcFormat == AV_PIX_FMT_GBRP14BE 
||
+ srcFormat == AV_PIX_FMT_GBRAP10LE || srcFormat == 
AV_PIX_FMT_GBRAP10BE ||
  srcFormat == AV_PIX_FMT_GBRAP12LE || srcFormat == 
AV_PIX_FMT_GBRAP12BE ||
  srcFormat == AV_PIX_FMT_GBRAP16LE || srcFormat == 
AV_PIX_FMT_GBRAP16BE) &&
 (dstFormat == AV_PIX_FMT_RGB48LE  || dstFormat == AV_PIX_FMT_RGB48BE  
||
@@ -1997,6 +1999,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP12) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP14) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP16) ||
+IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP10) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP12) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP16) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_RGB444) ||
diff --git a/tests/ref/fate/filter-pixfmts-copy 
b/tests/ref/fate/filter-pixfmts-copy
index 2417c577bd..82b8f28c31 100644
--- a/tests/ref/fate/filter-pixfmts-copy
+++ b/tests/ref/fate/filter-pixfmts-copy
@@ -25,7 +25,7 @@ bgra64be(le)b71d75a928aac14cb768403e6f6a9910
 bgra64leb71d75a928aac14cb768403e6f6a9910
 gbrap   98d30987407c51e5620921e11d40a4ff
 gbrap10be   edcffb185e44b6dae5c2ead5505b7125
-gbrap10be(le)   3a046be0d38289dda5d8fdbd0f34aaf5
+gbrap10be(le)   2a7392e14b21b1f9457526a071236a6d
 gbrap10le   2a7392e14b21b1f9457526a071236a6d
 gbrap12be   0c4c1f8af361571265ca259d5f70f026
 gbrap12be(le)   5f1d8c663d4c28863e687192433b34a4
diff --git a/tests/ref/fate/filter-pixfmts-crop 
b/tests/ref/fate/filter-pixfmts-crop
index a0e1d9584f..cc32f2c99c 100644
--- a/tests/ref/fate/filter-pixfmts-crop
+++ b/tests/ref/fate/filter-pixfmts-crop
@@ -25,7 +25,7 @@ bgra64be(le)dd29ec9aba43aa3e8f9f5b9a93ca8831
 bgra64ledd29ec9aba43aa3e8f9f5b9a93ca8831
 gbrap   188cd467fe7ae7d85ae9ca8bdfa07739
 gbrap10be   1880c4856d9cc6492b8b859f2711aaf1
-gbrap10be(le)   c8505df07f9eeb413f943b5f4d686c0b
+gbrap10be(le)   c2b6e35f8b7ca363a7ec021ccdf31d1f
 gbrap10le   c2b6e35f8b7ca363a7ec021ccdf31d1f
 gbrap12be   c9769d18733cdc2664d8b9af09a03f6d
 gbrap12be(le)   3f80453c1ac6c5d1b2febf3ef141b476
diff --git a/tests/ref/fate/filter-pixfmts-field 
b/tests/ref/fate/filter-pixfmts-field
index 210fa97e48..3ae7144e26 100644
--- a/tests/ref/fate/filter-pixfmts-field
+++ b/tests/ref/fate/filter-pixfmts-field
@@ -25,7 +25,7 @@ bgra64be(le)9e2def541e51bc6e77fbffbff7fa146a
 bgra64le9e2def541e51bc6e77fbffbff7fa146a
 gbrap   08a28b79dbd19246d1a94e3466af3624
 gbrap10be   29d46cbf021b233f5f1886e5d5fe21b4
-gbrap10be(le)   a5cfc53fbd96fcdf83b8b655fe25bf67
+gbrap10be(le)   4017c5d8c124438eb9aefa107db58d3b
 gbrap10le   4017c5d8c124438eb9aefa107db58d3b
 gbrap12be   e7f471132628b1c034199cc109b84bc2
 gbrap12be(le)   886207e5aa379a0312485b94e5fd5edd
diff --git a/tests/ref/fate/filter-pixfmts-fieldorder 
b/tests/ref/fate/filter-pixfmts-field

Re: [FFmpeg-devel] [PATCH 2/5] swscale/swscale_unscaled: add missing gbrap10 on ff_get_unscaled_swscale

[Muhammad Faiz]

On Mon, Jan 28, 2019 at 2:52 AM Michael Niedermayer
 wrote:
>
> On Sun, Jan 27, 2019 at 04:36:16PM +0700, Muhammad Faiz wrote:
> > Fix inconsistent checksums between gbrap10be
> > and gbrap10le on fate-filter-pixfmts.
> >
> > Signed-off-by: Muhammad Faiz 
> > ---
> >  libswscale/swscale_unscaled.c| 3 +++
> >  tests/ref/fate/filter-pixfmts-copy   | 2 +-
> >  tests/ref/fate/filter-pixfmts-crop   | 2 +-
> >  tests/ref/fate/filter-pixfmts-field  | 2 +-
> >  tests/ref/fate/filter-pixfmts-fieldorder | 2 +-
> >  tests/ref/fate/filter-pixfmts-hflip  | 2 +-
> >  tests/ref/fate/filter-pixfmts-il | 2 +-
> >  tests/ref/fate/filter-pixfmts-null   | 2 +-
> >  tests/ref/fate/filter-pixfmts-transpose  | 2 +-
> >  tests/ref/fate/filter-pixfmts-vflip  | 2 +-
> >  10 files changed, 12 insertions(+), 9 deletions(-)
> >
> > diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
> > index 058f2b94db..9abfae5c04 100644
> > --- a/libswscale/swscale_unscaled.c
> > +++ b/libswscale/swscale_unscaled.c
> > @@ -1942,6 +1942,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
> >   dstFormat == AV_PIX_FMT_GBRP12LE || dstFormat == 
> > AV_PIX_FMT_GBRP12BE ||
> >   dstFormat == AV_PIX_FMT_GBRP14LE || dstFormat == 
> > AV_PIX_FMT_GBRP14BE ||
> >   dstFormat == AV_PIX_FMT_GBRP16LE || dstFormat == 
> > AV_PIX_FMT_GBRP16BE ||
> > + dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == 
> > AV_PIX_FMT_GBRAP10LE ||
> >   dstFormat == AV_PIX_FMT_GBRAP12LE || dstFormat == 
> > AV_PIX_FMT_GBRAP12BE ||
> >   dstFormat == AV_PIX_FMT_GBRAP16LE || dstFormat == 
> > AV_PIX_FMT_GBRAP16BE ))
> >  c->swscale = Rgb16ToPlanarRgb16Wrapper;
>
> > @@ -1951,6 +1952,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
> >   srcFormat == AV_PIX_FMT_GBRP10LE || srcFormat == 
> > AV_PIX_FMT_GBRP10BE ||
> >   srcFormat == AV_PIX_FMT_GBRP12LE || srcFormat == 
> > AV_PIX_FMT_GBRP12BE ||
> >   srcFormat == AV_PIX_FMT_GBRP14LE || srcFormat == 
> > AV_PIX_FMT_GBRP14BE ||
> > + dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == 
> > AV_PIX_FMT_GBRAP10LE ||
> >   srcFormat == AV_PIX_FMT_GBRAP12LE || srcFormat == 
> > AV_PIX_FMT_GBRAP12BE ||
> >   srcFormat == AV_PIX_FMT_GBRAP16LE || srcFormat == 
> > AV_PIX_FMT_GBRAP16BE) &&
>
> this looks a bit strange, the added line adds a dstFormat check into a list of
> srcFormat checks, also the check is added twice

My bad. Will fix it.

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

Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts

[Muhammad Faiz]

On Mon, Jan 28, 2019 at 3:07 AM Michael Niedermayer
 wrote:
>
> On Sun, Jan 27, 2019 at 11:24:46PM +0700, Muhammad Faiz wrote:
> > On Sun, Jan 27, 2019 at 10:53 PM Michael Niedermayer
> >  wrote:
> > >
> > > On Sun, Jan 27, 2019 at 04:36:15PM +0700, Muhammad Faiz wrote:
> > > > regardless of the actual supported formats.
> > > > This allows filters to support only native-endian formats,
> > > > and also allows consistency checks between little-endian
> > > > and big-endian implementation.
> > > >
> > > > This also reveals bugs on gbrap10, p010, p016 format, and
> > > > super2xsai filter (mismatched checksums between little-endian
> > > > and big-endian).
> > > >
> > > > Suggested-by: Hendrik Leppkes 
> > > > Signed-off-by: Muhammad Faiz 
> > > > ---
> > > > Old thread is here: 
> > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195930.html
> > > >
> > > >  tests/fate-run.sh|   6 +-
> > > >  tests/ref/fate/filter-pixfmts-copy   | 112 +++
> > > >  tests/ref/fate/filter-pixfmts-crop   | 112 +++
> > > >  tests/ref/fate/filter-pixfmts-field  | 112 +++
> > > >  tests/ref/fate/filter-pixfmts-fieldorder |  88 +-
> > > >  tests/ref/fate/filter-pixfmts-hflip  | 112 +++
> > > >  tests/ref/fate/filter-pixfmts-il | 112 +++
> > > >  tests/ref/fate/filter-pixfmts-null   | 112 +++
> > > >  tests/ref/fate/filter-pixfmts-scale  | 112 +++
> > > >  tests/ref/fate/filter-pixfmts-super2xsai |   8 +-
> > > >  tests/ref/fate/filter-pixfmts-swapuv |  56 ++--
> > > >  tests/ref/fate/filter-pixfmts-transpose  |  90 +-
> > > >  tests/ref/fate/filter-pixfmts-vflip  | 112 +++
> > > >  13 files changed, 573 insertions(+), 571 deletions(-)
> > > >
> > > > diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> > > > index aece90a01d..faa4285e71 100755
> > > > --- a/tests/fate-run.sh
> > > > +++ b/tests/fate-run.sh
> > > > @@ -297,8 +297,10 @@ pixfmts(){
> > > >
> > > >  outertest=$test
> > > >  for pix_fmt in $pix_fmts; do
> > > > -test=$pix_fmt
> > > > -video_filter 
> > > > "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt 
> > > > $pix_fmt -frames:v $nframes
> > > > +# force little endian format on result
> > > > +pix_fmt_le=`echo $pix_fmt | sed 's/be$/le/'`
> > > > +test=$pix_fmt_le
> > > > +video_filter 
> > > > "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt 
> > > > $pix_fmt_le -frames:v $nframes
> > > >  done
> > >
> > > if the input to a filter is a big endian format and the output is little
> > > endian. Then there really isnt a gurantee that the filter will work with
> > > big endian data. The libavfilter core could convert before or after the 
> > > filter
> > > as it preferrs. At least thats how i remember it from the last time i 
> > > looked
> > > at the code.
> > > This also makes sense, as there are very good reasons to convert before,
> > > for example when doing so results in better quality or higher speed
> > > or fewer converts overall in multi input or multi output filters...
> >
> > Of course, this can be easily fixed by adding format=$pix_fmt after
> > $filter=$filter_args.
> >
>
> > >
> > > So if the output is always forced to LE then this may unintentionally
> > > remove testing a range of cases.
> > > also this removes testing the codepath for big endian formats after the
> > > convert. Or do we have remaining cases that test these ?
> >
> > Do you suggest to duplicate test to output BE and LE simultaneously?
>
> I dont really have a specific suggestion, just dont want to have some
> codepathes be lost from testing
> a solution that doesnt duplicate all the tests would be better i guess
> as it would be quicker

Do you feel that because BE disappears in the output, it means that BE
is untested?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] avfilter/drawutils: support native-endian instead of little endian

[Muhammad Faiz]

On Sun, Jan 27, 2019 at 11:21 PM Marton Balint  wrote:
>
>
>
> On Sun, 27 Jan 2019, Muhammad Faiz wrote:
>
> > On Sun, Jan 27, 2019 at 5:25 PM Marton Balint  wrote:
> >>
> >>
> >>
> >> On Sun, 27 Jan 2019, Muhammad Faiz wrote:
> >>
> >> > Signed-off-by: Muhammad Faiz 
> >> > ---
> >> > Old thread is here: 
> >> > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195941.html
> >> > Need someone test it on big-endian machine.
> >> >
> >> > libavfilter/drawutils.c | 48 +
> >> > libavfilter/vf_rotate.c | 26 ++--
> >> > libavfilter/vf_tinterlace.c | 30 +++
> >> > 3 files changed, 54 insertions(+), 50 deletions(-)
> >> >
> >> > diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
> >> > index 5f4cb548f0..12bdfcb900 100644
> >> > --- a/libavfilter/drawutils.c
> >> > +++ b/libavfilter/drawutils.c
> >> > @@ -175,6 +175,17 @@ void ff_copy_rectangle(uint8_t *dst[4], int 
> >> > dst_linesize[4],
> >> > }
> >> > }
> >> >
> >> > +static int is_native_endian(const AVPixFmtDescriptor *desc)
> >> > +{
> >> > +int len = strlen(desc->name);
> >> > +
> >> > +if (!strcmp(desc->name + len - 2, "be"))
> >> > +return HAVE_BIGENDIAN;
> >> > +if (!strcmp(desc->name + len - 2, "le"))
> >> > +return !HAVE_BIGENDIAN;
> >> > +return 1;
> >> > +}
> >> > +
> >>
> >> Maybe you can check if shift+depth > 8 and FMT_FLAG_BE instead of string
> >> compare?
> >
> > I don't really understand your code. Currently I can't test on
> > big-endian platform. Adding something that I don't understand and
> > can't test is not a good idea.
>
> Using strcmp to determine format endianness is ugly. Use other means, like
> checking component bit depth, or component step:
>
> static int is_native_endian(const AVPixFmtDescriptor *desc)
> {
>  return desc->comp[0].step <= 1 ||
> (HAVE_BIGENDIAN == !!(desc->comp[0].flags & AV_PIX_FMT_FLAG_BE));
> }
>

comp[0] doesn't have flags.
Anyway, I will try.

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

Re: [FFmpeg-devel] [PATCH 5/5] avfilter/drawutils: support native-endian instead of little endian

[Muhammad Faiz]

On Sun, Jan 27, 2019 at 11:02 PM Carl Eugen Hoyos  wrote:
>
> 2019-01-27 16:18 GMT+01:00, Muhammad Faiz :
> > On Sun, Jan 27, 2019 at 5:25 PM Marton Balint  wrote:
> >>
> >>
> >>
> >> On Sun, 27 Jan 2019, Muhammad Faiz wrote:
> >>
> >> > Signed-off-by: Muhammad Faiz 
> >> > ---
> >> > Old thread is here:
> >> > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195941.html
> >> > Need someone test it on big-endian machine.
> >> >
> >> > libavfilter/drawutils.c | 48 +
> >> > libavfilter/vf_rotate.c | 26 ++--
> >> > libavfilter/vf_tinterlace.c | 30 +++
> >> > 3 files changed, 54 insertions(+), 50 deletions(-)
> >> >
> >> > diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
> >> > index 5f4cb548f0..12bdfcb900 100644
> >> > --- a/libavfilter/drawutils.c
> >> > +++ b/libavfilter/drawutils.c
> >> > @@ -175,6 +175,17 @@ void ff_copy_rectangle(uint8_t *dst[4], int
> >> > dst_linesize[4],
> >> > }
> >> > }
> >> >
> >> > +static int is_native_endian(const AVPixFmtDescriptor *desc)
> >> > +{
> >> > +int len = strlen(desc->name);
> >> > +
> >> > +if (!strcmp(desc->name + len - 2, "be"))
> >> > +return HAVE_BIGENDIAN;
> >> > +if (!strcmp(desc->name + len - 2, "le"))
> >> > +return !HAVE_BIGENDIAN;
> >> > +return 1;
> >> > +}
> >> > +
> >>
> >> Maybe you can check if shift+depth > 8 and FMT_FLAG_BE
> >> instead of string compare?
> >
> > I don't really understand your code.
>
> Something like "return shift + depth <=8 ||
> desc->flags | FMT_FLAG_BE ^ !HAVE_BIGENDIAN"

OK, I will try.

>
> And since the new function is only used once, it may
> be more readable not to add a new function.

OK.

>
> > Currently I can't test on big-endian platform. Adding
> > something that I don't understand and
> > can't test is not a good idea.
>
> But your patchset does change big-endian code and only
> improves big-endian, no?

Yes. I write it blindly. I really depends on Michael's report on
big-endian platform.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts

[Muhammad Faiz]

On Sun, Jan 27, 2019 at 10:54 PM Carl Eugen Hoyos  wrote:
>
> 2019-01-27 16:07 GMT+01:00, Muhammad Faiz :
> > On Sun, Jan 27, 2019 at 9:15 PM Carl Eugen Hoyos  wrote:
> >>
> >> 2019-01-27 15:05 GMT+01:00, Muhammad Faiz :
> >> > On Sun, Jan 27, 2019 at 7:17 PM Carl Eugen Hoyos 
> >> > wrote:
> >> >>
> >> >> 2019-01-27 10:36 GMT+01:00, Muhammad Faiz :
> >> >>
> >> >> > -bgra64bec8d3217bf58d34f080ac88c0b0012c77
> >> >> > +bgra64leb71d75a928aac14cb768403e6f6a9910
> >> >> >  bgra64leb71d75a928aac14cb768403e6f6a9910
> >> >>
> >> >> I believe the output should be changed to make it less
> >> >> confusing.
> >> >
> >> > Any attempt to differentiate these two lines makes [4/5]
> >> > and [5/5] don't work.
> >>
> >> I wonder if this just indicates that your approach is wrong,
> >> and that the tests for the filters in question have to be
> >> (completely) different.
> >
> > How can this approach be wrong if it revealed bug?
>
> As I tried to explain I am happy that you found this issue,
> but I believe an approach should be searched that produces
> a little more useful output.

Can you give me an example how the output should be?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts

[Muhammad Faiz]

On Sun, Jan 27, 2019 at 10:53 PM Michael Niedermayer
 wrote:
>
> On Sun, Jan 27, 2019 at 04:36:15PM +0700, Muhammad Faiz wrote:
> > regardless of the actual supported formats.
> > This allows filters to support only native-endian formats,
> > and also allows consistency checks between little-endian
> > and big-endian implementation.
> >
> > This also reveals bugs on gbrap10, p010, p016 format, and
> > super2xsai filter (mismatched checksums between little-endian
> > and big-endian).
> >
> > Suggested-by: Hendrik Leppkes 
> > Signed-off-by: Muhammad Faiz 
> > ---
> > Old thread is here: 
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195930.html
> >
> >  tests/fate-run.sh|   6 +-
> >  tests/ref/fate/filter-pixfmts-copy   | 112 +++
> >  tests/ref/fate/filter-pixfmts-crop   | 112 +++
> >  tests/ref/fate/filter-pixfmts-field  | 112 +++
> >  tests/ref/fate/filter-pixfmts-fieldorder |  88 +-
> >  tests/ref/fate/filter-pixfmts-hflip  | 112 +++
> >  tests/ref/fate/filter-pixfmts-il | 112 +++
> >  tests/ref/fate/filter-pixfmts-null   | 112 +++
> >  tests/ref/fate/filter-pixfmts-scale  | 112 +++
> >  tests/ref/fate/filter-pixfmts-super2xsai |   8 +-
> >  tests/ref/fate/filter-pixfmts-swapuv |  56 ++--
> >  tests/ref/fate/filter-pixfmts-transpose  |  90 +-
> >  tests/ref/fate/filter-pixfmts-vflip  | 112 +++
> >  13 files changed, 573 insertions(+), 571 deletions(-)
> >
> > diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> > index aece90a01d..faa4285e71 100755
> > --- a/tests/fate-run.sh
> > +++ b/tests/fate-run.sh
> > @@ -297,8 +297,10 @@ pixfmts(){
> >
> >  outertest=$test
> >  for pix_fmt in $pix_fmts; do
> > -test=$pix_fmt
> > -video_filter 
> > "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt $pix_fmt 
> > -frames:v $nframes
> > +# force little endian format on result
> > +pix_fmt_le=`echo $pix_fmt | sed 's/be$/le/'`
> > +test=$pix_fmt_le
> > +video_filter 
> > "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt 
> > $pix_fmt_le -frames:v $nframes
> >  done
>
> if the input to a filter is a big endian format and the output is little
> endian. Then there really isnt a gurantee that the filter will work with
> big endian data. The libavfilter core could convert before or after the filter
> as it preferrs. At least thats how i remember it from the last time i looked
> at the code.
> This also makes sense, as there are very good reasons to convert before,
> for example when doing so results in better quality or higher speed
> or fewer converts overall in multi input or multi output filters...

Of course, this can be easily fixed by adding format=$pix_fmt after
$filter=$filter_args.

>
> So if the output is always forced to LE then this may unintentionally
> remove testing a range of cases.
> also this removes testing the codepath for big endian formats after the
> convert. Or do we have remaining cases that test these ?

Do you suggest to duplicate test to output BE and LE simultaneously?

>
> I am in favor of adding more and better tests but please make sure
> no codepathes drop out of all tests. (and not just by chance of the
> format negotiation randomly picking the intended choice, which it
> very well might)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] avfilter/drawutils: support native-endian instead of little endian

[Muhammad Faiz]

On Sun, Jan 27, 2019 at 5:25 PM Marton Balint  wrote:
>
>
>
> On Sun, 27 Jan 2019, Muhammad Faiz wrote:
>
> > Signed-off-by: Muhammad Faiz 
> > ---
> > Old thread is here: 
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195941.html
> > Need someone test it on big-endian machine.
> >
> > libavfilter/drawutils.c | 48 +
> > libavfilter/vf_rotate.c | 26 ++--
> > libavfilter/vf_tinterlace.c | 30 +++
> > 3 files changed, 54 insertions(+), 50 deletions(-)
> >
> > diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
> > index 5f4cb548f0..12bdfcb900 100644
> > --- a/libavfilter/drawutils.c
> > +++ b/libavfilter/drawutils.c
> > @@ -175,6 +175,17 @@ void ff_copy_rectangle(uint8_t *dst[4], int 
> > dst_linesize[4],
> > }
> > }
> >
> > +static int is_native_endian(const AVPixFmtDescriptor *desc)
> > +{
> > +int len = strlen(desc->name);
> > +
> > +if (!strcmp(desc->name + len - 2, "be"))
> > +return HAVE_BIGENDIAN;
> > +if (!strcmp(desc->name + len - 2, "le"))
> > +return !HAVE_BIGENDIAN;
> > +return 1;
> > +}
> > +
>
> Maybe you can check if shift+depth > 8 and FMT_FLAG_BE instead of string
> compare?

I don't really understand your code. Currently I can't test on
big-endian platform. Adding something that I don't understand and
can't test is not a good idea.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] avfilter/vf_super2xsai: fix big-endian writing

[Muhammad Faiz]

On Sun, Jan 27, 2019 at 9:17 PM Carl Eugen Hoyos  wrote:
>
> 2019-01-27 15:07 GMT+01:00, Muhammad Faiz :
> > On Sun, Jan 27, 2019 at 7:19 PM Carl Eugen Hoyos  wrote:
> >>
> >> 2019-01-27 10:36 GMT+01:00, Muhammad Faiz :
> >> > Fix mismatched checksum on fate-filter-pixfmts-super2xsai.
> >>
> >> I believe this patch and 2/5 are unrelated and should be
> >> committed independently of the patchset.
> >
> > No. [2/5] and [3/5] depend on [1/5].
>
> No (at least afaiu).
> The fate tests for these changes depend on the first patch.
> But if the tests are currently broken, they cannot be used
> as reasoning for anything.
> Instead, the code should be fixed and the tests disabled.
> (imo)

Don't forget that 2/5 and 3/5 bugs (and p010/p016 bugs) are revealed
by 1/5. It means that 1/5 is important.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts

[Muhammad Faiz]

On Sun, Jan 27, 2019 at 9:15 PM Carl Eugen Hoyos  wrote:
>
> 2019-01-27 15:05 GMT+01:00, Muhammad Faiz :
> > On Sun, Jan 27, 2019 at 7:17 PM Carl Eugen Hoyos  wrote:
> >>
> >> 2019-01-27 10:36 GMT+01:00, Muhammad Faiz :
> >>
> >> > -bgra64bec8d3217bf58d34f080ac88c0b0012c77
> >> > +bgra64leb71d75a928aac14cb768403e6f6a9910
> >> >  bgra64leb71d75a928aac14cb768403e6f6a9910
> >>
> >> I believe the output should be changed to make it less
> >> confusing.
> >
> > Any attempt to differentiate these two lines makes [4/5]
> > and [5/5] don't work.
>
> I wonder if this just indicates that your approach is wrong,
> and that the tests for the filters in question have to be
> (completely) different.

How can this approach be wrong if it revealed bug?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts

[Muhammad Faiz]

On Sun, Jan 27, 2019 at 7:17 PM Carl Eugen Hoyos  wrote:
>
> 2019-01-27 10:36 GMT+01:00, Muhammad Faiz :
>
> > -bgra64bec8d3217bf58d34f080ac88c0b0012c77
> > +bgra64leb71d75a928aac14cb768403e6f6a9910
> >  bgra64leb71d75a928aac14cb768403e6f6a9910
>
> I believe the output should be changed to make it less
> confusing.

Any attempt to differentiate these two lines makes [4/5] and [5/5] don't work.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] avfilter/vf_super2xsai: fix big-endian writing

[Muhammad Faiz]

On Sun, Jan 27, 2019 at 7:19 PM Carl Eugen Hoyos  wrote:
>
> 2019-01-27 10:36 GMT+01:00, Muhammad Faiz :
> > Fix mismatched checksum on fate-filter-pixfmts-super2xsai.
>
> I believe this patch and 2/5 are unrelated and should be
> committed independently of the patchset.

No. [2/5] and [3/5] depend on [1/5].
[4/5] and [5/5] depend on [1/5] and [2/5].
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/5] avfilter/vf_lut: support native-endian instead of little-endian

[Muhammad Faiz]

Signed-off-by: Muhammad Faiz 
---
Old thread is here: 
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195941.html
Need someone test it on big-endian machine.

 libavfilter/vf_lut.c | 95 
 1 file changed, 42 insertions(+), 53 deletions(-)

diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
index c815ddc194..29bb3172d7 100644
--- a/libavfilter/vf_lut.c
+++ b/libavfilter/vf_lut.c
@@ -116,28 +116,28 @@ static av_cold void uninit(AVFilterContext *ctx)
 AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA444P,   \
 AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P,   \
 AV_PIX_FMT_YUVJ440P, \
-AV_PIX_FMT_YUV444P9LE, AV_PIX_FMT_YUV422P9LE, AV_PIX_FMT_YUV420P9LE, \
-AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUV422P10LE, AV_PIX_FMT_YUV420P10LE, 
AV_PIX_FMT_YUV440P10LE, \
-AV_PIX_FMT_YUV444P12LE, AV_PIX_FMT_YUV422P12LE, AV_PIX_FMT_YUV420P12LE, 
AV_PIX_FMT_YUV440P12LE, \
-AV_PIX_FMT_YUV444P14LE, AV_PIX_FMT_YUV422P14LE, AV_PIX_FMT_YUV420P14LE, \
-AV_PIX_FMT_YUV444P16LE, AV_PIX_FMT_YUV422P16LE, AV_PIX_FMT_YUV420P16LE, \
-AV_PIX_FMT_YUVA444P16LE, AV_PIX_FMT_YUVA422P16LE, AV_PIX_FMT_YUVA420P16LE
+AV_PIX_FMT_YUV444P9, AV_PIX_FMT_YUV422P9, AV_PIX_FMT_YUV420P9, \
+AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV420P10, 
AV_PIX_FMT_YUV440P10, \
+AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV420P12, 
AV_PIX_FMT_YUV440P12, \
+AV_PIX_FMT_YUV444P14, AV_PIX_FMT_YUV422P14, AV_PIX_FMT_YUV420P14, \
+AV_PIX_FMT_YUV444P16, AV_PIX_FMT_YUV422P16, AV_PIX_FMT_YUV420P16, \
+AV_PIX_FMT_YUVA444P16, AV_PIX_FMT_YUVA422P16, AV_PIX_FMT_YUVA420P16
 
 #define RGB_FORMATS \
 AV_PIX_FMT_ARGB, AV_PIX_FMT_RGBA, \
 AV_PIX_FMT_ABGR, AV_PIX_FMT_BGRA, \
 AV_PIX_FMT_RGB24,AV_PIX_FMT_BGR24,\
-AV_PIX_FMT_RGB48LE,  AV_PIX_FMT_RGBA64LE, \
+AV_PIX_FMT_RGB48,  AV_PIX_FMT_RGBA64, \
 AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,\
-AV_PIX_FMT_GBRP9LE,  AV_PIX_FMT_GBRP10LE, \
-AV_PIX_FMT_GBRAP10LE, \
-AV_PIX_FMT_GBRP12LE, AV_PIX_FMT_GBRP14LE, \
-AV_PIX_FMT_GBRP16LE, AV_PIX_FMT_GBRAP12LE,\
-AV_PIX_FMT_GBRAP16LE
+AV_PIX_FMT_GBRP9,  AV_PIX_FMT_GBRP10, \
+AV_PIX_FMT_GBRAP10, \
+AV_PIX_FMT_GBRP12, AV_PIX_FMT_GBRP14, \
+AV_PIX_FMT_GBRP16, AV_PIX_FMT_GBRAP12,\
+AV_PIX_FMT_GBRAP16
 
 #define GRAY_FORMATS\
-AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY9LE, AV_PIX_FMT_GRAY10LE, \
-AV_PIX_FMT_GRAY12LE, AV_PIX_FMT_GRAY14LE, AV_PIX_FMT_GRAY16LE
+AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY9, AV_PIX_FMT_GRAY10, \
+AV_PIX_FMT_GRAY12, AV_PIX_FMT_GRAY14, AV_PIX_FMT_GRAY16
 
 static const enum AVPixelFormat yuv_pix_fmts[] = { YUV_FORMATS, 
AV_PIX_FMT_NONE };
 static const enum AVPixelFormat rgb_pix_fmts[] = { RGB_FORMATS, 
AV_PIX_FMT_NONE };
@@ -237,32 +237,32 @@ static int config_props(AVFilterLink *inlink)
 case AV_PIX_FMT_YUVA420P:
 case AV_PIX_FMT_YUVA422P:
 case AV_PIX_FMT_YUVA444P:
-case AV_PIX_FMT_YUV420P9LE:
-case AV_PIX_FMT_YUV422P9LE:
-case AV_PIX_FMT_YUV444P9LE:
-case AV_PIX_FMT_YUVA420P9LE:
-case AV_PIX_FMT_YUVA422P9LE:
-case AV_PIX_FMT_YUVA444P9LE:
-case AV_PIX_FMT_YUV420P10LE:
-case AV_PIX_FMT_YUV422P10LE:
-case AV_PIX_FMT_YUV440P10LE:
-case AV_PIX_FMT_YUV444P10LE:
-case AV_PIX_FMT_YUVA420P10LE:
-case AV_PIX_FMT_YUVA422P10LE:
-case AV_PIX_FMT_YUVA444P10LE:
-case AV_PIX_FMT_YUV420P12LE:
-case AV_PIX_FMT_YUV422P12LE:
-case AV_PIX_FMT_YUV440P12LE:
-case AV_PIX_FMT_YUV444P12LE:
-case AV_PIX_FMT_YUV420P14LE:
-case AV_PIX_FMT_YUV422P14LE:
-case AV_PIX_FMT_YUV444P14LE:
-case AV_PIX_FMT_YUV420P16LE:
-case AV_PIX_FMT_YUV422P16LE:
-case AV_PIX_FMT_YUV444P16LE:
-case AV_PIX_FMT_YUVA420P16LE:
-case AV_PIX_FMT_YUVA422P16LE:
-case AV_PIX_FMT_YUVA444P16LE:
+case AV_PIX_FMT_YUV420P9:
+case AV_PIX_FMT_YUV422P9:
+case AV_PIX_FMT_YUV444P9:
+case AV_PIX_FMT_YUVA420P9:
+case AV_PIX_FMT_YUVA422P9:
+case AV_PIX_FMT_YUVA444P9:
+case AV_PIX_FMT_YUV420P10:
+case AV_PIX_FMT_YUV422P10:
+case AV_PIX_FMT_YUV440P10:
+case AV_PIX_FMT_YUV444P10:
+case AV_PIX_FMT_YUVA420P10:
+case AV_PIX_FMT_YUVA422P10:
+case AV_PIX_FMT_YUVA444P10:
+case AV_PIX_FMT_YUV420P12:
+case AV_PIX_FMT_YUV422P12:
+case AV_PIX_FMT_YUV440P12:
+case AV_PIX_FMT_YUV444P12:
+case AV_PIX_FMT_YUV420P14:
+case AV_PIX_FMT_YUV422P14:
+case AV_PIX_FMT_YUV444P14:
+case AV_PIX_FMT_YUV420P16:
+case AV_PIX_FMT_YUV422P16:
+case AV_PIX_FMT_YUV444P16:
+case AV_PIX_FMT_YUVA420P16:
+case AV_PIX_FMT_YUVA422P16:
+case AV_PIX_FMT_YUVA444P16:
 min[Y] = 16 * (1

[FFmpeg-devel] [PATCH 2/5] swscale/swscale_unscaled: add missing gbrap10 on ff_get_unscaled_swscale

[Muhammad Faiz]

Fix inconsistent checksums between gbrap10be
and gbrap10le on fate-filter-pixfmts.

Signed-off-by: Muhammad Faiz 
---
 libswscale/swscale_unscaled.c| 3 +++
 tests/ref/fate/filter-pixfmts-copy   | 2 +-
 tests/ref/fate/filter-pixfmts-crop   | 2 +-
 tests/ref/fate/filter-pixfmts-field  | 2 +-
 tests/ref/fate/filter-pixfmts-fieldorder | 2 +-
 tests/ref/fate/filter-pixfmts-hflip  | 2 +-
 tests/ref/fate/filter-pixfmts-il | 2 +-
 tests/ref/fate/filter-pixfmts-null   | 2 +-
 tests/ref/fate/filter-pixfmts-transpose  | 2 +-
 tests/ref/fate/filter-pixfmts-vflip  | 2 +-
 10 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 058f2b94db..9abfae5c04 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -1942,6 +1942,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
  dstFormat == AV_PIX_FMT_GBRP12LE || dstFormat == AV_PIX_FMT_GBRP12BE 
||
  dstFormat == AV_PIX_FMT_GBRP14LE || dstFormat == AV_PIX_FMT_GBRP14BE 
||
  dstFormat == AV_PIX_FMT_GBRP16LE || dstFormat == AV_PIX_FMT_GBRP16BE 
||
+ dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == 
AV_PIX_FMT_GBRAP10LE ||
  dstFormat == AV_PIX_FMT_GBRAP12LE || dstFormat == 
AV_PIX_FMT_GBRAP12BE ||
  dstFormat == AV_PIX_FMT_GBRAP16LE || dstFormat == 
AV_PIX_FMT_GBRAP16BE ))
 c->swscale = Rgb16ToPlanarRgb16Wrapper;
@@ -1951,6 +1952,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
  srcFormat == AV_PIX_FMT_GBRP10LE || srcFormat == AV_PIX_FMT_GBRP10BE 
||
  srcFormat == AV_PIX_FMT_GBRP12LE || srcFormat == AV_PIX_FMT_GBRP12BE 
||
  srcFormat == AV_PIX_FMT_GBRP14LE || srcFormat == AV_PIX_FMT_GBRP14BE 
||
+ dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == 
AV_PIX_FMT_GBRAP10LE ||
  srcFormat == AV_PIX_FMT_GBRAP12LE || srcFormat == 
AV_PIX_FMT_GBRAP12BE ||
  srcFormat == AV_PIX_FMT_GBRAP16LE || srcFormat == 
AV_PIX_FMT_GBRAP16BE) &&
 (dstFormat == AV_PIX_FMT_RGB48LE  || dstFormat == AV_PIX_FMT_RGB48BE  
||
@@ -1997,6 +1999,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP12) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP14) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP16) ||
+IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP10) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP12) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP16) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_RGB444) ||
diff --git a/tests/ref/fate/filter-pixfmts-copy 
b/tests/ref/fate/filter-pixfmts-copy
index bf0977a96a..4694fb7676 100644
--- a/tests/ref/fate/filter-pixfmts-copy
+++ b/tests/ref/fate/filter-pixfmts-copy
@@ -19,7 +19,7 @@ bgra3934fb81a602dfa7d29420b1a66f0fd8
 bgra64leb71d75a928aac14cb768403e6f6a9910
 bgra64leb71d75a928aac14cb768403e6f6a9910
 gbrap   98d30987407c51e5620921e11d40a4ff
-gbrap10le   3a046be0d38289dda5d8fdbd0f34aaf5
+gbrap10le   2a7392e14b21b1f9457526a071236a6d
 gbrap10le   2a7392e14b21b1f9457526a071236a6d
 gbrap12le   5f1d8c663d4c28863e687192433b34a4
 gbrap12le   5f1d8c663d4c28863e687192433b34a4
diff --git a/tests/ref/fate/filter-pixfmts-crop 
b/tests/ref/fate/filter-pixfmts-crop
index 09b7ca9a27..9dd6f097b5 100644
--- a/tests/ref/fate/filter-pixfmts-crop
+++ b/tests/ref/fate/filter-pixfmts-crop
@@ -19,7 +19,7 @@ bgrae66a5f68ba463cbc89fce23a61bb5203
 bgra64ledd29ec9aba43aa3e8f9f5b9a93ca8831
 bgra64ledd29ec9aba43aa3e8f9f5b9a93ca8831
 gbrap   188cd467fe7ae7d85ae9ca8bdfa07739
-gbrap10le   c8505df07f9eeb413f943b5f4d686c0b
+gbrap10le   c2b6e35f8b7ca363a7ec021ccdf31d1f
 gbrap10le   c2b6e35f8b7ca363a7ec021ccdf31d1f
 gbrap12le   3f80453c1ac6c5d1b2febf3ef141b476
 gbrap12le   3f80453c1ac6c5d1b2febf3ef141b476
diff --git a/tests/ref/fate/filter-pixfmts-field 
b/tests/ref/fate/filter-pixfmts-field
index 5779469d41..7dfa0c3299 100644
--- a/tests/ref/fate/filter-pixfmts-field
+++ b/tests/ref/fate/filter-pixfmts-field
@@ -19,7 +19,7 @@ bgra66d6e0846990fff0f09a07c43c3add71
 bgra64le9e2def541e51bc6e77fbffbff7fa146a
 bgra64le9e2def541e51bc6e77fbffbff7fa146a
 gbrap   08a28b79dbd19246d1a94e3466af3624
-gbrap10le   a5cfc53fbd96fcdf83b8b655fe25bf67
+gbrap10le   4017c5d8c124438eb9aefa107db58d3b
 gbrap10le   4017c5d8c124438eb9aefa107db58d3b
 gbrap12le   886207e5aa379a0312485b94e5fd5edd
 gbrap12le   886207e5aa379a0312485b94e5fd5edd
diff --git a/tests/ref/fate/filter-pixfmts-fieldorder 
b/tests/ref/fate/filter-pixfmts-fieldorder
index 216ca3e769..e62768ab3d 100644
--- a/tes

[FFmpeg-devel] [PATCH 5/5] avfilter/drawutils: support native-endian instead of little endian

[Muhammad Faiz]

Signed-off-by: Muhammad Faiz 
---
Old thread is here: 
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195941.html
Need someone test it on big-endian machine.

 libavfilter/drawutils.c | 48 +
 libavfilter/vf_rotate.c | 26 ++--
 libavfilter/vf_tinterlace.c | 30 +++
 3 files changed, 54 insertions(+), 50 deletions(-)

diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
index 5f4cb548f0..12bdfcb900 100644
--- a/libavfilter/drawutils.c
+++ b/libavfilter/drawutils.c
@@ -175,6 +175,17 @@ void ff_copy_rectangle(uint8_t *dst[4], int 
dst_linesize[4],
 }
 }
 
+static int is_native_endian(const AVPixFmtDescriptor *desc)
+{
+int len = strlen(desc->name);
+
+if (!strcmp(desc->name + len - 2, "be"))
+return HAVE_BIGENDIAN;
+if (!strcmp(desc->name + len - 2, "le"))
+return !HAVE_BIGENDIAN;
+return 1;
+}
+
 int ff_draw_init(FFDrawContext *draw, enum AVPixelFormat format, unsigned 
flags)
 {
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(format);
@@ -185,20 +196,20 @@ int ff_draw_init(FFDrawContext *draw, enum AVPixelFormat 
format, unsigned flags)
 
 if (!desc || !desc->name)
 return AVERROR(EINVAL);
-if (desc->flags & ~(AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_RGB | 
FF_PSEUDOPAL | AV_PIX_FMT_FLAG_ALPHA))
+if (desc->flags & ~(AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_RGB | 
FF_PSEUDOPAL | AV_PIX_FMT_FLAG_ALPHA | AV_PIX_FMT_FLAG_BE))
 return AVERROR(ENOSYS);
 if (format == AV_PIX_FMT_P010LE || format == AV_PIX_FMT_P010BE || format 
== AV_PIX_FMT_P016LE || format == AV_PIX_FMT_P016BE)
 return AVERROR(ENOSYS);
 if (format == AV_PIX_FMT_YUVJ420P || format == AV_PIX_FMT_YUVJ422P || 
format == AV_PIX_FMT_YUVJ444P ||
 format == AV_PIX_FMT_YUVJ411P || format == AV_PIX_FMT_YUVJ440P)
 full_range = 1;
+if (!is_native_endian(desc))
+return AVERROR(ENOSYS);
 for (i = 0; i < desc->nb_components; i++) {
 c = >comp[i];
 /* for now, only 8-16 bits formats */
 if (c->depth < 8 || c->depth > 16)
 return AVERROR(ENOSYS);
-if (desc->flags & AV_PIX_FMT_FLAG_BE)
-return AVERROR(ENOSYS);
 if (c->plane >= MAX_PLANES)
 return AVERROR(ENOSYS);
 /* strange interleaving */
@@ -268,11 +279,11 @@ void ff_draw_color(FFDrawContext *draw, FFDrawColor 
*color, const uint8_t rgba[4
 EXPAND(1);
 EXPAND(0);
 } else if (draw->format == AV_PIX_FMT_GRAY8 || draw->format == 
AV_PIX_FMT_GRAY8A ||
-   draw->format == AV_PIX_FMT_GRAY16LE || draw->format == 
AV_PIX_FMT_YA16LE ||
-   draw->format == AV_PIX_FMT_GRAY9LE  ||
-   draw->format == AV_PIX_FMT_GRAY10LE ||
-   draw->format == AV_PIX_FMT_GRAY12LE ||
-   draw->format == AV_PIX_FMT_GRAY14LE) {
+   draw->format == AV_PIX_FMT_GRAY16 || draw->format == 
AV_PIX_FMT_YA16 ||
+   draw->format == AV_PIX_FMT_GRAY9  ||
+   draw->format == AV_PIX_FMT_GRAY10 ||
+   draw->format == AV_PIX_FMT_GRAY12 ||
+   draw->format == AV_PIX_FMT_GRAY14) {
 const AVPixFmtDescriptor *desc = draw->desc;
 color->comp[0].u8[0] = RGB_TO_Y_CCIR(rgba[0], rgba[1], rgba[2]);
 EXPAND(0);
@@ -331,11 +342,6 @@ void ff_fill_rectangle(FFDrawContext *draw, FFDrawColor 
*color,
 return;
 p = p0;
 
-if (HAVE_BIGENDIAN && draw->desc->comp[0].depth > 8) {
-for (x = 0; 2*x < draw->pixelstep[plane]; x++)
-color_tmp.comp[plane].u16[x] = 
av_bswap16(color_tmp.comp[plane].u16[x]);
-}
-
 /* copy first line from color */
 for (x = 0; x < wp; x++) {
 memcpy(p, color_tmp.comp[plane].u8, draw->pixelstep[plane]);
@@ -426,19 +432,19 @@ static void blend_line16(uint8_t *dst, unsigned src, 
unsigned alpha,
 
 if (left) {
 unsigned suba = (left * alpha) >> hsub;
-uint16_t value = AV_RL16(dst);
-AV_WL16(dst, (value * (0x10001 - suba) + src * suba) >> 16);
+uint16_t value = AV_RN16A(dst);
+AV_WN16A(dst, (value * (0x10001 - suba) + src * suba) >> 16);
 dst += dx;
 }
 for (x = 0; x < w; x++) {
-uint16_t value = AV_RL16(dst);
-AV_WL16(dst, (value * tau + asrc) >> 16);
+uint16_t value = AV_RN16A(dst);
+AV_WN16A(dst, (value * tau + asrc) >> 16);
 dst += dx;
 }
 if (right) {
 unsigned suba = (right * alpha) >> hsub;
-uint16_t value = AV_RL16(dst);
-AV_WL16(dst, (value * (0x10001 - suba) + src * suba) >> 16);
+uint16_t value = AV_RN16A(dst);
+AV_WN16A(dst, (value * (0x10001 - suba) + src 

[FFmpeg-devel] [PATCH 3/5] avfilter/vf_super2xsai: fix big-endian writing

[Muhammad Faiz]

Fix mismatched checksum on fate-filter-pixfmts-super2xsai.

Signed-off-by: Muhammad Faiz 
---
 libavfilter/vf_super2xsai.c  | 4 ++--
 tests/ref/fate/filter-pixfmts-super2xsai | 8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavfilter/vf_super2xsai.c b/libavfilter/vf_super2xsai.c
index 87eec04da8..4901e03e23 100644
--- a/libavfilter/vf_super2xsai.c
+++ b/libavfilter/vf_super2xsai.c
@@ -180,8 +180,8 @@ static void super2xsai(AVFilterContext *ctx,
 break;
 default: // bpp = 2
 if (s->is_be) {
-AV_WB32(dst_line[0] + x * 4, product1a | (product1b << 
16));
-AV_WB32(dst_line[1] + x * 4, product2a | (product2b << 
16));
+AV_WB32(dst_line[0] + x * 4, (product1a << 16) | 
product1b);
+AV_WB32(dst_line[1] + x * 4, (product2a << 16) | 
product2b);
 } else {
 AV_WL32(dst_line[0] + x * 4, product1a | (product1b << 
16));
 AV_WL32(dst_line[1] + x * 4, product2a | (product2b << 
16));
diff --git a/tests/ref/fate/filter-pixfmts-super2xsai 
b/tests/ref/fate/filter-pixfmts-super2xsai
index d42601dab1..c76d469880 100644
--- a/tests/ref/fate/filter-pixfmts-super2xsai
+++ b/tests/ref/fate/filter-pixfmts-super2xsai
@@ -1,14 +1,14 @@
 abgre21be14b5fe9d7a29740a418c325b17e
 argb563489534663cb2b32beed2b41370c37
 bgr24   a933eac9bb53c3ce3c33950b229996b5
-bgr555led69e39a24027afcb28feaabb46f0948d
 bgr555le70b819425f79f823356229b90b41cc84
-bgr565le78f3b43ddcc1f8558444c97d249a6123
+bgr555le70b819425f79f823356229b90b41cc84
+bgr565le6fb9dc50a81b853800ba65d5ec6b8417
 bgr565le6fb9dc50a81b853800ba65d5ec6b8417
 bgrae9cc6644e2f35103c241094ab4bb8fec
 rgb24   3fd7653f414f350ddb0c0a236ce0c809
-rgb555lef2f9f30e8be582729f12a03331e3c635
 rgb555le53325a20c913826566880eb25d1d2946
-rgb565le340ffed3645809f68346280764ca3de6
+rgb555le53325a20c913826566880eb25d1d2946
+rgb565le14fe550f449a7539d9f1e99e85cf40f1
 rgb565le14fe550f449a7539d9f1e99e85cf40f1
 rgba7041184d35c316e73e849504b64bc4f6
-- 
2.17.2

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

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[Muhammad Faiz]

On Tue, Feb 20, 2018 at 2:30 AM, Michael Niedermayer
 wrote:
> On Sun, Feb 18, 2018 at 05:58:16PM +, Josh de Kock wrote:
>> This should be the last of the major API changes. I'm not entirely
>> sure if I missed anything.
>
> Moving from a register based system where a user app can register
> any subset to a system which registers all via an array will
> increase the size of statically linked binaries for users only
> using a subset.
>
> An example of this effect for codecs is tools/target_dec_fuzzer.c

Just an idea.
Is it possible to generate just one executable to fuzz all decoders?
The target decoder can be added as an argument or environment variable.
e.g: ./fuzzer --target aac
or FUZZER_TARGET=aac ./fuzzer

With this approach, we can save lot of disk space.


>
> This effect results because when the linker collects all objects
> of all static libs with a user application it can remove all symbols
> which are not referenced.
> If there is a single array that references all codecs, filters, formats
> and this array is referenced by a function which must be used then
> nothing can be removed at the link stage
>
> OTOH with a register function a register all which refernces all
> a user application can simply not use the reference all code and register
> the specific subset it needs with individual register calls.
> In this case the linker can ommit the register all and all codecs, formats
> and filters teh user application does not explicitly refer too.
> In the case where this applies this results in significantly smaller files
>
> I also expect they link faster and load faster but i forgot to benchmark this
> when i realized this issue exists and tested ...
>
> I am thus in favor of a system that does not unconditionally reference every
> codec/format/filter
>
> There can also be an advantage security wise if unneeded parts are never
> "registered"
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many things microsoft did are stupid, but not doing something just because
> microsoft did it is even more stupid. If everything ms did were stupid they
> would be bankrupt already.
>
> ___
> 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]lavf/rtpdec*: Constify all RTPDynamicProtocolHandler

[Muhammad Faiz]

On Tue, Feb 13, 2018 at 4:22 AM, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch marks the RTPDynamicProtocolHandler as const.
>
> Please comment, Carl Eugen
>
> From e219322aa7396db6ecb6ab02fd5b42b42271f27f Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Mon, 12 Feb 2018 22:21:06 +0100
> Subject: [PATCH] lavf/rtpdec*: Constify all RTPDynamicProtocolHandler.


> +const extern RTPDynamicProtocolHandler ff_theora_dynamic_handler;
> +const extern RTPDynamicProtocolHandler ff_vc2hq_dynamic_handler;
> +const extern RTPDynamicProtocolHandler ff_vorbis_dynamic_handler;
> +const extern RTPDynamicProtocolHandler ff_vp8_dynamic_handler;
> +const extern RTPDynamicProtocolHandler ff_vp9_dynamic_handler;

Cosmetics: probably extern const?

Rest LGTM.

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

Re: [FFmpeg-devel] [PATCH] avcodec: remove av_codec_init_static()

[Muhammad Faiz]

On Tue, Feb 13, 2018 at 3:57 AM, wm4 <nfx...@googlemail.com> wrote:
> On Mon, 12 Feb 2018 12:42:10 +0700
> Muhammad Faiz <mfc...@gmail.com> wrote:
>
>> Modify the behavior of init_static_data().
>>
>> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>> ---
>
> Seems OK, but I'm also not sure about the benefit. The fundamental
> problem that these codecs need to mutate AVCodec before the users sees
> it won't go away.

Actually, I'm too. Any idea how to remove init_static_data()?

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

Re: [FFmpeg-devel] [PATCH] avcodec: remove av_codec_init_static()

[Muhammad Faiz]

On Tue, Feb 13, 2018 at 2:40 AM, James Almer <jamr...@gmail.com> wrote:
> On 2/12/2018 2:42 AM, Muhammad Faiz wrote:
>> Modify the behavior of init_static_data().
>>
>> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>> ---
>>  libavcodec/allcodecs.c | 16 
>>  libavcodec/avcodec.h   |  4 +++-
>>  libavcodec/libvpxdec.c | 15 ++-
>>  libavcodec/libvpxenc.c | 15 ++-
>>  libavcodec/libx264.c   | 11 ++-
>>  libavcodec/libx265.c   | 11 ++-
>>  6 files changed, 55 insertions(+), 17 deletions(-)
>>
>> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
>> index 774b78ef09..02910b5594 100644
>> --- a/libavcodec/allcodecs.c
>> +++ b/libavcodec/allcodecs.c
>> @@ -757,24 +757,16 @@ extern AVCodec ff_vp9_vaapi_encoder;
>>
>>  #include "libavcodec/codec_list.c"
>>
>> -static AVOnce av_codec_static_init = AV_ONCE_INIT;
>> -static void av_codec_init_static(void)
>> -{
>> -for (int i = 0; codec_list[i]; i++) {
>> -if (codec_list[i]->init_static_data)
>> -codec_list[i]->init_static_data((AVCodec*)codec_list[i]);
>> -}
>> -}
>> -
>>  const AVCodec *av_codec_iterate(void **opaque)
>>  {
>>  uintptr_t i = (uintptr_t)*opaque;
>>  const AVCodec *c = codec_list[i];
>>
>> -ff_thread_once(_codec_static_init, av_codec_init_static);
>> -
>> -if (c)
>> +if (c) {
>> +if (c->init_static_data)
>> +c->init_static_data();
>>  *opaque = (void*)(i + 1);
>> +}
>>
>>  return c;
>>  }
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index ad0b48a839..d89bf300fc 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -3443,8 +3443,10 @@ typedef struct AVCodec {
>>   *
>>   * This is not intended for time consuming operations as it is
>>   * run for every codec regardless of that codec being used.
>> + * This may be called multiple times from different threads, the callee
>> + * has responsibility for thread synchronization.
>>   */
>> -void (*init_static_data)(struct AVCodec *codec);
>> +void (*init_static_data)(void);
>
> What's the benefit of removing the parameter?

It is unused because the callee should use ff_thread_once.


>
>>
>>  int (*init)(AVCodecContext *);
>>  int (*encode_sub)(AVCodecContext *, uint8_t *buf, int buf_size,
>> diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
>> index 04f27d3396..f2003b836b 100644
>> --- a/libavcodec/libvpxdec.c
>> +++ b/libavcodec/libvpxdec.c
>> @@ -30,6 +30,7 @@
>>  #include "libavutil/common.h"
>>  #include "libavutil/imgutils.h"
>>  #include "libavutil/intreadwrite.h"
>> +#include "libavutil/thread.h"
>>  #include "avcodec.h"
>>  #include "internal.h"
>>  #include "libvpx.h"
>> @@ -299,6 +300,18 @@ static av_cold int vp9_init(AVCodecContext *avctx)
>>  return vpx_init(avctx, _codec_vp9_dx_algo, 0);
>>  }
>>
>> +static av_cold void vp9_init_static_once(void)
>> +{
>> +extern AVCodec ff_libvpx_vp9_decoder;
>> +ff_vp9_init_static(_libvpx_vp9_decoder);
>> +}
>> +
>> +static av_cold void vp9_init_static(void)
>> +{
>> +static AVOnce once = AV_ONCE_INIT;
>> +ff_thread_once(, vp9_init_static_once);
>> +}
>> +
>>  AVCodec ff_libvpx_vp9_decoder = {
>>  .name   = "libvpx-vp9",
>>  .long_name  = NULL_IF_CONFIG_SMALL("libvpx VP9"),
>> @@ -309,7 +322,7 @@ AVCodec ff_libvpx_vp9_decoder = {
>>  .close  = vpx_free,
>>  .decode = vpx_decode,
>>  .capabilities   = AV_CODEC_CAP_AUTO_THREADS | AV_CODEC_CAP_DR1,
>> -.init_static_data = ff_vp9_init_static,
>> +.init_static_data = vp9_init_static,
>
> I think you can remove the init_static_data call to ff_vp9_init_static
> from the decoder altogether. It just sets AVCodec.pix_fmts, which afaics
> is only needed for the encoder.
>
> Doing it would also let us get rid of libvpx.c, as everything there can
> then be moved into libvpxenc.c

It should be in separate patch.


>
>>  .profiles   = NULL_IF_CONFIG_SMALL(ff_vp9_profiles),
>>  .wrapper_name   = "libvpx",
>>  };
>> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
>> index d0bd1e997a..086dd5defa 100644
>

[FFmpeg-devel] [PATCH] avcodec: remove av_codec_init_static()

[Muhammad Faiz]

Modify the behavior of init_static_data().

Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
---
 libavcodec/allcodecs.c | 16 
 libavcodec/avcodec.h   |  4 +++-
 libavcodec/libvpxdec.c | 15 ++-
 libavcodec/libvpxenc.c | 15 ++-
 libavcodec/libx264.c   | 11 ++-
 libavcodec/libx265.c   | 11 ++-
 6 files changed, 55 insertions(+), 17 deletions(-)

diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 774b78ef09..02910b5594 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -757,24 +757,16 @@ extern AVCodec ff_vp9_vaapi_encoder;
 
 #include "libavcodec/codec_list.c"
 
-static AVOnce av_codec_static_init = AV_ONCE_INIT;
-static void av_codec_init_static(void)
-{
-for (int i = 0; codec_list[i]; i++) {
-if (codec_list[i]->init_static_data)
-codec_list[i]->init_static_data((AVCodec*)codec_list[i]);
-}
-}
-
 const AVCodec *av_codec_iterate(void **opaque)
 {
 uintptr_t i = (uintptr_t)*opaque;
 const AVCodec *c = codec_list[i];
 
-ff_thread_once(_codec_static_init, av_codec_init_static);
-
-if (c)
+if (c) {
+if (c->init_static_data)
+c->init_static_data();
 *opaque = (void*)(i + 1);
+}
 
 return c;
 }
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index ad0b48a839..d89bf300fc 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3443,8 +3443,10 @@ typedef struct AVCodec {
  *
  * This is not intended for time consuming operations as it is
  * run for every codec regardless of that codec being used.
+ * This may be called multiple times from different threads, the callee
+ * has responsibility for thread synchronization.
  */
-void (*init_static_data)(struct AVCodec *codec);
+void (*init_static_data)(void);
 
 int (*init)(AVCodecContext *);
 int (*encode_sub)(AVCodecContext *, uint8_t *buf, int buf_size,
diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
index 04f27d3396..f2003b836b 100644
--- a/libavcodec/libvpxdec.c
+++ b/libavcodec/libvpxdec.c
@@ -30,6 +30,7 @@
 #include "libavutil/common.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/intreadwrite.h"
+#include "libavutil/thread.h"
 #include "avcodec.h"
 #include "internal.h"
 #include "libvpx.h"
@@ -299,6 +300,18 @@ static av_cold int vp9_init(AVCodecContext *avctx)
 return vpx_init(avctx, _codec_vp9_dx_algo, 0);
 }
 
+static av_cold void vp9_init_static_once(void)
+{
+extern AVCodec ff_libvpx_vp9_decoder;
+ff_vp9_init_static(_libvpx_vp9_decoder);
+}
+
+static av_cold void vp9_init_static(void)
+{
+static AVOnce once = AV_ONCE_INIT;
+ff_thread_once(, vp9_init_static_once);
+}
+
 AVCodec ff_libvpx_vp9_decoder = {
 .name   = "libvpx-vp9",
 .long_name  = NULL_IF_CONFIG_SMALL("libvpx VP9"),
@@ -309,7 +322,7 @@ AVCodec ff_libvpx_vp9_decoder = {
 .close  = vpx_free,
 .decode = vpx_decode,
 .capabilities   = AV_CODEC_CAP_AUTO_THREADS | AV_CODEC_CAP_DR1,
-.init_static_data = ff_vp9_init_static,
+.init_static_data = vp9_init_static,
 .profiles   = NULL_IF_CONFIG_SMALL(ff_vp9_profiles),
 .wrapper_name   = "libvpx",
 };
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index d0bd1e997a..086dd5defa 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -39,6 +39,7 @@
 #include "libavutil/intreadwrite.h"
 #include "libavutil/mathematics.h"
 #include "libavutil/opt.h"
+#include "libavutil/thread.h"
 
 /**
  * Portion of struct vpx_codec_cx_pkt from vpx_encoder.h.
@@ -1209,6 +1210,18 @@ static av_cold int vp9_init(AVCodecContext *avctx)
 return vpx_init(avctx, vpx_codec_vp9_cx());
 }
 
+static av_cold void vp9_init_static_once(void)
+{
+extern AVCodec ff_libvpx_vp9_encoder;
+ff_vp9_init_static(_libvpx_vp9_encoder);
+}
+
+static av_cold void vp9_init_static(void)
+{
+static AVOnce once = AV_ONCE_INIT;
+ff_thread_once(, vp9_init_static_once);
+}
+
 static const AVClass class_vp9 = {
 .class_name = "libvpx-vp9 encoder",
 .item_name  = av_default_item_name,
@@ -1229,7 +1242,7 @@ AVCodec ff_libvpx_vp9_encoder = {
 .profiles   = NULL_IF_CONFIG_SMALL(ff_vp9_profiles),
 .priv_class = _vp9,
 .defaults   = defaults,
-.init_static_data = ff_vp9_init_static,
+.init_static_data = vp9_init_static,
 .wrapper_name   = "libvpx",
 };
 #endif /* CONFIG_LIBVPX_VP9_ENCODER */
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 12379ff763..0da61a0fcd 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -26,6 +26,7 @@
 #include "libavutil/pixdesc.h"
 #include "libavutil/stereo3d.h"
 #include "libavutil/intreadwrite.h"
+#include "libavutil

Re: [FFmpeg-devel] [PATCH] fate/libavcodec: add codec_desc test

[Muhammad Faiz]

On Sun, Feb 11, 2018 at 6:43 AM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Sat, Feb 10, 2018 at 04:37:00PM +0700, Muhammad Faiz wrote:
>> Remove runtime check at codec_desc.c
>>
>> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>> ---
>>  libavcodec/Makefile   |  1 +
>>  libavcodec/codec_desc.c   | 24 ---
>>  libavcodec/tests/codec_desc.c | 45 
>> +++
>>  tests/fate/libavcodec.mak |  5 +
>>  4 files changed, 51 insertions(+), 24 deletions(-)
>>  create mode 100644 libavcodec/tests/codec_desc.c
>
> LGTM

Applied.

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

Re: [FFmpeg-devel] [PATCH]lavf/rtpdec: Constify several pointers

[Muhammad Faiz]

On Mon, Feb 12, 2018 at 2:05 AM, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> 2018-02-11 0:32 GMT+01:00 Muhammad Faiz <mfc...@gmail.com>:
>> On Sat, Feb 10, 2018 at 8:57 AM, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
>>> Hi!
>>>
>>> Attached patch fixes two warnings.
>>> libavformat/rtpdec.c: In function ‘ff_rtp_handler_find_by_name’:
>>> libavformat/rtpdec.c:155:20: warning: return discards ‘const’
>>> qualifier from pointer target type [-Wdiscarded-qualifiers]
>>>  return handler;
>>> ^~~
>>> libavformat/rtpdec.c: In function ‘ff_rtp_handler_find_by_id’:
>>> libavformat/rtpdec.c:168:20: warning: return discards ‘const’
>>> qualifier from pointer target type [-Wdiscarded-qualifiers]
>>>  return handler;
>>> ^~~
>>>
>>> Please comment, Carl Eugen
>>>
>>> From b0383afe16c62fcb0fbc7ea49168edd2f26ac0aa Mon Sep 17 00:00:00 2001
>>> From: Carl Eugen Hoyos <ceffm...@gmail.com>
>>> Date: Sat, 10 Feb 2018 02:54:42 +0100
>>> Subject: [PATCH] lavf/rtpdec: Constify several pointers.
>>>
>>> Fixes two warnings:
>>> libavformat/rtpdec.c:155:20: warning: return discards 'const' qualifier 
>>> from pointer target type [-Wdiscarded-qualifiers]
>>> libavformat/rtpdec.c:168:20: warning: return discards 'const' qualifier 
>>> from pointer target type [-Wdiscarded-qualifiers]
>>> ---
>>>  libavformat/rdt.c|2 +-
>>>  libavformat/rdt.h|2 +-
>>>  libavformat/rtpdec.c |6 +++---
>>>  libavformat/rtpdec.h |6 +++---
>>>  libavformat/rtsp.c   |8 
>>>  libavformat/rtsp.h   |2 +-
>>>  6 files changed, 13 insertions(+), 13 deletions(-)
>>
>> LGTM.
>
> Patch applied.
>
>> Probably, the variables should also be constified.
>
> Not sure which variables you mean.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: add new API for iterating codecs and codec parsers

[Muhammad Faiz]

On Sun, Feb 11, 2018 at 6:37 AM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Sat, Feb 10, 2018 at 05:13:10PM +0700, Muhammad Faiz wrote:
>> On Sat, Feb 10, 2018 at 7:51 AM, Michael Niedermayer
>> <mich...@niedermayer.cc> wrote:
>> > On Fri, Feb 09, 2018 at 10:21:04PM +0700, Muhammad Faiz wrote:
>> >> On Fri, Feb 9, 2018 at 6:53 PM, James Almer <jamr...@gmail.com> wrote:
>> >> > On 2/9/2018 7:56 AM, Muhammad Faiz wrote:
>> >> >> On Thu, Feb 8, 2018 at 7:04 AM, Michael Niedermayer
>> >> >> <mich...@niedermayer.cc> wrote:
>> >> >>> On Wed, Feb 07, 2018 at 01:52:33PM +0100, Nicolas George wrote:
>> >> >>>> Josh de Kock (2018-02-06):
>> >> >>>>> ffmpeg | branch: master | Josh de Kock <j...@itanimul.li> | Fri Dec 
>> >> >>>>> 22 22:17:00 2017 +| [7e8eba2d8755962d9dca5eade57bf8f591a73c0c] 
>> >> >>>>> | committer: Josh de Kock
>> >> >>>>>
>> >> >>>>> lavc: add new API for iterating codecs and codec parsers
>> >> >>>>>
>> >> >>>>> Based on an unfinished patch by atomnuker.
>> >> >>>
>> >> >>> This commit also breaks
>> >> >>>
>> >> >>> ./configure --enable-libsoxr && make -j12 fate-checkasm
>> >> >>>  make -j12 fate-checkasm
>> >> >>>  ...
>> >> >>> LD  tests/checkasm/checkasm
>> >> >>> libswresample/libswresample.a(soxr_resample.o): In function 
>> >> >>> `get_out_samples':
>> >> >>> ffmpeg/libswresample/soxr_resample.c:118: undefined reference to 
>> >> >>> `soxr_delay'
>> >> >>> libswresample/libswresample.a(soxr_resample.o): In function 
>> >> >>> `get_delay':
>> >> >>> ffmpeg/libswresample/soxr_resample.c:100: undefined reference to 
>> >> >>> `soxr_delay'
>> >> >>> libswresample/libswresample.a(soxr_resample.o): In function `flush':
>> >> >>> ffmpeg/libswresample/soxr_resample.c:70: undefined reference to 
>> >> >>> `soxr_delay'
>> >> >>> ffmpeg/libswresample/soxr_resample.c:72: undefined reference to 
>> >> >>> `soxr_process'
>> >> >>> ffmpeg/libswresample/soxr_resample.c:77: undefined reference to 
>> >> >>> `soxr_process'
>> >> >>> ffmpeg/libswresample/soxr_resample.c:78: undefined reference to 
>> >> >>> `soxr_delay'
>> >> >>> libswresample/libswresample.a(soxr_resample.o): In function `process':
>> >> >>> ffmpeg/libswresample/soxr_resample.c:88: undefined reference to 
>> >> >>> `soxr_set_num_channels'
>> >> >>> ffmpeg/libswresample/soxr_resample.c:88: undefined reference to 
>> >> >>> `soxr_set_error'
>> >> >>> ffmpeg/libswresample/soxr_resample.c:90: undefined reference to 
>> >> >>> `soxr_process'
>> >> >>> libswresample/libswresample.a(soxr_resample.o): In function `destroy':
>> >> >>> ffmpeg/libswresample/soxr_resample.c:65: undefined reference to 
>> >> >>> `soxr_delete'
>> >> >>> libswresample/libswresample.a(soxr_resample.o): In function `create':
>> >> >>> ffmpeg/libswresample/soxr_resample.c:46: undefined reference to 
>> >> >>> `soxr_io_spec'
>> >> >>> ffmpeg/libswresample/soxr_resample.c:48: undefined reference to 
>> >> >>> `soxr_quality_spec'
>> >> >>> ffmpeg/libswresample/soxr_resample.c:56: undefined reference to 
>> >> >>> `soxr_delete'
>> >> >>> ffmpeg/libswresample/soxr_resample.c:57: undefined reference to 
>> >> >>> `soxr_create'
>> >> >>> collect2: error: ld returned 1 exit status
>> >> >>> make: *** [tests/checkasm/checkasm] Error 1
>> >> >>
>> >> >> Fixed in 81d6501be77b273053a66eeced94d78e2021f1d1
>> >> >>
>> >> >> Thank's.
>> >> >
>> >> > This is not a proper solution. swr is pulled by avcodec only if Opus
>> >> > decoder is enabled. There's no reason to hardcode it for checkasm 
>> >> > otherwise.
>> >> > The problem here i

Re: [FFmpeg-devel] [PATCH]lavf/rtpdec: Constify several pointers

[Muhammad Faiz]

On Sat, Feb 10, 2018 at 8:57 AM, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes two warnings.
> libavformat/rtpdec.c: In function ‘ff_rtp_handler_find_by_name’:
> libavformat/rtpdec.c:155:20: warning: return discards ‘const’
> qualifier from pointer target type [-Wdiscarded-qualifiers]
>  return handler;
> ^~~
> libavformat/rtpdec.c: In function ‘ff_rtp_handler_find_by_id’:
> libavformat/rtpdec.c:168:20: warning: return discards ‘const’
> qualifier from pointer target type [-Wdiscarded-qualifiers]
>  return handler;
> ^~~
>
> Please comment, Carl Eugen
>
> From b0383afe16c62fcb0fbc7ea49168edd2f26ac0aa Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sat, 10 Feb 2018 02:54:42 +0100
> Subject: [PATCH] lavf/rtpdec: Constify several pointers.
>
> Fixes two warnings:
> libavformat/rtpdec.c:155:20: warning: return discards 'const' qualifier from 
> pointer target type [-Wdiscarded-qualifiers]
> libavformat/rtpdec.c:168:20: warning: return discards 'const' qualifier from 
> pointer target type [-Wdiscarded-qualifiers]
> ---
>  libavformat/rdt.c|2 +-
>  libavformat/rdt.h|2 +-
>  libavformat/rtpdec.c |6 +++---
>  libavformat/rtpdec.h |6 +++---
>  libavformat/rtsp.c   |8 
>  libavformat/rtsp.h   |2 +-
>  6 files changed, 13 insertions(+), 13 deletions(-)

LGTM. Probably, the variables should also be constified.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: add new API for iterating codecs and codec parsers

[Muhammad Faiz]

On Sat, Feb 10, 2018 at 7:51 AM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Fri, Feb 09, 2018 at 10:21:04PM +0700, Muhammad Faiz wrote:
>> On Fri, Feb 9, 2018 at 6:53 PM, James Almer <jamr...@gmail.com> wrote:
>> > On 2/9/2018 7:56 AM, Muhammad Faiz wrote:
>> >> On Thu, Feb 8, 2018 at 7:04 AM, Michael Niedermayer
>> >> <mich...@niedermayer.cc> wrote:
>> >>> On Wed, Feb 07, 2018 at 01:52:33PM +0100, Nicolas George wrote:
>> >>>> Josh de Kock (2018-02-06):
>> >>>>> ffmpeg | branch: master | Josh de Kock <j...@itanimul.li> | Fri Dec 22 
>> >>>>> 22:17:00 2017 +| [7e8eba2d8755962d9dca5eade57bf8f591a73c0c] | 
>> >>>>> committer: Josh de Kock
>> >>>>>
>> >>>>> lavc: add new API for iterating codecs and codec parsers
>> >>>>>
>> >>>>> Based on an unfinished patch by atomnuker.
>> >>>
>> >>> This commit also breaks
>> >>>
>> >>> ./configure --enable-libsoxr && make -j12 fate-checkasm
>> >>>  make -j12 fate-checkasm
>> >>>  ...
>> >>> LD  tests/checkasm/checkasm
>> >>> libswresample/libswresample.a(soxr_resample.o): In function 
>> >>> `get_out_samples':
>> >>> ffmpeg/libswresample/soxr_resample.c:118: undefined reference to 
>> >>> `soxr_delay'
>> >>> libswresample/libswresample.a(soxr_resample.o): In function `get_delay':
>> >>> ffmpeg/libswresample/soxr_resample.c:100: undefined reference to 
>> >>> `soxr_delay'
>> >>> libswresample/libswresample.a(soxr_resample.o): In function `flush':
>> >>> ffmpeg/libswresample/soxr_resample.c:70: undefined reference to 
>> >>> `soxr_delay'
>> >>> ffmpeg/libswresample/soxr_resample.c:72: undefined reference to 
>> >>> `soxr_process'
>> >>> ffmpeg/libswresample/soxr_resample.c:77: undefined reference to 
>> >>> `soxr_process'
>> >>> ffmpeg/libswresample/soxr_resample.c:78: undefined reference to 
>> >>> `soxr_delay'
>> >>> libswresample/libswresample.a(soxr_resample.o): In function `process':
>> >>> ffmpeg/libswresample/soxr_resample.c:88: undefined reference to 
>> >>> `soxr_set_num_channels'
>> >>> ffmpeg/libswresample/soxr_resample.c:88: undefined reference to 
>> >>> `soxr_set_error'
>> >>> ffmpeg/libswresample/soxr_resample.c:90: undefined reference to 
>> >>> `soxr_process'
>> >>> libswresample/libswresample.a(soxr_resample.o): In function `destroy':
>> >>> ffmpeg/libswresample/soxr_resample.c:65: undefined reference to 
>> >>> `soxr_delete'
>> >>> libswresample/libswresample.a(soxr_resample.o): In function `create':
>> >>> ffmpeg/libswresample/soxr_resample.c:46: undefined reference to 
>> >>> `soxr_io_spec'
>> >>> ffmpeg/libswresample/soxr_resample.c:48: undefined reference to 
>> >>> `soxr_quality_spec'
>> >>> ffmpeg/libswresample/soxr_resample.c:56: undefined reference to 
>> >>> `soxr_delete'
>> >>> ffmpeg/libswresample/soxr_resample.c:57: undefined reference to 
>> >>> `soxr_create'
>> >>> collect2: error: ld returned 1 exit status
>> >>> make: *** [tests/checkasm/checkasm] Error 1
>> >>
>> >> Fixed in 81d6501be77b273053a66eeced94d78e2021f1d1
>> >>
>> >> Thank's.
>> >
>> > This is not a proper solution. swr is pulled by avcodec only if Opus
>> > decoder is enabled. There's no reason to hardcode it for checkasm 
>> > otherwise.
>> > The problem here is that the Makefile should pull all the dependencies
>> > of its hardcoded dependencies. This is what FFLIBS and FFEXTRALIBS do in
>> > common.mak to link the actual libraries.
>>
>> Probably, this is not a proper solution, but it is trivial enough.
>> (I'm sorry that I pushed it without posting).
>> So, please fix it with the proper solution. Probably, by adding
>> swresample-extralibs to avcodec-extralibs when avcodec has dependency
>> to swresample. I don't know how to do it.
>>
>
>> >
>> > That said, was this really a regression generated by this commit? It
>> > looks unrelated.
>>
>> Actually, it was a bug even before this commit. Just, previously it
>> was hidden because linker was smart enough 

[FFmpeg-devel] [PATCH] fate/libavcodec: add codec_desc test

[Muhammad Faiz]

Remove runtime check at codec_desc.c

Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
---
 libavcodec/Makefile   |  1 +
 libavcodec/codec_desc.c   | 24 ---
 libavcodec/tests/codec_desc.c | 45 +++
 tests/fate/libavcodec.mak |  5 +
 4 files changed, 51 insertions(+), 24 deletions(-)
 create mode 100644 libavcodec/tests/codec_desc.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index beaca9ee51..3d4b738e0b 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1090,6 +1090,7 @@ SKIPHEADERS-$(CONFIG_V4L2_M2M) += v4l2_buffers.h 
v4l2_context.h v4l2_m2m
 
 TESTPROGS = avpacket\
 celp_math   \
+codec_desc  \
 htmlsubtitles   \
 imgconvert  \
 jpeg2000dwt \
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 15f6489278..44a54a31c9 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -21,10 +21,8 @@
 
 #include 
 
-#include "libavutil/avassert.h"
 #include "libavutil/common.h"
 #include "libavutil/internal.h"
-#include "libavutil/thread.h"
 #include "avcodec.h"
 #include "profiles.h"
 #include "version.h"
@@ -3111,26 +3109,6 @@ static const AVCodecDescriptor codec_descriptors[] = {
 },
 };
 
-#if defined(ASSERT_LEVEL) && ASSERT_LEVEL >= 2
-static void check_validity(void)
-{
-int i;
-
-for (i = 0; i < FF_ARRAY_ELEMS(codec_descriptors) - 1; i++) {
-if (codec_descriptors[i].id >= codec_descriptors[i+1].id) {
-av_log(NULL, AV_LOG_FATAL, "unsorted codec_id '%s' and '%s'.\n",
-   codec_descriptors[i].name, codec_descriptors[i+1].name);
-av_assert0(0);
-}
-}
-}
-
-static AVOnce check_validity_once = AV_ONCE_INIT;
-#define CHECK_VALIDITY() ff_thread_once(_validity_once, check_validity);
-#else
-#define CHECK_VALIDITY() ((void)0)
-#endif
-
 static int descriptor_compare(const void *key, const void *member)
 {
 enum AVCodecID id = *(const enum AVCodecID *) key;
@@ -3141,8 +3119,6 @@ static int descriptor_compare(const void *key, const void 
*member)
 
 const AVCodecDescriptor *avcodec_descriptor_get(enum AVCodecID id)
 {
-CHECK_VALIDITY();
-
 return bsearch(, codec_descriptors, FF_ARRAY_ELEMS(codec_descriptors),
sizeof(codec_descriptors[0]), descriptor_compare);
 }
diff --git a/libavcodec/tests/codec_desc.c b/libavcodec/tests/codec_desc.c
new file mode 100644
index 00..c9b3497343
--- /dev/null
+++ b/libavcodec/tests/codec_desc.c
@@ -0,0 +1,45 @@
+/*
+ * 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 "libavcodec/avcodec.h"
+
+int main(int argc, char **argv)
+{
+const AVCodecDescriptor *old_desc = NULL, *desc;
+
+while (desc = avcodec_descriptor_next(old_desc)) {
+if (old_desc && old_desc->id >= desc->id) {
+av_log(NULL, AV_LOG_FATAL, "Unsorted codec_descriptors '%s' and 
'%s'.\n", old_desc->name, desc->name);
+return 1;
+}
+
+if (avcodec_descriptor_get(desc->id) != desc) {
+av_log(NULL, AV_LOG_FATAL, "avcodec_descriptor_get() failed with 
'%s'.\n", desc->name);
+return 1;
+}
+
+if (avcodec_descriptor_get_by_name(desc->name) != desc) {
+av_log(NULL, AV_LOG_FATAL, "avcodec_descriptor_get_by_name() 
failed with '%s'.\n", desc->name);
+return 1;
+}
+
+old_desc = desc;
+}
+
+return 0;
+}
diff --git a/tests/fate/libavcodec.mak b/tests/fate/libavcodec.mak
index a2d5d9fe33..d3b2dd874e 100644
--- a/tests/fate/libavcodec.mak
+++ b/tests/fate/libavcodec.mak
@@ -13,6 +13,11 @@ fate-celp_math: libavcodec/tests/celp_math$(EXESUF)
 fate-celp_math: CMD = run libavcodec/tests/celp_math
 fate-celp_math: CMP = n

Re: [FFmpeg-devel] [PATCH] avformat/format: temporarily use old next api

[Muhammad Faiz]

On Sat, Feb 10, 2018 at 1:08 AM, Muhammad Faiz <mfc...@gmail.com> wrote:
> On Fri, Feb 9, 2018 at 7:04 PM, James Almer <jamr...@gmail.com> wrote:
>> On 2/9/2018 7:16 AM, Muhammad Faiz wrote:
>>> Should fix 
>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225066.html
>>>
>>> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>>> ---
>>> The actual problem is that av*next() and av*iterate() have different
>>> semantics:
>>>   - av*next() iterate all formats+devices
>>>   - av*iterate() iterate formats only.
>>> Is this the intended behaviour?
>>>
>>>  libavformat/format.c | 13 -
>>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavformat/format.c b/libavformat/format.c
>>> index b8c5a90a92..75951938cf 100644
>>> --- a/libavformat/format.c
>>> +++ b/libavformat/format.c
>>> @@ -52,7 +52,9 @@ AVOutputFormat *av_guess_format(const char *short_name, 
>>> const char *filename,
>>>  const char *mime_type)
>>>  {
>>>  AVOutputFormat *fmt = NULL, *fmt_found;
>>> +#if !FF_API_NEXT
>>>  void *i = 0;
>>> +#endif
>>>  int score_max, score;
>>>
>>>  /* specific test for image sequences */
>>> @@ -66,7 +68,13 @@ AVOutputFormat *av_guess_format(const char *short_name, 
>>> const char *filename,
>>>  /* Find the proper file type. */
>>>  fmt_found = NULL;
>>>  score_max = 0;
>>> -while ((fmt = av_muxer_iterate())) {
>>> +#if FF_API_NEXT
>>> +FF_DISABLE_DEPRECATION_WARNINGS
>>> +while ((fmt = av_oformat_next(fmt)))
>>> +#else
>>> +while ((fmt = av_muxer_iterate()))
>>> +#endif
>>> + {
>>>  score = 0;
>>>  if (fmt->name && short_name && av_match_name(short_name, 
>>> fmt->name))
>>>  score += 100;
>>> @@ -81,6 +89,9 @@ AVOutputFormat *av_guess_format(const char *short_name, 
>>> const char *filename,
>>>  fmt_found = fmt;
>>>  }
>>>  }
>>> +#if FF_API_NEXT
>>> +FF_ENABLE_DEPRECATION_WARNINGS
>>> +#endif
>>>  return fmt_found;
>>>  }
>>
>> Is your intention to schedule this change to happen once the deprecation
>> period ends two years from now, or were you just disabling it for a bit
>> until the new API is fixed/finalized?
>> If the latter, then please don't add the wrappers. Just replace the
>> _iterate() calls.
>
> My intention is the first. With assumption that people agree with
> current new API, and
> the different semantic between av_iformat/oformat_next (which iterate
> formats+devices)
> and av_muxer/demuxer_iterate (which iterate formats only) is intended 
> behaviour.
>
> Thank's.

Pushed.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: add new API for iterating codecs and codec parsers

[Muhammad Faiz]

On Fri, Feb 9, 2018 at 6:12 PM, Nicolas George <geo...@nsup.org> wrote:
> Muhammad Faiz (2018-02-08):
>> I actually prefer _next() without introducing new API. Yeah, it is
>> slower because it must initialize next pointer
>
> I am not sure what you mean here. The problem with initing the next
> pointer was never speed.
>
> The problem with the next pointer is that it requires a run-time write
> in the codec structure, that requires it to be in the data section
> instead of the rodata section.

This is what I mean "speed" (Don't forget we also need to call
ff_thread_once on every _next() call).

>
> The static init of this pointer, as you proposed, fixes that specific
> issue.
>
> But that is still a linked list. Linked lists are very good when you
> need to insert and remove in the list frequently, but for something that
> is built once and then static, it has very limited usefulness.

I dislike that we introduce new API just because it is "slightly"
better than old API.
Also, migrating to new API isn't trivial enough (see cmdutils.c problem).

>
> If the drawback of memory management for solution C (returning the whole
> list at once) is considered too bad, then I think solution B is
> preferable: more versatile, easier to understand.

If we really need to introduce new API, I also choose B. (Unless we
have a plan to make
the array become linked list again in the future).

Actually, I don't care so much about this. I will follow what people agree.

>
> And by the way, until we decide between solutions A, B, C or anything
> else proposed, starting coding would be useless. Just as starting to
> pack your bags before deciding whether you go to the sea or mountain.

Except for fixing regression.

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

Re: [FFmpeg-devel] [PATCH] avformat/format: temporarily use old next api

[Muhammad Faiz]

On Fri, Feb 9, 2018 at 7:04 PM, James Almer <jamr...@gmail.com> wrote:
> On 2/9/2018 7:16 AM, Muhammad Faiz wrote:
>> Should fix 
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225066.html
>>
>> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>> ---
>> The actual problem is that av*next() and av*iterate() have different
>> semantics:
>>   - av*next() iterate all formats+devices
>>   - av*iterate() iterate formats only.
>> Is this the intended behaviour?
>>
>>  libavformat/format.c | 13 -
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/format.c b/libavformat/format.c
>> index b8c5a90a92..75951938cf 100644
>> --- a/libavformat/format.c
>> +++ b/libavformat/format.c
>> @@ -52,7 +52,9 @@ AVOutputFormat *av_guess_format(const char *short_name, 
>> const char *filename,
>>  const char *mime_type)
>>  {
>>  AVOutputFormat *fmt = NULL, *fmt_found;
>> +#if !FF_API_NEXT
>>  void *i = 0;
>> +#endif
>>  int score_max, score;
>>
>>  /* specific test for image sequences */
>> @@ -66,7 +68,13 @@ AVOutputFormat *av_guess_format(const char *short_name, 
>> const char *filename,
>>  /* Find the proper file type. */
>>  fmt_found = NULL;
>>  score_max = 0;
>> -while ((fmt = av_muxer_iterate())) {
>> +#if FF_API_NEXT
>> +FF_DISABLE_DEPRECATION_WARNINGS
>> +while ((fmt = av_oformat_next(fmt)))
>> +#else
>> +while ((fmt = av_muxer_iterate()))
>> +#endif
>> + {
>>  score = 0;
>>  if (fmt->name && short_name && av_match_name(short_name, fmt->name))
>>  score += 100;
>> @@ -81,6 +89,9 @@ AVOutputFormat *av_guess_format(const char *short_name, 
>> const char *filename,
>>  fmt_found = fmt;
>>  }
>>  }
>> +#if FF_API_NEXT
>> +FF_ENABLE_DEPRECATION_WARNINGS
>> +#endif
>>  return fmt_found;
>>  }
>
> Is your intention to schedule this change to happen once the deprecation
> period ends two years from now, or were you just disabling it for a bit
> until the new API is fixed/finalized?
> If the latter, then please don't add the wrappers. Just replace the
> _iterate() calls.

My intention is the first. With assumption that people agree with
current new API, and
the different semantic between av_iformat/oformat_next (which iterate
formats+devices)
and av_muxer/demuxer_iterate (which iterate formats only) is intended behaviour.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: add new API for iterating codecs and codec parsers

[Muhammad Faiz]

On Fri, Feb 9, 2018 at 6:53 PM, James Almer <jamr...@gmail.com> wrote:
> On 2/9/2018 7:56 AM, Muhammad Faiz wrote:
>> On Thu, Feb 8, 2018 at 7:04 AM, Michael Niedermayer
>> <mich...@niedermayer.cc> wrote:
>>> On Wed, Feb 07, 2018 at 01:52:33PM +0100, Nicolas George wrote:
>>>> Josh de Kock (2018-02-06):
>>>>> ffmpeg | branch: master | Josh de Kock <j...@itanimul.li> | Fri Dec 22 
>>>>> 22:17:00 2017 +| [7e8eba2d8755962d9dca5eade57bf8f591a73c0c] | 
>>>>> committer: Josh de Kock
>>>>>
>>>>> lavc: add new API for iterating codecs and codec parsers
>>>>>
>>>>> Based on an unfinished patch by atomnuker.
>>>
>>> This commit also breaks
>>>
>>> ./configure --enable-libsoxr && make -j12 fate-checkasm
>>>  make -j12 fate-checkasm
>>>  ...
>>> LD  tests/checkasm/checkasm
>>> libswresample/libswresample.a(soxr_resample.o): In function 
>>> `get_out_samples':
>>> ffmpeg/libswresample/soxr_resample.c:118: undefined reference to 
>>> `soxr_delay'
>>> libswresample/libswresample.a(soxr_resample.o): In function `get_delay':
>>> ffmpeg/libswresample/soxr_resample.c:100: undefined reference to 
>>> `soxr_delay'
>>> libswresample/libswresample.a(soxr_resample.o): In function `flush':
>>> ffmpeg/libswresample/soxr_resample.c:70: undefined reference to `soxr_delay'
>>> ffmpeg/libswresample/soxr_resample.c:72: undefined reference to 
>>> `soxr_process'
>>> ffmpeg/libswresample/soxr_resample.c:77: undefined reference to 
>>> `soxr_process'
>>> ffmpeg/libswresample/soxr_resample.c:78: undefined reference to `soxr_delay'
>>> libswresample/libswresample.a(soxr_resample.o): In function `process':
>>> ffmpeg/libswresample/soxr_resample.c:88: undefined reference to 
>>> `soxr_set_num_channels'
>>> ffmpeg/libswresample/soxr_resample.c:88: undefined reference to 
>>> `soxr_set_error'
>>> ffmpeg/libswresample/soxr_resample.c:90: undefined reference to 
>>> `soxr_process'
>>> libswresample/libswresample.a(soxr_resample.o): In function `destroy':
>>> ffmpeg/libswresample/soxr_resample.c:65: undefined reference to 
>>> `soxr_delete'
>>> libswresample/libswresample.a(soxr_resample.o): In function `create':
>>> ffmpeg/libswresample/soxr_resample.c:46: undefined reference to 
>>> `soxr_io_spec'
>>> ffmpeg/libswresample/soxr_resample.c:48: undefined reference to 
>>> `soxr_quality_spec'
>>> ffmpeg/libswresample/soxr_resample.c:56: undefined reference to 
>>> `soxr_delete'
>>> ffmpeg/libswresample/soxr_resample.c:57: undefined reference to 
>>> `soxr_create'
>>> collect2: error: ld returned 1 exit status
>>> make: *** [tests/checkasm/checkasm] Error 1
>>
>> Fixed in 81d6501be77b273053a66eeced94d78e2021f1d1
>>
>> Thank's.
>
> This is not a proper solution. swr is pulled by avcodec only if Opus
> decoder is enabled. There's no reason to hardcode it for checkasm otherwise.
> The problem here is that the Makefile should pull all the dependencies
> of its hardcoded dependencies. This is what FFLIBS and FFEXTRALIBS do in
> common.mak to link the actual libraries.

Probably, this is not a proper solution, but it is trivial enough.
(I'm sorry that I pushed it without posting).
So, please fix it with the proper solution. Probably, by adding
swresample-extralibs to avcodec-extralibs when avcodec has dependency
to swresample. I don't know how to do it.

>
> That said, was this really a regression generated by this commit? It
> looks unrelated.

Actually, it was a bug even before this commit. Just, previously it
was hidden because linker was smart enough to discard unneeded
dependency. But now when the list is changed to array, the linker is
unable to do it.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: add new API for iterating codecs and codec parsers

[Muhammad Faiz]

On Thu, Feb 8, 2018 at 7:04 AM, Michael Niedermayer
 wrote:
> On Wed, Feb 07, 2018 at 01:52:33PM +0100, Nicolas George wrote:
>> Josh de Kock (2018-02-06):
>> > ffmpeg | branch: master | Josh de Kock  | Fri Dec 22 
>> > 22:17:00 2017 +| [7e8eba2d8755962d9dca5eade57bf8f591a73c0c] | 
>> > committer: Josh de Kock
>> >
>> > lavc: add new API for iterating codecs and codec parsers
>> >
>> > Based on an unfinished patch by atomnuker.
>
> This commit also breaks
>
> ./configure --enable-libsoxr && make -j12 fate-checkasm
>  make -j12 fate-checkasm
>  ...
> LD  tests/checkasm/checkasm
> libswresample/libswresample.a(soxr_resample.o): In function `get_out_samples':
> ffmpeg/libswresample/soxr_resample.c:118: undefined reference to `soxr_delay'
> libswresample/libswresample.a(soxr_resample.o): In function `get_delay':
> ffmpeg/libswresample/soxr_resample.c:100: undefined reference to `soxr_delay'
> libswresample/libswresample.a(soxr_resample.o): In function `flush':
> ffmpeg/libswresample/soxr_resample.c:70: undefined reference to `soxr_delay'
> ffmpeg/libswresample/soxr_resample.c:72: undefined reference to `soxr_process'
> ffmpeg/libswresample/soxr_resample.c:77: undefined reference to `soxr_process'
> ffmpeg/libswresample/soxr_resample.c:78: undefined reference to `soxr_delay'
> libswresample/libswresample.a(soxr_resample.o): In function `process':
> ffmpeg/libswresample/soxr_resample.c:88: undefined reference to 
> `soxr_set_num_channels'
> ffmpeg/libswresample/soxr_resample.c:88: undefined reference to 
> `soxr_set_error'
> ffmpeg/libswresample/soxr_resample.c:90: undefined reference to `soxr_process'
> libswresample/libswresample.a(soxr_resample.o): In function `destroy':
> ffmpeg/libswresample/soxr_resample.c:65: undefined reference to `soxr_delete'
> libswresample/libswresample.a(soxr_resample.o): In function `create':
> ffmpeg/libswresample/soxr_resample.c:46: undefined reference to `soxr_io_spec'
> ffmpeg/libswresample/soxr_resample.c:48: undefined reference to 
> `soxr_quality_spec'
> ffmpeg/libswresample/soxr_resample.c:56: undefined reference to `soxr_delete'
> ffmpeg/libswresample/soxr_resample.c:57: undefined reference to `soxr_create'
> collect2: error: ld returned 1 exit status
> make: *** [tests/checkasm/checkasm] Error 1

Fixed in 81d6501be77b273053a66eeced94d78e2021f1d1

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

Re: [FFmpeg-devel] [PATCH] avcodec/codec_desc: sort codec_descriptors

[Muhammad Faiz]

On Fri, Feb 9, 2018 at 9:11 AM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Sat, Feb 03, 2018 at 01:35:34AM +0700, Muhammad Faiz wrote:
>> Use bsearch on avcodec_descriptor_get().
>>
>> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>> ---
>>  libavcodec/codec_desc.c | 1103 
>> ---
>>  1 file changed, 563 insertions(+), 540 deletions(-)
>
> probably ok

Pushed.

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

[FFmpeg-devel] [PATCH] avformat/format: temporarily use old next api

[Muhammad Faiz]

Should fix https://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225066.html

Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
---
The actual problem is that av*next() and av*iterate() have different
semantics:
  - av*next() iterate all formats+devices
  - av*iterate() iterate formats only.
Is this the intended behaviour?

 libavformat/format.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/libavformat/format.c b/libavformat/format.c
index b8c5a90a92..75951938cf 100644
--- a/libavformat/format.c
+++ b/libavformat/format.c
@@ -52,7 +52,9 @@ AVOutputFormat *av_guess_format(const char *short_name, const 
char *filename,
 const char *mime_type)
 {
 AVOutputFormat *fmt = NULL, *fmt_found;
+#if !FF_API_NEXT
 void *i = 0;
+#endif
 int score_max, score;
 
 /* specific test for image sequences */
@@ -66,7 +68,13 @@ AVOutputFormat *av_guess_format(const char *short_name, 
const char *filename,
 /* Find the proper file type. */
 fmt_found = NULL;
 score_max = 0;
-while ((fmt = av_muxer_iterate())) {
+#if FF_API_NEXT
+FF_DISABLE_DEPRECATION_WARNINGS
+while ((fmt = av_oformat_next(fmt)))
+#else
+while ((fmt = av_muxer_iterate()))
+#endif
+ {
 score = 0;
 if (fmt->name && short_name && av_match_name(short_name, fmt->name))
 score += 100;
@@ -81,6 +89,9 @@ AVOutputFormat *av_guess_format(const char *short_name, const 
char *filename,
 fmt_found = fmt;
 }
 }
+#if FF_API_NEXT
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
 return fmt_found;
 }
 
-- 
2.13.2

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

Re: [FFmpeg-devel] [PATCH] avcodec/codec_desc: sort codec_descriptors

[Muhammad Faiz]

On Sat, Feb 3, 2018 at 1:35 AM, Muhammad Faiz <mfc...@gmail.com> wrote:
> Use bsearch on avcodec_descriptor_get().
>
> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
> ---
>  libavcodec/codec_desc.c | 1103 
> ---
>  1 file changed, 563 insertions(+), 540 deletions(-)
>
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index c3688de1d6..1e5d715416 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -21,8 +21,10 @@
>
>  #include 
>
> +#include "libavutil/avassert.h"
>  #include "libavutil/common.h"
>  #include "libavutil/internal.h"
> +#include "libavutil/thread.h"
>  #include "avcodec.h"
>  #include "profiles.h"
>  #include "version.h"
> @@ -90,6 +92,28 @@ static const AVCodecDescriptor codec_descriptors[] = {
>  .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
>  },
>  {
> +.id= AV_CODEC_ID_LJPEG,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "ljpeg",
> +.long_name = NULL_IF_CONFIG_SMALL("Lossless JPEG"),
> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
> +},
> +{
> +.id= AV_CODEC_ID_SP5X,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "sp5x",
> +.long_name = NULL_IF_CONFIG_SMALL("Sunplus JPEG (SP5X)"),
> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
> +},
> +{
> +.id= AV_CODEC_ID_JPEGLS,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "jpegls",
> +.long_name = NULL_IF_CONFIG_SMALL("JPEG-LS"),
> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY |
> + AV_CODEC_PROP_LOSSLESS,
> +},
> +{
>  .id= AV_CODEC_ID_MPEG4,
>  .type  = AVMEDIA_TYPE_VIDEO,
>  .name  = "mpeg4",
> @@ -161,14 +185,6 @@ static const AVCodecDescriptor codec_descriptors[] = {
>  .props = AV_CODEC_PROP_LOSSY,
>  },
>  {
> -.id= AV_CODEC_ID_SVG,
> -.type  = AVMEDIA_TYPE_VIDEO,
> -.name  = "svg",
> -.long_name = NULL_IF_CONFIG_SMALL("Scalable Vector Graphics"),
> -.props = AV_CODEC_PROP_LOSSLESS,
> -.mime_types= MT("image/svg+xml"),
> -},
> -{
>  .id= AV_CODEC_ID_SVQ1,
>  .type  = AVMEDIA_TYPE_VIDEO,
>  .name  = "svq1",
> @@ -408,13 +424,6 @@ static const AVCodecDescriptor codec_descriptors[] = {
>  .props = AV_CODEC_PROP_LOSSLESS,
>  },
>  {
> -.id= AV_CODEC_ID_SNOW,
> -.type  = AVMEDIA_TYPE_VIDEO,
> -.name  = "snow",
> -.long_name = NULL_IF_CONFIG_SMALL("Snow"),
> -.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_LOSSLESS,
> -},
> -{
>  .id= AV_CODEC_ID_TSCC,
>  .type  = AVMEDIA_TYPE_VIDEO,
>  .name  = "tscc",
> @@ -450,6 +459,50 @@ static const AVCodecDescriptor codec_descriptors[] = {
>  .props = AV_CODEC_PROP_LOSSY,
>  },
>  {
> +.id= AV_CODEC_ID_PNG,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "png",
> +.long_name = NULL_IF_CONFIG_SMALL("PNG (Portable Network Graphics) 
> image"),
> +.props = AV_CODEC_PROP_LOSSLESS,
> +.mime_types= MT("image/png"),
> +},
> +{
> +.id= AV_CODEC_ID_PPM,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "ppm",
> +.long_name = NULL_IF_CONFIG_SMALL("PPM (Portable PixelMap) image"),
> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
> +},
> +{
> +.id= AV_CODEC_ID_PBM,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "pbm",
> +.long_name = NULL_IF_CONFIG_SMALL("PBM (Portable BitMap) image"),
> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
> +},
> +{
> +.id= AV_CODEC_ID_PGM,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "pgm",
> +.long_name = NULL_IF_CONFIG_SMALL("PGM (Portable GrayMap) image"),
> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
> +},
> +{
> +.id= AV_CO

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: add new API for iterating codecs and codec parsers

[Muhammad Faiz]

On Thu, Feb 8, 2018 at 1:33 AM, Nicolas George  wrote:
> James Almer (2018-02-07):
>> Since reverting would be dirty, I'd prefer if we keep the discussion
>> about the desired API going and then apply the needed patches on top of
>> the current tree.
>> As long as we don't take weeks to do it (and do it before a release is
>> tagged), any kind of change to what is already committed is ok.
>
> Yes, that is exactly what I meant with "virtually revoked". Let us hope
> people will not start using the API before we stabilize it.
>
> But I would like that people be more careful with it. Twice in a few
> days have patches been pushed while there were outstanding objections
> about the API. If it had been done on purpose, I think it would have
> been ground for revoking git commit rights.
>
> Now, as for the possible APIs for iterating:
>
> (A) this one using an opaque pointer and a _next() call;
>
> (B) using an index;
>
> (C) returning the whole list at once in a newly allocated array.
>
> Are there any missing?
>
> I am rather in favour of (C), because it is the one that puts the least
> constraint on the internal implementation. And it is very convenient for
> the caller.

I actually prefer _next() without introducing new API. Yeah, it is
slower because it must initialize next pointer (people seem dislike
the patch that fixes it (i.e. with ff_next things)). But, as long as
the internal doesn't use it but uses list directly, it has no
problems.

If speed is really a concern for users, then (B) probably is an option.

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

Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs

[Muhammad Faiz]

On Thu, Feb 8, 2018 at 7:35 AM, James Almer  wrote:
> On 2/7/2018 9:32 PM, Michael Niedermayer wrote:
>> On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote:
>>> Yes, my bad. It looked like it worked initially (was more
>>> worried about getting a fix out quickly), but it didnt. Try this one.
>>>
>>> ---
>>>  fftools/cmdutils.c | 104 
>>> +
>>>  1 file changed, 58 insertions(+), 46 deletions(-)
>>
>> I dont know if this is supposed to fix the other lists
>> but
>> ./ffmpeg -demuxers
>> still returns nonsense with this patch
>>
>> File formats:
>>  D. = Demuxing supported
>>  .E = Muxing supported
>>  --
>>   E 3dostr  3DO STR
>>   E 4xm 4X Technologies
>> ...
>> a while ago this was returned:
>>
>> File formats:
>>  D. = Demuxing supported
>>  .E = Muxing supported
>>  --
>>  D  3dostr  3DO STR
>>  D  4xm 4X Technologies
>
> Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
> then. If the new API may actually get changed in the coming days once
> some consensus is reached then there's no point trying to get this
> working with things as is.

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

Re: [FFmpeg-devel] [PATCH] avcodec: Document that init_static_data() is not intended for time consuming operations.

[Muhammad Faiz]

On Tue, Feb 6, 2018 at 7:21 AM, Michael Niedermayer
 wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/avcodec.h | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 8fbbc798a2..9f4e8dd3c5 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3439,6 +3439,9 @@ typedef struct AVCodec {
>
>  /**
>   * Initialize codec static data, called from avcodec_register().
> + *
> + * This is not intended for time consuming operations as it is
> + * run for every codec regardless of that codec being used.
>   */
>  void (*init_static_data)(struct AVCodec *codec);
>

LGTM.

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

Re: [FFmpeg-devel] [PATCH v4 3/7] lavf: add new API for iterating muxers and demuxers

[Muhammad Faiz]

On Sat, Feb 3, 2018 at 2:44 AM, Josh de Kock  wrote:
> ---
>  Makefile |   3 +-
>  configure|   6 +-
>  doc/APIchanges   |   7 +-
>  libavformat/.gitignore   |   2 +
>  libavformat/allformats.c | 866 
> ---
>  libavformat/avformat.h   |  31 ++
>  libavformat/format.c |  68 +---
>  libavformat/version.h|   3 +
>  8 files changed, 566 insertions(+), 420 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 1d1c886..0cd0a1d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -143,7 +143,8 @@ distclean:: clean
> ffbuild/.config ffbuild/config.* libavutil/avconfig.h \
> version.h libavutil/ffversion.h libavcodec/codec_names.h \
> libavcodec/bsf_list.c libavformat/protocol_list.c \
> -   libavcodec/codec_list.c libavcodec/parser_list.c
> +   libavcodec/codec_list.c libavcodec/parser_list.c \
> +   libavformat/muxer_list.c libavformat/demuxer_list.c
>  ifeq ($(SRC_LINK),src)
> $(RM) src
>  endif
> diff --git a/configure b/configure
> index e8795d8..d6d7980 100755
> --- a/configure
> +++ b/configure
> @@ -3523,8 +3523,6 @@ find_things(){
>  sed -n "s/^[^#]*$pattern.*([^,]*, *\([^,]*\)\(,.*\)*).*/\1_$thing/p" 
> "$file"
>  }
>
> -MUXER_LIST=$(find_thingsmuxer_MUX libavformat/allformats.c)
> -DEMUXER_LIST=$(find_things  demuxer  DEMUXlibavformat/allformats.c)
>  OUTDEV_LIST=$(find_things   outdev   OUTDEV   libavdevice/alldevices.c)
>  INDEV_LIST=$(find_thingsindev_IN  libavdevice/alldevices.c)
>  FILTER_LIST=$(find_things   filter   FILTER   libavfilter/allfilters.c)
> @@ -3536,6 +3534,8 @@ find_things_extern(){
>  sed -n "s/^[^#]*extern.*$pattern *ff_\([^ ]*\)_$thing;/\1_$thing/p" 
> "$file"
>  }
>
> +MUXER_LIST=$(find_things_extern muxer AVOutputFormat 
> libavformat/allformats.c)
> +DEMUXER_LIST=$(find_things_extern demuxer AVInputFormat 
> libavformat/allformats.c)
>  ENCODER_LIST=$(find_things_extern encoder AVCodec libavcodec/allcodecs.c)
>  DECODER_LIST=$(find_things_extern decoder AVCodec libavcodec/allcodecs.c)
>  CODEC_LIST="
> @@ -7034,6 +7034,8 @@ print_enabled_components(){
>  print_enabled_components libavcodec/codec_list.c AVCodec codec_list 
> $CODEC_LIST
>  print_enabled_components libavcodec/parser_list.c AVCodecParser parser_list 
> $PARSER_LIST
>  print_enabled_components libavcodec/bsf_list.c AVBitStreamFilter 
> bitstream_filters $BSF_LIST
> +print_enabled_components libavformat/demuxer_list.c AVInputFormat 
> demuxer_list $DEMUXER_LIST
> +print_enabled_components libavformat/muxer_list.c AVOutputFormat muxer_list 
> $MUXER_LIST
>  print_enabled_components libavformat/protocol_list.c URLProtocol 
> url_protocols $PROTOCOL_LIST
>
>  # Settings for pkg-config files
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 77da22c..2a12f22 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,7 +15,12 @@ libavutil: 2017-10-21
>
>  API changes, most recent first:
>
> -2018-01-xx - xxx - lavc 58.9.100 - avcodec.h
> +2018-xx-xx - xxx - lavf 58.9.100 - avformat.h
> +  Deprecate use of av_register_input_format(), av_register_output_format(),
> +  avformat_register_all(), av_iformat_next(), av_oformat_next().
> +  Add av_demuxer_iterate(), and av_muxer_iterate().
> +
> +2018-xx-xx - xxx - lavc 58.9.100 - avcodec.h
>Deprecate use of avcodec_register(), avcodec_register_all(), and
>av_codec_next(). Add av_codec_iterate().
>
> diff --git a/libavformat/.gitignore b/libavformat/.gitignore
> index cdc24b7..fb70c12 100644
> --- a/libavformat/.gitignore
> +++ b/libavformat/.gitignore
> @@ -1 +1,3 @@
>  /protocol_list.c
> +/muxer_list.c
> +/demuxer_list.c
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 83ed766..0f198d5 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -26,370 +26,528 @@
>  #include "url.h"
>  #include "version.h"
>
> -#define REGISTER_MUXER(X, x)\
> -{   \
> -extern AVOutputFormat ff_##x##_muxer;   \
> -if (CONFIG_##X##_MUXER) \
> -av_register_output_format(_##x##_muxer); \
> -}
> +/* (de)muxers */
> +extern AVOutputFormat ff_a64_muxer;
> +extern AVInputFormat  ff_aa_demuxer;
> +extern AVInputFormat  ff_aac_demuxer;
> +extern AVInputFormat  ff_ac3_demuxer;
> +extern AVOutputFormat ff_ac3_muxer;
> +extern AVInputFormat  ff_acm_demuxer;
> +extern AVInputFormat  ff_act_demuxer;
> +extern AVInputFormat  ff_adf_demuxer;
> +extern AVInputFormat  ff_adp_demuxer;
> +extern AVInputFormat  ff_ads_demuxer;
> +extern AVOutputFormat ff_adts_muxer;
> +extern AVInputFormat  ff_adx_demuxer;
> +extern AVOutputFormat ff_adx_muxer;
> +extern AVInputFormat  ff_aea_demuxer;
> 

Re: [FFmpeg-devel] [PATCH v4 5/7] lavd: add new API for iterating input and output devices

[Muhammad Faiz]

On Tue, Feb 6, 2018 at 6:35 AM, Muhammad Faiz <mfc...@gmail.com> wrote:
> On Sat, Feb 3, 2018 at 2:44 AM, Josh de Kock <j...@itanimul.li> wrote:
>> This also adds an avpriv function to register devices in
>> libavformat
>> ---
>>  Makefile |   3 +-
>>  configure|  27 +--
>>  libavdevice/.gitignore   |   2 +
>>  libavdevice/alldevices.c | 181 
>> ---
>>  libavdevice/avdevice.c   |  46 
>>  libavdevice/avdevice.h   |  28 
>>  libavdevice/version.h|   4 ++
>>  libavformat/allformats.c |  45 +++-
>>  libavformat/format.c |   8 +++
>>  libavformat/internal.h   |   7 ++
>>  10 files changed, 255 insertions(+), 96 deletions(-)
>>  create mode 100644 libavdevice/.gitignore
>>
>> diff --git a/Makefile b/Makefile
>> index 0cd0a1d..bb93b69 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -144,7 +144,8 @@ distclean:: clean
>> version.h libavutil/ffversion.h libavcodec/codec_names.h \
>> libavcodec/bsf_list.c libavformat/protocol_list.c \
>> libavcodec/codec_list.c libavcodec/parser_list.c \
>> -   libavformat/muxer_list.c libavformat/demuxer_list.c
>> +   libavformat/muxer_list.c libavformat/demuxer_list.c \
>> +   libavdevice/indev_list.c libavdevice/outdev_list.c
>>  ifeq ($(SRC_LINK),src)
>> $(RM) src
>>  endif
>> diff --git a/configure b/configure
>> index d6d7980..040b848 100755
>> --- a/configure
>> +++ b/configure
>> @@ -568,6 +568,12 @@ add_suffix(){
>>  for v; do echo ${v}${suffix}; done
>>  }
>>
>> +remove_suffix(){
>> +suffix=$1
>> +shift
>> +for v; do echo ${v%$suffix}; done
>> +}
>> +
>>  set_all(){
>>  value=$1
>>  shift
>> @@ -3523,17 +3529,18 @@ find_things(){
>>  sed -n "s/^[^#]*$pattern.*([^,]*, *\([^,]*\)\(,.*\)*).*/\1_$thing/p" 
>> "$file"
>>  }
>>
>> -OUTDEV_LIST=$(find_things   outdev   OUTDEV   libavdevice/alldevices.c)
>> -INDEV_LIST=$(find_thingsindev_IN  libavdevice/alldevices.c)
>>  FILTER_LIST=$(find_things   filter   FILTER   libavfilter/allfilters.c)
>>
>>  find_things_extern(){
>>  thing=$1
>>  pattern=$2
>>  file=$source_path/$3
>> -sed -n "s/^[^#]*extern.*$pattern *ff_\([^ ]*\)_$thing;/\1_$thing/p" 
>> "$file"
>> +out=${4:-$thing}
>> +sed -n "s/^[^#]*extern.*$pattern *ff_\([^ ]*\)_$thing;/\1_$out/p" 
>> "$file"
>>  }
>>
>> +OUTDEV_LIST=$(find_things_extern muxer AVOutputFormat 
>> libavdevice/alldevices.c outdev)
>> +INDEV_LIST=$(find_things_extern demuxer AVInputFormat 
>> libavdevice/alldevices.c indev)
>>  MUXER_LIST=$(find_things_extern muxer AVOutputFormat 
>> libavformat/allformats.c)
>>  DEMUXER_LIST=$(find_things_extern demuxer AVInputFormat 
>> libavformat/allformats.c)
>>  ENCODER_LIST=$(find_things_extern encoder AVCodec libavcodec/allcodecs.c)
>> @@ -7025,7 +7032,17 @@ print_enabled_components(){
>>  shift 3
>>  echo "static const $struct_name * const $name[] = {" > $TMPH
>>  for c in $*; do
>> -enabled $c && printf "_%s,\n" $c >> $TMPH
>> +if enabled $c; then
>> +case $name in
>> +indev_list)
>> +c=$(add_suffix _demuxer $(remove_suffix _indev $c))
>> +;;
>> +outdev_list)
>> +c=$(add_suffix _muxer $(remove_suffix _outdev $c))
>> +;;
>> +esac
>> +printf "_%s,\n" $c >> $TMPH
>> +fi
>>  done
>>  echo "NULL };" >> $TMPH
>>  cp_if_changed $TMPH $file
>> @@ -7034,6 +7051,8 @@ print_enabled_components(){
>>  print_enabled_components libavcodec/codec_list.c AVCodec codec_list 
>> $CODEC_LIST
>>  print_enabled_components libavcodec/parser_list.c AVCodecParser parser_list 
>> $PARSER_LIST
>>  print_enabled_components libavcodec/bsf_list.c AVBitStreamFilter 
>> bitstream_filters $BSF_LIST
>> +print_enabled_components libavdevice/indev_list.c AVInputFormat indev_list 
>> $INDEV_LIST
>> +print_enabled_components libavdevice/outdev_list.c AVOutputFormat 
>> outdev_list $OUTDEV_LIST
>>  print_enab

Re: [FFmpeg-devel] [PATCH v4 5/7] lavd: add new API for iterating input and output devices

[Muhammad Faiz]

On Sat, Feb 3, 2018 at 2:44 AM, Josh de Kock  wrote:
> This also adds an avpriv function to register devices in
> libavformat
> ---
>  Makefile |   3 +-
>  configure|  27 +--
>  libavdevice/.gitignore   |   2 +
>  libavdevice/alldevices.c | 181 
> ---
>  libavdevice/avdevice.c   |  46 
>  libavdevice/avdevice.h   |  28 
>  libavdevice/version.h|   4 ++
>  libavformat/allformats.c |  45 +++-
>  libavformat/format.c |   8 +++
>  libavformat/internal.h   |   7 ++
>  10 files changed, 255 insertions(+), 96 deletions(-)
>  create mode 100644 libavdevice/.gitignore
>
> diff --git a/Makefile b/Makefile
> index 0cd0a1d..bb93b69 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -144,7 +144,8 @@ distclean:: clean
> version.h libavutil/ffversion.h libavcodec/codec_names.h \
> libavcodec/bsf_list.c libavformat/protocol_list.c \
> libavcodec/codec_list.c libavcodec/parser_list.c \
> -   libavformat/muxer_list.c libavformat/demuxer_list.c
> +   libavformat/muxer_list.c libavformat/demuxer_list.c \
> +   libavdevice/indev_list.c libavdevice/outdev_list.c
>  ifeq ($(SRC_LINK),src)
> $(RM) src
>  endif
> diff --git a/configure b/configure
> index d6d7980..040b848 100755
> --- a/configure
> +++ b/configure
> @@ -568,6 +568,12 @@ add_suffix(){
>  for v; do echo ${v}${suffix}; done
>  }
>
> +remove_suffix(){
> +suffix=$1
> +shift
> +for v; do echo ${v%$suffix}; done
> +}
> +
>  set_all(){
>  value=$1
>  shift
> @@ -3523,17 +3529,18 @@ find_things(){
>  sed -n "s/^[^#]*$pattern.*([^,]*, *\([^,]*\)\(,.*\)*).*/\1_$thing/p" 
> "$file"
>  }
>
> -OUTDEV_LIST=$(find_things   outdev   OUTDEV   libavdevice/alldevices.c)
> -INDEV_LIST=$(find_thingsindev_IN  libavdevice/alldevices.c)
>  FILTER_LIST=$(find_things   filter   FILTER   libavfilter/allfilters.c)
>
>  find_things_extern(){
>  thing=$1
>  pattern=$2
>  file=$source_path/$3
> -sed -n "s/^[^#]*extern.*$pattern *ff_\([^ ]*\)_$thing;/\1_$thing/p" 
> "$file"
> +out=${4:-$thing}
> +sed -n "s/^[^#]*extern.*$pattern *ff_\([^ ]*\)_$thing;/\1_$out/p" "$file"
>  }
>
> +OUTDEV_LIST=$(find_things_extern muxer AVOutputFormat 
> libavdevice/alldevices.c outdev)
> +INDEV_LIST=$(find_things_extern demuxer AVInputFormat 
> libavdevice/alldevices.c indev)
>  MUXER_LIST=$(find_things_extern muxer AVOutputFormat 
> libavformat/allformats.c)
>  DEMUXER_LIST=$(find_things_extern demuxer AVInputFormat 
> libavformat/allformats.c)
>  ENCODER_LIST=$(find_things_extern encoder AVCodec libavcodec/allcodecs.c)
> @@ -7025,7 +7032,17 @@ print_enabled_components(){
>  shift 3
>  echo "static const $struct_name * const $name[] = {" > $TMPH
>  for c in $*; do
> -enabled $c && printf "_%s,\n" $c >> $TMPH
> +if enabled $c; then
> +case $name in
> +indev_list)
> +c=$(add_suffix _demuxer $(remove_suffix _indev $c))
> +;;
> +outdev_list)
> +c=$(add_suffix _muxer $(remove_suffix _outdev $c))
> +;;
> +esac
> +printf "_%s,\n" $c >> $TMPH
> +fi
>  done
>  echo "NULL };" >> $TMPH
>  cp_if_changed $TMPH $file
> @@ -7034,6 +7051,8 @@ print_enabled_components(){
>  print_enabled_components libavcodec/codec_list.c AVCodec codec_list 
> $CODEC_LIST
>  print_enabled_components libavcodec/parser_list.c AVCodecParser parser_list 
> $PARSER_LIST
>  print_enabled_components libavcodec/bsf_list.c AVBitStreamFilter 
> bitstream_filters $BSF_LIST
> +print_enabled_components libavdevice/indev_list.c AVInputFormat indev_list 
> $INDEV_LIST
> +print_enabled_components libavdevice/outdev_list.c AVOutputFormat 
> outdev_list $OUTDEV_LIST
>  print_enabled_components libavformat/demuxer_list.c AVInputFormat 
> demuxer_list $DEMUXER_LIST
>  print_enabled_components libavformat/muxer_list.c AVOutputFormat muxer_list 
> $MUXER_LIST
>  print_enabled_components libavformat/protocol_list.c URLProtocol 
> url_protocols $PROTOCOL_LIST
> diff --git a/libavdevice/.gitignore b/libavdevice/.gitignore
> new file mode 100644
> index 000..08ac3eb
> --- /dev/null
> +++ b/libavdevice/.gitignore
> @@ -0,0 +1,2 @@
> +/indev_list.c
> +/outdev_list.c
> diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
> index b767b6a..8b58aa1 100644
> --- a/libavdevice/alldevices.c
> +++ b/libavdevice/alldevices.c
> @@ -22,57 +22,152 @@
>  #include "libavutil/thread.h"
>  #include "avdevice.h"
>
> -#define REGISTER_OUTDEV(X, x)   \
> -{   \
> -extern AVOutputFormat ff_##x##_muxer;   \
> -if (CONFIG_##X##_OUTDEV) 

Re: [FFmpeg-devel] [PATCH v4 7/7] lavc/bsf: make BSF iteration the same as other iterators

[Muhammad Faiz]

On Mon, Feb 5, 2018 at 4:29 AM, Nicolas George  wrote:
> Josh de Kock (2018-02-04):
>> If we were to add in APIs which allowed you to register external components
>> again, this idea wouldn't work well as indexes wouldn't necessarily 
>> correspond
>> to the component which it previously did after you register extra components.
>
> That is not a problem if the documentation states "index change when
> components are registered".

Index isn't changed when extra component is added. Because the extra
component will reside in the last index + 1.

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

Re: [FFmpeg-devel] [PATCH v4 4/7] lavf: move fifo test muxer into separate file

[Muhammad Faiz]

On Sat, Feb 3, 2018 at 2:44 AM, Josh de Kock  wrote:
> This fixes the fate-fifo-muxer test.
> ---
>  libavformat/Makefile   |   2 +-
>  libavformat/allformats.c   |   1 +
>  libavformat/fifo_test.c| 150 
> +
>  libavformat/tests/fifo_muxer.c | 115 +--
>  4 files changed, 154 insertions(+), 114 deletions(-)
>  create mode 100644 libavformat/fifo_test.c
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index de0de92..e0bb8ae 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -163,7 +163,7 @@ OBJS-$(CONFIG_EAC3_MUXER)+= rawenc.o
>  OBJS-$(CONFIG_EPAF_DEMUXER)  += epafdec.o pcm.o
>  OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
>  OBJS-$(CONFIG_FFMETADATA_MUXER)  += ffmetaenc.o
> -OBJS-$(CONFIG_FIFO_MUXER)+= fifo.o
> +OBJS-$(CONFIG_FIFO_MUXER)+= fifo.o fifo_test.o
>  OBJS-$(CONFIG_FILMSTRIP_DEMUXER) += filmstripdec.o
>  OBJS-$(CONFIG_FILMSTRIP_MUXER)   += filmstripenc.o
>  OBJS-$(CONFIG_FITS_DEMUXER)  += fitsdec.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 0f198d5..09c4213 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -125,6 +125,7 @@ extern AVOutputFormat ff_f4v_muxer;
>  extern AVInputFormat  ff_ffmetadata_demuxer;
>  extern AVOutputFormat ff_ffmetadata_muxer;
>  extern AVOutputFormat ff_fifo_muxer;
> +extern AVOutputFormat ff_fifo_test_muxer;
>  extern AVInputFormat  ff_filmstrip_demuxer;
>  extern AVOutputFormat ff_filmstrip_muxer;
>  extern AVInputFormat  ff_fits_demuxer;
> diff --git a/libavformat/fifo_test.c b/libavformat/fifo_test.c
> new file mode 100644
> index 000..b86195b
> --- /dev/null
> +++ b/libavformat/fifo_test.c
> @@ -0,0 +1,150 @@
> +/*
> + * FIFO test pseudo-muxer
> + * Copyright (c) 2016 Jan Sebechlebsky
> + *
> + * 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 
> +#include "libavutil/opt.h"
> +#include "libavutil/time.h"
> +#include "libavutil/avassert.h"
> +#include "libavformat/avformat.h"
> +#include "libavformat/url.h"
> +#include "libavformat/network.h"
> +
> +/* Implementation of mock muxer to simulate real muxer failures */
> +
> +#define MAX_TST_PACKETS 128
> +#define SLEEPTIME_50_MS 5
> +#define SLEEPTIME_10_MS 1
> +
> +/* Implementation of mock muxer to simulate real muxer failures */
> +
> +/* This is structure of data sent in packets to
> + * failing muxer */
> +typedef struct FailingMuxerPacketData {
> +int ret; /* return value of write_packet call*/
> +int recover_after;   /* set ret to zero after this number of recovery 
> attempts */
> +unsigned sleep_time; /* sleep for this long in write_packet to simulate 
> long I/O operation */
> +} FailingMuxerPacketData;
> +
> +
> +typedef struct FailingMuxerContext {
> +AVClass *class;
> +int write_header_ret;
> +int write_trailer_ret;
> +/* If non-zero, summary of processed packets will be printed in deinit */
> +int print_deinit_summary;
> +
> +int flush_count;
> +int pts_written[MAX_TST_PACKETS];
> +int pts_written_nr;
> +} FailingMuxerContext;
> +
> +static int failing_write_header(AVFormatContext *avf)
> +{
> +FailingMuxerContext *ctx = avf->priv_data;
> +return ctx->write_header_ret;
> +}
> +
> +static int failing_write_packet(AVFormatContext *avf, AVPacket *pkt)
> +{
> +FailingMuxerContext *ctx = avf->priv_data;
> +int ret = 0;
> +if (!pkt) {
> +ctx->flush_count++;
> +} else {
> +FailingMuxerPacketData *data = (FailingMuxerPacketData*) pkt->data;
> +
> +if (!data->recover_after) {
> +data->ret = 0;
> +} else {
> +data->recover_after--;
> +}
> +
> +ret = data->ret;
> +
> +if (data->sleep_time) {
> +int64_t slept = 0;
> +while (slept < data->sleep_time) {
> +if (ff_check_interrupt(>interrupt_callback))
> +return AVERROR_EXIT;
> +av_usleep(SLEEPTIME_10_MS);
> +slept += SLEEPTIME_10_MS;
> +}
> +  

Re: [FFmpeg-devel] [PATCH] avcodec/me_cmp: remove ff_me_cmp_init_static()

[Muhammad Faiz]

On Sun, Feb 4, 2018 at 9:26 AM, James Almer <jamr...@gmail.com> wrote:
> On 2/3/2018 7:51 PM, Muhammad Faiz wrote:
>> Precalculate and constify ff_square_tab.
>>
>> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>> ---
>>  libavcodec/me_cmp.c  | 51 
>> +---
>>  libavcodec/me_cmp.h  |  4 +---
>>  libavcodec/mpegvideo_enc.c   |  2 +-
>>  libavcodec/mpegvideoencdsp.c |  2 +-
>>  libavcodec/snowenc.c |  2 +-
>>  libavcodec/utils.c   | 13 ---
>>  6 files changed, 43 insertions(+), 31 deletions(-)
>>
>> diff --git a/libavcodec/me_cmp.c b/libavcodec/me_cmp.c
>> index 5e34a11593..67a5bb5c71 100644
>> --- a/libavcodec/me_cmp.c
>> +++ b/libavcodec/me_cmp.c
>> @@ -22,6 +22,7 @@
>>
>>  #include "libavutil/attributes.h"
>>  #include "libavutil/internal.h"
>> +#include "libavutil/thread.h"
>
> Unused?
>
>>  #include "avcodec.h"
>>  #include "copy_block.h"
>>  #include "simple_idct.h"
>> @@ -29,13 +30,47 @@
>>  #include "mpegvideo.h"
>>  #include "config.h"
>>
>> -uint32_t ff_square_tab[512] = { 0, };
>> +/* (i - 256) * (i - 256) */
>> +const uint32_t ff_square_tab[512] = {
>> +65536, 65025, 64516, 64009, 63504, 63001, 62500, 62001, 61504, 61009, 
>> 60516, 60025, 59536, 59049, 58564, 58081,
>> +57600, 57121, 56644, 56169, 55696, 55225, 54756, 54289, 53824, 53361, 
>> 52900, 52441, 51984, 51529, 51076, 50625,
>> +50176, 49729, 49284, 48841, 48400, 47961, 47524, 47089, 46656, 46225, 
>> 45796, 45369, 44944, 44521, 44100, 43681,
>> +43264, 42849, 42436, 42025, 41616, 41209, 40804, 40401, 4, 39601, 
>> 39204, 38809, 38416, 38025, 37636, 37249,
>> +36864, 36481, 36100, 35721, 35344, 34969, 34596, 34225, 33856, 33489, 
>> 33124, 32761, 32400, 32041, 31684, 31329,
>> +30976, 30625, 30276, 29929, 29584, 29241, 28900, 28561, 28224, 27889, 
>> 27556, 27225, 26896, 26569, 26244, 25921,
>> +25600, 25281, 24964, 24649, 24336, 24025, 23716, 23409, 23104, 22801, 
>> 22500, 22201, 21904, 21609, 21316, 21025,
>> +20736, 20449, 20164, 19881, 19600, 19321, 19044, 18769, 18496, 18225, 
>> 17956, 17689, 17424, 17161, 16900, 16641,
>> +16384, 16129, 15876, 15625, 15376, 15129, 14884, 14641, 14400, 14161, 
>> 13924, 13689, 13456, 13225, 12996, 12769,
>> +12544, 12321, 12100, 11881, 11664, 11449, 11236, 11025, 10816, 10609, 
>> 10404, 10201, 1,  9801,  9604,  9409,
>> + 9216,  9025,  8836,  8649,  8464,  8281,  8100,  7921,  7744,  7569,  
>> 7396,  7225,  7056,  6889,  6724,  6561,
>> + 6400,  6241,  6084,  5929,  5776,  5625,  5476,  5329,  5184,  5041,  
>> 4900,  4761,  4624,  4489,  4356,  4225,
>> + 4096,  3969,  3844,  3721,  3600,  3481,  3364,  3249,  3136,  3025,  
>> 2916,  2809,  2704,  2601,  2500,  2401,
>> + 2304,  2209,  2116,  2025,  1936,  1849,  1764,  1681,  1600,  1521,  
>> 1444,  1369,  1296,  1225,  1156,  1089,
>> + 1024,   961,   900,   841,   784,   729,   676,   625,   576,   529,   
>> 484,   441,   400,   361,   324,   289,
>> +  256,   225,   196,   169,   144,   121,   100,81,64,49,   
>>  36,25,16, 9, 4, 1,
>> +0, 1, 4, 9,16,25,36,49,64,81,   
>> 100,   121,   144,   169,   196,   225,
>> +  256,   289,   324,   361,   400,   441,   484,   529,   576,   625,   
>> 676,   729,   784,   841,   900,   961,
>> + 1024,  1089,  1156,  1225,  1296,  1369,  1444,  1521,  1600,  1681,  
>> 1764,  1849,  1936,  2025,  2116,  2209,
>> + 2304,  2401,  2500,  2601,  2704,  2809,  2916,  3025,  3136,  3249,  
>> 3364,  3481,  3600,  3721,  3844,  3969,
>> + 4096,  4225,  4356,  4489,  4624,  4761,  4900,  5041,  5184,  5329,  
>> 5476,  5625,  5776,  5929,  6084,  6241,
>> + 6400,  6561,  6724,  6889,  7056,  7225,  7396,  7569,  7744,  7921,  
>> 8100,  8281,  8464,  8649,  8836,  9025,
>> + 9216,  9409,  9604,  9801, 1, 10201, 10404, 10609, 10816, 11025, 
>> 11236, 11449, 11664, 11881, 12100, 12321,
>> +12544, 12769, 12996, 13225, 13456, 13689, 13924, 14161, 14400, 14641, 
>> 14884, 15129, 15376, 15625, 15876, 16129,
>> +16384, 16641, 16900, 17161, 17424, 17689, 17956, 18225, 18496, 18769, 
>> 19044, 19321, 19600, 19881, 20164, 20449,
>> +20736, 21025, 21316, 21609, 21904, 22201, 22500, 22801, 23104, 23409, 
>> 23716, 24025, 24336, 24649, 24964, 25281,
>

Re: [FFmpeg-devel] [PATCH v4 2/7] lavf/rtp: replace linked list with array

[Muhammad Faiz]

On Sat, Feb 3, 2018 at 2:44 AM, Josh de Kock  wrote:
> ---
>  libavformat/allformats.c |   4 --
>  libavformat/rdt.c|   9 +---
>  libavformat/rdt.h|   5 --
>  libavformat/rtpdec.c | 138 
> ++-
>  libavformat/rtpdec.h |  25 +++--
>  5 files changed, 100 insertions(+), 81 deletions(-)
>
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index ec84096..83ed766 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -282,10 +282,6 @@ static void register_all(void)
>  REGISTER_DEMUXER (SDR2, sdr2);
>  REGISTER_DEMUXER (SDS,  sds);
>  REGISTER_DEMUXER (SDX,  sdx);
> -#if CONFIG_RTPDEC
> -ff_register_rtp_dynamic_payload_handlers();
> -ff_register_rdt_dynamic_payload_handlers();
> -#endif
>  REGISTER_DEMUXER (SEGAFILM, segafilm);
>  REGISTER_MUXER   (SEGMENT,  segment);
>  REGISTER_MUXER   (SEGMENT,  stream_segment);
> diff --git a/libavformat/rdt.c b/libavformat/rdt.c
> index b69827f..31a32ff 100644
> --- a/libavformat/rdt.c
> +++ b/libavformat/rdt.c
> @@ -554,7 +554,7 @@ rdt_close_context (PayloadContext *rdt)
>  }
>
>  #define RDT_HANDLER(n, s, t) \
> -static RTPDynamicProtocolHandler rdt_ ## n ## _handler = { \
> +RTPDynamicProtocolHandler ff_rdt_ ## n ## _handler = { \
>  .enc_name = s, \
>  .codec_type   = t, \
>  .codec_id = AV_CODEC_ID_NONE, \
> @@ -570,10 +570,3 @@ RDT_HANDLER(live_audio, "x-pn-multirate-realaudio-live", 
> AVMEDIA_TYPE_AUDIO);
>  RDT_HANDLER(video,  "x-pn-realvideo",AVMEDIA_TYPE_VIDEO);
>  RDT_HANDLER(audio,  "x-pn-realaudio",AVMEDIA_TYPE_AUDIO);
>
> -void ff_register_rdt_dynamic_payload_handlers(void)
> -{
> -ff_register_dynamic_payload_handler(_video_handler);
> -ff_register_dynamic_payload_handler(_audio_handler);
> -ff_register_dynamic_payload_handler(_live_video_handler);
> -ff_register_dynamic_payload_handler(_live_audio_handler);
> -}
> diff --git a/libavformat/rdt.h b/libavformat/rdt.h
> index ce6026f..2480565 100644
> --- a/libavformat/rdt.h
> +++ b/libavformat/rdt.h
> @@ -60,11 +60,6 @@ void ff_rdt_calc_response_and_checksum(char response[41], 
> char chksum[9],
> const char *challenge);
>
>  /**
> - * Register RDT-related dynamic payload handlers with our cache.
> - */
> -void ff_register_rdt_dynamic_payload_handlers(void);
> -
> -/**
>   * Add subscription information to Subscribe parameter string.
>   *
>   * @param cmd string to write the subscription information into.
> diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
> index 4acb1ca..6499e27 100644
> --- a/libavformat/rtpdec.c
> +++ b/libavformat/rtpdec.c
> @@ -69,88 +69,104 @@ static RTPDynamicProtocolHandler t140_dynamic_handler = 
> { /* RFC 4103 */
>  .codec_id   = AV_CODEC_ID_TEXT,
>  };
>
> -static RTPDynamicProtocolHandler *rtp_first_dynamic_payload_handler = NULL;
> +extern RTPDynamicProtocolHandler ff_rdt_video_handler;
> +extern RTPDynamicProtocolHandler ff_rdt_audio_handler;
> +extern RTPDynamicProtocolHandler ff_rdt_live_video_handler;
> +extern RTPDynamicProtocolHandler ff_rdt_live_audio_handler;
> +
> +static const RTPDynamicProtocolHandler *rtp_dynamic_protocol_handler_list[] 
> = {
> +/* rtp */
> +_ac3_dynamic_handler,
> +_amr_nb_dynamic_handler,
> +_amr_wb_dynamic_handler,
> +_dv_dynamic_handler,
> +_g726_16_dynamic_handler,
> +_g726_24_dynamic_handler,
> +_g726_32_dynamic_handler,
> +_g726_40_dynamic_handler,
> +_g726le_16_dynamic_handler,
> +_g726le_24_dynamic_handler,
> +_g726le_32_dynamic_handler,
> +_g726le_40_dynamic_handler,
> +_h261_dynamic_handler,
> +_h263_1998_dynamic_handler,
> +_h263_2000_dynamic_handler,
> +_h263_rfc2190_dynamic_handler,
> +_h264_dynamic_handler,
> +_hevc_dynamic_handler,
> +_ilbc_dynamic_handler,
> +_jpeg_dynamic_handler,
> +_mp4a_latm_dynamic_handler,
> +_mp4v_es_dynamic_handler,
> +_mpeg_audio_dynamic_handler,
> +_mpeg_audio_robust_dynamic_handler,
> +_mpeg_video_dynamic_handler,
> +_mpeg4_generic_dynamic_handler,
> +_mpegts_dynamic_handler,
> +_ms_rtp_asf_pfa_handler,
> +_ms_rtp_asf_pfv_handler,
> +_qcelp_dynamic_handler,
> +_qdm2_dynamic_handler,
> +_qt_rtp_aud_handler,
> +_qt_rtp_vid_handler,
> +_quicktime_rtp_aud_handler,
> +_quicktime_rtp_vid_handler,
> +_rfc4175_rtp_handler,
> +_svq3_dynamic_handler,
> +_theora_dynamic_handler,
> +_vc2hq_dynamic_handler,
> +_vorbis_dynamic_handler,
> +_vp8_dynamic_handler,
> +_vp9_dynamic_handler,
> +_dynamic_handler,
> +_dynamic_handler,
> +_dynamic_handler,
> +_mp3_dynamic_handler,
> +_dynamic_handler,
> +_dynamic_handler,
> +/* rdt */
> +_rdt_video_handler,
> +

Re: [FFmpeg-devel] [PATCH] avfilter/af_loudnorm: correctly initialize PTS

[Muhammad Faiz]

On Sun, Feb 4, 2018 at 3:32 PM, Paul B Mahol <one...@gmail.com> wrote:
> On 2/4/18, Muhammad Faiz <mfc...@gmail.com> wrote:
>> On Sat, Feb 3, 2018 at 9:22 PM, Niklas Haas <ffm...@haasn.xyz> wrote:
>>> From: Niklas Haas <g...@haasn.xyz>
>>>
>>> Right now, the PTS always starts out as 0, which causes problems on a
>>> seek or when inserting this filter mid-stream.
>>>
>>> Initialize it instead to AV_NOPTS_VALUE and copy the PTS from the first
>>> frame instead if this is the case.
>>> ---
>>>  libavfilter/af_loudnorm.c | 5 -
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavfilter/af_loudnorm.c b/libavfilter/af_loudnorm.c
>>> index a7f11cbe6e..314b25fa39 100644
>>> --- a/libavfilter/af_loudnorm.c
>>> +++ b/libavfilter/af_loudnorm.c
>>> @@ -431,6 +431,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
>>> *in)
>>>  av_frame_copy_props(out, in);
>>>  }
>>>
>>> +if (s->pts == AV_NOPTS_VALUE)
>>> +s->pts = in->pts;
>>> +
>>>  out->pts = s->pts;
>>>  src = (const double *)in->data[0];
>>>  dst = (double *)out->data[0];
>>> @@ -763,7 +766,7 @@ static int config_input(AVFilterLink *inlink)
>>>  inlink->partial_buf_size = frame_size(inlink->sample_rate, 3000);
>>>  }
>>>
>>> -s->pts =
>>> +s->pts = AV_NOPTS_VALUE;
>>>  s->buf_index =
>>>  s->prev_buf_index =
>>>  s->limiter_buf_index = 0;
>>> --
>>> 2.16.1
>>
>> Output pts ideally should be based on input pts in all cases
>> (not only in the first pts case), because input pts may be non-monotonic.
>
> That have nothing to do with this patch.

Of course, if ideal fix isn't trivial, this fix is enough.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/me_cmp: remove ff_me_cmp_init_static()

[Muhammad Faiz]

On Sun, Feb 4, 2018 at 9:26 AM, James Almer <jamr...@gmail.com> wrote:
> On 2/3/2018 7:51 PM, Muhammad Faiz wrote:
>> Precalculate and constify ff_square_tab.
>>
>> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>> ---
>>  libavcodec/me_cmp.c  | 51 
>> +---
>>  libavcodec/me_cmp.h  |  4 +---
>>  libavcodec/mpegvideo_enc.c   |  2 +-
>>  libavcodec/mpegvideoencdsp.c |  2 +-
>>  libavcodec/snowenc.c |  2 +-
>>  libavcodec/utils.c   | 13 ---
>>  6 files changed, 43 insertions(+), 31 deletions(-)
>>
>> diff --git a/libavcodec/me_cmp.c b/libavcodec/me_cmp.c
>> index 5e34a11593..67a5bb5c71 100644
>> --- a/libavcodec/me_cmp.c
>> +++ b/libavcodec/me_cmp.c
>> @@ -22,6 +22,7 @@
>>
>>  #include "libavutil/attributes.h"
>>  #include "libavutil/internal.h"
>> +#include "libavutil/thread.h"
>
> Unused?

Fixed locally.

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

Re: [FFmpeg-devel] [PATCH] avfilter/af_loudnorm: correctly initialize PTS

[Muhammad Faiz]

On Sat, Feb 3, 2018 at 9:22 PM, Niklas Haas  wrote:
> From: Niklas Haas 
>
> Right now, the PTS always starts out as 0, which causes problems on a
> seek or when inserting this filter mid-stream.
>
> Initialize it instead to AV_NOPTS_VALUE and copy the PTS from the first
> frame instead if this is the case.
> ---
>  libavfilter/af_loudnorm.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/af_loudnorm.c b/libavfilter/af_loudnorm.c
> index a7f11cbe6e..314b25fa39 100644
> --- a/libavfilter/af_loudnorm.c
> +++ b/libavfilter/af_loudnorm.c
> @@ -431,6 +431,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>  av_frame_copy_props(out, in);
>  }
>
> +if (s->pts == AV_NOPTS_VALUE)
> +s->pts = in->pts;
> +
>  out->pts = s->pts;
>  src = (const double *)in->data[0];
>  dst = (double *)out->data[0];
> @@ -763,7 +766,7 @@ static int config_input(AVFilterLink *inlink)
>  inlink->partial_buf_size = frame_size(inlink->sample_rate, 3000);
>  }
>
> -s->pts =
> +s->pts = AV_NOPTS_VALUE;
>  s->buf_index =
>  s->prev_buf_index =
>  s->limiter_buf_index = 0;
> --
> 2.16.1

Output pts ideally should be based on input pts in all cases
(not only in the first pts case), because input pts may be non-monotonic.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: do not use init_static_data on some codecs

[Muhammad Faiz]

On Sat, Feb 3, 2018 at 9:29 AM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Sat, Feb 03, 2018 at 01:36:37AM +0700, Muhammad Faiz wrote:
>> They don't modify AVCodec, no needs to call it at register. They will be
>> wasteful if these codecs are unused. Instead, call static data initialization
>> at codecs' init.
>>
>> Benchmark:
>> old: 51281340 decicycles in avcodec_register_all,   1 runs,  0 skips
>> new:  6738960 decicycles in avcodec_register_all,   1 runs,  0 skips
>>
>> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>> ---
>>  libavcodec/jpeg2000dec.c | 16 +---
>>  libavcodec/qdmc.c|  7 +--
>>  libavcodec/wmavoice.c|  7 +--
>>  3 files changed, 19 insertions(+), 11 deletions(-)
>
> LGTM

Applied.

>
> it would be better though if this would happen for all
> init_static_data() without the need for extra code per codec

As wm4 explained.

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

Re: [FFmpeg-devel] [PATCH v4 7/7] lavc/bsf: make BSF iteration the same as other iterators

[Muhammad Faiz]

On Sat, Feb 3, 2018 at 5:39 PM, wm4  wrote:
> On Fri,  2 Feb 2018 19:44:18 +
> Josh de Kock  wrote:
>
>> ---
>>  fftools/cmdutils.c |  2 +-
>>  libavcodec/avcodec.h   |  6 +-
>>  libavcodec/bitstream_filter.c  |  4 ++--
>>  libavcodec/bitstream_filters.c | 29 ++---
>>  4 files changed, 26 insertions(+), 15 deletions(-)
>>
>> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
>> index 9ecc51b..0b06ccc 100644
>> --- a/fftools/cmdutils.c
>> +++ b/fftools/cmdutils.c
>> @@ -1586,7 +1586,7 @@ int show_bsfs(void *optctx, const char *opt, const 
>> char *arg)
>>  void *opaque = NULL;
>>
>>  printf("Bitstream filters:\n");
>> -while ((bsf = av_bsf_next()))
>> +while ((bsf = av_bsf_iterate()))
>>  printf("%s\n", bsf->name);
>>  printf("\n");
>>  return 0;
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 99f5fb9..c41779a 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -5728,7 +5728,7 @@ attribute_deprecated
>>  void av_bitstream_filter_close(AVBitStreamFilterContext *bsf);
>>  /**
>>   * @deprecated the old bitstream filtering API (using 
>> AVBitStreamFilterContext)
>> - * is deprecated. Use av_bsf_next() from the new bitstream filtering API 
>> (using
>> + * is deprecated. Use av_bsf_iterate() from the new bitstream filtering API 
>> (using
>>   * AVBSFContext).
>>   */
>>  attribute_deprecated
>> @@ -5750,7 +5750,11 @@ const AVBitStreamFilter *av_bsf_get_by_name(const 
>> char *name);
>>   * @return the next registered bitstream filter or NULL when the iteration 
>> is
>>   * finished
>>   */
>> +const AVBitStreamFilter *av_bsf_iterate(void **opaque);
>> +#if FF_API_NEXT
>> +attribute_deprecated
>>  const AVBitStreamFilter *av_bsf_next(void **opaque);
>> +#endif
>>
>>  /**
>>   * Allocate a context for a given bitstream filter. The caller must fill in 
>> the
>> diff --git a/libavcodec/bitstream_filter.c b/libavcodec/bitstream_filter.c
>> index ed1cf33..ca11ed3 100644
>> --- a/libavcodec/bitstream_filter.c
>> +++ b/libavcodec/bitstream_filter.c
>> @@ -34,9 +34,9 @@ const AVBitStreamFilter *av_bitstream_filter_next(const 
>> AVBitStreamFilter *f)
>>  void *opaque = NULL;
>>
>>  while (filter != f)
>> -filter = av_bsf_next();
>> +filter = av_bsf_iterate();
>>
>> -return av_bsf_next();
>> +return av_bsf_iterate();
>>  }
>>
>>  void av_register_bitstream_filter(AVBitStreamFilter *bsf)
>> diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
>> index 7b0cb50..338ef82 100644
>> --- a/libavcodec/bitstream_filters.c
>> +++ b/libavcodec/bitstream_filters.c
>> @@ -52,7 +52,7 @@ extern const AVBitStreamFilter ff_vp9_superframe_split_bsf;
>>
>>  #include "libavcodec/bsf_list.c"
>>
>> -const AVBitStreamFilter *av_bsf_next(void **opaque)
>> +const AVBitStreamFilter *av_bsf_iterate(void **opaque)
>>  {
>>  uintptr_t i = (uintptr_t)*opaque;
>>  const AVBitStreamFilter *f = bitstream_filters[i];
>> @@ -63,12 +63,18 @@ const AVBitStreamFilter *av_bsf_next(void **opaque)
>>  return f;
>>  }
>>
>> +#if FF_API_NEXT
>> +const AVBitStreamFilter *av_bsf_next(void **opaque) {
>> +return av_bsf_iterate(opaque);
>> +}
>> +#endif
>> +
>>  const AVBitStreamFilter *av_bsf_get_by_name(const char *name)
>>  {
>> -int i;
>> +const AVBitStreamFilter *f = NULL;
>> +void *i = 0;
>>
>> -for (i = 0; bitstream_filters[i]; i++) {
>> -const AVBitStreamFilter *f = bitstream_filters[i];
>> +while ((f = av_bsf_iterate())) {
>>  if (!strcmp(f->name, name))
>>  return f;
>>  }
>> @@ -78,19 +84,20 @@ const AVBitStreamFilter *av_bsf_get_by_name(const char 
>> *name)
>>
>>  const AVClass *ff_bsf_child_class_next(const AVClass *prev)
>>  {
>> -int i;
>> +const AVBitStreamFilter *f = NULL;
>> +void *i = 0;
>>
>>  /* find the filter that corresponds to prev */
>> -for (i = 0; prev && bitstream_filters[i]; i++) {
>> -if (bitstream_filters[i]->priv_class == prev) {
>> -i++;
>> +while (prev && (f = av_bsf_iterate())) {
>> +if (f->priv_class == prev) {
>>  break;
>>  }
>>  }
>>
>>  /* find next filter with priv options */
>> -for (; bitstream_filters[i]; i++)
>> -if (bitstream_filters[i]->priv_class)
>> -return bitstream_filters[i]->priv_class;
>> +while ((f = av_bsf_iterate())) {
>> +if (f->priv_class)
>> +return f->priv_class;
>> +}
>>  return NULL;
>>  }
>
> I like _next better than _iterate (as others have also said), but I
> think I can tolerate it. At least it'll be consistent across all those
> APIs.

What about av*iterate(int index)?
As you suggested in
https://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/224702.html

Anyway av_bsf_iterate() previously didn't exist, so we can freely
choose how it will be called (with int index 

[FFmpeg-devel] [PATCH] avcodec/me_cmp: remove ff_me_cmp_init_static()

[Muhammad Faiz]

Precalculate and constify ff_square_tab.

Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
---
 libavcodec/me_cmp.c  | 51 +---
 libavcodec/me_cmp.h  |  4 +---
 libavcodec/mpegvideo_enc.c   |  2 +-
 libavcodec/mpegvideoencdsp.c |  2 +-
 libavcodec/snowenc.c |  2 +-
 libavcodec/utils.c   | 13 ---
 6 files changed, 43 insertions(+), 31 deletions(-)

diff --git a/libavcodec/me_cmp.c b/libavcodec/me_cmp.c
index 5e34a11593..67a5bb5c71 100644
--- a/libavcodec/me_cmp.c
+++ b/libavcodec/me_cmp.c
@@ -22,6 +22,7 @@
 
 #include "libavutil/attributes.h"
 #include "libavutil/internal.h"
+#include "libavutil/thread.h"
 #include "avcodec.h"
 #include "copy_block.h"
 #include "simple_idct.h"
@@ -29,13 +30,47 @@
 #include "mpegvideo.h"
 #include "config.h"
 
-uint32_t ff_square_tab[512] = { 0, };
+/* (i - 256) * (i - 256) */
+const uint32_t ff_square_tab[512] = {
+65536, 65025, 64516, 64009, 63504, 63001, 62500, 62001, 61504, 61009, 
60516, 60025, 59536, 59049, 58564, 58081,
+57600, 57121, 56644, 56169, 55696, 55225, 54756, 54289, 53824, 53361, 
52900, 52441, 51984, 51529, 51076, 50625,
+50176, 49729, 49284, 48841, 48400, 47961, 47524, 47089, 46656, 46225, 
45796, 45369, 44944, 44521, 44100, 43681,
+43264, 42849, 42436, 42025, 41616, 41209, 40804, 40401, 4, 39601, 
39204, 38809, 38416, 38025, 37636, 37249,
+36864, 36481, 36100, 35721, 35344, 34969, 34596, 34225, 33856, 33489, 
33124, 32761, 32400, 32041, 31684, 31329,
+30976, 30625, 30276, 29929, 29584, 29241, 28900, 28561, 28224, 27889, 
27556, 27225, 26896, 26569, 26244, 25921,
+25600, 25281, 24964, 24649, 24336, 24025, 23716, 23409, 23104, 22801, 
22500, 22201, 21904, 21609, 21316, 21025,
+20736, 20449, 20164, 19881, 19600, 19321, 19044, 18769, 18496, 18225, 
17956, 17689, 17424, 17161, 16900, 16641,
+16384, 16129, 15876, 15625, 15376, 15129, 14884, 14641, 14400, 14161, 
13924, 13689, 13456, 13225, 12996, 12769,
+12544, 12321, 12100, 11881, 11664, 11449, 11236, 11025, 10816, 10609, 
10404, 10201, 1,  9801,  9604,  9409,
+ 9216,  9025,  8836,  8649,  8464,  8281,  8100,  7921,  7744,  7569,  
7396,  7225,  7056,  6889,  6724,  6561,
+ 6400,  6241,  6084,  5929,  5776,  5625,  5476,  5329,  5184,  5041,  
4900,  4761,  4624,  4489,  4356,  4225,
+ 4096,  3969,  3844,  3721,  3600,  3481,  3364,  3249,  3136,  3025,  
2916,  2809,  2704,  2601,  2500,  2401,
+ 2304,  2209,  2116,  2025,  1936,  1849,  1764,  1681,  1600,  1521,  
1444,  1369,  1296,  1225,  1156,  1089,
+ 1024,   961,   900,   841,   784,   729,   676,   625,   576,   529,   
484,   441,   400,   361,   324,   289,
+  256,   225,   196,   169,   144,   121,   100,81,64,49,
36,25,16, 9, 4, 1,
+0, 1, 4, 9,16,25,36,49,64,81,   
100,   121,   144,   169,   196,   225,
+  256,   289,   324,   361,   400,   441,   484,   529,   576,   625,   
676,   729,   784,   841,   900,   961,
+ 1024,  1089,  1156,  1225,  1296,  1369,  1444,  1521,  1600,  1681,  
1764,  1849,  1936,  2025,  2116,  2209,
+ 2304,  2401,  2500,  2601,  2704,  2809,  2916,  3025,  3136,  3249,  
3364,  3481,  3600,  3721,  3844,  3969,
+ 4096,  4225,  4356,  4489,  4624,  4761,  4900,  5041,  5184,  5329,  
5476,  5625,  5776,  5929,  6084,  6241,
+ 6400,  6561,  6724,  6889,  7056,  7225,  7396,  7569,  7744,  7921,  
8100,  8281,  8464,  8649,  8836,  9025,
+ 9216,  9409,  9604,  9801, 1, 10201, 10404, 10609, 10816, 11025, 
11236, 11449, 11664, 11881, 12100, 12321,
+12544, 12769, 12996, 13225, 13456, 13689, 13924, 14161, 14400, 14641, 
14884, 15129, 15376, 15625, 15876, 16129,
+16384, 16641, 16900, 17161, 17424, 17689, 17956, 18225, 18496, 18769, 
19044, 19321, 19600, 19881, 20164, 20449,
+20736, 21025, 21316, 21609, 21904, 22201, 22500, 22801, 23104, 23409, 
23716, 24025, 24336, 24649, 24964, 25281,
+25600, 25921, 26244, 26569, 26896, 27225, 27556, 27889, 28224, 28561, 
28900, 29241, 29584, 29929, 30276, 30625,
+30976, 31329, 31684, 32041, 32400, 32761, 33124, 33489, 33856, 34225, 
34596, 34969, 35344, 35721, 36100, 36481,
+36864, 37249, 37636, 38025, 38416, 38809, 39204, 39601, 4, 40401, 
40804, 41209, 41616, 42025, 42436, 42849,
+43264, 43681, 44100, 44521, 44944, 45369, 45796, 46225, 46656, 47089, 
47524, 47961, 48400, 48841, 49284, 49729,
+50176, 50625, 51076, 51529, 51984, 52441, 52900, 53361, 53824, 54289, 
54756, 55225, 55696, 56169, 56644, 57121,
+57600, 58081, 58564, 59049, 59536, 60025, 60516, 61009, 61504, 62001, 
62500, 63001, 63504, 64009, 64516, 65025,
+};
 
 static int sse4_c(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2,
   ptrdiff_t stride, int h)
 {
 int s = 0, i;
-uint32_t *sq = ff_square_tab + 256;
+const uint32_

Re: [FFmpeg-devel] [PATCH v3 1/6] lavc: add new API for iterating codecs and codec parsers

[Muhammad Faiz]

On Sat, Feb 3, 2018 at 6:34 AM, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> Am 02.02.2018 11:58 nachm. schrieb "Muhammad Faiz" <mfc...@gmail.com>:
>
> On Sat, Feb 3, 2018 at 1:55 AM, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
>> On Fri, Feb 2, 2018 at 7:49 PM, Muhammad Faiz <mfc...@gmail.com> wrote:
>>> On Fri, Feb 2, 2018 at 10:23 PM, Josh de Kock <j...@itanimul.li> wrote:
>>>>
>>>>> On 1 Feb 2018, at 18:51, Muhammad Faiz <mfc...@gmail.com> wrote:
>>>>>
>>>>>> On Thu, Feb 1, 2018 at 3:25 AM, Josh de Kock <j...@itanimul.li> wrote:
>>>>>> Also replace linked list with an array.
>>>>>> ---
>>>>>> configure  |   12 +-
>>>>>> doc/APIchanges |4 +
>>>>>> libavcodec/.gitignore  |2 +
>>>>>> libavcodec/allcodecs.c | 1473 --
> --
>>>>>> libavcodec/avcodec.h   |   31 +
>>>>>> libavcodec/parser.c|   84 ++-
>>>>>> libavcodec/utils.c |  112 
>>>>>> libavcodec/version.h   |3 +
>>>>>> 8 files changed, 971 insertions(+), 750 deletions(-)
>>>>>>
>>>>>
>>>>> I have a plan to sort codecs based on name and codec_id (which overlap
>>>>> with this patch). Is it OK if I overtake this?
>>>>> If it is not OK, I will wait until this patchset pushed.
>>>>>
>>>>
>>>> I am unsure why you would need to sort codecs.
>>>
>>> For performance reason.
>>
>> Performance of what?
>
> avcodec_find_decoder/encoder (by using bsearch).
>
>
> Considering you can have multiple of those for any given codec Id and order
> matters, that seems like a risky idea, or a rather complex one at least.
> Perhaps not the first (or second) place to start optimization.

I've thought about it.

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

Re: [FFmpeg-devel] [PATCH v3 1/6] lavc: add new API for iterating codecs and codec parsers

[Muhammad Faiz]

On Sat, Feb 3, 2018 at 1:55 AM, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Fri, Feb 2, 2018 at 7:49 PM, Muhammad Faiz <mfc...@gmail.com> wrote:
>> On Fri, Feb 2, 2018 at 10:23 PM, Josh de Kock <j...@itanimul.li> wrote:
>>>
>>>> On 1 Feb 2018, at 18:51, Muhammad Faiz <mfc...@gmail.com> wrote:
>>>>
>>>>> On Thu, Feb 1, 2018 at 3:25 AM, Josh de Kock <j...@itanimul.li> wrote:
>>>>> Also replace linked list with an array.
>>>>> ---
>>>>> configure  |   12 +-
>>>>> doc/APIchanges |4 +
>>>>> libavcodec/.gitignore  |2 +
>>>>> libavcodec/allcodecs.c | 1473 
>>>>> 
>>>>> libavcodec/avcodec.h   |   31 +
>>>>> libavcodec/parser.c|   84 ++-
>>>>> libavcodec/utils.c |  112 
>>>>> libavcodec/version.h   |3 +
>>>>> 8 files changed, 971 insertions(+), 750 deletions(-)
>>>>>
>>>>
>>>> I have a plan to sort codecs based on name and codec_id (which overlap
>>>> with this patch). Is it OK if I overtake this?
>>>> If it is not OK, I will wait until this patchset pushed.
>>>>
>>>
>>> I am unsure why you would need to sort codecs.
>>
>> For performance reason.
>
> Performance of what?

avcodec_find_decoder/encoder (by using bsearch).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 1/6] lavc: add new API for iterating codecs and codec parsers

[Muhammad Faiz]

On Fri, Feb 2, 2018 at 10:23 PM, Josh de Kock <j...@itanimul.li> wrote:
>
>> On 1 Feb 2018, at 18:51, Muhammad Faiz <mfc...@gmail.com> wrote:
>>
>>> On Thu, Feb 1, 2018 at 3:25 AM, Josh de Kock <j...@itanimul.li> wrote:
>>> Also replace linked list with an array.
>>> ---
>>> configure  |   12 +-
>>> doc/APIchanges |4 +
>>> libavcodec/.gitignore  |2 +
>>> libavcodec/allcodecs.c | 1473 
>>> 
>>> libavcodec/avcodec.h   |   31 +
>>> libavcodec/parser.c|   84 ++-
>>> libavcodec/utils.c |  112 
>>> libavcodec/version.h   |3 +
>>> 8 files changed, 971 insertions(+), 750 deletions(-)
>>>
>>
>> I have a plan to sort codecs based on name and codec_id (which overlap
>> with this patch). Is it OK if I overtake this?
>> If it is not OK, I will wait until this patchset pushed.
>>
>
> I am unsure why you would need to sort codecs.

For performance reason.

>The point of my patches is to bring 
> the rest of ffmpeg up to the bsf iteration api (which abstracts internals 
> away from the user). I planned on doing lavfi as well, but how the build 
> system worked with filter names made it awkward. Hence me submitting these 
> patches without a lavfi counterpart (I stills haven’t worked out the best way 
> to do it yet). The way you’ve done your static initialisation of lavfi seems 
> like a backwards way to do it, and would make overalls consistency difficult 
> (something quite desirable, which my patches work towards).

Imho, av*iterate things are less elegant than av*next. But, the change
actually is not based on elegance, but based on performance (av*next
requires initialization of next pointer).

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

Re: [FFmpeg-devel] [PATCH v2] avfilter: sort filter list

[Muhammad Faiz]

On Fri, Feb 2, 2018 at 5:36 PM, Nicolas George <geo...@nsup.org> wrote:
> Muhammad Faiz (2018-02-02):
>> Move REGISTER_FILTER to FILTER_TABLE in configure.
>> Replace linked list with static table, and sort it.
>> Use bsearch() on avfilter_get_by_name().
>> Deprecate avfilter_register_all(), avfilter_register(), and
>> avfilter_next().
>> Add avfilter_iterate() as a replacement for avfilter_next().
>
> I'll be explicit: unless discussed otherwise, I oppose this patch as
> long as it is not part of a series that applies the same treatment to
> all components (codecs, parsers, formats).

Yeah, probably no needs to rush on this.

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

[FFmpeg-devel] [PATCH] avcodec: do not use init_static_data on some codecs

[Muhammad Faiz]

They don't modify AVCodec, no needs to call it at register. They will be
wasteful if these codecs are unused. Instead, call static data initialization
at codecs' init.

Benchmark:
old: 51281340 decicycles in avcodec_register_all,   1 runs,  0 skips
new:  6738960 decicycles in avcodec_register_all,   1 runs,  0 skips

Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
---
 libavcodec/jpeg2000dec.c | 16 +---
 libavcodec/qdmc.c|  7 +--
 libavcodec/wmavoice.c|  7 +--
 3 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 01fe4b3949..4cf8a2880c 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -34,6 +34,7 @@
 #include "libavutil/imgutils.h"
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
+#include "libavutil/thread.h"
 #include "avcodec.h"
 #include "bytestream.h"
 #include "internal.h"
@@ -2142,10 +2143,18 @@ static int jp2_find_codestream(Jpeg2000DecoderContext 
*s)
 return 0;
 }
 
+static av_cold void jpeg2000_init_static_data(void)
+{
+ff_jpeg2000_init_tier1_luts();
+ff_mqc_init_context_tables();
+}
+
 static av_cold int jpeg2000_decode_init(AVCodecContext *avctx)
 {
+static AVOnce init_static_once = AV_ONCE_INIT;
 Jpeg2000DecoderContext *s = avctx->priv_data;
 
+ff_thread_once(_static_once, jpeg2000_init_static_data);
 ff_jpeg2000dsp_init(>dsp);
 
 return 0;
@@ -2223,12 +2232,6 @@ end:
 return ret;
 }
 
-static av_cold void jpeg2000_init_static_data(AVCodec *codec)
-{
-ff_jpeg2000_init_tier1_luts();
-ff_mqc_init_context_tables();
-}
-
 #define OFFSET(x) offsetof(Jpeg2000DecoderContext, x)
 #define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
 
@@ -2252,7 +2255,6 @@ AVCodec ff_jpeg2000_decoder = {
 .id   = AV_CODEC_ID_JPEG2000,
 .capabilities = AV_CODEC_CAP_SLICE_THREADS | 
AV_CODEC_CAP_FRAME_THREADS | AV_CODEC_CAP_DR1,
 .priv_data_size   = sizeof(Jpeg2000DecoderContext),
-.init_static_data = jpeg2000_init_static_data,
 .init = jpeg2000_decode_init,
 .decode   = jpeg2000_decode_frame,
 .priv_class   = _class,
diff --git a/libavcodec/qdmc.c b/libavcodec/qdmc.c
index 1c8952b97b..f1f86accd8 100644
--- a/libavcodec/qdmc.c
+++ b/libavcodec/qdmc.c
@@ -26,6 +26,7 @@
 #define BITSTREAM_READER_LE
 
 #include "libavutil/channel_layout.h"
+#include "libavutil/thread.h"
 
 #include "avcodec.h"
 #include "bytestream.h"
@@ -204,7 +205,7 @@ static const uint8_t phase_diff_codes[] = {
INIT_VLC_LE | INIT_VLC_USE_NEW_STATIC); \
 } while (0)
 
-static av_cold void qdmc_init_static_data(AVCodec *codec)
+static av_cold void qdmc_init_static_data(void)
 {
 int i;
 
@@ -250,10 +251,13 @@ static void make_noises(QDMCContext *s)
 
 static av_cold int qdmc_decode_init(AVCodecContext *avctx)
 {
+static AVOnce init_static_once = AV_ONCE_INIT;
 QDMCContext *s = avctx->priv_data;
 int fft_size, fft_order, size, g, j, x;
 GetByteContext b;
 
+ff_thread_once(_static_once, qdmc_init_static_data);
+
 if (!avctx->extradata || (avctx->extradata_size < 48)) {
 av_log(avctx, AV_LOG_ERROR, "extradata missing or truncated\n");
 return AVERROR_INVALIDDATA;
@@ -775,7 +779,6 @@ AVCodec ff_qdmc_decoder = {
 .id   = AV_CODEC_ID_QDMC,
 .priv_data_size   = sizeof(QDMCContext),
 .init = qdmc_decode_init,
-.init_static_data = qdmc_init_static_data,
 .close= qdmc_decode_close,
 .decode   = qdmc_decode_frame,
 .flush= qdmc_flush,
diff --git a/libavcodec/wmavoice.c b/libavcodec/wmavoice.c
index 3f86d0da35..444e303b0d 100644
--- a/libavcodec/wmavoice.c
+++ b/libavcodec/wmavoice.c
@@ -30,6 +30,7 @@
 #include "libavutil/channel_layout.h"
 #include "libavutil/float_dsp.h"
 #include "libavutil/mem.h"
+#include "libavutil/thread.h"
 #include "avcodec.h"
 #include "internal.h"
 #include "get_bits.h"
@@ -310,7 +311,7 @@ static av_cold int decode_vbmtree(GetBitContext *gb, int8_t 
vbm_tree[25])
 return 0;
 }
 
-static av_cold void wmavoice_init_static_data(AVCodec *codec)
+static av_cold void wmavoice_init_static_data(void)
 {
 static const uint8_t bits[] = {
  2,  2,  2,  4,  4,  4,
@@ -365,9 +366,12 @@ static av_cold void wmavoice_flush(AVCodecContext *ctx)
  */
 static av_cold int wmavoice_decode_init(AVCodecContext *ctx)
 {
+static AVOnce init_static_once = AV_ONCE_INIT;
 int n, flags, pitch_range, lsp16_flag;
 WMAVoiceContext *s = ctx->priv_data;
 
+ff_thread_once(_static_once, wmavoice_init_static_data);
+
 /**
  * Extradata layout:
  * - byte  0-18: WMAPro-in-WMAVoice extradat

[FFmpeg-devel] [PATCH] avcodec/codec_desc: sort codec_descriptors

[Muhammad Faiz]

Use bsearch on avcodec_descriptor_get().

Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
---
 libavcodec/codec_desc.c | 1103 ---
 1 file changed, 563 insertions(+), 540 deletions(-)

diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index c3688de1d6..1e5d715416 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -21,8 +21,10 @@
 
 #include 
 
+#include "libavutil/avassert.h"
 #include "libavutil/common.h"
 #include "libavutil/internal.h"
+#include "libavutil/thread.h"
 #include "avcodec.h"
 #include "profiles.h"
 #include "version.h"
@@ -90,6 +92,28 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
 },
 {
+.id= AV_CODEC_ID_LJPEG,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "ljpeg",
+.long_name = NULL_IF_CONFIG_SMALL("Lossless JPEG"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
+{
+.id= AV_CODEC_ID_SP5X,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "sp5x",
+.long_name = NULL_IF_CONFIG_SMALL("Sunplus JPEG (SP5X)"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
+},
+{
+.id= AV_CODEC_ID_JPEGLS,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "jpegls",
+.long_name = NULL_IF_CONFIG_SMALL("JPEG-LS"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY |
+ AV_CODEC_PROP_LOSSLESS,
+},
+{
 .id= AV_CODEC_ID_MPEG4,
 .type  = AVMEDIA_TYPE_VIDEO,
 .name  = "mpeg4",
@@ -161,14 +185,6 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .props = AV_CODEC_PROP_LOSSY,
 },
 {
-.id= AV_CODEC_ID_SVG,
-.type  = AVMEDIA_TYPE_VIDEO,
-.name  = "svg",
-.long_name = NULL_IF_CONFIG_SMALL("Scalable Vector Graphics"),
-.props = AV_CODEC_PROP_LOSSLESS,
-.mime_types= MT("image/svg+xml"),
-},
-{
 .id= AV_CODEC_ID_SVQ1,
 .type  = AVMEDIA_TYPE_VIDEO,
 .name  = "svq1",
@@ -408,13 +424,6 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .props = AV_CODEC_PROP_LOSSLESS,
 },
 {
-.id= AV_CODEC_ID_SNOW,
-.type  = AVMEDIA_TYPE_VIDEO,
-.name  = "snow",
-.long_name = NULL_IF_CONFIG_SMALL("Snow"),
-.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_LOSSLESS,
-},
-{
 .id= AV_CODEC_ID_TSCC,
 .type  = AVMEDIA_TYPE_VIDEO,
 .name  = "tscc",
@@ -450,6 +459,50 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .props = AV_CODEC_PROP_LOSSY,
 },
 {
+.id= AV_CODEC_ID_PNG,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "png",
+.long_name = NULL_IF_CONFIG_SMALL("PNG (Portable Network Graphics) 
image"),
+.props = AV_CODEC_PROP_LOSSLESS,
+.mime_types= MT("image/png"),
+},
+{
+.id= AV_CODEC_ID_PPM,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "ppm",
+.long_name = NULL_IF_CONFIG_SMALL("PPM (Portable PixelMap) image"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
+{
+.id= AV_CODEC_ID_PBM,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "pbm",
+.long_name = NULL_IF_CONFIG_SMALL("PBM (Portable BitMap) image"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
+{
+.id= AV_CODEC_ID_PGM,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "pgm",
+.long_name = NULL_IF_CONFIG_SMALL("PGM (Portable GrayMap) image"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
+{
+.id= AV_CODEC_ID_PGMYUV,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "pgmyuv",
+.long_name = NULL_IF_CONFIG_SMALL("PGMYUV (Portable GrayMap YUV) 
image"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
+{
+.id= AV_CODEC_ID_PAM,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "pam",
+.long_name = NULL_IF_CONFIG_SMALL("PAM (Portable AnyMap) image"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+.mime_types= MT("image/x-portable-pixmap"),
+},
+{
 .id= AV_CODE

[FFmpeg-devel] [PATCH v2] avfilter: sort filter list

[Muhammad Faiz]

Move REGISTER_FILTER to FILTER_TABLE in configure.
Replace linked list with static table, and sort it.
Use bsearch() on avfilter_get_by_name().
Deprecate avfilter_register_all(), avfilter_register(), and
avfilter_next().
Add avfilter_iterate() as a replacement for avfilter_next().

Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
---
 Makefile |   5 +-
 configure| 428 -
 doc/APIchanges   |   4 +
 libavfilter/allfilters.c | 441 ++-
 libavfilter/avfilter.c   |  65 ++-
 libavfilter/avfilter.h   |  20 ++-
 libavfilter/buffersink.c |   4 +-
 libavfilter/version.h|  10 +-
 tests/checkasm/Makefile  |   2 +-
 9 files changed, 532 insertions(+), 447 deletions(-)

diff --git a/Makefile b/Makefile
index 9defddebfd..6427abafb5 100644
--- a/Makefile
+++ b/Makefile
@@ -61,7 +61,7 @@ CONFIGURABLE_COMPONENTS = 
  \
 $(SRC_PATH)/libavformat/protocols.c \
 
 config.h: ffbuild/.config
-ffbuild/.config: $(CONFIGURABLE_COMPONENTS)
+ffbuild/.config: $(CONFIGURABLE_COMPONENTS) $(SRC_PATH)/configure
@-tput bold 2>/dev/null
@-printf '\nWARNING: $(?) newer than config.h, rerun configure\n\n'
@-tput sgr0 2>/dev/null
@@ -142,7 +142,8 @@ distclean:: clean
$(RM) .version avversion.h config.asm config.h mapfile  \
ffbuild/.config ffbuild/config.* libavutil/avconfig.h \
version.h libavutil/ffversion.h libavcodec/codec_names.h \
-   libavcodec/bsf_list.c libavformat/protocol_list.c
+   libavcodec/bsf_list.c libavformat/protocol_list.c \
+   libavfilter/filter_list.c
 ifeq ($(SRC_LINK),src)
$(RM) src
 endif
diff --git a/configure b/configure
index fcfa7aa442..a11798625e 100755
--- a/configure
+++ b/configure
@@ -3177,6 +3177,381 @@ unix_protocol_deps="sys_un_h"
 unix_protocol_select="network"
 
 # filters
+FILTER_TABLE="
+abench  af
+acompressor af
+acontrast   af
+acopy   af
+acrossfade  af
+acrusheraf
+adelay  af
+aecho   af
+aemphasis   af
+aeval   af
+afade   af
+afftfiltaf
+afiraf
+aformat af
+agate   af
+aiiraf
+ainterleave af
+alimiteraf
+allpass af
+aloop   af
+amerge  af
+ametadata   af
+amixaf
+anequalizer af
+anull   af
+apadaf
+aperms  af
+aphaser af
+apulsator   af
+arealtime   af
+aresample   af
+areverseaf
+aselect af
+asendcmdaf
+asetnsamplesaf
+asetpts af
+asetrateaf
+asettb  af
+ashowinfo   af
+asidedata   af
+asplit  af
+astats  af
+astreamselect   af
+atempo  af
+atrim   af
+azmqaf
+bandpassaf
+bandreject  af
+bassaf
+biquad  af
+bs2baf
+channelmap  af
+channelsplitaf
+chorus  af
+compand af
+compensationdelay   af
+crossfeed   af
+crystalizer af
+dcshift af
+dynaudnorm  af
+earwax  af
+ebur128 af
+equalizer   af
+extrastereo af
+firequalizeraf
+flanger af
+haasaf
+hdcdaf
+headphone   af
+highpassaf
+joinaf
+ladspa  af
+loudnormaf
+lowpass af
+lv2 af
+mcompandaf
+pan af
+replaygain  af
+resampleaf
+rubberband  af
+sidechaincompress   af
+sidechaingate   af
+silencedetect   af
+silenceremove   af
+sofalizer   af
+stereotools af
+stereowiden af
+superequalizer  af
+surroundaf
+treble  af
+tremolo af
+vibrato af
+volume  af
+volumedetectaf
+aevalsrcasrc
+anoisesrc   asrc
+anullsrcasrc
+flite   asrc
+hilbert asrc
+sineasrc
+anullsink   asink
+alphaextractvf
+alphamerge  vf
+ass vf

Re: [FFmpeg-devel] [PATCH v3 1/6] lavc: add new API for iterating codecs and codec parsers

[Muhammad Faiz]

On Thu, Feb 1, 2018 at 3:25 AM, Josh de Kock  wrote:
> Also replace linked list with an array.
> ---
>  configure  |   12 +-
>  doc/APIchanges |4 +
>  libavcodec/.gitignore  |2 +
>  libavcodec/allcodecs.c | 1473 
> 
>  libavcodec/avcodec.h   |   31 +
>  libavcodec/parser.c|   84 ++-
>  libavcodec/utils.c |  112 
>  libavcodec/version.h   |3 +
>  8 files changed, 971 insertions(+), 750 deletions(-)
>

I have a plan to sort codecs based on name and codec_id (which overlap
with this patch). Is it OK if I overtake this?
If it is not OK, I will wait until this patchset pushed.

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

Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

[Muhammad Faiz]

On Wed, Jan 31, 2018 at 7:03 PM, wm4  wrote:
> On Wed, 31 Jan 2018 11:52:14 +
> Mark Thompson  wrote:
>
>> >> On the other side, you get rid of a field in AVFilter and avoid having to 
>> >> put some pointless boilerplate in a lot of places.
>> >
>> > The other solution is to initialize next pointer on
>> > avfilter_register_all() as before,  add new iterate API, and deprecate
>> > both avfilter_register_all() and avfilter_next().
>>
>> I guess having thought about this further my problem is that you appear to 
>> be writing a lot of new infrastructure for creating and updating the next 
>> links (with special generation code in configure and extra boilerplate on 
>> every filter) when the feature does not have any clear value.  Once other 
>> functions are properly updated the only place where the next link is used is 
>> in avfilter_next(), which is only slowed down a little bit and would never 
>> be called in performance-sensitive code anyway.  A new iterate API would be 
>> welcome but is mostly orthogonal - you aren't going to call that in 
>> performance-sensitive code either.
>>
>> So, can we just drop the next links completely?
>
> Just as a comment on the side: if he changes that, I'd prefer of the
> next links are lazily initialized and only when using the old API. That
> would waste less memory (since writing the next link will trigger copy
> on write and in the worst case waste 4K (a page) per filter.
>
> (Personally I found the static next links rather neat, but yeah, maybe
> it's too much configure magic.)

I've posted a new patch
https://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/224787.html

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

Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

[Muhammad Faiz]

On Thu, Feb 1, 2018 at 5:03 PM, Nicolas George <geo...@nsup.org> wrote:
> Hi.
>
> Muhammad Faiz (2018-01-30):
>> Move REGISTER_FILTER to FILTER_TABLE in configure.
>> Auto generate filter extern and filter table.
>> Sort filter table, use bsearch on avfilter_get_by_name.
>> Define next pointer at filter extern, no need to initialize
>> next pointer at run time, so AVFilter can be set to const.
>> Make avfilter_register always return error.
>> Target checkasm now depends on EXTRALIBS-avformat.
>
> Regarding registering user filters, do not bother about that. That ship
> has sailed a long time ago; it is already more than half-way across and
> decelerating. If somebody wants to implement plugins, they will have a
> lot of work. Designing a way of registering user filters so that they
> can be parsed by name would be a spoonful in the pool.
>
> Regarding the actual implementation:
>
> I do not like that you moved the list into configure. Not per se, but
> because it is completely different from what Josh de Kock is doing with
> codecs, parsers and formats. Please coordinate with Josh to have a
> consistent solution for all components.

Actually I have a plan to sort codecs based on name and codec_id. And
it is difficult to sort based on codec_id with only extern declaration
in allcodecs.


>
> I think the fact that you need to insert a line in each filter is rather
> a sign that the design is far from perfect.

I remove it in my new patch.

>
> Regarding the efficiency of avfilter_next(), I think we should not care.
> Almost nobody uses that function outside lavfi anyway. If it proves a
> concern for some application, we can deal with it when it is found.


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

[FFmpeg-devel] [PATCH] avfilter: sort filter list

[Muhammad Faiz]

Move REGISTER_FILTER to FILTER_TABLE in configure.
Replace linked list with static table, and sort it.
Use bsearch() on avfilter_get_by_name().
Deprecate avfilter_register_all(), avfilter_register(), and
avfilter_next().
Add avfilter_iterate() as a replacement for avfilter_next().

Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
---
 Makefile |   5 +-
 configure| 428 -
 doc/APIchanges   |   4 +
 libavfilter/allfilters.c | 441 ++-
 libavfilter/avfilter.c   |  65 ++-
 libavfilter/avfilter.h   |  20 ++-
 libavfilter/buffersink.c |   4 +-
 libavfilter/version.h|  10 +-
 tests/checkasm/Makefile  |   2 +-
 9 files changed, 532 insertions(+), 447 deletions(-)

diff --git a/Makefile b/Makefile
index 9defddebfd..6427abafb5 100644
--- a/Makefile
+++ b/Makefile
@@ -61,7 +61,7 @@ CONFIGURABLE_COMPONENTS = 
  \
 $(SRC_PATH)/libavformat/protocols.c \
 
 config.h: ffbuild/.config
-ffbuild/.config: $(CONFIGURABLE_COMPONENTS)
+ffbuild/.config: $(CONFIGURABLE_COMPONENTS) $(SRC_PATH)/configure
@-tput bold 2>/dev/null
@-printf '\nWARNING: $(?) newer than config.h, rerun configure\n\n'
@-tput sgr0 2>/dev/null
@@ -142,7 +142,8 @@ distclean:: clean
$(RM) .version avversion.h config.asm config.h mapfile  \
ffbuild/.config ffbuild/config.* libavutil/avconfig.h \
version.h libavutil/ffversion.h libavcodec/codec_names.h \
-   libavcodec/bsf_list.c libavformat/protocol_list.c
+   libavcodec/bsf_list.c libavformat/protocol_list.c \
+   libavfilter/filter_list.c
 ifeq ($(SRC_LINK),src)
$(RM) src
 endif
diff --git a/configure b/configure
index fcfa7aa442..a11798625e 100755
--- a/configure
+++ b/configure
@@ -3177,6 +3177,381 @@ unix_protocol_deps="sys_un_h"
 unix_protocol_select="network"
 
 # filters
+FILTER_TABLE="
+abench  af
+acompressor af
+acontrast   af
+acopy   af
+acrossfade  af
+acrusheraf
+adelay  af
+aecho   af
+aemphasis   af
+aeval   af
+afade   af
+afftfiltaf
+afiraf
+aformat af
+agate   af
+aiiraf
+ainterleave af
+alimiteraf
+allpass af
+aloop   af
+amerge  af
+ametadata   af
+amixaf
+anequalizer af
+anull   af
+apadaf
+aperms  af
+aphaser af
+apulsator   af
+arealtime   af
+aresample   af
+areverseaf
+aselect af
+asendcmdaf
+asetnsamplesaf
+asetpts af
+asetrateaf
+asettb  af
+ashowinfo   af
+asidedata   af
+asplit  af
+astats  af
+astreamselect   af
+atempo  af
+atrim   af
+azmqaf
+bandpassaf
+bandreject  af
+bassaf
+biquad  af
+bs2baf
+channelmap  af
+channelsplitaf
+chorus  af
+compand af
+compensationdelay   af
+crossfeed   af
+crystalizer af
+dcshift af
+dynaudnorm  af
+earwax  af
+ebur128 af
+equalizer   af
+extrastereo af
+firequalizeraf
+flanger af
+haasaf
+hdcdaf
+headphone   af
+highpassaf
+joinaf
+ladspa  af
+loudnormaf
+lowpass af
+lv2 af
+mcompandaf
+pan af
+replaygain  af
+resampleaf
+rubberband  af
+sidechaincompress   af
+sidechaingate   af
+silencedetect   af
+silenceremove   af
+sofalizer   af
+stereotools af
+stereowiden af
+superequalizer  af
+surroundaf
+treble  af
+tremolo af
+vibrato af
+volume  af
+volumedetectaf
+aevalsrcasrc
+anoisesrc   asrc
+anullsrcasrc
+flite   asrc
+hilbert asrc
+sineasrc
+anullsink   asink
+alphaextractvf
+alphamerge  vf
+ass vf

Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

[Muhammad Faiz]

On Wed, Jan 31, 2018 at 5:26 AM, Mark Thompson <s...@jkqxz.net> wrote:
> On 30/01/18 18:06, Muhammad Faiz wrote:
>> On Tue, Jan 30, 2018 at 9:09 PM, Mark Thompson <s...@jkqxz.net> wrote:
>>> On 30/01/18 07:24, Muhammad Faiz wrote:
>>>> Move REGISTER_FILTER to FILTER_TABLE in configure.
>>>> Auto generate filter extern and filter table.
>>>> Sort filter table, use bsearch on avfilter_get_by_name.
>>>> Define next pointer at filter extern, no need to initialize
>>>> next pointer at run time, so AVFilter can be set to const.
>>>> Make avfilter_register always return error.
>>>> Target checkasm now depends on EXTRALIBS-avformat.
>>>>
>>>> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>>>> ---
>>>
>>> I like the idea of this, but I'm not sure about some of the implementation 
>>> details.
>>>
>>> Have you considered dropping the "next" links entirely and having just the 
>>> array of pointers instead?  I feel like they don't really add anything 
>>> useful once we are in this form, and result in more boilerplate on every 
>>> filter and some tricky generation code.
>>>
>>> avfilter_next() would be a bit slower (since it would have to search the 
>>> array, and therefore have runtime linear in the number of filters), but 
>>> avfilter_get_by_name() is a lot faster because of the binary search (and is 
>>> the only common use of it) so I don't think that complaint would be a 
>>> strong one.
>>
>> Making avfilter_next() slower (even if it is rarely used) isn't good, I 
>> think.
>
> I think the slowdown is irrelevant if it is rarely used.
>
> On the other side, you get rid of a field in AVFilter and avoid having to put 
> some pointless boilerplate in a lot of places.

The other solution is to initialize next pointer on
avfilter_register_all() as before,  add new iterate API, and deprecate
both avfilter_register_all() and avfilter_next().


>
> Related: the one remaining use of avfilter_next() inside lavfi, in 
> filter_child_class_next(), should also be replaced with array operations.  (I 
> can easily do that if you don't want to bother as part of this patch.)

Oh, I forgot it.


>
>>>
>>>>  Makefile   |   4 +-
>>>>  configure  | 440 
>>>> -
>>>> ...
>>>>  tests/checkasm/Makefile|   2 +-
>>>>  303 files changed, 1229 insertions(+), 796 deletions(-)
>>>>
>>>> diff --git a/Makefile b/Makefile
>>>> index 9defddebfd..f607579369 100644
>>>> --- a/Makefile
>>>> +++ b/Makefile
>>>> @@ -56,6 +56,7 @@ tools/uncoded_frame$(EXESUF): ELIBS = $(FF_EXTRALIBS)
>>>>  tools/target_dec_%_fuzzer$(EXESUF): $(FF_DEP_LIBS)
>>>>
>>>>  CONFIGURABLE_COMPONENTS =   \
>>>> +$(SRC_PATH)/configure   \
>>>>  $(wildcard $(FFLIBS:%=$(SRC_PATH)/lib%/all*.c)) \
>>>>  $(SRC_PATH)/libavcodec/bitstream_filters.c  \
>>>>  $(SRC_PATH)/libavformat/protocols.c \
>>>> @@ -142,7 +143,8 @@ distclean:: clean
>>>>   $(RM) .version avversion.h config.asm config.h mapfile  \
>>>>   ffbuild/.config ffbuild/config.* libavutil/avconfig.h \
>>>>   version.h libavutil/ffversion.h libavcodec/codec_names.h \
>>>> - libavcodec/bsf_list.c libavformat/protocol_list.c
>>>> + libavcodec/bsf_list.c libavformat/protocol_list.c \
>>>> + libavfilter/filter_list.h libavfilter/filter_list.c
>>>>  ifeq ($(SRC_LINK),src)
>>>>   $(RM) src
>>>>  endif
>>>> diff --git a/configure b/configure
>>>> index fcfa7aa442..3261f5fd1a 100755
>>>> --- a/configure
>>>> +++ b/configure
>>>> @@ -3177,6 +3177,381 @@ unix_protocol_deps="sys_un_h"
>>>>  unix_protocol_select="network"
>>>>
>>>>  # filters
>>>> +FILTER_TABLE="
>>>> +abench  af
>>>> +acompressor af
>>>> +acontrast   af
>>>> ...
>>>> +spectrumsynth   vaf
>>>> +amovie  avsrc
>>>> +movie   avsrc
>>>> +"
>>>

Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

[Muhammad Faiz]

On Tue, Jan 30, 2018 at 9:09 PM, Mark Thompson <s...@jkqxz.net> wrote:
> On 30/01/18 07:24, Muhammad Faiz wrote:
>> Move REGISTER_FILTER to FILTER_TABLE in configure.
>> Auto generate filter extern and filter table.
>> Sort filter table, use bsearch on avfilter_get_by_name.
>> Define next pointer at filter extern, no need to initialize
>> next pointer at run time, so AVFilter can be set to const.
>> Make avfilter_register always return error.
>> Target checkasm now depends on EXTRALIBS-avformat.
>>
>> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>> ---
>
> I like the idea of this, but I'm not sure about some of the implementation 
> details.
>
> Have you considered dropping the "next" links entirely and having just the 
> array of pointers instead?  I feel like they don't really add anything useful 
> once we are in this form, and result in more boilerplate on every filter and 
> some tricky generation code.
>
> avfilter_next() would be a bit slower (since it would have to search the 
> array, and therefore have runtime linear in the number of filters), but 
> avfilter_get_by_name() is a lot faster because of the binary search (and is 
> the only common use of it) so I don't think that complaint would be a strong 
> one.

Making avfilter_next() slower (even if it is rarely used) isn't good, I think.


>
>>  Makefile   |   4 +-
>>  configure  | 440 
>> -
>> ...
>>  tests/checkasm/Makefile|   2 +-
>>  303 files changed, 1229 insertions(+), 796 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 9defddebfd..f607579369 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -56,6 +56,7 @@ tools/uncoded_frame$(EXESUF): ELIBS = $(FF_EXTRALIBS)
>>  tools/target_dec_%_fuzzer$(EXESUF): $(FF_DEP_LIBS)
>>
>>  CONFIGURABLE_COMPONENTS =   \
>> +$(SRC_PATH)/configure   \
>>  $(wildcard $(FFLIBS:%=$(SRC_PATH)/lib%/all*.c)) \
>>  $(SRC_PATH)/libavcodec/bitstream_filters.c  \
>>  $(SRC_PATH)/libavformat/protocols.c \
>> @@ -142,7 +143,8 @@ distclean:: clean
>>   $(RM) .version avversion.h config.asm config.h mapfile  \
>>   ffbuild/.config ffbuild/config.* libavutil/avconfig.h \
>>   version.h libavutil/ffversion.h libavcodec/codec_names.h \
>> - libavcodec/bsf_list.c libavformat/protocol_list.c
>> + libavcodec/bsf_list.c libavformat/protocol_list.c \
>> + libavfilter/filter_list.h libavfilter/filter_list.c
>>  ifeq ($(SRC_LINK),src)
>>   $(RM) src
>>  endif
>> diff --git a/configure b/configure
>> index fcfa7aa442..3261f5fd1a 100755
>> --- a/configure
>> +++ b/configure
>> @@ -3177,6 +3177,381 @@ unix_protocol_deps="sys_un_h"
>>  unix_protocol_select="network"
>>
>>  # filters
>> +FILTER_TABLE="
>> +abench  af
>> +acompressor af
>> +acontrast   af
>> ...
>> +spectrumsynth   vaf
>> +amovie  avsrc
>> +movie   avsrc
>> +"
>> +
>> +UNCONDITIONAL_FILTER_TABLE="
>> +abuffer asrc
>> +buffer  vsrc
>> +abuffersink asink
>> +buffersink  vsink
>> +afifo   af
>> +fifovf
>> +"
>> +
>
> I don't really like having this table in configure.  Since you're generating 
> the filter_list.h header with the external definitions from it anyway, why 
> not write that and use it as the source rather than having the table here?

Imho, parsing source code and then generating source code is
pointless, it is redundant. Previously, it was just parsing source
code without generating source code. And now it is just generating
source code without parsing source code. There are no duplicates here.

Also storing filter table in configure is more consistent, I think.
Because filter dependencies are in configure.


>
>>  afftfilt_filter_deps="avcodec"
>>  afftfilt_filter_select="fft"
>>  afir_filter_deps="avcodec"
>> @@ -3530,7 +3905,18 @@ MUXER_LIST=$(find_thingsmuxer_MUX 
>> libavformat/allformats.c)
>>  DEMUXER_LIST=$(find_things  demuxer  DEMUXlibavformat/allformats.c)
>>  OUTDEV_LIST=$(find_things   outdev   OUTDEV   libavdevice/alldevices.c)
>>  INDEV_LIST=$(find_thingsindev_IN  libavdevi

Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

[Muhammad Faiz]

On Tue, Jan 30, 2018 at 7:50 PM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Tue, Jan 30, 2018 at 02:24:12PM +0700, Muhammad Faiz wrote:
>> Move REGISTER_FILTER to FILTER_TABLE in configure.
>> Auto generate filter extern and filter table.
>> Sort filter table, use bsearch on avfilter_get_by_name.
>> Define next pointer at filter extern, no need to initialize
>> next pointer at run time, so AVFilter can be set to const.
>
>> Make avfilter_register always return error.
>
> That breaks API

No. Because with current API, it is impossible to implement external filter.


> Its also a step away from supporting plugins.
> Why plugins matter ? Because having plugin
> support is a big advantage, it allows a much wider
> community to work on, write and maintain filters.
>
> With plugins, people can write filters that are
> written in languages other than C. Or filters which
> some developer in FFmpeg doesnt want. Or they can be
> maintained externally by people who just do not like us.
> Or by people who perfer a FOSS license different from
> LGPL/GPL/BSD. Iam sure others can come up with more
> reasons ...
>
> Of course avfilter_register() isnt enough for plugins
> but it or something equivalent is needed for plugins.
>
> So i would prefer if avfilter_register() stays supported
> indefinitly or in case a different system is written for
> plugins then until that system is in place.

It just returns error and logs error message that currently external
filter is unsupported. If someone wants to implement support for
external filter, it can be easily added later using separate
list/table.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

[Muhammad Faiz]

On Tue, Jan 30, 2018 at 2:58 PM, wm4 <nfx...@googlemail.com> wrote:
> On Tue, 30 Jan 2018 14:24:12 +0700
> Muhammad Faiz <mfc...@gmail.com> wrote:
>
>> Move REGISTER_FILTER to FILTER_TABLE in configure.
>> Auto generate filter extern and filter table.
>> Sort filter table, use bsearch on avfilter_get_by_name.
>> Define next pointer at filter extern, no need to initialize
>> next pointer at run time, so AVFilter can be set to const.
>> Make avfilter_register always return error.
>> Target checkasm now depends on EXTRALIBS-avformat.
>>
>> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>> ---
>
> Pretty nice. Should we still add a new filter listing API that uses the
> same idiom as the BSF API? (Although you generate the .next links at
> configure time it might still be nice to eventually get rid of that.)

IMHO, it is uglier (i.e. by requiring opaque pointer). I don't know
other people's opinion. Anyway, it can be added later.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

[Muhammad Faiz]

On Tue, Jan 30, 2018 at 4:47 PM, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> 2018-01-30 8:24 GMT+01:00 Muhammad Faiz <mfc...@gmail.com>:
>
>> +UNCONDITIONAL_FILTER_TABLE="
>> +abuffer asrc
>> +buffer  vsrc
>> +abuffersink asink
>> +buffersink  vsink
>> +afifo   af
>> +fifovf
>
> Why are these unconditional now?

They were previously unconditional by REGISTER_FILTER_UNCONDITIONAL().
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_framerate: fix cpy_line_width calculation on >8 bits format

[Muhammad Faiz]

On Sat, Jan 20, 2018 at 3:04 PM, Muhammad Faiz <mfc...@gmail.com> wrote:
> Fix tsan warnings on fate-filter-framerate-12bit-down and
> fate-filter-framerate-12bit-up.
>
> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
> ---
>  libavfilter/vf_framerate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
> index a5ae6ddb71..578acaae52 100644
> --- a/libavfilter/vf_framerate.c
> +++ b/libavfilter/vf_framerate.c
> @@ -240,7 +240,7 @@ static int filter_slice16(AVFilterContext *ctx, void 
> *arg, int job, int nb_jobs)
>  int plane, line, pixel;
>
>  for (plane = 0; plane < 4 && td->copy_src1->data[plane] && 
> td->copy_src2->data[plane]; plane++) {
> -int cpy_line_width = s->line_size[plane];
> +int cpy_line_width = s->line_size[plane] / 2;
>  const uint16_t *cpy_src1_data = (const uint16_t 
> *)td->copy_src1->data[plane];
>  int cpy_src1_line_size = td->copy_src1->linesize[plane] / 2;
>  const uint16_t *cpy_src2_data = (const uint16_t 
> *)td->copy_src2->data[plane];
> --
> 2.13.2
>

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

Re: [FFmpeg-devel] [PATCH 1/3] avutil: add staticpool

[Muhammad Faiz]

On Sun, Jan 21, 2018 at 7:11 PM, wm4 <nfx...@googlemail.com> wrote:
> On Sun, 21 Jan 2018 10:24:21 +0700
> Muhammad Faiz <mfc...@gmail.com> wrote:
>
>> >  I don't trust the atomics use
>> > either, I'm don't want to have to debug that ever.
>>
>> Of course, using atomics is more complicated that using mutex (with
>> benefits that it will be faster when properly used).
>> But it is not a valid reason to avoid using atomic because it is more
>> complicated.
>
> Sure, but it also means it should be really be confined to cases where
> it _really_ helps with performance.
>
> Where is this a bottleneck at all?

Performance difference is noticeable with audio-only stuff.
Because audio processing is typically fast, malloc-free cycle of
AVFrame, AVBuffer, etc becomes bottlenecks.


>
> I also think that this really belongs into a malloc implementation
> instead. You might also want to try "alternative" malloc
> implementations like jemalloc.

jemalloc nicely is fast. The performance is on par with staticpool and
even faster on high contending situation. I hope that new glibc-malloc
is also fast. So I drop the patch.

With this malloc performance, usage of AVBufferPool on audio frame
becomes questionable.

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

Re: [FFmpeg-devel] [PATCH 1/3] avutil: add staticpool

[Muhammad Faiz]

On Sat, Jan 20, 2018 at 5:22 PM, wm4 <nfx...@googlemail.com> wrote:
> On Sat, 20 Jan 2018 11:29:13 +0700
> Muhammad Faiz <mfc...@gmail.com> wrote:
>
>> Help avoiding malloc-free cycles when allocating-freeing common
>> structures.
>>
>> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>> ---
>>  libavutil/staticpool.h | 117 
>> +
>>  1 file changed, 117 insertions(+)
>>  create mode 100644 libavutil/staticpool.h
>>
>> diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
>> new file mode 100644
>> index 00..9c9b2784bc
>> --- /dev/null
>> +++ b/libavutil/staticpool.h
>> @@ -0,0 +1,117 @@
>> +/*
>> + * 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 AVUTIL_STATICPOOL_H
>> +#define AVUTIL_STATICPOOL_H
>> +
>> +#include 
>> +#include "avassert.h"
>> +#include "mem.h"
>> +
>> +/**
>> + * FF_STATICPOOL allocate memory without av_malloc if possible
>> + * @param size must be 2^n between 64 and 4096
>> + */
>> +#define FF_STATICPOOL_DECLARE(type, size)   
>> \
>> +typedef struct type##_StaticPoolWrapper {   
>> \
>> +typebuf;
>> \
>> +unsignedindex;  
>> \
>> +atomic_uint next;   
>> \
>> +} type##_StaticPoolWrapper; 
>> \
>> +
>> \
>> +static atomic_uint  type##_staticpool_next; 
>> \
>> +static atomic_uint  type##_staticpool_last; 
>> \
>> +static type##_StaticPoolWrapper type##_staticpool_table[size];  
>> \
>> +
>> \
>> +static type *type##_staticpool_malloc(void) 
>> \
>> +{   
>> \
>> +unsigned val, index, serial, new_val;   
>> \
>> +
>> \
>> +av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) - 1))); 
>> \
>> +
>> \
>> +/* use serial, avoid spinlock */
>> \
>> +/* acquire, so we don't get stalled table[index].next */
>> \
>> +val = atomic_load_explicit(##_staticpool_next, 
>> memory_order_acquire);  \
>> +do {
>> \
>> +index  = val & ((size) - 1);
>> \
>> +serial = val & ~((size) - 1);   
>> \
>> +new_val = 
>> atomic_load_explicit(##_staticpool_table[index].next, 
>> memory_order_relaxed) | (serial + (size)); \
>> +} while 
>> (!atomic_compare_exchange_strong_explicit(##_staticpool_next, , 
>> new_val, \
>> +  memory_order_acquire, 
>> memory_order_acquire)); \
>> +
>

Re: [FFmpeg-devel] [PATCH 1/3] avutil: add staticpool

[Muhammad Faiz]

On Sat, Jan 20, 2018 at 5:18 PM, wm4 <nfx...@googlemail.com> wrote:
> On Sat, 20 Jan 2018 12:52:46 +0700
> Muhammad Faiz <mfc...@gmail.com> wrote:
>
>> On Sat, Jan 20, 2018 at 11:49 AM, James Almer <jamr...@gmail.com> wrote:
>> > On 1/20/2018 1:29 AM, Muhammad Faiz wrote:
>> >> Help avoiding malloc-free cycles when allocating-freeing common
>> >> structures.
>> >>
>> >> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>> >> ---
>> >>  libavutil/staticpool.h | 117 
>> >> +
>> >>  1 file changed, 117 insertions(+)
>> >>  create mode 100644 libavutil/staticpool.h
>> >>
>> >> diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
>> >> new file mode 100644
>> >> index 00..9c9b2784bc
>> >> --- /dev/null
>> >> +++ b/libavutil/staticpool.h
>> >> @@ -0,0 +1,117 @@
>> >> +/*
>> >> + * 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 AVUTIL_STATICPOOL_H
>> >> +#define AVUTIL_STATICPOOL_H
>> >> +
>> >> +#include 
>> >> +#include "avassert.h"
>> >> +#include "mem.h"
>> >> +
>> >> +/**
>> >> + * FF_STATICPOOL allocate memory without av_malloc if possible
>> >> + * @param size must be 2^n between 64 and 4096
>> >> + */
>> >> +#define FF_STATICPOOL_DECLARE(type, size)
>> >>\
>> >> +typedef struct type##_StaticPoolWrapper {
>> >>\
>> >> +typebuf; 
>> >>\
>> >> +unsignedindex;   
>> >>\
>> >> +atomic_uint next;
>> >>\
>> >> +} type##_StaticPoolWrapper;  
>> >>\
>> >> + 
>> >>\
>> >> +static atomic_uint  type##_staticpool_next;  
>> >>\
>> >> +static atomic_uint  type##_staticpool_last;  
>> >>\
>> >> +static type##_StaticPoolWrapper type##_staticpool_table[size];   
>> >>\
>> >> + 
>> >>\
>> >> +static type *type##_staticpool_malloc(void)  
>> >>\
>> >> +{
>> >>\
>> >> +unsigned val, index, serial, new_val;
>> >>\
>> >> + 
>> >>\
>> >> +av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) - 
>> >> 1))); \
>> >> + 
>> >>\
>> >> +/* use serial, avoid spinlock */ 
>> >>\
>> >> +/* acquire, so we don't get stalled table[index].next */ 
>> >>\
>> >> +val = atomic_load_ex

Re: [FFmpeg-devel] [PATCH 1/3] avutil: add staticpool

[Muhammad Faiz]

On Sat, Jan 20, 2018 at 6:32 PM, Rostislav Pehlivanov
<atomnu...@gmail.com> wrote:
> On 20 January 2018 at 11:13, Rostislav Pehlivanov <atomnu...@gmail.com>
> wrote:
>
>>
>>
>> On 20 January 2018 at 10:22, wm4 <nfx...@googlemail.com> wrote:
>>
>>> On Sat, 20 Jan 2018 11:29:13 +0700
>>> Muhammad Faiz <mfc...@gmail.com> wrote:
>>>
>>> > Help avoiding malloc-free cycles when allocating-freeing common
>>> > structures.
>>> >
>>> > Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>>> > ---
>>> >  libavutil/staticpool.h | 117 ++
>>> +++
>>> >  1 file changed, 117 insertions(+)
>>> >  create mode 100644 libavutil/staticpool.h
>>> >
>>> > diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
>>> > new file mode 100644
>>> > index 00..9c9b2784bc
>>> > --- /dev/null
>>> > +++ b/libavutil/staticpool.h
>>> > @@ -0,0 +1,117 @@
>>> > +/*
>>> > + * 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 AVUTIL_STATICPOOL_H
>>> > +#define AVUTIL_STATICPOOL_H
>>> > +
>>> > +#include 
>>> > +#include "avassert.h"
>>> > +#include "mem.h"
>>> > +
>>> > +/**
>>> > + * FF_STATICPOOL allocate memory without av_malloc if possible
>>> > + * @param size must be 2^n between 64 and 4096
>>> > + */
>>> > +#define FF_STATICPOOL_DECLARE(type, size)
>>>  \
>>> > +typedef struct type##_StaticPoolWrapper {
>>>  \
>>> > +typebuf;
>>>   \
>>> > +unsignedindex;
>>>   \
>>> > +atomic_uint next;
>>>  \
>>> > +} type##_StaticPoolWrapper;
>>>  \
>>> > +
>>>   \
>>> > +static atomic_uint  type##_staticpool_next;
>>>  \
>>> > +static atomic_uint  type##_staticpool_last;
>>>  \
>>> > +static type##_StaticPoolWrapper type##_staticpool_table[size];
>>>   \
>>> > +
>>>   \
>>> > +static type *type##_staticpool_malloc(void)
>>>\
>>> > +{
>>>  \
>>> > +unsigned val, index, serial, new_val;
>>>  \
>>> > +
>>>   \
>>> > +av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) -
>>> 1))); \
>>> > +
>>>   \
>>> > +/* use serial, avoid spinlock */
>>>   \
>>> > +/* acquire, so we don't get stalled table[index].next */
>>>   \
>>> > +val = atomic_load_explicit(##_staticpool_next,
>>> memory_order_acquire);  \
>>> > +do {
>>>   \
>>> > +index  = val & ((size) - 1);
>>>   \
>>> > +serial = val & ~((size) - 1);
>>>  \
>>> > +new_val = 
>>> > atomic_load_explicit(##_staticpool_table[index].next,
>>> memory_order_relaxed) | (serial + (size)); \
>>> > +} while (!atomic_compare_exchange_stro
>>> ng_explicit(##_staticpool_next, , new_val, \
>>> > +
>>> memory_order_acquire, memory_order_acquire)); \
>>> > +
>>>   \
>>> > +index = val & ((s

[FFmpeg-devel] [PATCH] avfilter/vf_framerate: fix cpy_line_width calculation on >8 bits format

[Muhammad Faiz]

Fix tsan warnings on fate-filter-framerate-12bit-down and
fate-filter-framerate-12bit-up.

Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
---
 libavfilter/vf_framerate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
index a5ae6ddb71..578acaae52 100644
--- a/libavfilter/vf_framerate.c
+++ b/libavfilter/vf_framerate.c
@@ -240,7 +240,7 @@ static int filter_slice16(AVFilterContext *ctx, void *arg, 
int job, int nb_jobs)
 int plane, line, pixel;
 
 for (plane = 0; plane < 4 && td->copy_src1->data[plane] && 
td->copy_src2->data[plane]; plane++) {
-int cpy_line_width = s->line_size[plane];
+int cpy_line_width = s->line_size[plane] / 2;
 const uint16_t *cpy_src1_data = (const uint16_t 
*)td->copy_src1->data[plane];
 int cpy_src1_line_size = td->copy_src1->linesize[plane] / 2;
 const uint16_t *cpy_src2_data = (const uint16_t 
*)td->copy_src2->data[plane];
-- 
2.13.2

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

Re: [FFmpeg-devel] [PATCH 1/3] avutil: add staticpool

[Muhammad Faiz]

On Sat, Jan 20, 2018 at 11:49 AM, James Almer <jamr...@gmail.com> wrote:
> On 1/20/2018 1:29 AM, Muhammad Faiz wrote:
>> Help avoiding malloc-free cycles when allocating-freeing common
>> structures.
>>
>> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>> ---
>>  libavutil/staticpool.h | 117 
>> +
>>  1 file changed, 117 insertions(+)
>>  create mode 100644 libavutil/staticpool.h
>>
>> diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
>> new file mode 100644
>> index 00..9c9b2784bc
>> --- /dev/null
>> +++ b/libavutil/staticpool.h
>> @@ -0,0 +1,117 @@
>> +/*
>> + * 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 AVUTIL_STATICPOOL_H
>> +#define AVUTIL_STATICPOOL_H
>> +
>> +#include 
>> +#include "avassert.h"
>> +#include "mem.h"
>> +
>> +/**
>> + * FF_STATICPOOL allocate memory without av_malloc if possible
>> + * @param size must be 2^n between 64 and 4096
>> + */
>> +#define FF_STATICPOOL_DECLARE(type, size)   
>> \
>> +typedef struct type##_StaticPoolWrapper {   
>> \
>> +typebuf;
>> \
>> +unsignedindex;  
>> \
>> +atomic_uint next;   
>> \
>> +} type##_StaticPoolWrapper; 
>> \
>> +
>> \
>> +static atomic_uint  type##_staticpool_next; 
>> \
>> +static atomic_uint  type##_staticpool_last; 
>> \
>> +static type##_StaticPoolWrapper type##_staticpool_table[size];  
>> \
>> +
>> \
>> +static type *type##_staticpool_malloc(void) 
>> \
>> +{   
>> \
>> +unsigned val, index, serial, new_val;   
>> \
>> +
>> \
>> +av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) - 1))); 
>> \
>> +
>> \
>> +/* use serial, avoid spinlock */
>> \
>> +/* acquire, so we don't get stalled table[index].next */
>> \
>> +val = atomic_load_explicit(##_staticpool_next, 
>> memory_order_acquire);  \
>> +do {
>> \
>> +index  = val & ((size) - 1);
>> \
>> +serial = val & ~((size) - 1);   
>> \
>> +new_val = 
>> atomic_load_explicit(##_staticpool_table[index].next, 
>> memory_order_relaxed) | (serial + (size)); \
>> +} while 
>> (!atomic_compare_exchange_strong_explicit(##_staticpool_next, , 
>> new_val, \
>
> The wrappers for atomic_compare_exchange_* in the compat folder are not
> really working and fixing them is supposedly not trivial, so this will
> only work with GCC and Clang but not with for example MSVC or SunCC.

What's the problem? I only see that stdatomic compat make typedef
every atomic ty

[FFmpeg-devel] [PATCH 1/3] avutil: add staticpool

[Muhammad Faiz]

Help avoiding malloc-free cycles when allocating-freeing common
structures.

Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
---
 libavutil/staticpool.h | 117 +
 1 file changed, 117 insertions(+)
 create mode 100644 libavutil/staticpool.h

diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
new file mode 100644
index 00..9c9b2784bc
--- /dev/null
+++ b/libavutil/staticpool.h
@@ -0,0 +1,117 @@
+/*
+ * 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 AVUTIL_STATICPOOL_H
+#define AVUTIL_STATICPOOL_H
+
+#include 
+#include "avassert.h"
+#include "mem.h"
+
+/**
+ * FF_STATICPOOL allocate memory without av_malloc if possible
+ * @param size must be 2^n between 64 and 4096
+ */
+#define FF_STATICPOOL_DECLARE(type, size)  
 \
+typedef struct type##_StaticPoolWrapper {  
 \
+typebuf;   
 \
+unsignedindex; 
 \
+atomic_uint next;  
 \
+} type##_StaticPoolWrapper;
 \
+   
 \
+static atomic_uint  type##_staticpool_next;
 \
+static atomic_uint  type##_staticpool_last;
 \
+static type##_StaticPoolWrapper type##_staticpool_table[size]; 
 \
+   
 \
+static type *type##_staticpool_malloc(void)
 \
+{  
 \
+unsigned val, index, serial, new_val;  
 \
+   
 \
+av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) - 1)));
 \
+   
 \
+/* use serial, avoid spinlock */   
 \
+/* acquire, so we don't get stalled table[index].next */   
 \
+val = atomic_load_explicit(##_staticpool_next, memory_order_acquire); 
 \
+do {   
 \
+index  = val & ((size) - 1);   
 \
+serial = val & ~((size) - 1);  
 \
+new_val = atomic_load_explicit(##_staticpool_table[index].next, 
memory_order_relaxed) | (serial + (size)); \
+} while (!atomic_compare_exchange_strong_explicit(##_staticpool_next, 
, new_val, \
+  memory_order_acquire, 
memory_order_acquire)); \
+   
 \
+index = val & ((size) - 1);
 \
+if (index) 
 \
+return ##_staticpool_table[index].buf;
 \
+   
 \
+index = atomic_fetch_add_explicit(##_staticpool_last, 1, 
memory_order_relaxed) + 1; \
+if (index < (size)) {  
 \
+type##_staticpool_table[index].index = index;  
 \
+return ##_staticpool_table[index].buf;
 \
+}  
 \
+   
 \
+atomic_fetch_add_explicit(##_staticpool_last, -1, 
memory_order_relaxed); \
+return av_malloc(sizeof(type));
 \
+}  
 \
+ 

[FFmpeg-devel] [PATCH 2/3] avutil/buffer: use staticpool

[Muhammad Faiz]

Use default size 1024.
Benchmark:
time ./ffmpeg -f s16le -ac 5 -ar 48000 -t 1 -i /dev/zero \
-af "aformat=s16p, asetnsamples=256" -f null -
old: 27.616s
new: 22.079s

Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
---
 libavutil/buffer.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/libavutil/buffer.c b/libavutil/buffer.c
index 8d1aa5fa84..6dd3f0441b 100644
--- a/libavutil/buffer.c
+++ b/libavutil/buffer.c
@@ -24,6 +24,11 @@
 #include "common.h"
 #include "mem.h"
 #include "thread.h"
+#include "staticpool.h"
+
+FF_STATICPOOL_DECLARE(AVBufferRef, 1024)
+FF_STATICPOOL_DECLARE(AVBuffer, 1024)
+FF_STATICPOOL_DECLARE(BufferPoolEntry, 1024)
 
 AVBufferRef *av_buffer_create(uint8_t *data, int size,
   void (*free)(void *opaque, uint8_t *data),
@@ -32,7 +37,7 @@ AVBufferRef *av_buffer_create(uint8_t *data, int size,
 AVBufferRef *ref = NULL;
 AVBuffer*buf = NULL;
 
-buf = av_mallocz(sizeof(*buf));
+buf = FF_STATICPOOL_MALLOCZ(AVBuffer);
 if (!buf)
 return NULL;
 
@@ -46,9 +51,9 @@ AVBufferRef *av_buffer_create(uint8_t *data, int size,
 if (flags & AV_BUFFER_FLAG_READONLY)
 buf->flags |= BUFFER_FLAG_READONLY;
 
-ref = av_mallocz(sizeof(*ref));
+ref = FF_STATICPOOL_MALLOCZ(AVBufferRef);
 if (!ref) {
-av_freep();
+FF_STATICPOOL_FREEP(AVBuffer, );
 return NULL;
 }
 
@@ -92,7 +97,7 @@ AVBufferRef *av_buffer_allocz(int size)
 
 AVBufferRef *av_buffer_ref(AVBufferRef *buf)
 {
-AVBufferRef *ret = av_mallocz(sizeof(*ret));
+AVBufferRef *ret = FF_STATICPOOL_MALLOCZ(AVBufferRef);
 
 if (!ret)
 return NULL;
@@ -112,13 +117,13 @@ static void buffer_replace(AVBufferRef **dst, AVBufferRef 
**src)
 
 if (src) {
 **dst = **src;
-av_freep(src);
+FF_STATICPOOL_FREEP(AVBufferRef, src);
 } else
-av_freep(dst);
+FF_STATICPOOL_FREEP(AVBufferRef, dst);
 
 if (atomic_fetch_add_explicit(>refcount, -1, memory_order_acq_rel) == 
1) {
 b->free(b->opaque, b->data);
-av_freep();
+FF_STATICPOOL_FREEP(AVBuffer, );
 }
 }
 
@@ -262,7 +267,7 @@ static void buffer_pool_free(AVBufferPool *pool)
 pool->pool = buf->next;
 
 buf->free(buf->opaque, buf->data);
-av_freep();
+FF_STATICPOOL_FREEP(BufferPoolEntry, );
 }
 ff_mutex_destroy(>mutex);
 
@@ -314,7 +319,7 @@ static AVBufferRef *pool_alloc_buffer(AVBufferPool *pool)
 if (!ret)
 return NULL;
 
-buf = av_mallocz(sizeof(*buf));
+buf = FF_STATICPOOL_MALLOCZ(BufferPoolEntry);
 if (!buf) {
 av_buffer_unref();
 return NULL;
-- 
2.13.2

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

[FFmpeg-devel] [PATCH 3/3] avutil/frame: use staticpool

[Muhammad Faiz]

Use default size 256.
Benchmark:
time ./ffmpeg -f s16le -ac 5 -ar 48000 -t 1 -i /dev/zero \
-af "aformat=s16p, asetnsamples=256" -f null -
old: 22.079s
new: 21.180s

Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
---
 libavutil/frame.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 662a7e5ab5..dd13d2b67b 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -25,8 +25,11 @@
 #include "imgutils.h"
 #include "mem.h"
 #include "samplefmt.h"
+#include "staticpool.h"
 
 
+FF_STATICPOOL_DECLARE(AVFrame, 256)
+
 static AVFrameSideData *frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 AVBufferRef *buf);
@@ -149,7 +152,7 @@ static void wipe_side_data(AVFrame *frame)
 
 AVFrame *av_frame_alloc(void)
 {
-AVFrame *frame = av_mallocz(sizeof(*frame));
+AVFrame *frame = FF_STATICPOOL_MALLOCZ(AVFrame);
 
 if (!frame)
 return NULL;
@@ -166,7 +169,7 @@ void av_frame_free(AVFrame **frame)
 return;
 
 av_frame_unref(*frame);
-av_freep(frame);
+FF_STATICPOOL_FREEP(AVFrame, frame);
 }
 
 static int get_video_buffer(AVFrame *frame, int align)
-- 
2.13.2

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

Re: [FFmpeg-devel] [PATCH v2 1/6] lavc: add new API for iterating codecs and codec parsers

[Muhammad Faiz]

On Thu, Jan 4, 2018 at 2:59 AM, Rostislav Pehlivanov
<atomnu...@gmail.com> wrote:
> On 3 January 2018 at 19:16, Muhammad Faiz <mfc...@gmail.com> wrote:
>
>> On Wed, Jan 3, 2018 at 7:42 AM, Josh de Kock <j...@itanimul.li> wrote:
>> > Also replace linked list with an array.
>> > ---
>> >  configure  |   12 +-
>> >  doc/APIchanges |4 +
>> >  libavcodec/allcodecs.c | 1473 --
>> --
>> >  libavcodec/avcodec.h   |   31 +
>> >  libavcodec/parser.c|   87 ++-
>> >  libavcodec/utils.c |  105 
>> >  libavcodec/version.h   |3 +
>> >  7 files changed, 974 insertions(+), 741 deletions(-)
>> >
>>
>> > +
>> > +#include "codec_list.c"
>>
>> Won't work when building outside source directory. Use
>> "libavcodec/codec_list.c"
>>
>
> It pretty much will, this is exactly how hwaccels and bitstream filters
> currently work.

At bitstream_filters.c:
#include "libavcodec/bsf_list.c"

>
>
>
>>
>> > +static void av_codec_init_next(void)
>> > +{
>> > +AVCodec *prev = NULL, *p;
>> > +void *i = 0;
>> > +while ((p = (AVCodec*)av_codec_iterate())) {
>>
>> Better use: for (i = 0; codec_list[i]; i++)
>>
>>
>> > diff --git a/libavcodec/parser.c b/libavcodec/parser.c
>> > index 670680e..76532e2 100644
>> > --- a/libavcodec/parser.c
>> > +++ b/libavcodec/parser.c
>> > @@ -32,33 +32,104 @@
>> >  #include "internal.h"
>> >  #include "parser.h"
>> >
>> > -static AVCodecParser *av_first_parser = NULL;
>> > +#include "pthread.h"
>> > +
>> > +/* Parsers */
>> > +extern AVCodecParser ff_aac_parser;
>> > +extern AVCodecParser ff_aac_latm_parser;
>> > +extern AVCodecParser ff_ac3_parser;
>> > +extern AVCodecParser ff_adx_parser;
>> > +extern AVCodecParser ff_bmp_parser;
>> > +extern AVCodecParser ff_cavsvideo_parser;
>> > +extern AVCodecParser ff_cook_parser;
>> > +extern AVCodecParser ff_dca_parser;
>> > +extern AVCodecParser ff_dirac_parser;
>> > +extern AVCodecParser ff_dnxhd_parser;
>> > +extern AVCodecParser ff_dpx_parser;
>> > +extern AVCodecParser ff_dvaudio_parser;
>> > +extern AVCodecParser ff_dvbsub_parser;
>> > +extern AVCodecParser ff_dvdsub_parser;
>> > +extern AVCodecParser ff_dvd_nav_parser;
>> > +extern AVCodecParser ff_flac_parser;
>> > +extern AVCodecParser ff_g729_parser;
>> > +extern AVCodecParser ff_gsm_parser;
>> > +extern AVCodecParser ff_h261_parser;
>> > +extern AVCodecParser ff_h263_parser;
>> > +extern AVCodecParser ff_h264_parser;
>> > +extern AVCodecParser ff_hevc_parser;
>> > +extern AVCodecParser ff_mjpeg_parser;
>> > +extern AVCodecParser ff_mlp_parser;
>> > +extern AVCodecParser ff_mpeg4video_parser;
>> > +extern AVCodecParser ff_mpegaudio_parser;
>> > +extern AVCodecParser ff_mpegvideo_parser;
>> > +extern AVCodecParser ff_opus_parser;
>> > +extern AVCodecParser ff_png_parser;
>> > +extern AVCodecParser ff_pnm_parser;
>> > +extern AVCodecParser ff_rv30_parser;
>> > +extern AVCodecParser ff_rv40_parser;
>> > +extern AVCodecParser ff_sipr_parser;
>> > +extern AVCodecParser ff_tak_parser;
>> > +extern AVCodecParser ff_vc1_parser;
>> > +extern AVCodecParser ff_vorbis_parser;
>> > +extern AVCodecParser ff_vp3_parser;
>> > +extern AVCodecParser ff_vp8_parser;
>> > +extern AVCodecParser ff_vp9_parser;
>> > +extern AVCodecParser ff_xma_parser;
>>
>> Why these are not in allcodecs.c?
>>
>
> Because they're parsers.
>

They still need initialize next pointer. So better to initialize it on
avcodec_register_all().
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/6] lavc: add new API for iterating codecs and codec parsers

[Muhammad Faiz]

On Wed, Jan 3, 2018 at 7:42 AM, Josh de Kock  wrote:
> Also replace linked list with an array.
> ---
>  configure  |   12 +-
>  doc/APIchanges |4 +
>  libavcodec/allcodecs.c | 1473 
> 
>  libavcodec/avcodec.h   |   31 +
>  libavcodec/parser.c|   87 ++-
>  libavcodec/utils.c |  105 
>  libavcodec/version.h   |3 +
>  7 files changed, 974 insertions(+), 741 deletions(-)
>

> +
> +#include "codec_list.c"

Won't work when building outside source directory. Use "libavcodec/codec_list.c"


> +static void av_codec_init_next(void)
> +{
> +AVCodec *prev = NULL, *p;
> +void *i = 0;
> +while ((p = (AVCodec*)av_codec_iterate())) {

Better use: for (i = 0; codec_list[i]; i++)


> diff --git a/libavcodec/parser.c b/libavcodec/parser.c
> index 670680e..76532e2 100644
> --- a/libavcodec/parser.c
> +++ b/libavcodec/parser.c
> @@ -32,33 +32,104 @@
>  #include "internal.h"
>  #include "parser.h"
>
> -static AVCodecParser *av_first_parser = NULL;
> +#include "pthread.h"
> +
> +/* Parsers */
> +extern AVCodecParser ff_aac_parser;
> +extern AVCodecParser ff_aac_latm_parser;
> +extern AVCodecParser ff_ac3_parser;
> +extern AVCodecParser ff_adx_parser;
> +extern AVCodecParser ff_bmp_parser;
> +extern AVCodecParser ff_cavsvideo_parser;
> +extern AVCodecParser ff_cook_parser;
> +extern AVCodecParser ff_dca_parser;
> +extern AVCodecParser ff_dirac_parser;
> +extern AVCodecParser ff_dnxhd_parser;
> +extern AVCodecParser ff_dpx_parser;
> +extern AVCodecParser ff_dvaudio_parser;
> +extern AVCodecParser ff_dvbsub_parser;
> +extern AVCodecParser ff_dvdsub_parser;
> +extern AVCodecParser ff_dvd_nav_parser;
> +extern AVCodecParser ff_flac_parser;
> +extern AVCodecParser ff_g729_parser;
> +extern AVCodecParser ff_gsm_parser;
> +extern AVCodecParser ff_h261_parser;
> +extern AVCodecParser ff_h263_parser;
> +extern AVCodecParser ff_h264_parser;
> +extern AVCodecParser ff_hevc_parser;
> +extern AVCodecParser ff_mjpeg_parser;
> +extern AVCodecParser ff_mlp_parser;
> +extern AVCodecParser ff_mpeg4video_parser;
> +extern AVCodecParser ff_mpegaudio_parser;
> +extern AVCodecParser ff_mpegvideo_parser;
> +extern AVCodecParser ff_opus_parser;
> +extern AVCodecParser ff_png_parser;
> +extern AVCodecParser ff_pnm_parser;
> +extern AVCodecParser ff_rv30_parser;
> +extern AVCodecParser ff_rv40_parser;
> +extern AVCodecParser ff_sipr_parser;
> +extern AVCodecParser ff_tak_parser;
> +extern AVCodecParser ff_vc1_parser;
> +extern AVCodecParser ff_vorbis_parser;
> +extern AVCodecParser ff_vp3_parser;
> +extern AVCodecParser ff_vp8_parser;
> +extern AVCodecParser ff_vp9_parser;
> +extern AVCodecParser ff_xma_parser;

Why these are not in allcodecs.c?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc: add new API for iterating codecs and codec parsers

[Muhammad Faiz]

On Sat, Dec 23, 2017 at 8:27 PM, Josh de Kock  wrote:
> This is the first patch to add the new API for iterating items within the 
> libraries to lavc, this completes lavc's support for this API (BSFs were 
> already using it).
>
> I'm currently working on a similar patch for lavfi, lavf and lavd. Note that 
> I'm not entirely sure how to properly deprecate stuff so if that's incorrect 
> some advice would be appreciated.
>
> --
> Josh de Kock 

>+
>+#include "codec_list.c"
>+

Building outside ffmpeg tree, I got
CC  libavcodec/allcodecs.o
CC  libavcodec/alsdec.o
src/libavcodec/allcodecs.c:756:24: fatal error: codec_list.c: No such
file or directory
compilation terminated.

Also, the patch contains tabs and trailing whitespace.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/crc: use ff_thread_once at av_crc_get_table

[Muhammad Faiz]

On Sun, Nov 12, 2017 at 8:28 PM, Muhammad Faiz <mfc...@gmail.com> wrote:
> On Wed, Nov 1, 2017 at 12:37 AM, Muhammad Faiz <mfc...@gmail.com> wrote:
>> On Mon, Oct 30, 2017 at 8:07 PM, Michael Niedermayer
>> <mich...@niedermayer.cc> wrote:
>>> On Mon, Oct 30, 2017 at 02:14:35PM +0700, Muhammad Faiz wrote:
>>>> On Tue, Oct 24, 2017 at 4:31 PM, Muhammad Faiz <mfc...@gmail.com> wrote:
>>>> > Fix tsan warnings.
>>>> >
>>>> > Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>>>> > ---
>>>> >  libavutil/crc.c | 49 +
>>>> >  1 file changed, 29 insertions(+), 20 deletions(-)
>>>>
>>>> Ping.
>>>
>>> I assume james patch is faster than both ?
>>>
>>> If this code is never run in speed relevant loops then your solution is
>>> better. Otherwise i think james patch is better
>>
>> I guess the common usage is to call av_crc() which is far more
>> computationally intensive after calling av_crc_get_table().
>
> Ping.
> I'm going to apply this tomorrow.
>
> Thank's.

Applied.

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

Re: [FFmpeg-devel] [PATCH] avutil/crc: use ff_thread_once at av_crc_get_table

[Muhammad Faiz]

On Wed, Nov 1, 2017 at 12:37 AM, Muhammad Faiz <mfc...@gmail.com> wrote:
> On Mon, Oct 30, 2017 at 8:07 PM, Michael Niedermayer
> <mich...@niedermayer.cc> wrote:
>> On Mon, Oct 30, 2017 at 02:14:35PM +0700, Muhammad Faiz wrote:
>>> On Tue, Oct 24, 2017 at 4:31 PM, Muhammad Faiz <mfc...@gmail.com> wrote:
>>> > Fix tsan warnings.
>>> >
>>> > Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>>> > ---
>>> >  libavutil/crc.c | 49 +
>>> >  1 file changed, 29 insertions(+), 20 deletions(-)
>>>
>>> Ping.
>>
>> I assume james patch is faster than both ?
>>
>> If this code is never run in speed relevant loops then your solution is
>> better. Otherwise i think james patch is better
>
> I guess the common usage is to call av_crc() which is far more
> computationally intensive after calling av_crc_get_table().

Ping.
I'm going to apply this tomorrow.

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

Re: [FFmpeg-devel] [PATCH] avutil/crc: use ff_thread_once at av_crc_get_table

[Muhammad Faiz]

On Mon, Oct 30, 2017 at 8:07 PM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Mon, Oct 30, 2017 at 02:14:35PM +0700, Muhammad Faiz wrote:
>> On Tue, Oct 24, 2017 at 4:31 PM, Muhammad Faiz <mfc...@gmail.com> wrote:
>> > Fix tsan warnings.
>> >
>> > Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
>> > ---
>> >  libavutil/crc.c | 49 +
>> >  1 file changed, 29 insertions(+), 20 deletions(-)
>>
>> Ping.
>
> I assume james patch is faster than both ?
>
> If this code is never run in speed relevant loops then your solution is
> better. Otherwise i think james patch is better

I guess the common usage is to call av_crc() which is far more
computationally intensive after calling av_crc_get_table().
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC]lswr/rematrix: Support s32p

[Muhammad Faiz]

On Sun, Oct 29, 2017 at 3:55 AM, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes a random testcase for ticket #6785 here but I
> don't know if this is the correct fix.
>
> Please review, Carl Eugen
>
> From a93b9309d74f5eadece371ee1e682d266af6cd83 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sat, 28 Oct 2017 22:52:02 +0200
> Subject: [PATCH] lswr/rematrix: Support s32p.
>
> Fixes ticket #6785.
> ---
>  libswresample/rematrix.c |   21 +++--
>  1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
> index 66a43c1..a6aa6b0 100644
> --- a/libswresample/rematrix.c
> +++ b/libswresample/rematrix.c
> @@ -445,14 +445,23 @@ av_cold int swri_rematrix_init(SwrContext *s){
>  s->mix_2_1_f = (mix_2_1_func_type*)sum2_double;
>  s->mix_any_f = (mix_any_func_type*)get_mix_any_func_double(s);
>  }else if(s->midbuf.fmt == AV_SAMPLE_FMT_S32P){
> -// Only for dithering currently
> -// s->native_matrix = av_calloc(nb_in * nb_out, sizeof(double));
> -s->native_one= av_mallocz(sizeof(int));
> +s->native_one= av_mallocz(sizeof(int64_t));
>  if (!s->native_one)
>  return AVERROR(ENOMEM);
> -// for (i = 0; i < nb_out; i++)
> -// for (j = 0; j < nb_in; j++)
> -// ((double*)s->native_matrix)[i * nb_in + j] = 
> s->matrix[i][j];
> +s->native_matrix = av_calloc(nb_in * nb_out, sizeof(int));
> +if (!s->native_matrix) {
> +av_freep(>native_one);
> +return AVERROR(ENOMEM);
> +}
> +for (i = 0; i < nb_out; i++) {
> +double rem = 0;
> +
> +for (j = 0; j < nb_in; j++) {
> +double target = s->matrix[i][j] * 32768 + rem;
> +((int*)s->native_matrix)[i * nb_in + j] = lrintf(target);
> +rem += target - ((int64_t*)s->native_matrix)[i * nb_in + j];
> +}
> +}
>  *((int*)s->native_one) = 32768;
>  s->mix_1_1_f = (mix_1_1_func_type*)copy_s32;
>  s->mix_2_1_f = (mix_2_1_func_type*)sum2_s32;

The code is confusing.
Which is the type of native_matrix and native_one? int or int64_t?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/crc: use ff_thread_once at av_crc_get_table

[Muhammad Faiz]

On Tue, Oct 24, 2017 at 4:31 PM, Muhammad Faiz <mfc...@gmail.com> wrote:
> Fix tsan warnings.
>
> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
> ---
>  libavutil/crc.c | 49 +
>  1 file changed, 29 insertions(+), 20 deletions(-)

Ping.

My recent benchmark:

old/new:
 296320/ 340400 decicycles in AV_CRC_8_ATM,   1 runs,  0 skips
   1180/   2040 decicycles in AV_CRC_8_ATM,   1 runs,  0 skips
830/   1460 decicycles in AV_CRC_8_ATM,   2 runs,  0 skips
620/995 decicycles in AV_CRC_8_ATM,   4 runs,  0 skips
505/797 decicycles in AV_CRC_8_ATM,   8 runs,  0 skips
487/653 decicycles in AV_CRC_8_ATM,  16 runs,  0 skips
448/546 decicycles in AV_CRC_8_ATM,  32 runs,  0 skips
435/531 decicycles in AV_CRC_8_ATM,  64 runs,  0 skips
445/479 decicycles in AV_CRC_8_ATM, 128 runs,  0 skips
454/451 decicycles in AV_CRC_8_ATM, 256 runs,  0 skips
469/436 decicycles in AV_CRC_8_ATM, 512 runs,  0 skips
459/429 decicycles in AV_CRC_8_ATM,1024 runs,  0 skips
467/425 decicycles in AV_CRC_8_ATM,2048 runs,  0 skips

 137180/ 118440 decicycles in AV_CRC_16_ANSI,   1 runs,  0 skips
720/   1140 decicycles in AV_CRC_16_ANSI,   1 runs,  0 skips
550/880 decicycles in AV_CRC_16_ANSI,   2 runs,  0 skips
515/700 decicycles in AV_CRC_16_ANSI,   4 runs,  0 skips
550/560 decicycles in AV_CRC_16_ANSI,   8 runs,  0 skips
508/515 decicycles in AV_CRC_16_ANSI,  16 runs,  0 skips
493/520 decicycles in AV_CRC_16_ANSI,  32 runs,  0 skips
482/515 decicycles in AV_CRC_16_ANSI,  64 runs,  0 skips
482/468 decicycles in AV_CRC_16_ANSI, 128 runs,  0 skips
481/443 decicycles in AV_CRC_16_ANSI, 256 runs,  0 skips
467/429 decicycles in AV_CRC_16_ANSI, 512 runs,  0 skips
474/422 decicycles in AV_CRC_16_ANSI,1024 runs,  0 skips
469/425 decicycles in AV_CRC_16_ANSI,2048 runs,  0 skips

 124720/ 104060 decicycles in AV_CRC_16_CCITT,   1 runs,  0 skips
460/860 decicycles in AV_CRC_16_CCITT,   1 runs,  0 skips
440/740 decicycles in AV_CRC_16_CCITT,   2 runs,  0 skips
505/660 decicycles in AV_CRC_16_CCITT,   4 runs,  0 skips
472/605 decicycles in AV_CRC_16_CCITT,   8 runs,  0 skips
486/561 decicycles in AV_CRC_16_CCITT,  16 runs,  0 skips
466/557 decicycles in AV_CRC_16_CCITT,  32 runs,  0 skips
489/546 decicycles in AV_CRC_16_CCITT,  64 runs,  0 skips
496/552 decicycles in AV_CRC_16_CCITT, 128 runs,  0 skips
459/522 decicycles in AV_CRC_16_CCITT, 256 runs,  0 skips
447/493 decicycles in AV_CRC_16_CCITT, 512 runs,  0 skips
468/469 decicycles in AV_CRC_16_CCITT,1024 runs,  0 skips
477/454 decicycles in AV_CRC_16_CCITT,2048 runs,  0 skips

 123500/ 102600 decicycles in AV_CRC_32_IEEE,   1 runs,  0 skips
460/   1060 decicycles in AV_CRC_32_IEEE,   1 runs,  0 skips
420/850 decicycles in AV_CRC_32_IEEE,   2 runs,  0 skips
415/685 decicycles in AV_CRC_32_IEEE,   4 runs,  0 skips
407/557 decicycles in AV_CRC_32_IEEE,   8 runs,  0 skips
402/540 decicycles in AV_CRC_32_IEEE,  16 runs,  0 skips
428/491 decicycles in AV_CRC_32_IEEE,  32 runs,  0 skips
452/501 decicycles in AV_CRC_32_IEEE,  64 runs,  0 skips
466/507 decicycles in AV_CRC_32_IEEE, 128 runs,  0 skips
474/506 decicycles in AV_CRC_32_IEEE, 256 runs,  0 skips
478/482 decicycles in AV_CRC_32_IEEE, 512 runs,  0 skips
476/454 decicycles in AV_CRC_32_IEEE,1024 runs,  0 skips
472/435 decicycles in AV_CRC_32_IEEE,2048 runs,  0 skips

 133800/ 110660 decicycles in AV_CRC_32_IEEE_LE,   1 runs,  0 skips
460/   1060 decicycles in AV_CRC_32_IEEE_LE,   1 runs,  0 skips
560/820 decicycles in AV_CRC_32_IEEE_LE,   2 runs,  0 skips
530/665 decicycles in AV_CRC_32_IEEE_LE,   4 runs,  0 skips
502/547 decicycles in AV_CRC_32_IEEE_LE,   8 runs,  0 skips
498/533 decicycles in AV_CRC_32_IEEE_LE,  16 runs,  0 skips
481/533 decicycles in AV_CRC_32_IEEE_LE,  32 runs,  0 skips
493/542 decicycles in AV_CRC_32_IEEE_LE,  64 runs,  0 skips
494/489 decicycles in AV_CRC_32_IEEE_LE, 128 runs,  0 skips
500/461 decicycles in AV_CRC_32_IEEE_LE, 256 runs,  0 skips
493/446 decicycles in AV_CRC_32_IEEE_LE, 512 runs,  0 skips
498/439 decicycles

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

[Muhammad Faiz]

On Tue, Oct 24, 2017 at 6:05 PM, Michael Niedermayer
 wrote:
> On Mon, Oct 23, 2017 at 10:36:21PM -0300, James Almer wrote:
>> On 10/23/2017 10:24 PM, Michael Niedermayer wrote:
>> > On Tue, Oct 24, 2017 at 01:39:03AM +0100, Mark Thompson wrote:
>> >> On 24/10/17 00:52, Michael Niedermayer wrote:
>> >>> Hi
>> >>>
>> >>> On Mon, Oct 23, 2017 at 04:43:19PM +0100, Mark Thompson wrote:
>>  On 23/10/17 03:56, Michael Niedermayer wrote:
>> > the initialization should be thread safe as it never writes a different
>> > value in the same spot
>> 
>>  This is not true; please be very careful with assumptions like this.
>> 
>>  The C standard calls this a data race and it is undefined behaviour.
>> >>>
>> >>> Thats interresting, we definitly do not want undefined behavior
>> >>> can you quote the relevant parts of the C standard
>> >>> which make writing the same value, a data race ?
>> >>>
>> >>> I was not aware of this if its true.
>> >>> Also i dont immedeatly see this in the "latest" draft i am looking at
>> >>> atm
>> >>>
>> >>> What i see is this:
>> >>> 4 Two expression evaluations conflict if one of them modifies a memory 
>> >>> location and the
>> >>>   other one reads or modifies the same memory location.
>> >>> ...
>> >>> 25 The execution of a program contains a data race if it contains two 
>> >>> conflicting actions in
>> >>>different threads, at least one of which is not atomic, and neither 
>> >>> happens before the
>> >>>other. Any such data race results in undefined behavior.
>> >>>
>> >>> This seems carefully worded to not include writing the same value.
>> >>> As "modification" implies change which does not occur when writing the
>> >>> same value.
>> >>
>> >> All writes are modifications.
>> >>
>> >> See section 3.1 note 2:
>> >> """
>> >> 3 NOTE 2   "Modify"€™ includes the case where the new value being stored 
>> >> is the same as the previous value.
>> >> """
>> >
>> > That resolves the difference between our interpretation
>> >
>> > thanks
>>
>> Should i push this, or does someone want to give ff_thread_once() a try?
>
> If ff_thread_once() is used outside init code, it should be benchmarked
> as it may be a bad idea speed wise.
> During init speed doesnt matter so ff_thread_once() there would be fine
> but would require more changes to move it to init.

Using my patch:
Benchmark: make fate-lavf-png at pngenc.c:png_write_chunk
old:
 150640 decicycles in av_crc_get_table:first, 1 runs,  0 skips
   1740 decicycles in av_crc_get_table,   1 runs,  0 skips
   1390 decicycles in av_crc_get_table,   2 runs,  0 skips
945 decicycles in av_crc_get_table,   4 runs,  0 skips
720 decicycles in av_crc_get_table,   8 runs,  0 skips
592 decicycles in av_crc_get_table,  16 runs,  0 skips
536 decicycles in av_crc_get_table,  32 runs,  0 skips
510 decicycles in av_crc_get_table,  64 runs,  0 skips
497 decicycles in av_crc_get_table, 128 runs,  0 skips
494 decicycles in av_crc_get_table, 256 runs,  0 skips
479 decicycles in av_crc_get_table, 512 runs,  0 skips
454 decicycles in av_crc_get_table,1024 runs,  0 skips
434 decicycles in av_crc_get_table,2048 runs,  0 skips


new:
 235060 decicycles in av_crc_get_table:first, 1 runs,  0 skips
   2900 decicycles in av_crc_get_table,   1 runs,  0 skips
   2560 decicycles in av_crc_get_table,   2 runs,  0 skips
   1825 decicycles in av_crc_get_table,   4 runs,  0 skips
   1200 decicycles in av_crc_get_table,   8 runs,  0 skips
902 decicycles in av_crc_get_table,  16 runs,  0 skips
719 decicycles in av_crc_get_table,  32 runs,  0 skips
628 decicycles in av_crc_get_table,  64 runs,  0 skips
576 decicycles in av_crc_get_table, 128 runs,  0 skips
550 decicycles in av_crc_get_table, 256 runs,  0 skips
532 decicycles in av_crc_get_table, 512 runs,  0 skips
499 decicycles in av_crc_get_table,1024 runs,  0 skips
470 decicycles in av_crc_get_table,2048 runs,  0 skips

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

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

[Muhammad Faiz]

On Tue, Oct 24, 2017 at 8:36 AM, James Almer  wrote:
> On 10/23/2017 10:24 PM, Michael Niedermayer wrote:
>> On Tue, Oct 24, 2017 at 01:39:03AM +0100, Mark Thompson wrote:
>>> On 24/10/17 00:52, Michael Niedermayer wrote:
 Hi

 On Mon, Oct 23, 2017 at 04:43:19PM +0100, Mark Thompson wrote:
> On 23/10/17 03:56, Michael Niedermayer wrote:
>> the initialization should be thread safe as it never writes a different
>> value in the same spot
>
> This is not true; please be very careful with assumptions like this.
>
> The C standard calls this a data race and it is undefined behaviour.

 Thats interresting, we definitly do not want undefined behavior
 can you quote the relevant parts of the C standard
 which make writing the same value, a data race ?

 I was not aware of this if its true.
 Also i dont immedeatly see this in the "latest" draft i am looking at
 atm

 What i see is this:
 4 Two expression evaluations conflict if one of them modifies a memory 
 location and the
   other one reads or modifies the same memory location.
 ...
 25 The execution of a program contains a data race if it contains two 
 conflicting actions in
different threads, at least one of which is not atomic, and neither 
 happens before the
other. Any such data race results in undefined behavior.

 This seems carefully worded to not include writing the same value.
 As "modification" implies change which does not occur when writing the
 same value.
>>>
>>> All writes are modifications.
>>>
>>> See section 3.1 note 2:
>>> """
>>> 3 NOTE 2   "Modify"€™ includes the case where the new value being stored is 
>>> the same as the previous value.
>>> """
>>
>> That resolves the difference between our interpretation
>>
>> thanks
>
> Should i push this, or does someone want to give ff_thread_once() a try?

I've posted a patch.

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

[FFmpeg-devel] [PATCH] avutil/crc: use ff_thread_once at av_crc_get_table

[Muhammad Faiz]

Fix tsan warnings.

Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
---
 libavutil/crc.c | 49 +
 1 file changed, 29 insertions(+), 20 deletions(-)

diff --git a/libavutil/crc.c b/libavutil/crc.c
index 495732b163..d44550c9c0 100644
--- a/libavutil/crc.c
+++ b/libavutil/crc.c
@@ -20,6 +20,8 @@
 
 #include "config.h"
 
+#include "thread.h"
+#include "avassert.h"
 #include "bswap.h"
 #include "common.h"
 #include "crc.h"
@@ -291,20 +293,24 @@ static const AVCRC av_crc_table[AV_CRC_MAX][257] = {
 #else
 #define CRC_TABLE_SIZE 1024
 #endif
-static struct {
-uint8_t  le;
-uint8_t  bits;
-uint32_t poly;
-} av_crc_table_params[AV_CRC_MAX] = {
-[AV_CRC_8_ATM]  = { 0,  8,   0x07 },
-[AV_CRC_16_ANSI]= { 0, 16, 0x8005 },
-[AV_CRC_16_CCITT]   = { 0, 16, 0x1021 },
-[AV_CRC_24_IEEE]= { 0, 24,   0x864CFB },
-[AV_CRC_32_IEEE]= { 0, 32, 0x04C11DB7 },
-[AV_CRC_32_IEEE_LE] = { 1, 32, 0xEDB88320 },
-[AV_CRC_16_ANSI_LE] = { 1, 16, 0xA001 },
-};
 static AVCRC av_crc_table[AV_CRC_MAX][CRC_TABLE_SIZE];
+
+#define DECLARE_CRC_INIT_TABLE_ONCE(id, le, bits, poly)
   \
+static AVOnce id ## _once_control = AV_ONCE_INIT;  
   \
+static void id ## _init_table_once(void)   
   \
+{  
   \
+av_assert0(av_crc_init(av_crc_table[id], le, bits, poly, 
sizeof(av_crc_table[id])) >= 0); \
+}
+
+#define CRC_INIT_TABLE_ONCE(id) ff_thread_once( ## _once_control, id ## 
_init_table_once)
+
+DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_8_ATM,  0,  8,   0x07)
+DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_16_ANSI,0, 16, 0x8005)
+DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_16_CCITT,   0, 16, 0x1021)
+DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_24_IEEE,0, 24,   0x864CFB)
+DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_32_IEEE,0, 32, 0x04C11DB7)
+DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_32_IEEE_LE, 1, 32, 0xEDB88320)
+DECLARE_CRC_INIT_TABLE_ONCE(AV_CRC_16_ANSI_LE, 1, 16, 0xA001)
 #endif
 
 int av_crc_init(AVCRC *ctx, int le, int bits, uint32_t poly, int ctx_size)
@@ -343,13 +349,16 @@ int av_crc_init(AVCRC *ctx, int le, int bits, uint32_t 
poly, int ctx_size)
 const AVCRC *av_crc_get_table(AVCRCId crc_id)
 {
 #if !CONFIG_HARDCODED_TABLES
-if (!av_crc_table[crc_id][FF_ARRAY_ELEMS(av_crc_table[crc_id]) - 1])
-if (av_crc_init(av_crc_table[crc_id],
-av_crc_table_params[crc_id].le,
-av_crc_table_params[crc_id].bits,
-av_crc_table_params[crc_id].poly,
-sizeof(av_crc_table[crc_id])) < 0)
-return NULL;
+switch (crc_id) {
+case AV_CRC_8_ATM:  CRC_INIT_TABLE_ONCE(AV_CRC_8_ATM); break;
+case AV_CRC_16_ANSI:CRC_INIT_TABLE_ONCE(AV_CRC_16_ANSI); break;
+case AV_CRC_16_CCITT:   CRC_INIT_TABLE_ONCE(AV_CRC_16_CCITT); break;
+case AV_CRC_24_IEEE:CRC_INIT_TABLE_ONCE(AV_CRC_24_IEEE); break;
+case AV_CRC_32_IEEE:CRC_INIT_TABLE_ONCE(AV_CRC_32_IEEE); break;
+case AV_CRC_32_IEEE_LE: CRC_INIT_TABLE_ONCE(AV_CRC_32_IEEE_LE); break;
+case AV_CRC_16_ANSI_LE: CRC_INIT_TABLE_ONCE(AV_CRC_16_ANSI_LE); break;
+default: av_assert0(0);
+}
 #endif
 return av_crc_table[crc_id];
 }
-- 
2.13.2

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

Re: [FFmpeg-devel] [PATCH 3/4] lavc: Add wrapped_avframe decoder

[Muhammad Faiz]

On Sun, Sep 3, 2017 at 5:21 AM, Mark Thompson  wrote:
> Intended for use with hardware frames for which rawvideo is not
> sufficient.
> ---
> Kindof nasty.  Any thoughts on better ways of achieving the same result 
> (hardware frames out of lavd) very welcome!
>
>
>  libavcodec/Makefile  |  1 +
>  libavcodec/allcodecs.c   |  2 +-
>  libavcodec/wrapped_avframe.c | 31 +++
>  3 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 999632cf9e..943e5db511 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -653,6 +653,7 @@ OBJS-$(CONFIG_WMV2_DECODER)+= wmv2dec.o 
> wmv2.o wmv2data.o \
>  OBJS-$(CONFIG_WMV2_ENCODER)+= wmv2enc.o wmv2.o wmv2data.o \
>msmpeg4.o msmpeg4enc.o 
> msmpeg4data.o
>  OBJS-$(CONFIG_WNV1_DECODER)+= wnv1.o
> +OBJS-$(CONFIG_WRAPPED_AVFRAME_DECODER) += wrapped_avframe.o
>  OBJS-$(CONFIG_WRAPPED_AVFRAME_ENCODER) += wrapped_avframe.o
>  OBJS-$(CONFIG_WS_SND1_DECODER) += ws-snd1.o
>  OBJS-$(CONFIG_XAN_DPCM_DECODER)+= dpcm.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index ce0bc7ecf3..625720578f 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -377,7 +377,7 @@ static void register_all(void)
>  REGISTER_DECODER(VQA,   vqa);
>  REGISTER_DECODER(BITPACKED, bitpacked);
>  REGISTER_DECODER(WEBP,  webp);
> -REGISTER_ENCODER(WRAPPED_AVFRAME,   wrapped_avframe);
> +REGISTER_ENCDEC (WRAPPED_AVFRAME,   wrapped_avframe);
>  REGISTER_ENCDEC (WMV1,  wmv1);
>  REGISTER_ENCDEC (WMV2,  wmv2);
>  REGISTER_DECODER(WMV3,  wmv3);
> diff --git a/libavcodec/wrapped_avframe.c b/libavcodec/wrapped_avframe.c
> index 14360320ff..e66f0cfa4c 100644
> --- a/libavcodec/wrapped_avframe.c
> +++ b/libavcodec/wrapped_avframe.c
> @@ -75,6 +75,28 @@ static int wrapped_avframe_encode(AVCodecContext *avctx, 
> AVPacket *pkt,
>  return 0;
>  }
>
> +static int wrapped_avframe_decode(AVCodecContext *avctx, void *data,
> +  int *got_frame, AVPacket *pkt)
> +{
> +AVFrame *in, *out;
> +int err;
> +
> +if (pkt->size < sizeof(AVFrame))
> +return AVERROR(EINVAL);
> +
> +in  = (AVFrame*)pkt->data;
> +out = data;
> +
> +err = ff_decode_frame_props(avctx, out);
> +if (err < 0)
> +return err;
> +
> +av_frame_move_ref(out, in);
> +
> +*got_frame = 1;
> +return 0;
> +}
> +
>  AVCodec ff_wrapped_avframe_encoder = {
>  .name   = "wrapped_avframe",
>  .long_name  = NULL_IF_CONFIG_SMALL("AVFrame to AVPacket 
> passthrough"),
> @@ -83,3 +105,12 @@ AVCodec ff_wrapped_avframe_encoder = {
>  .encode2= wrapped_avframe_encode,
>  .caps_internal  = FF_CODEC_CAP_INIT_THREADSAFE,
>  };
> +
> +AVCodec ff_wrapped_avframe_decoder = {
> +.name   = "wrapped_avframe",
> +.long_name  = NULL_IF_CONFIG_SMALL("AVPacket to AVFrame 
> passthrough"),
> +.type   = AVMEDIA_TYPE_VIDEO,
> +.id = AV_CODEC_ID_WRAPPED_AVFRAME,
> +.decode = wrapped_avframe_decode,
> +.caps_internal  = FF_CODEC_CAP_INIT_THREADSAFE,
> +};
> --
> 2.11.0

Security issues:
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/182985.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/af_firequalizer: add min_phase option

[Muhammad Faiz]

On Wed, Aug 23, 2017 at 1:38 AM, Muhammad Faiz <mfc...@gmail.com> wrote:
> Signed-off-by: Muhammad Faiz <mfc...@gmail.com>
> ---
>  doc/filters.texi  |   3 +
>  libavfilter/af_firequalizer.c | 147 
> +-
>  2 files changed, 147 insertions(+), 3 deletions(-)

Applied

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