Hi.

On Mon, Aug 22, 2016 at 7:52 PM, James Almer <jamr...@gmail.com> wrote:
> A couple comments about the library.
>
> -The name hdcd_decode2 is still used in some places after your rename
> commit, like the installed header and main c file.
That is intentional. I want to keep the code there compatible with
foo_hdcd, with my additions all optional. foo_hdcd just drops
hdcd_decode2.{c,h} in, it doesn't use the shared library.
I've added a line to README.md that specifies the include line to use.

> -Does every struct currently defined in the installed header need to be
> there? Most if not all of the stuff in both hdcd_state_* structs kinda
> look like it could be internal, much like it currently is in af_hdcd.c
There could possibly be a simpler api that exposes less, but again,
foo_hdcd looks into those structures directly, I want to remain
compatible there. If you look at README.md, you should see that the
api is very simple to use as it is, even with the large exposure in
the header. The logging callback, detection, analyze mode, are all
optional features. The library does build as a windows dll, but I
don't know that the maintainer of foo_hdcd will be interested in that.

> You can play around with the API until you tag a first release.
I will do that soon.

> -Make the flags field int and update the relevant function signatures.
> You may not intend to add new flags now, but you may in the future, and
> uint8_t is too small for that.
Perhaps, ok.

> -Make sure it builds a shared library and symbols are visible.
It does build and work as a shared library as I far as I have tested
it, which is everything I can think of. Is there something specific
that is not visible or working?

> -Some doxy for the public functions would be nice.
I will add some code comments for that.

Thanks for your comments, any more are welcome.

--
Burt
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to