From: Jon Turney <jon.turney@dronecode.org.uk>
To: Takashi Yano <takashi.yano@nifty.ne.jp>,
"cygwin-apps@cygwin.com" <cygwin-apps@cygwin.com>
Subject: Re: List [ITP],[ITA] by me
Date: Mon, 13 Feb 2023 18:02:27 +0000 [thread overview]
Message-ID: <463cea83-5c36-b095-f19d-af690517cd5c@dronecode.org.uk> (raw)
In-Reply-To: <20230206212130.22e1a465e2eeb8f467afdeaa@nifty.ne.jp>
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.
next prev parent reply other threads:[~2023-02-13 18:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-05 8:40 Takashi Yano
2023-02-05 16:33 ` Jon Turney
2023-02-06 12:21 ` Takashi Yano
2023-02-13 18:02 ` Jon Turney [this message]
2023-02-14 9:11 ` Takashi Yano
2023-02-14 13:33 ` Takashi Yano
2023-02-16 18:52 ` Jon Turney
2023-02-13 10:47 ` Status update (Re: List [ITP],[ITA] by me) Takashi Yano
2023-02-13 18:29 ` Jon Turney
2023-02-14 9:11 ` Takashi Yano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=463cea83-5c36-b095-f19d-af690517cd5c@dronecode.org.uk \
--to=jon.turney@dronecode.org.uk \
--cc=cygwin-apps@cygwin.com \
--cc=takashi.yano@nifty.ne.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).