[FFmpeg-devel] [PATCH] lavfi: add xbr filter

[Stefano Sabatini]

On date Thursday 2014-10-30 18:23:35 +0530, arwa arif encoded:
> On Wed, Oct 29, 2014 at 3:36 AM, Clément Bœsch <u at pkh.me> wrote:
> 
> > On Tue, Oct 28, 2014 at 10:51:27PM +0100, Michael Niedermayer wrote:
> > > On Tue, Oct 28, 2014 at 07:16:45PM +0100, Clément Bœsch wrote:
> > > > On Tue, Oct 28, 2014 at 06:30:34PM +0100, Stefano Sabatini wrote:
> > > > [...]
> > > > > How much effort would it take to implement the remaining scaling
> > modes?
> > > > >
> > > >
> > > > According to
> > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164574.html
> > > >
> > > > "I think 4x can be done fast enough, but 3x will take time."
> > > >
> > > > [...]
> > > > > > +typedef struct {
> > > > > > +    uint32_t rgbtoyuv[1<<24];
> > > > >
> > > > > We should avoid this 64MiB. Also the table should be possibly static,
> > > > > so you don't have to fill it per each xBR instance.
> > > > >
> > > >
> > > > So, I requested to do it exactly the same as HQx because this part is
> > > > common according to the specifications. This should be kept the same
> > > > vf_hqx, and then factorized.
> > > >
> > >
> > > > Now about removing this allocation, I did benchmark this LUT vs
> > > > computation (see attached patch for comp. version). And the problem is
> > > > that it's slightly slower, probably due to the /1000.
> > >
> > > why do you divide at all ?
> > > cant you do the computations with full precission ?
> >
> > I wasn't able to... but I was probably doing it wrong.
> >
> > And anyway, so far I observed this:
> >   lut:         127fps
> >   nolut+div:   119fps
> >   nolut+nodiv: 123fps
> >
> > So even with "fast" computation, it's still slower than the LUT. It
> > probably
> > doesn't matter that much in practice, and dropping that huge table might be
> > worth the performance impact (feel free to discuss).
> >
> > Note that looking at the original code (which was working on rgb565 only),
> > it was bitexact. The rgb 24-bit was added in the "modern" hqx with float
> > point. So we can probably tolerate the inaccuracy. Still, if you find a
> > way of keeping full accuracy with the modern implementation...
> >
> > Typically, I tried stuff like this:
> >
> >   const uint32_t y = (uint32_t)((1225*r + 2404*g +  467*b + (1<<11)) >>
> > 12);
> >   const uint32_t u = (uint32_t)((-692*r - 1356*g + 2048*b + (1<<11)) >>
> > 12) + 128;
> >   const uint32_t v = (uint32_t)((2048*r - 1716*g -  332*b + (1<<11)) >>
> > 12) + 128;
> >
> > ...but I'm probably doing it very wrong somewhere (sign issue maybe?),
> > haven't
> > looked deeper. I went up to 15 bits, still didn't match, so I was probably
> > doing something stupid.
> >
> > > also instead of doing 2 rgb2yuv and then taking their difference you
> > > can do the difference in rgb space and convert the rgb difference to
> > > a yuv difference
> > > its just aM - bM = (a-b)M
> >
> > Ah, sounds like a good idea, I guess I'll try that.
> >
> > [...]
> >
> > --
> > Clément B.
> >
> > Updated the patch. How should I finally go about converting rgb to yuv?
> 
> 
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >

> From 905fb0f15033e447fc344097dd649ca671fa1074 Mon Sep 17 00:00:00 2001
> From: Arwa Arif <arwaarif1994 at gmail.com>
> Date: Thu, 30 Oct 2014 18:05:45 +0530
> Subject: [PATCH] [PATCH]lvafi: add xbr filter

lavfi: add xbr filter

> 
> ---

>  doc/filters.texi         |   81 ++----------

what happened with this? Did you edit the patch by hand? I can't apply
the patch...

>  libavfilter/Makefile     |    1 +
>  libavfilter/allfilters.c |    1 +
>  libavfilter/vf_xbr.c     |  319 ++++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 335 insertions(+), 67 deletions(-)
>  create mode 100644 libavfilter/vf_xbr.c
> 
[...]
-- 
FFmpeg = Fostering Fundamental Minimal Plastic Enhanced Geisha