[FFmpeg-devel] [PATCH] lavfi: add xbr filter
Michael Niedermayer
michaelni at gmx.at
Thu Oct 30 21:49:27 CET 2014
On Fri, Oct 31, 2014 at 01:36:46AM +0530, arwa arif wrote:
> 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
> >
> doc/filters.texi | 5
> libavfilter/Makefile | 1
> libavfilter/allfilters.c | 1
> libavfilter/vf_xbr.c | 319 +++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 326 insertions(+)
> d35fb76ff4da98ec29266655f8e6868b20f738d5 0001-PATCH-lvafi-add-xbr-filter.patch
> From b9b56b594f856fef8b113b283df2d2045e8357f7 Mon Sep 17 00:00:00 2001
> From: Arwa Arif <arwaarif1994 at gmail.com>
> Date: Thu, 30 Oct 2014 22:06:20 +0530
> Subject: [PATCH] [PATCH]lvafi: add xbr filter
its still accessing outside the array
here output with valgrind
==11336== Invalid read of size 1
==11336== at 0x519A40: d.isra.0 (in ffmpeg_g)
==11336== by 0x519EF3: filter_frame (in ffmpeg_g)
==11336== by 0x4B4D07: ff_filter_frame_framed (in ffmpeg_g)
==11336== by 0x4B6F40: ff_filter_frame (in ffmpeg_g)
==11336== by 0x50E574: filter_frame (in ffmpeg_g)
==11336== by 0x4B4D07: ff_filter_frame_framed (in ffmpeg_g)
==11336== by 0x4B6F40: ff_filter_frame (in ffmpeg_g)
==11336== by 0x4BAFE1: request_frame (in ffmpeg_g)
==11336== by 0x4BB325: av_buffersrc_add_frame_internal (in ffmpeg_g)
==11336== by 0x4BB45D: av_buffersrc_add_frame_flags (in ffmpeg_g)
==11336== by 0x49C765: process_input_packet (in ffmpeg_g)
==11336== by 0x49F444: process_input (in ffmpeg_g)
==11336== by 0x486D04: main (in ffmpeg_g)
==11336== Address 0x1739ce9e is 2 bytes before a block of size 172,063 alloc'd
==11336== at 0x4C2A6C5: memalign (vg_replace_malloc.c:727)
==11336== by 0x4C2A760: posix_memalign (vg_replace_malloc.c:876)
==11336== by 0xE27CEF: av_malloc (in ffmpeg_g)
==11336== by 0xE1A7B7: av_buffer_alloc (in ffmpeg_g)
==11336== by 0xE215B4: av_frame_get_buffer (in ffmpeg_g)
==11336== by 0x51DF4A: ff_get_video_buffer (in ffmpeg_g)
==11336== by 0x50E351: filter_frame (in ffmpeg_g)
==11336== by 0x4B4D07: ff_filter_frame_framed (in ffmpeg_g)
==11336== by 0x4B6F40: ff_filter_frame (in ffmpeg_g)
==11336== by 0x4BAFE1: request_frame (in ffmpeg_g)
==11336== by 0x4BB325: av_buffersrc_add_frame_internal (in ffmpeg_g)
==11336== by 0x4BB45D: av_buffersrc_add_frame_flags (in ffmpeg_g)
==11336== by 0x49C765: process_input_packet (in ffmpeg_g)
==11336== by 0x49F444: process_input (in ffmpeg_g)
==11336== by 0x486D04: main (in ffmpeg_g)
==11336==
==11336== Invalid read of size 1
==11336== at 0x519A4F: d.isra.0 (in ffmpeg_g)
==11336== by 0x519EF3: filter_frame (in ffmpeg_g)
==11336== by 0x4B4D07: ff_filter_frame_framed (in ffmpeg_g)
==11336== by 0x4B6F40: ff_filter_frame (in ffmpeg_g)
==11336== by 0x50E574: filter_frame (in ffmpeg_g)
==11336== by 0x4B4D07: ff_filter_frame_framed (in ffmpeg_g)
==11336== by 0x4B6F40: ff_filter_frame (in ffmpeg_g)
==11336== by 0x4BAFE1: request_frame (in ffmpeg_g)
==11336== by 0x4BB325: av_buffersrc_add_frame_internal (in ffmpeg_g)
==11336== by 0x4BB45D: av_buffersrc_add_frame_flags (in ffmpeg_g)
==11336== by 0x49C765: process_input_packet (in ffmpeg_g)
==11336== by 0x49F444: process_input (in ffmpeg_g)
==11336== by 0x486D04: main (in ffmpeg_g)
==11336== Address 0x1739ce9f is 1 bytes before a block of size 172,063 alloc'd
==11336== at 0x4C2A6C5: memalign (vg_replace_malloc.c:727)
==11336== by 0x4C2A760: posix_memalign (vg_replace_malloc.c:876)
==11336== by 0xE27CEF: av_malloc (in ffmpeg_g)
==11336== by 0xE1A7B7: av_buffer_alloc (in ffmpeg_g)
==11336== by 0xE215B4: av_frame_get_buffer (in ffmpeg_g)
==11336== by 0x51DF4A: ff_get_video_buffer (in ffmpeg_g)
==11336== by 0x50E351: filter_frame (in ffmpeg_g)
==11336== by 0x4B4D07: ff_filter_frame_framed (in ffmpeg_g)
==11336== by 0x4B6F40: ff_filter_frame (in ffmpeg_g)
==11336== by 0x4BAFE1: request_frame (in ffmpeg_g)
==11336== by 0x4BB325: av_buffersrc_add_frame_internal (in ffmpeg_g)
==11336== by 0x4BB45D: av_buffersrc_add_frame_flags (in ffmpeg_g)
==11336== by 0x49C765: process_input_packet (in ffmpeg_g)
==11336== by 0x49F444: process_input (in ffmpeg_g)
==11336== by 0x486D04: main (in ffmpeg_g)
...
[...]
> +static int filter_frame(AVFilterLink *inlink, AVFrame *in)
> +{
> + AVFilterContext *ctx = inlink->dst;
> + AVFilterLink *outlink = ctx->outputs[0];
> + int i,j;
> + xBRContext *xBR = ctx->priv;
> + const uint32_t *r2y = xBR->rgbtoyuv;
> + AVFrame *out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
> + if (!out) {
> + av_frame_free(&in);
> + return AVERROR(ENOMEM);
> + }
> +
> + av_frame_copy_props(out, in);
> + for (i=0; i<inlink->w; i++)
> + for (j=0; j<inlink->h; j++)
> + apply_edge_detection_rules(in, out, i, j, r2y);
tab,
maybe you can configure your editor not to insert tabs
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141030/80192405/attachment.asc>
More information about the ffmpeg-devel
mailing list