On Mon, Feb 27, 2012 at 7:28 PM, Attila Kinali <[email protected]> wrote: > 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...
I will believe it when I see it. I have heard through the years of a lot of code that was supposed to be ready, yet never shipped. I'm not holding my breath for code that is not only not ready, but theoretical. In the meantime, I am naming the library libtidsp, since it doesn't collide with anything existing, or planned. >> > 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. Or you wouldn't be offensive about it. I have sent a new patch series using 'tidspbridge' which I still believe is ridiculously cumbersome. Cheers. -- Felipe Contreras _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
