On Mon, 13 Feb 2023 18:02:27 +0000
Jon Turney wrote:
> On 06/02/2023 12:21, Takashi Yano via Cygwin-apps wrote:
> > On Sun, 5 Feb 2023 16:33:45 +0000
> > Jon Turney wrote:
> >> On 05/02/2023 08:40, Takashi Yano via Cygwin-apps wrote:
> >>> [ITP]
[...]
> >>> AMF: for ffmpeg (new)
[...]
> >>> nv-codec-headers : for ffmpeg (new)
> >>
> >> I have a question about how this (and AMF I guess) works.
> >>
> >> Are these headers which implement the whole codec? or do they expect the
> >> codec to be accessible via the driver somehow?
> > 
> > nv-codec-headers provides header files which dynamically
> > loads nvcuda.dll, nvcuvid.dll and nvEncodeAPI{,64}.dll.
> > 
> > Similary, AMF loads amfrt{64,32}.dll dinamically.
> > 
> > The codec itself is implemented in the dlls which is provided
> > by nVidia/AMD. mfx_dispatch also does the similar. It loads
> > some dlls dynamically privided by Intel.
> 
> I see.
> 
> It might be helpful to mention that (in general terms) in the 
> description for those packages.

I have added descriptions to cygport files each of AMF,
nv-codec-headers and mfx_dispatcher.

> Generally, there are some ABI concerns with using interfaces like this, 
> e.g.:
> 
> i) You need to be sure that Windows API sized types are used (e.g. 
> DWORD) rather than C ABI sized types (e.g. long)
> 
> See https://cygwin.com/faq.html#faq.programming.64bitporting

AMF:
Seems to specify the argument bit-width explicitly.

typedef uint64_t amf_uint64;
typedef AMF_RESULT (AMF_CDECL_CALL *AMFInit_Fn)(amf_uint64 version, AMFFactory **ppFactory);


nv-codec-headers:
Also specifies bit-width explicitly.

NVENCSTATUS NVENCAPI NvEncOpenEncodeSession (void* device, uint32_t deviceType, void** encoder);


mfx_dispatch:
This also specifies the bit-width explicitly.

typedef mfxI32 mfxIMPL;
typedef void (MFX_CDECL * mfxFunctionPointer)(void);
typedef struct _mfxSession *mfxSession;
typedef struct {
    mfxU32  AllocId;
    mfxU32  reserved[2];
    mfxU16  reserved3;
    mfxU16  AsyncDepth;

    union {
        mfxInfoMFX  mfx;
        mfxInfoVPP  vpp;
    };
    mfxU16  Protected;
    mfxU16  IOPattern;
    mfxExtBuffer** ExtParam;
    mfxU16  NumExtParam;
    mfxU16  reserved2;
} mfxVideoParam;

struct _mfxSession
{
    // A real handle from MFX engine passed to a called function
    mfxSession session;

    mfxFunctionPointer callTable[eVideoFuncTotal];
    mfxFunctionPointer callPlugInsTable[ePluginFuncTotal];
    mfxFunctionPointer callAudioTable[eAudioFuncTotal];

    // Current library's implementation (exact implementation)
    mfxIMPL impl;
};

FUNCTION(mfxStatus, MFXVideoENC_GetVideoParam, (mfxSession session, mfxVideoParam *par), (session, par))


> ii) Since these dynamically loaded DLLs are linked with a different C 
> runtime, one must tread carefully, as caution is required:
> 
> e.g. if an exported function returns a pointer to some memory 
> dynamically allocated using malloc(), which you are expected to release 
> with free() VERY BAD THINGS will happen when you pass it to Cygwin's 
> free() rather than the MSVCRT free() matchin the alloc() it came from.

AMF:
Seems to use the pair of malloc()/free().

static AMF_INLINE void* AMF_CDECL_CALL amf_variant_alloc(amf_size count)
{
    return malloc(count);
}
static AMF_INLINE void AMF_CDECL_CALL amf_variant_free(void* ptr)
{
    free(ptr);
}

nv-codec-headers:
Uses the pair of alloc/free function in the dll.

tcuMemAlloc_v2 *cuMemAlloc;
tcuMemFree_v2 *cuMemFree;


mfx_dispatch:
Use the pair of Alloc/Free function defined by itself.

typedef struct {
    mfxU32      reserved[4];
    mfxHDL      pthis;
    mfxStatus  (MFX_CDECL *Alloc)    (mfxHDL pthis, mfxU32 nbytes, mfxU16 type, mfxMemId *mid);
    mfxStatus  (MFX_CDECL *Lock)     (mfxHDL pthis, mfxMemId mid, mfxU8 **ptr);
    mfxStatus  (MFX_CDECL *Unlock)   (mfxHDL pthis, mfxMemId mid);
    mfxStatus  (MFX_CDECL *Free)     (mfxHDL pthis, mfxMemId mid);
} mfxBufferAllocator;



Therefore, I do not think the problems i) and ii) apply.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>