From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-01.nifty.com (conssluserg-01.nifty.com [210.131.2.80]) by sourceware.org (Postfix) with ESMTPS id 85608385842B for ; Tue, 14 Feb 2023 09:11:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 85608385842B Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=nifty.ne.jp Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nifty.ne.jp Received: from HP-Z230 (aj135041.dynamic.ppp.asahi-net.or.jp [220.150.135.41]) (authenticated) by conssluserg-01.nifty.com with ESMTP id 31E9BKWM027430 for ; Tue, 14 Feb 2023 18:11:20 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-01.nifty.com 31E9BKWM027430 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1676365880; bh=pTGCJ6X0W0M+ZFOamS3Sq4K7ru0iw0XmLo27XYf1Lzs=; h=Date:From:To:Subject:In-Reply-To:References:From; b=gHccolXwUxsJv9n3vpeuuKe+GhgL3dOEUNoFtBrvbBdTggCEU8x46I0nt1USjclKb b2hOnqWPF/c6d5JLLq0d9BnLR52XH5tJv8HMLAU2Ai6SmCEhcM65xl38+obkrPlgj0 WKi8TuB0fSW9JB98BrKxgi4N4kBA+wwaiI0Q6zVzQJ3GvZamnYenpZOijIL147NURl 0epgSyANfnCOp51znVK0dNjTF4gcO1lTLvd0am1Zob6tG4lDln4f0vbYXObqaIEyqV Ant0svrxoLLL6241cvKHfH2YX/Bm29RpP7i6WI7b6URDzI+HzF/VDmIgrthHbeDw6D yz/sIe0DQ75xA== X-Nifty-SrcIP: [220.150.135.41] Date: Tue, 14 Feb 2023 18:11:20 +0900 From: Takashi Yano To: "cygwin-apps@cygwin.com" Subject: Re: List [ITP],[ITA] by me Message-Id: <20230214181120.b4eacba75560a6b7b1dbaea6@nifty.ne.jp> In-Reply-To: <463cea83-5c36-b095-f19d-af690517cd5c@dronecode.org.uk> References: <20230205174024.3fd85a3c1dfb33e0c34aafa5@nifty.ne.jp> <20230206212130.22e1a465e2eeb8f467afdeaa@nifty.ne.jp> <463cea83-5c36-b095-f19d-af690517cd5c@dronecode.org.uk> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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: > >>> 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. Thanks for the advice. I will check just to be sure. -- Takashi Yano