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:
The list of ITPs and ITAs I recently proposed, is as follows.
Sorry, there are so many, but thank you in advance.
No problem. I'll try to give them all the attention they deserve.
Thank you very much!
[ITP]
AMF: for ffmpeg (new)
aom: for ffmpeg (new)
faad2 : for moc
fdk-aac-free : for ffmpeg (new)
ffmpeg : for moc (under discussion)
libopusenc : for opus-tools
mfx_dispatch : for ffmpeg (new)
moc
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.
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
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.
I'm going to assume that these concerns don't apply, because you would
have noticed the dismal failure to work at all.
