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

Michael Niedermayer michaelni at gmx.at
Thu Oct 30 14:32:30 CET 2014


On Thu, Oct 30, 2014 at 06:23:35PM +0530, arwa arif wrote:
> 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
> >
> >

>  doc/filters.texi         |    5 
>  libavfilter/Makefile     |    1 
>  libavfilter/allfilters.c |    1 
>  libavfilter/vf_xbr.c     |  319 +++++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 326 insertions(+)
> 9b29290b32395a8f580cf4e5bc88aed162ad69f4  0001-PATCH-lvafi-add-xbr-filter.patch
> 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
> 
> ---
>  doc/filters.texi         |   81 ++----------
>  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
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 7be29de..253384b 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> + at section xbr
> +Apply high-quality magnification filter which is designed for pixel art. It follows a set
> +of edge-detection rules @url{http://www.libretro.com/forums/viewtopic.php?f=6&t=134}.
> +This filter was originally created by Hyllian.
> +
>  @anchor{yadif}
>  @section yadif
>  
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile

that patch doesnt apply

without the docs hunk, the rest still segfaults:

./ffmpeg -i images.jpeg -vf xbr -f null -

==19872==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f357062c7fd at pc 0x0000006ae2e6 bp 0x7ffff4d5cd90 sp 0x7ffff4d5cd88
READ of size 1 at 0x7f357062c7fd thread T0
    #0 0x6ae2e5 in d libavfilter/vf_xbr.c:55:5
    #1 0x6ad8eb in apply_edge_detection_rules libavfilter/vf_xbr.c:128:21
    #2 0x6ad6a7 in filter_frame libavfilter/vf_xbr.c:261:6
    #3 0x5a79d5 in ff_filter_frame_framed libavfilter/avfilter.c:1103:11
    #4 0x68b5fd in filter_frame libavfilter/vf_scale.c:530:12
    #5 0x5a79d5 in ff_filter_frame_framed libavfilter/avfilter.c:1103:11
    #6 0x5bb201 in request_frame libavfilter/buffersrc.c:499:12
    #7 0x5b92e3 in av_buffersrc_add_frame_internal libavfilter/buffersrc.c:181:20
    #8 0x5b8bdf in av_buffersrc_add_frame_flags libavfilter/buffersrc.c:106:16
    #9 0x558bee in decode_video ffmpeg.c:1989:15
    #10 0x552c78 in process_input_packet ffmpeg.c:2123:19
    #11 0x560cb8 in process_input ffmpeg.c:3561:11
    #12 0x55094e in transcode_step ffmpeg.c:3655:11
    #13 0x54745b in transcode ffmpeg.c:3707:15
    #14 0x5468c2 in main ffmpeg.c:3883:9
    #15 0x7f3582b6476c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
    #16 0x51bdfc in _start (ffmpeg_g+0x51bdfc)

0x7f357062c7fd is located 3 bytes to the left of 172063-byte region [0x7f357062c800,0x7f357065681f)
allocated by thread T0 here:
    #0 0x4ff03f in __interceptor_posix_memalign (ffmpeg_g+0x4ff03f)
    #1 0x191eac1 in av_malloc libavutil/mem.c:95:9
    #2 0x1903ff4 in av_buffer_alloc libavutil/buffer.c:70:12
    #3 0x1912393 in get_video_buffer libavutil/frame.c:175:25
    #4 0x6b69c6 in ff_default_get_video_buffer libavfilter/video.c:55:11
    #5 0x68a9e3 in filter_frame libavfilter/vf_scale.c:465:11
    #6 0x5a79d5 in ff_filter_frame_framed libavfilter/avfilter.c:1103:11
    #7 0x5bb201 in request_frame libavfilter/buffersrc.c:499:12
    #8 0x5b92e3 in av_buffersrc_add_frame_internal libavfilter/buffersrc.c:181:20
    #9 0x5b8bdf in av_buffersrc_add_frame_flags libavfilter/buffersrc.c:106:16
    #10 0x558bee in decode_video ffmpeg.c:1989:15
    #11 0x552c78 in process_input_packet ffmpeg.c:2123:19
    #12 0x560cb8 in process_input ffmpeg.c:3561:11
    #13 0x55094e in transcode_step ffmpeg.c:3655:11
    #14 0x54745b in transcode ffmpeg.c:3707:15
    #15 0x5468c2 in main ffmpeg.c:3883:9
    #16 0x7f3582b6476c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- 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/735fdc67/attachment.asc>


More information about the ffmpeg-devel mailing list