On Mon, 20 Feb 2017 22:03:50 +0000 Mark Thompson <[email protected]> wrote:
> On 20/02/17 05:42, wm4 wrote: > > On Sun, 19 Feb 2017 18:46:24 +0000 > > Mark Thompson <[email protected]> wrote: > > > >> --- > >> libavutil/hwcontext.c | 11 +++++++++++ > >> libavutil/hwcontext.h | 8 ++++++++ > >> 2 files changed, 19 insertions(+) > >> > >> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c > >> index 1f9442622..e3484c78c 100644 > >> --- a/libavutil/hwcontext.c > >> +++ b/libavutil/hwcontext.c > >> @@ -18,6 +18,7 @@ > >> > >> #include "config.h" > >> > >> +#include "avstring.h" > >> #include "buffer.h" > >> #include "common.h" > >> #include "hwcontext.h" > >> @@ -47,6 +48,16 @@ static const HWContextType * const hw_table[] = { > >> NULL, > >> }; > >> > >> +enum AVHWDeviceType av_hwdevice_find_type_by_name(const char *name) > >> +{ > >> + int i; > >> + for (i = 0; hw_table[i]; i++) { > >> + if (!av_strcasecmp(hw_table[i]->name, name)) > >> + return hw_table[i]->type; > >> + } > >> + return -1; > >> +} > >> + > > > > You could argue that this shouldn't depend on whether the > > implementation is compiled-in. > > You could - would you like to so argue? > > I don't mind, it was easier to do this way because the list would have to be > duplicated. (The difference in current code is between hwmap saying "Invalid > device type" and "Failed to created derived device context".) Depends how useful this should be. If we add a reverse map function, it'd probably be pretty useful, and we could eventually drop duplicated tables in user code (such as avconv), although there are other bits missing yet. Compare to pixfmts: they're always present, and can be parsed/stringified, even if they don't make sense on a specific platform. Likewise we have codec and profile strings even if there are no decoders or encoders. I think it'd be strange that string conversion would fail just because a hwcontext is not compiled it. But you're writing the patch, so it depends on how strongly you feel about about redoing it, or how much you think there's an actual worth in providing the functionality in the way I advocated for. Maybe an elenril opinion on this would be good too. > > Why is it case-insensitive? > > Again don't mind. Current strings are upper-case, but I wanted to use > lower-case in avconv. I guess the user can do tolower() or whatever anyway. > > Feel free make an arbitrary choice and I'll do it. I'd suggest making the current names all lowe-case, and switching to strcmp. Or having a separate table for the names. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
