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

[arwa arif]

On Thu, Oct 30, 2014 at 9:34 PM, Stefano Sabatini <stefasab at gmail.com>
wrote:

> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-PATCH-lvafi-add-xbr-filter.patch
Type: text/x-patch
Size: 13325 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141031/661536b9/attachment.bin>