On Sun, 02 Mar 2008 18:11:10 +0100 Vitor Sessak <[EMAIL PROTECTED]> wrote:
> Hi > > Bobby Bingham wrote: > > On Sun, 02 Mar 2008 15:00:34 +0100 > > Vitor Sessak <[EMAIL PROTECTED]> wrote: > >> Bobby Bingham wrote: > >>> On Thu, 28 Feb 2008 00:18:59 +0100 (CET) > >>> koorogi <[EMAIL PROTECTED]> wrote: > >>> > >>>> Author: koorogi > >>>> Date: Thu Feb 28 00:18:58 2008 > >>>> New Revision: 1932 > >>>> > >>>> Log: > >>>> Slice support for vf_scale. > >>>> > >>>> > >>>> Modified: > >>>> libavfilter/vf_scale.c > >>>> > >> [...] > >> > >>> After some more testing, it seems this doesn't work right with > >>> --enable-swscaler. I'll take a closer look at it later tonight. > >> I was wondering one thing: imagine doing a 200x200 -> 400x400 > >> linear interpolation resizing. > >> > >> The filter gets as input a (for ex.) 4x100 slice. It can then > >> interpolate the line numbers (1,2,3,4,5,6,7) of the output. For the > >> next slice, it would be able to output the lines > >> (9,10,11,12,13,14,15). But to evaluate the output line 8, it'll > >> need both the input line 4 and 5. So to do slice-based resizing, > >> it would be necessary a complicated, resize algorithm dependent, > >> caching. Also it would require some kind of memcpy. > >> > >> So my opinion is that implementing slices in resizing is hard and > >> maybe not worth the effort. In the other hand, colospace conversion > >> should be pretty simple. Or am I missing something? > >> > > > > I believe that this caching is already implemented by libswscale. > > Does imgresample.c also support this? It doesn't appear to. Hmmm... Maybe it's a good time to implement some flags to let filters tell the system that they require full-frame slices, and make vf_scale use that in the imgresample.c case. -- Bobby Bingham Never trust atoms. Or anything made of atoms. このメールは再利用されたバイトでできている。 _______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
