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...@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@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > >
> From 905fb0f15033e447fc344097dd649ca671fa1074 Mon Sep 17 00:00:00 2001 > From: Arwa Arif <arwaarif1...@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@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
