On Mon, 27 Feb 2012 19:15:51 +0200
Felipe Contreras <[email protected]> wrote:
> > Uhmm. Have you considered that from the point of view of libav
> > that tidsp is in itself inconsistent? Libav has to consider way more
> > than just a chip or a library out there. Hence it tries to be consistent
> > over all that it supports and possible will support. This decision can
> > be influenced by what the libraries the module is based on is named but
> > does not have to be. In this case tidsp would be incosistent and misleading.
> > If i'd read "tidsp" somewhere, i'd imediatly think about a TMS320 support
> > and not about a TMS320-in-OMAP3-funnelling support.
>
> I see your point; you mean that libav would be running on the DSP, and
> libtidsp would provide certain utilities to accelerate certain libav
> functions. I think that's pretty far-fetched. I would name that
> library libtidsp-util anyway, or something like that.
Believe me, that's not so far fetched as it might seem...
> > In my oppinion you should accept Vladimirs advice and name it tidspbridge.
> > Otherwise i fear your patch will not be accepted. Of course unless it's
> > your intention to make your patch inacceptable in order to call names,
> > because "they" refused to accept your patch...
> > ...but i think you are not playing that dirty, are you?
>
> I still believe that's inconsistent and cumbersome, but I'll consider
> it. However, given the responses received so far, which I think are
> not reasonable, I don't really feel any motivation to do that any time
> soon.
>
> Moreover, I wanted to use this code through gst-av -> libav ->
> libtidsp, but right now there are certain bottlenecks that makes that
> whole thing inefficient (compared to gst-dsp).
>
> So I guess I will be working on gst-dsp-ng -> libtidsp (or something
> like that) right now, since I don't see a smooth path to resolve the
> issues I see with the libav interfaces, and merge path.
Well, it would help to concentrate on the real issues, like this
bottleneck, if you wouldnt be so defensive about the name. I'm
quite sure that this feature would interest more than just the N900/N9
users. At least there are a few OMAP3 devices out there that are
in TI's catalog, ie which will be produces in industrial time scales
(probably for 10y or longer).
Attila Kinali
--
Why does it take years to find the answers to
the questions one should have asked long ago?
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
