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...@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 > > > >
> 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 <arwaarif1...@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
> +@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
