So I haven't looked in great detail so this may all be info that you know, and maybe not helpful...
1. You can easily link C objects to C++ code by marking it `extern "C"` 2. You can not easily link C++ objects to C code, because there are classes, vtables, name mangling etc. 3. The solution for this interop is usually a shim layer that is compiled in C++ and has a C interface, and is imported as extern "C" so the names aren't mangled. 4. there are 2 common headers for decklink, one that can contain C++ symbols and one that contains only C symbols ( `IDeckLink` is a c++ class and can't be included C Code) So I don't know how you would really combine everything... you could keep the all of the DeckLink classes in the decklink_cctx as (void *) but that isn't elegant. The only thing that seems useful would be de-duplication of the duplicate fields and if those are only for state to be read on opening, then I dont know that is exactly useful either, but you could make an options struct and keep one ref to it in both contexts, they are similar but slightly different... > On Mar 27, 2018, at 12:27 PM, Devin Heitmueller <dheitmuel...@ltnglobal.com> > wrote: > > Hello, > > I’m continuing to do some cleanup work on the decklink libavdevice > input/output, and I’m trying to understand how the way state is managed has > evolved over time. > > Specifically, there are two key state structures - decklink_ctx and > decklink_cctx. It would appear the motivation behind this was to store any > C++ members (mainly stuff exported by the Blackmagic driver) in a context > which doesn’t need to be accessed by the C code. At one point I had assumed > the decklink_cctx was intended for the “capture" specific features (as > opposed to output), but after further review it looks like the goal is not > exposing the C++ members to the C code. > > My concern is that I’m seeing a couple of trends: > > 1. Lots of C members appearing in the decklink_ctx state (i.e. stuff that > could be in decklink_cctx). Presumably if the goal was to partition the C++ > stuff out, why not put everything except the actual C++ members into the > decklink_cctx state? > > 2. Duplicate members between the two state structs. Both structs contain a > number of the same members (e.g. list_devices, list_formats, etc). In some > cases the members are copied from one to the other after initialization, but > it’s not clear why the members are duplicated in the first place - why not > just reference the original member? > > Can anyone offer any background on how this evolved? I would like to see if > I can improve the situation, but I need to better understand what the goal(s) > were. Also as I’m adding new features to both capture and output, it would > be good to better understand which of the two structs is appropriate to own > the state information. > > Thanks in advance, > > Devin > > --- > Devin Heitmueller - LTN Global Communications > dheitmuel...@ltnglobal.com > > > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
