[FFmpeg-devel] discussion around the best way to patch the swscale for Blackfin

[Marc Hoffman]

On 6/14/07, Marc Hoffman <mmhoffm at gmail.com> wrote:
>
>
>
> On 6/14/07, Reimar Doeffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>
> wrote:
> >
> > Hello,
> > On Thu, Jun 14, 2007 at 03:00:44PM -0400, Marc Hoffman wrote:
> > [...]
> > > What do you mean "doesn't allow to use special bfin converters only
> > for some
> > > colourspaces"?
> >
> > I mean that above where you inserted you new code there is e.g.:
> > c->swScale= gray16swap;
> > With your patch, this gray16swap will never be used for colourspace
> > conversion on blackfin, even if you do not have an optimized variant of
> > it (unless you also duplicate the selection code for non-optimzed
> > conversion in you new function, I can't know that from your patch of
> > course ;-) ).
>
>
>
> I think we are on the same page.
>
> I guess I was thinking that the  my function could choose to override but
> it doesn't need to do that.  The semantics of the function I would define
> would be something like this.
>
> SwsFunc ff_bfin_get_unscaled_swscale (SwsContext *c)
> {
>   SwsFunc swScale = c->swScale;
>   if ((c->flags & SWS_CPU_CAPS_BFIN) &&
>       ((c->dstFormat == PIX_FMT_YUV420P &&
>     (c->srcFormat == PIX_FMT_YUYV422 || c->srcFormat ==
> PIX_FMT_UYVY422)))) {
>     return ff_bfin_yuy2toyv12_unscaled;
>   }
>   return c->swScale;
> }
>
>
> This way I can freely add optimizations for Blackfin with out changing the
> existing infastructure. I guess in a sense its much like what the dsputils
> do right now.
>
> Maybe I should just do this in swscale
>
> #ifdef ARCH_BFIN
>     ff_bfin_get_unscaled_swscale (c);
> #endif
>
> And just do the following?
>
> void ff_bfin_get_unscaled_swscale (SwsContext *c)
> {
>   SwsFunc swScale = c->swScale;
>   if ((c->flags & SWS_CPU_CAPS_BFIN) &&
>       ((c->dstFormat == PIX_FMT_YUV420P &&
>     (c->srcFormat == PIX_FMT_YUYV422 || c->srcFormat ==
> PIX_FMT_UYVY422)))) {
>     c->swScale = ff_bfin_yuy2toyv12_unscaled;
>   }
> }
>
> Now that you came up with a bit of confusion I'm thinking the later might
> be a better choice for us.



Does this look like a clean integration for the unscaled variant for the
swscale infrastructure?  Seems reasonably clean to me but another set of
eyes would be great.

Thanks
Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s.patch
Type: application/octet-stream
Size: 3508 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070621/3a3f4a3a/attachment.obj>