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
