[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