From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa-prd-fep-044.btinternet.com (mailomta7-sa.btinternet.com [213.120.69.13]) by sourceware.org (Postfix) with ESMTPS id B7A8638493CE for ; Mon, 13 Feb 2023 18:02:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B7A8638493CE Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from sa-prd-rgout-003.btmx-prd.synchronoss.net ([10.2.38.6]) by sa-prd-fep-044.btinternet.com with ESMTP id <20230213180228.YICA23588.sa-prd-fep-044.btinternet.com@sa-prd-rgout-003.btmx-prd.synchronoss.net>; Mon, 13 Feb 2023 18:02:28 +0000 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 613942904F840AC7 X-Originating-IP: [81.153.98.246] X-OWM-Source-IP: 81.153.98.246 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvhedrudeiuddguddthecutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepheduueevueejueejgeeufeehtddtkeevtdduieelfeetteeffeejjedukeefgffgnecuffhomhgrihhnpegthihgfihinhdrtghomhenucfkphepkedurdduheefrdelkedrvdegieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddruddtiegnpdhinhgvthepkedurdduheefrdelkedrvdegiedpmhgrihhlfhhrohhmpehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkpdhnsggprhgtphhtthhopedvpdhrtghpthhtoheptgihghifihhnqdgrphhpshestgihghifihhnrdgtohhmpdhrtghpthhtohepthgrkhgrshhhihdrhigrnhhosehnihhfthihrdhnvgdrjhhp X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.106] (81.153.98.246) by sa-prd-rgout-003.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 613942904F840AC7; Mon, 13 Feb 2023 18:02:28 +0000 Message-ID: <463cea83-5c36-b095-f19d-af690517cd5c@dronecode.org.uk> Date: Mon, 13 Feb 2023 18:02:27 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Subject: Re: List [ITP],[ITA] by me Content-Language: en-GB To: Takashi Yano , "cygwin-apps@cygwin.com" References: <20230205174024.3fd85a3c1dfb33e0c34aafa5@nifty.ne.jp> <20230206212130.22e1a465e2eeb8f467afdeaa@nifty.ne.jp> From: Jon Turney In-Reply-To: <20230206212130.22e1a465e2eeb8f467afdeaa@nifty.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1191.5 required=5.0 tests=BAYES_00,FORGED_SPF_HELO,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=no 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 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.