List [ITP],[ITA] by me

List [ITP],[ITA] by me

[Takashi Yano]

The list of ITPs and ITAs I recently proposed, is as follows.
Sorry, there are so many, but thank you in advance.

[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)
openh264 : for ffmpeg (new)
xvidcore : for ffmpeg

[ITA]
libsndfile : maintainer changed, no GTG yet
opus : maintainer changed, no GTG yet
opusfile : maintainer changed, no GTG yet
opus-tools : maintainer changed, no GTG yet
pulseaudio : (new)

SDL2 : already has GTG
mpg123 : already has GTG

[WITHDRAW]
x264
x265

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

Re: List [ITP],[ITA] by me

[Jon Turney]

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.

> [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?

> openh264 : for ffmpeg (new)
> xvidcore : for ffmpeg
> 
> [ITA]
> libsndfile : maintainer changed, no GTG yet
> opus : maintainer changed, no GTG yet
> opusfile : maintainer changed, no GTG yet
> opus-tools : maintainer changed, no GTG yet
> pulseaudio : (new)
> 
> SDL2 : already has GTG
> mpg123 : already has GTG
> 
> [WITHDRAW]
> x264
> x265
> 

I've posted some specific comments on some of these.

Please double-check that packages which contain a soversioned library 
include that in the package name (for reasons touched on in [1]).

If you'd like me to review any of these again, please post the just new 
.cygport file in a follow-up (since that will save me a little time in 
having to extract it)

I've updated the package list.

[1] https://cygwin.com/pipermail/cygwin-apps/2023-January/042480.html

Re: List [ITP],[ITA] by me

[Takashi Yano]

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.

> > openh264 : for ffmpeg (new)
> > xvidcore : for ffmpeg
> > 
> > [ITA]
> > libsndfile : maintainer changed, no GTG yet
> > opus : maintainer changed, no GTG yet
> > opusfile : maintainer changed, no GTG yet
> > opus-tools : maintainer changed, no GTG yet
> > pulseaudio : (new)
> > 
> > SDL2 : already has GTG
> > mpg123 : already has GTG
> > 
> > [WITHDRAW]
> > x264
> > x265
> > 
> 
> I've posted some specific comments on some of these.
> 
> Please double-check that packages which contain a soversioned library 
> include that in the package name (for reasons touched on in [1]).
> 
> If you'd like me to review any of these again, please post the just new 
> .cygport file in a follow-up (since that will save me a little time in 
> having to extract it)
> 
> I've updated the package list.
> 
> [1] https://cygwin.com/pipermail/cygwin-apps/2023-January/042480.html

Thanks. I'll check and fix that.

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

Status update (Re: List [ITP],[ITA] by me)

[Takashi Yano]

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.
> 
> > [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?
> 
> > openh264 : for ffmpeg (new)
> > xvidcore : for ffmpeg
> > 
> > [ITA]
> > libsndfile : maintainer changed, no GTG yet
> > opus : maintainer changed, no GTG yet
> > opusfile : maintainer changed, no GTG yet
> > opus-tools : maintainer changed, no GTG yet
> > pulseaudio : (new)
> > 
> > SDL2 : already has GTG
> > mpg123 : already has GTG
> > 
> > [WITHDRAW]
> > x264
> > x265
> > 
> 
> I've posted some specific comments on some of these.
> 
> Please double-check that packages which contain a soversioned library 
> include that in the package name (for reasons touched on in [1]).
> 
> If you'd like me to review any of these again, please post the just new 
> .cygport file in a follow-up (since that will save me a little time in 
> having to extract it)
> 
> I've updated the package list.
> 
> [1] https://cygwin.com/pipermail/cygwin-apps/2023-January/042480.html

+----+------------------------+------------+---------+----------------------+
| No.| Package                | Maintainer | GTG     | Comment              |
+----+------------------------+------------+---------+----------------------+
|  1 | [ITP] AMF              |            |         |                      |
|  2 | [ITP] nv-codec-headers |            |         |                      |
|  3 | [ITP] mfx_dispatch     |            |         |                      |
|  4 | [ITP] aom              | Assigned   | Almost  |                      |
|  5 | [ITP] xvidcore         | Assigned   |         |                      |
|  6 | [ITP] openh264         | Assigned   |         |                      |
|  7 | [ITP] ffmpeg           | Assigned   |         | Needs 1,2,3,4,5,6,10 |
|  8 | [ITP] moc              | Assigned   | Almost  | Needs 7              |
|  9 | [ITP] libopusenc       |            | Almost  |                      |
+----+------------------------+------------+---------+----------------------+
| 10 | [ITA] fdk-aac          |            | Almost  | [ITP] -> [ITA]       |
| 11 | [ITA] libsndfile       | Assigned   | Almost  | Needs 13             |
| 12 | [ITA] pulseaudio       | Assigned   | Almost  |                      |
| 13 | [ITA] opus             | Assigned   |         |                      |
| 14 | [ITA] opusfile         | Assigned   |         |                      |
| 15 | [ITA] opus-tools       | Assigned   |         | Needs 9              |
| 16 | [ITA] mpg123           | Assigned   | Almost  |                      |
| 17 | [ITA] SDL2             | Assigned   | Yes     |                      |
+----+------------------------+------------+---------+----------------------+
| 18 | [ITP] x264             |            |         | Withdrawn            |
| 19 | [ITP] x265             |            |         | Withdrawn            |
| 20 | [ITP] faad2            | Assigned * |         | Withdrawn            |
+----+------------------------+------------+---------+----------------------+

* Please remove faad2 from package list (ref. Yaakov's reply).

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

Re: List [ITP],[ITA] by me

[Jon Turney]

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.

Re: Status update (Re: List [ITP],[ITA] by me)

[Jon Turney]

On 13/02/2023 10:47, Takashi Yano via Cygwin-apps wrote:

>>
>> I've posted some specific comments on some of these.
>>
>> Please double-check that packages which contain a soversioned library
>> include that in the package name (for reasons touched on in [1]).
>>
>> If you'd like me to review any of these again, please post the just new
>> .cygport file in a follow-up (since that will save me a little time in
>> having to extract it)
>>
>> I've updated the package list.
>>
>> [1] https://cygwin.com/pipermail/cygwin-apps/2023-January/042480.html
> 
> +----+------------------------+------------+---------+----------------------+
> | No.| Package                | Maintainer | GTG     | Comment              |
> +----+------------------------+------------+---------+----------------------+
> |  1 | [ITP] AMF              |            |         |                      |
> |  2 | [ITP] nv-codec-headers |            |         |                      |
> |  3 | [ITP] mfx_dispatch     |            |         |                      |
> |  4 | [ITP] aom              | Assigned   | Almost  |                      |
> |  5 | [ITP] xvidcore         | Assigned   |         |                      |
> |  6 | [ITP] openh264         | Assigned   |         |                      |
> |  7 | [ITP] ffmpeg           | Assigned   |         | Needs 1,2,3,4,5,6,10 |
> |  8 | [ITP] moc              | Assigned   | Almost  | Needs 7              |
> |  9 | [ITP] libopusenc       |            | Almost  |                      |
> +----+------------------------+------------+---------+----------------------+
> | 10 | [ITA] fdk-aac          |            | Almost  | [ITP] -> [ITA]       |
> | 11 | [ITA] libsndfile       | Assigned   | Almost  | Needs 13             |
> | 12 | [ITA] pulseaudio       | Assigned   | Almost  |                      |
> | 13 | [ITA] opus             | Assigned   |         |                      |
> | 14 | [ITA] opusfile         | Assigned   |         |                      |
> | 15 | [ITA] opus-tools       | Assigned   |         | Needs 9              |
> | 16 | [ITA] mpg123           | Assigned   | Almost  |                      |
> | 17 | [ITA] SDL2             | Assigned   | Yes     |                      |
> +----+------------------------+------------+---------+----------------------+
> | 18 | [ITP] x264             |            |         | Withdrawn            |
> | 19 | [ITP] x265             |            |         | Withdrawn            |
> | 20 | [ITP] faad2            | Assigned * |         | Withdrawn            |
> +----+------------------------+------------+---------+----------------------+
> 
> * Please remove faad2 from package list (ref. Yaakov's reply).
> 

I have applied these updates.

All the the ITPs and ITAs I haven't specifically replied to are also 
approved.

Thanks again!

Re: Status update (Re: List [ITP],[ITA] by me)

[Takashi Yano]

On Mon, 13 Feb 2023 18:29:57 +0000
Jon Turney wrote:
> On 13/02/2023 10:47, Takashi Yano via Cygwin-apps wrote:
> 
> >>
> >> I've posted some specific comments on some of these.
> >>
> >> Please double-check that packages which contain a soversioned library
> >> include that in the package name (for reasons touched on in [1]).
> >>
> >> If you'd like me to review any of these again, please post the just new
> >> .cygport file in a follow-up (since that will save me a little time in
> >> having to extract it)
> >>
> >> I've updated the package list.
> >>
> >> [1] https://cygwin.com/pipermail/cygwin-apps/2023-January/042480.html
> > 
> > +----+------------------------+------------+---------+----------------------+
> > | No.| Package                | Maintainer | GTG     | Comment              |
> > +----+------------------------+------------+---------+----------------------+
> > |  1 | [ITP] AMF              |            |         |                      |
> > |  2 | [ITP] nv-codec-headers |            |         |                      |
> > |  3 | [ITP] mfx_dispatch     |            |         |                      |
> > |  4 | [ITP] aom              | Assigned   | Almost  |                      |
> > |  5 | [ITP] xvidcore         | Assigned   |         |                      |
> > |  6 | [ITP] openh264         | Assigned   |         |                      |
> > |  7 | [ITP] ffmpeg           | Assigned   |         | Needs 1,2,3,4,5,6,10 |
> > |  8 | [ITP] moc              | Assigned   | Almost  | Needs 7              |
> > |  9 | [ITP] libopusenc       |            | Almost  |                      |
> > +----+------------------------+------------+---------+----------------------+
> > | 10 | [ITA] fdk-aac          |            | Almost  | [ITP] -> [ITA]       |
> > | 11 | [ITA] libsndfile       | Assigned   | Almost  | Needs 13             |
> > | 12 | [ITA] pulseaudio       | Assigned   | Almost  |                      |
> > | 13 | [ITA] opus             | Assigned   |         |                      |
> > | 14 | [ITA] opusfile         | Assigned   |         |                      |
> > | 15 | [ITA] opus-tools       | Assigned   |         | Needs 9              |
> > | 16 | [ITA] mpg123           | Assigned   | Almost  |                      |
> > | 17 | [ITA] SDL2             | Assigned   | Yes     |                      |
> > +----+------------------------+------------+---------+----------------------+
> > | 18 | [ITP] x264             |            |         | Withdrawn            |
> > | 19 | [ITP] x265             |            |         | Withdrawn            |
> > | 20 | [ITP] faad2            | Assigned * |         | Withdrawn            |
> > +----+------------------------+------------+---------+----------------------+
> > 
> > * Please remove faad2 from package list (ref. Yaakov's reply).
> > 
> 
> I have applied these updates.
> 
> All the the ITPs and ITAs I haven't specifically replied to are also 
> approved.
> 
> Thanks again!

Thank you too!

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

Re: List [ITP],[ITA] by me

[Takashi Yano]

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 <takashi.yano@nifty.ne.jp>

Re: List [ITP],[ITA] by me

[Takashi Yano]

[-- Attachment #1: Type: text/plain, Size: 4045 bytes --]

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>

[-- Attachment #2: nv-codec-headers.cygport --]
[-- Type: text/plain, Size: 712 bytes --]

NAME="nv-codec-headers"
VERSION=11.1.5.2
RELEASE=1
LICENSE="MIT"
CATEGORY="Devel"
SUMMARY="FFmpeg version of Nvidia Codec SDK headers"
DESCRIPTION="FFmpeg version of headers required to interface with Nvidias codec APIs. This package provides headers which loads corresponding dlls dynamically. The codec itself is implemented in the dlls and the Nvidia GPU."
HOMEPAGE="https://github.com/FFmpeg/nv-codec-headers"
ARCH="noarch" # This is noarch because it's just header files.
SRC_URI="https://github.com/FFmpeg/nv-codec-headers/archive/refs/tags/n${VERSION}.tar.gz"

SRC_DIR="${NAME}-n${VERSION}"
src_compile() {
	cd ${B}
	ln -sf ${S}/Makefile .
	ln -sf ${S}/ffnvcodec.pc.in .
	ln -sf ${S}/include .
	cygmake
}

[-- Attachment #3: AMF.cygport --]
[-- Type: text/plain, Size: 1753 bytes --]

NAME="AMF"
VERSION=1.4.29
RELEASE=1
LICENSE="MIT"
CATEGORY="Devel"
SUMMARY="Advanced Media Framework (AMF) SDK"
DESCRIPTION="A light-weight, portable multimedia framework that abstracts away most of the platform and API-specific details. AMF is supported on the closed source AMD Pro driver and OpenMax on the open source AMD Mesa driver, whose dlls are dynamically loaded by the SDK header. The codec itself is impelemted in the dlls and the AMD GPU."
HOMEPAGE="https://gpuopen.com/advanced-media-framework/"
ARCH="noarch" # This is noarch because it's just header files.

SRC_URI="${NAME}-cleaned-${VERSION}.tar.xz"

# Make dummy source file for prep if the cleaned one is not exist.
if [ ! -f ${SRC_URI} ]
then
	mkdir ${NAME}-${VERSION}
	touch ${NAME}-${VERSION}/dummy
	tar acf ${SRC_URI} ${NAME}-${VERSION}
	rm -rf ${NAME}-${VERSION}
fi

CYGPORT_USE_UNSTABLE_API=1
src_unpack_hook() {
	if [ $(tar tvf ../../../${SRC_URI} | wc -l) -eq 2 ] # Source file is dummy
	then
		NV=${NAME}-${VERSION}
		pushd ..
		rm -rf ${NV} # Remove dummy source file.
		# Download original source file.
		wget https://github.com/GPUOpen-LibrariesAndSDKs/AMF/archive/refs/tags/v${VERSION}.tar.gz
		tar xf v${VERSION}.tar.gz
		rm -f v${VERSION}.tar.gz
		# Remove unnecessary files.
		rm -rf ${NV}/Thirdparty ${NV}/amf/public/common ${NV}/amf/public/make ${NV}/amf/public/proj ${NV}/amf/public/props ${NV}/amf/public/samples ${NV}/amf/public/src ${NV}/amf/doc ${NV}/.github
		# Make cleaned source file which has only necessary header files.
		tar acf ../../${NAME}-cleaned-${VERSION}.tar.xz ${NV}
		popd
	fi
}

src_compile() {
	:
}

src_install() {
	mkdir -p ${D}/usr/include
	# Just make symlink for header files.
	ln -fs ${S}/amf/public/include ${D}/usr/include/${NAME}
}

[-- Attachment #4: mfx_dispatch.cygport --]
[-- Type: text/plain, Size: 575 bytes --]

NAME="mfx_dispatch"
VERSION=1.35.1
RELEASE=1
LICENSE="BSD-3-Clause"
CATEGORY="Libs"
SUMMARY="Intel MediaSDK dispatcher (Alternative to libmfx)"
DESCRIPTION="This package provides the headers and the library which loads Intel MediaSDK dlls dynamically. The codec itself is implemented in the dlls and the Intel GPU."
HOMEPAGE="https://github.com/lu-zero/mfx_dispatch"
SRC_URI="https://github.com/lu-zero/mfx_dispatch/archive/refs/tags/${VERSION}.tar.gz"

PKG_NAMES="libmfx1 libmfx-devel"
libmfx1_CONTENTS="usr/bin usr/share/doc/"
libmfx_devel_CONTENTS="usr/include/ usr/lib/"

Re: List [ITP],[ITA] by me

[Jon Turney]

On 14/02/2023 13:33, Takashi Yano via Cygwin-apps wrote:
> 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.:
[...]
> Therefore, I do not think the problems i) and ii) apply.

Thanks very much for investigating and checking these details.

These are approved.