[FFmpeg-devel] State of decklink_ctx vs. decklink_cctx
derfooser at icloud.com
Tue Mar 27 22:05:37 EEST 2018
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 <dheitmueller at ltnglobal.com> wrote:
> 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 Heitmueller - LTN Global Communications
> dheitmueller at ltnglobal.com
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel