On 21/02/17 07:35, wm4 wrote: > 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.
With mapping for all supported names in both directions it looks like avconv_hw.c actually loses its table entirely (the HWDeviceType there disappears as well), so I think that's a win. I'll change all of it. >>> 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. It then needs a separate table for the names so that they are always present, so that can be lower-case and the problem goes away. Will change. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
