| Message ID | CAB0OVGph61DCkW3HCEDvgdUyx3nZ+8sK7uXDebaNWwThs6hVnQ@mail.gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
Hi, On Sat, Sep 30, 2017 at 3:40 PM, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > 2017-09-30 20:30 GMT+02:00 Ronald S. Bultje <rsbultje@gmail.com>: > > Hi Carl, > > > > On Sat, Sep 30, 2017 at 2:19 PM, Carl Eugen Hoyos <ceffmpeg@gmail.com> > > wrote: > > > >> 2017-09-30 19:47 GMT+02:00 Ronald S. Bultje <rsbultje@gmail.com>: > >> > Hi Carl, > >> > > >> > On Sat, Sep 30, 2017 at 1:31 PM, Carl Eugen Hoyos <ceffmpeg@gmail.com > > > >> > wrote: > >> > > >> >> Hi! > >> >> > >> >> 2017-09-15 22:47 GMT+02:00 Ashish Pratap Singh <ashk43712@gmail.com > >: > >> >> > >> >> > +static int query_formats(AVFilterContext *ctx) > >> >> > +{ > >> >> > + static const enum AVPixelFormat pix_fmts[] = { > >> >> > + AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV422P, > >> >> > AV_PIX_FMT_YUV420P, > >> >> > + AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV422P10, > >> >> > AV_PIX_FMT_YUV420P10, > >> >> > >> >> Is the algorithm only defined for these formats and bit-depth > >> >> or are there just missing features? > >> >> Gray and gray10 come to mind... > >> >> > >> > > >> > Great question! I _believe_ that vmaf overall is luma-only, so it > should > >> be > >> > entirely independent of chroma. > >> > >> Then imo, above function is just wrong, it should check for > >> non-rgb or similar (think of YUVA444 and friends). > >> > > > > I don't think I'm familiar enough with lavfi to send a patch, can you > send > > one? What I've asked Ashish to do (and what he's done here) is simply to > > reproduce as closely as possible what Netflix' code does, and they only > > support 420, 422 and 444 for 8 and 10 bits/component. I'm happy to > support > > more if I know how to. > > Attached patch also support GBRP, I don't know if this is a good or > bad idea. > I would personally probably err on the side of caution, but no strong opinions. If this works (I assume it does), I guess it's fine (?). Ronald
2017-10-01 14:03 GMT+02:00 Ronald S. Bultje <rsbultje@gmail.com>: > Hi, > > On Sat, Sep 30, 2017 at 3:40 PM, Carl Eugen Hoyos <ceffmpeg@gmail.com> > wrote: >> Attached patch also support GBRP, I don't know if this is a good or >> bad idea. > > I would personally probably err on the side of caution, but no strong > opinions. If this works (I assume it does), I guess it's fine (?). Do you want me to commit (with or without GBRP)? Sorry, I really don't know if this is supposed to do something useful or not. Carl Eugen
Hi, On Sun, Oct 1, 2017 at 12:17 PM, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > 2017-10-01 14:03 GMT+02:00 Ronald S. Bultje <rsbultje@gmail.com>: > > Hi, > > > > On Sat, Sep 30, 2017 at 3:40 PM, Carl Eugen Hoyos <ceffmpeg@gmail.com> > > wrote: > > >> Attached patch also support GBRP, I don't know if this is a good or > >> bad idea. > > > > I would personally probably err on the side of caution, but no strong > > opinions. If this works (I assume it does), I guess it's fine (?). > > Do you want me to commit (with or without GBRP)? > > Sorry, I really don't know if this is supposed to do something > useful or not. > vmafmotion in itself isn't very useful, but it's part of the native vmaf filter, which will be quite useful. I'd suggest to commit it without GBRP support for now. I'm not against GBRP support per se, I just don't know if the results are meaningful (since we'd base the metric on the G channel only), so I'd rather be conservative. Ronald
2017-10-01 20:44 GMT+02:00 Ronald S. Bultje <rsbultje@gmail.com>: > Hi, > > On Sun, Oct 1, 2017 at 12:17 PM, Carl Eugen Hoyos <ceffmpeg@gmail.com> > wrote: > >> 2017-10-01 14:03 GMT+02:00 Ronald S. Bultje <rsbultje@gmail.com>: >> > Hi, >> > >> > On Sat, Sep 30, 2017 at 3:40 PM, Carl Eugen Hoyos <ceffmpeg@gmail.com> >> > wrote: >> >> >> Attached patch also support GBRP, I don't know if this is a good or >> >> bad idea. >> > >> > I would personally probably err on the side of caution, but no strong >> > opinions. If this works (I assume it does), I guess it's fine (?). >> >> Do you want me to commit (with or without GBRP)? >> >> Sorry, I really don't know if this is supposed to do something >> useful or not. >> > > vmafmotion in itself isn't very useful, but it's part of the native vmaf > filter, which will be quite useful. > > I'd suggest to commit it without GBRP support for now. I'm not against GBRP > support per se, I just don't know if the results are meaningful (since we'd > base the metric on the G channel only), so I'd rather be conservative. Pushed without GBRP, thank you! Carl Eugen
From c7da156438424bf9b08aaddaada4967868d28105 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos <ceffmpeg@gmail.com> Date: Sat, 30 Sep 2017 21:39:08 +0200 Subject: [PATCH] lavfi/vmafmotion: Allow more pix_fmts. --- libavfilter/vf_vmafmotion.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/libavfilter/vf_vmafmotion.c b/libavfilter/vf_vmafmotion.c index 6b6150a..48986b7 100644 --- a/libavfilter/vf_vmafmotion.c +++ b/libavfilter/vf_vmafmotion.c @@ -261,15 +261,19 @@ int ff_vmafmotion_init(VMAFMotionData *s, static int query_formats(AVFilterContext *ctx) { - static const enum AVPixelFormat pix_fmts[] = { - AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV420P, - AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV420P10, - AV_PIX_FMT_NONE - }; - - AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts); - if (!fmts_list) - return AVERROR(ENOMEM); + AVFilterFormats *fmts_list = NULL; + int format, ret; + + for (format = 0; av_pix_fmt_desc_get(format); format++) { + const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(format); + if (!(desc->flags & (AV_PIX_FMT_FLAG_HWACCEL | AV_PIX_FMT_FLAG_BITSTREAM | AV_PIX_FMT_FLAG_PAL)) && + (desc->flags & AV_PIX_FMT_FLAG_PLANAR || desc->nb_components == 1) && + (!(desc->flags & AV_PIX_FMT_FLAG_BE) == !HAVE_BIGENDIAN || desc->comp[0].depth == 8) && + (desc->comp[0].depth == 8 || desc->comp[0].depth == 10) && + (ret = ff_add_format(&fmts_list, format)) < 0) + return ret; + } + return ff_set_common_formats(ctx, fmts_list); } -- 1.7.10.4