On Mon, Feb 27, 2012 at 6:48 PM, Attila Kinali <[email protected]> wrote: > On Mon, 27 Feb 2012 17:54:32 +0200 > Felipe Contreras <[email protected]> wrote: > >> 2012/2/27 Måns Rullgård <[email protected]>: >> > Felipe Contreras <[email protected]> writes: >> > >> >> 2012/2/27 Måns Rullgård <[email protected]>: >> >>> Felipe Contreras <[email protected]> writes: >> >> The name is libtidsp. You get to call libav support for libtidsp >> >> whatever you want, but anything other than libtidsp, or tidsp, is >> >> *inconsistent*. Kind of calling vaapi hwaccel, intellink hwaccel. > [...] >> >> That's not up to you, all you can decide is if to be inconsistent, or not. > > 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. > 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. Cheers. -- Felipe Contreras _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
