On 3/12/17, Marton Balint <[email protected]> wrote:
>
> On Sat, 11 Mar 2017, Paras Chadha wrote:
>
>> On Sat, Mar 11, 2017 at 5:40 AM, Moritz Barsnick <[email protected]> wrote:
>>
>>>
>>> > +static int color_table_compare(const void *lhs, const void *rhs)
>>> > +{
>>> > + return av_strcasecmp(lhs, ((const ColorEntry *)rhs)->name);
>>> > +}
>>> > +
>>> > +static const ColorEntry color_table[] = {
>>> > + { "AliceBlue", { 0xF0, 0xF8, 0xFF } },
>>> > + { "AntiqueWhite", { 0xFA, 0xEB, 0xD7 } },
>>> > + { "Aqua", { 0x00, 0xFF, 0xFF } },
>>> [...]
>>>
>>> Is this duplicated from libavutil/parseutils.c?
>>>
>>
>> Yes, it is duplicated from parseutils.c
>> XPM format also specifies a color None which is transparent, it has been
>> added to the array.
>> Also ColorEntry is changed a bit.
>> These changes are in my next patch.
>>
>
> Why don't you improve the code in parseutils then, and use that?
> Duplicating code is generally not welcome without a good reason.
There is very good reason. There are even values for colors that conflict
with one presented in parseutils. There are even more colors to be added to XPM.
>
>>
>>>
>>> > +static uint32_t hexstring_to_rgba(const char *p, int len){
>>> > + uint32_t ret = 0xFF000000;
>>> > + const ColorEntry *entry;
>>> > + char color_name[100];
>>> > +
>>> > + if(*p == '#'){
>>> > + p++;
>>> > + len--;
>>> > + if (len == 3) {
>>> > + ret |= (convert(p[2]) << 4) |
>>> > + (convert(p[1]) << 12) |
>>> > + (convert(p[0]) << 20);
>>>
>>> So is this a modified or redesigned av_parse_color()? Just wondering.
>>>
>>
>> Yes, it is redesigned version of av_parse_color(). It is a bit fast than
>> the original.
>
> So please integrate your changes in parseutils, and use that if you can,
> unless there is a reason for the duplication.
parseutils have different code and its code is slower.
We tried to use it and found its not what XPM decoder needs.
_______________________________________________
ffmpeg-devel mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
