[FFmpeg-devel] [PATCH 2/2] lavd: add decklink output device

Reimar Döffinger Reimar.Doeffinger at gmx.de
Tue Jan 14 00:08:22 CET 2014



On 13.01.2014, at 04:22, Ramiro Polla <ramiro.polla at gmail.com> wrote:

> On Sat, Dec 28, 2013 at 6:31 PM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
>> On Sat, Dec 28, 2013 at 05:06:16PM -0200, Ramiro Polla wrote:
>>> Hi Reimar,
>>> 
>>> On Sat, Dec 28, 2013 at 1:23 PM, Reimar Döffinger
>>> <Reimar.Doeffinger at gmx.de> wrote:
>>>> On 26.12.2013, at 02:44, Ramiro Polla <ramiro.polla at gmail.com> wrote:
>>>>> Attached patch adds decklink output support to lavd. Works under Linux
>>>>> and Windows.
>>>> 
>>>> Maybe a bit crazy, but how about splitting the C++ part out even more?
>>>> So that we can use designated initializers like for all other demuxers.
>>>> Otherwise it will break as soon as we add a new field in the middle, and in addition unless you add FATE testing that works without the hardware/library "nobody" will even notice.
>>> 
>>> I thought about so too. On Windows it is possible to use COBJMACROS
>>> and write the code in C. But for Linux only a C++ interface is
>>> provided. What do you think about putting just the AVOption, AVClass
>>> and AVOutputFormat in a C file?
>> 
>> Yes, either that or basically do a C++-to-C wrapper for the library.
>> I guess both will look quite similar.
>> As said, not sure if it's really worth it, but it _sounds_ better so
>> far.
> 
> In ff_decklink_muxer, there's a sizeof(struct decklink_ctx), which
> contains a class* inside it. So that has to be c++ unless we make some
> hacks using void* or somesuch. Ideas?

Void * should work fine.
You can also use an opaque struct decklink_stuff that is only fully declared in the C++ part and contains all the classes.
Means an additional allocation and deallocation for that sub-part though.


More information about the ffmpeg-devel mailing list