[FFmpeg-devel] [PATCH 4/5] drawutils: new API.
nicolas.george at normalesup.org
Sun Mar 11 00:07:07 CET 2012
Le decadi 20 ventôse, an CCXX, Stefano Sabatini a écrit :
> uhmmm maybe we could create a special logging context for DrawContext,
> drop the error message altogether and/or return an error code.
Ideally, this error should never be visible: when support for a new pixel
format is added to the functions, it should be added to _color too, this is
not much work.
I added a test program that walks all the pixels formats and detects which
ones are supported, and which ones lack support for color. Then I fixed the
six that were missing support for color: 0rgb and permutations, gray(8a).
> > +static uint8_t *pointer_at(FFDrawContext *draw, uint8_t *data, int linesize,
> maybe turn it to a macro or an inline function
I think we can afford to trust the compiler to do whatever is best, as it is
not used in an inner loop. With ffmpeg's normal build options, gcc 4.6 seems
to decide to inline.
> Add something along the lines of:
> Only a limited number of pixel formats is supported, if format is not
> supported the function will return an error.
By the way, is it obvious that I intend that if a filter is built using only
this API, it should automatically start working with pixel formats if they
are added to drawutils?
> copy&paste error
> Mention how to "prepare" a color.
> > +AVFilterFormats *ff_draw_supported_pixel_formats(void);
Added a flags argument, same as _init.
Rationale for the flags argument: if, in the future, there are a subset a
functions that work with a lot of pixel formats, and another subset that
work with only a few, a filter that only uses the first should be able to
> Looks fine otherwise, but testing this new API with FATE before to
> commit it may help to spot eventual errors.
What do you mean exactly?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel