Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> on behalf of Compn 
<te...@mi.rr.com>
Sent: Friday, December 15, 2017 9:27 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] AMD external header

On Fri, 15 Dec 2017 00:31:27 +, "Mironov, Mikhail"
<mikhail.miro...@amd.com> wrote:

> Do you think that two and half weeks is long enough to wait?
> So far except creating a repo for NVidia there is no activity.

did you resend your patchset without the header included? sorry i am
too busy to even read the list right now.

maybe the patchset without the included header could get reviewed some
more and possibly applied while we wait for the external repo changes.

remember we are mostly volunteers working on ffmpeg. which means we all
have regular non-ffmpeg jobs.

-compn

I understand this very well and appreciate ffmpeg team spirit. I am asking just 
because I am new here and don't know what to expect.
Btw: amf encoder without headers is in the master for some time and if 
something can be improved just let me know.
Thanks,
Mikhail

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

Am 15.12.2017 um 15:27 schrieb Compn:

On Fri, 15 Dec 2017 00:31:27 +, "Mironov, Mikhail"
 wrote:


Do you think that two and half weeks is long enough to wait?
So far except creating a repo for NVidia there is no activity.


did you resend your patchset without the header included? sorry i am
too busy to even read the list right now.


The patchset without the included header is already merged in master.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Compn]

On Fri, 15 Dec 2017 00:31:27 +, "Mironov, Mikhail"
 wrote:

> Do you think that two and half weeks is long enough to wait? 
> So far except creating a repo for NVidia there is no activity.

did you resend your patchset without the header included? sorry i am
too busy to even read the list right now.

maybe the patchset without the included header could get reviewed some
more and possibly applied while we wait for the external repo changes.

remember we are mostly volunteers working on ffmpeg. which means we all
have regular non-ffmpeg jobs.

-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

Do you think that two and half weeks is long enough to wait?
So far except creating a repo for NVidia there is no activity.


I'm not yet happy with how the external repository works, and I'm quite 
busy with other stuff at the moment.

But it will get used eventually.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Compn
> Sent: November 29, 2017 10:50 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] AMD external header
> 
> On Wed, 29 Nov 2017 15:45:28 +, "Mironov, Mikhail"
> <mikhail.miro...@amd.com> wrote:
> > May I suggest to go down to business of enabling HW encoders by default?
> > Yesterday Mark submitted the initial implementation and I really want
> > to thank him for his mentoring and participation - it was very useful.
> > Question is: how to move forward on practical terms? I really don’t know
> how this team makes such decisions.
> > Or maybe it is impasse case and  all want to keep things the way they are
> today?
> 
> probably wait a few days until the maintainer of hwaccels can chime in,
> possibly with some more reviews.
> 
> please be patient.
> 
> -compn
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Do you think that two and half weeks is long enough to wait? 
So far except creating a repo for NVidia there is no activity.
Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Tobias Rapp]

On 01.12.2017 00:32, Marton Balint wrote:


On Wed, 29 Nov 2017, Mironov, Mikhail wrote:


Hi,
This conversation is very entertaining but leads us nowhere.
May I suggest to go down to business of enabling HW encoders by default?
Yesterday Mark submitted the initial implementation and I really want
to thank him for his mentoring and participation - it was very useful.
The submission doesn't have AMD header so AMD encoder is off in any 
default build.
I counted responses to my posts and found six people are for the 
default enabling

of HW blocks one way or another: by including headers or pulling them out
automatically using git (I guess via submodules?).
Two people want to remove external headers and disable default HW 
acceleration.
Question is: how to move forward on practical terms? I really don’t 
know how this team makes such decisions.
Or maybe it is impasse case and  all want to keep things the way they 
are today?


The project has a voting system which was used in the past for issues 
where no consensus was reached. A voting however is a tedious process 
which usually leaves a few frustrated people on the losing side, so I'd 
say that is a last resort.


+1

An alternative solution to adding AMD or removing Nvidia headers might 
be to simply disable the Nvidia hwaccel autodetection, and require the 
user to explicitly enable it. That seems mostly fair to me, and keeps 
the current status of the headers.


Still some decision about these external headers should be made but the 
outcome would have less impact on user experience.


What is the current policy for adding a library on the 
HWACCEL_AUTODETECT_LIBRARY_LIST versus putting it on 
HWACCEL_LIBRARY_LIST? Is it different from 
EXTERNAL_AUTODETECT_LIBRARY_LIST / EXTERNAL_LIBRARY_LIST?


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Marton Balint]

On Wed, 29 Nov 2017, Mironov, Mikhail wrote:


-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
Of Paul B Mahol
Sent: November 29, 2017 10:16 AM
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] AMD external header

On 11/29/17, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:

2017-11-29 15:58 GMT+01:00 wm4 <nfx...@googlemail.com>:


Well, don't worry too much. People like him are, as some would say,
toxic members of the community. Frequent drama and flame wars

happen.

(And here's where I wished ffmpeg were a properly managed project.)


Look who's talking!

Given that you started a fork of FFmpeg repeating ancient lies and
stating you don't support FFmpeg anymore:
Why do you post here?


Because he like to argue with toxic people like you.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Hi,
This conversation is very entertaining but leads us nowhere.
May I suggest to go down to business of enabling HW encoders by default?
Yesterday Mark submitted the initial implementation and I really want
to thank him for his mentoring and participation - it was very useful.
The submission doesn't have AMD header so AMD encoder is off in any default 
build.
I counted responses to my posts and found six people are for the default 
enabling
of HW blocks one way or another: by including headers or pulling them out
automatically using git (I guess via submodules?).
Two people want to remove external headers and disable default HW acceleration.
Question is: how to move forward on practical terms? I really don’t know how 
this team makes such decisions.
Or maybe it is impasse case and  all want to keep things the way they are today?


The project has a voting system which was used in the past for issues 
where no consensus was reached. A voting however is a tedious process 
which usually leaves a few frustrated people on the losing side, so I'd 
say that is a last resort.


An alternative solution to adding AMD or removing Nvidia headers might be 
to simply disable the Nvidia hwaccel autodetection, and require the user 
to explicitly enable it. That seems mostly fair to me, and keeps the 
current status of the headers.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[wm4]

On Thu, 30 Nov 2017 02:41:44 +0100
Carl Eugen Hoyos  wrote:

> 2017-11-29 16:30 GMT+01:00 wm4 :
> 
> > You won't hear any lies from me.  
> 
> That's too good to be true;-(

So you admit you're denying the truth because the truth hurts you?
That's pretty hilarious, but entirely consistent with your behavior.

> > But it's well known that you twist the
> > truth whenever it fits you.  
> 
> I finally realize that you staying anonymous to get away
> with defamation.

Well that statement of yours is certainly defamation. I don't want to
hear this from the king of defamation either. (Cf. Libav situation,
where you will insult random people, accusing them of crimes etc. I
always picture you foaming out of your mouth.)

I'm not particularly anonymous either.

> Thank you for the explanation, Carl Eugen

What explanation? Just because you made some shit up that allows you to
cope with your distorted image of reality it doesn't mean anyone gave
an explanation. These things are obviously entirely unrelated.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Carl Eugen Hoyos]

2017-11-29 16:30 GMT+01:00 wm4 :

> You won't hear any lies from me.

That's too good to be true;-(

> But it's well known that you twist the
> truth whenever it fits you.

I finally realize that you staying anonymous to get away
with defamation.

Thank you for the explanation, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Carl Eugen Hoyos]

2017-11-29 16:42 GMT+01:00 Hendrik Leppkes :
> On Wed, Nov 29, 2017 at 4:07 PM, Carl Eugen Hoyos  wrote:
>> 2017-11-29 15:58 GMT+01:00 wm4 :
>>
>>> Well, don't worry too much. People like him are, as some would say,
>>> toxic members of the community. Frequent drama and flame wars happen.
>>> (And here's where I wished ffmpeg were a properly managed project.)
>>
>> Look who's talking!
>>
>> Given that you started a fork of FFmpeg [...] Why do you post here?
>
> Forking is an integral part of open-source development.

Of course and I never had an issue with anybody because of forking.

Please try not to edit my posts to fundamentally change their meaning!

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Nicolas George]

Mironov, Mikhail (2017-11-29):
> Now we have seven people not counting me

I suggest we weight this based on how often people voicing an opinion
need to run git grep.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Compn
> Sent: November 29, 2017 2:17 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] AMD external header
> 
> On Wed, 29 Nov 2017 18:06:46 +, "Mironov, Mikhail"
> <mikhail.miro...@amd.com> wrote:
> 
> > This was a suggestion in one of the posts, not my idea. I personally would
> prefer to include headers.
> 
> i also prefer including headers into ffmpeg. only for the big 3 intel amd and
> nvidia... unless something else comes along i have no problem with this. but
> its also not my call, just my personal opinion.
> 
> to make it easier on users who dont have to go around looking for sdk and
> extracting headers and all that baloney.
> 
> -compn
> 

Now we have seven people not counting me 
Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Compn]

On Wed, 29 Nov 2017 18:06:46 +, "Mironov, Mikhail"
 wrote:

> This was a suggestion in one of the posts, not my idea. I personally would 
> prefer to include headers.

i also prefer including headers into ffmpeg. only for the big 3 intel
amd and nvidia... unless something else comes along i have no problem
with this. but its also not my call, just my personal opinion.

to make it easier on users who dont have to go around looking for sdk
and extracting headers and all that baloney.

-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[wm4]

On Wed, 29 Nov 2017 18:10:49 +
"Mironov, Mikhail"  wrote:

> > 
> > It also should be made clear that nvidia does not somehow receive preferred
> > treatment over other vendors.  
> 
> Respectfully, but it does by inaction.
> Thanks,
> Mikhail

Not really. Intel has the best hardware transcoding support (on all
platforms) in ffmpeg. And they don't have any in-tree headers. These
are really different issues.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> 
> It also should be made clear that nvidia does not somehow receive preferred
> treatment over other vendors.

Respectfully, but it does by inaction.
Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of wm4
> Sent: November 29, 2017 11:06 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] AMD external header
> 
> On Wed, 29 Nov 2017 15:45:28 +
> "Mironov, Mikhail" <mikhail.miro...@amd.com> wrote:
> 
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > Behalf Of Paul B Mahol
> > > Sent: November 29, 2017 10:16 AM
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] AMD external header
> > >
> > > On 11/29/17, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> > > > 2017-11-29 15:58 GMT+01:00 wm4 <nfx...@googlemail.com>:
> > > >
> > > >> Well, don't worry too much. People like him are, as some would
> > > >> say, toxic members of the community. Frequent drama and flame
> > > >> wars
> > > happen.
> > > >> (And here's where I wished ffmpeg were a properly managed
> > > >> project.)
> > > >
> > > > Look who's talking!
> > > >
> > > > Given that you started a fork of FFmpeg repeating ancient lies and
> > > > stating you don't support FFmpeg anymore:
> > > > Why do you post here?
> > >
> > > Because he like to argue with toxic people like you.
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > Hi,
> > This conversation is very entertaining but leads us nowhere.
> > May I suggest to go down to business of enabling HW encoders by default?
> > Yesterday Mark submitted the initial implementation and I really want
> > to thank him for his mentoring and participation - it was very useful.
> > The submission doesn't have AMD header so AMD encoder is off in any
> default build.
> > I counted responses to my posts and found six people are for the
> > default enabling of HW blocks one way or another: by including headers
> > or pulling them out automatically using git (I guess via submodules?).
> > Two people want to remove external headers and disable default HW
> acceleration.
> > Question is: how to move forward on practical terms? I really don’t know
> how this team makes such decisions.
> > Or maybe it is impasse case and  all want to keep things the way they are
> today?
> 
> We don't automatically check out git repos as part of the build process. That
> means the user will have to get those headers to build AMD support. AMD
> support could still be autodetected, and enabled if the headers are available.

This was a suggestion in one of the posts, not my idea. I personally would 
prefer to include headers.

> 
> This is not different from how it works with Intel and vaapi/qsv, so I'd say
> that's fair.
> 
> Do you agree with this?

If NVidia headers moved to a separate repo - yes.

Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

Yeah, I understand that. But the function loading should make only a
small part of it, and could just be a normal source file. (We do
ad-hoc function loading for a lot of other stuff too.)

Then we could depend on external, unmodified SDK headers, which someone
could extract to a git repo, to avoid going through nvidia's broken
procedures.


The plain headers are also modified, because nvidia did not take a lot 
of care about a lot of compilers ffmpeg supports (I fixed various 
anonymous structs that failed to compile with for example older gcc).
It also uses types whose size varies between msvc and gcc, which I fixed 
to always use the right size on the right OS.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[wm4]

On Wed, 29 Nov 2017 17:42:05 +0100
Timo Rothenpieler  wrote:

> Am 29.11.2017 um 17:40 schrieb wm4:
> > On Wed, 29 Nov 2017 17:27:01 +0100
> > Hendrik Leppkes  wrote:
> >   
> >> On Wed, Nov 29, 2017 at 5:24 PM, wm4  wrote:  
> >>>
> >>> What really irks me is that nvidia is not giving us any support for
> >>> supporting their stuff. AFAIK the current headers are the last MIT
> >>> licensed ones, and future headers are closed?  
> >>
> >> No, thats not how it is. They re-licensed the video related headers to
> >> be usable some time ago, and there have been no signs of this changing
> >> back again.
> >> Only the actual CUDA headers are still closed, but we don't need them.  
> > 
> > Oh, great. Then why do we do that at all? We'd only need have some code
> > for dynamically loading actual functions, but this would be way less
> > code.  
> 
> Because the headers are in an SDK you have to be an approved nvidia 
> developer for to download it.

Oh, how evil.

> And they are also not useful without quite some modifications. The whole 
> dynamic loading is made by me, not by nvidia.
> 

Yeah, I understand that. But the function loading should make only a
small part of it, and could just be a normal source file. (We do
ad-hoc function loading for a lot of other stuff too.)

Then we could depend on external, unmodified SDK headers, which someone
could extract to a git repo, to avoid going through nvidia's broken
procedures.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Tobias Rapp]

On 28.11.2017 10:25, Timo Rothenpieler wrote:
Your use-case looks like an argument for moving the external headers 
into some separate repository. Not that I personally care much about 
bundling or not bundling. To me the more important question seems to 
be whether to auto-enable the encoders/decoders that depend on the 
external headers and libraries or not.


At least nvenc will stay as auto-enable even with out-of-tree headers, 
except that it will obviously check if it has the required headers 
available.


What confuses me is that libraries like libopus/libx264/... must be 
manually enabled while the library behind nvenc is auto-enabled.


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

Am 29.11.2017 um 17:40 schrieb wm4:

On Wed, 29 Nov 2017 17:27:01 +0100
Hendrik Leppkes  wrote:


On Wed, Nov 29, 2017 at 5:24 PM, wm4  wrote:


What really irks me is that nvidia is not giving us any support for
supporting their stuff. AFAIK the current headers are the last MIT
licensed ones, and future headers are closed?


No, thats not how it is. They re-licensed the video related headers to
be usable some time ago, and there have been no signs of this changing
back again.
Only the actual CUDA headers are still closed, but we don't need them.


Oh, great. Then why do we do that at all? We'd only need have some code
for dynamically loading actual functions, but this would be way less
code.


Because the headers are in an SDK you have to be an approved nvidia 
developer for to download it.
And they are also not useful without quite some modifications. The whole 
dynamic loading is made by me, not by nvidia.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[wm4]

On Wed, 29 Nov 2017 17:27:01 +0100
Hendrik Leppkes  wrote:

> On Wed, Nov 29, 2017 at 5:24 PM, wm4  wrote:
> >
> > What really irks me is that nvidia is not giving us any support for
> > supporting their stuff. AFAIK the current headers are the last MIT
> > licensed ones, and future headers are closed?  
> 
> No, thats not how it is. They re-licensed the video related headers to
> be usable some time ago, and there have been no signs of this changing
> back again.
> Only the actual CUDA headers are still closed, but we don't need them.

Oh, great. Then why do we do that at all? We'd only need have some code
for dynamically loading actual functions, but this would be way less
code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Hendrik Leppkes]

On Wed, Nov 29, 2017 at 5:24 PM, wm4  wrote:
>
> What really irks me is that nvidia is not giving us any support for
> supporting their stuff. AFAIK the current headers are the last MIT
> licensed ones, and future headers are closed?

No, thats not how it is. They re-licensed the video related headers to
be usable some time ago, and there have been no signs of this changing
back again.
Only the actual CUDA headers are still closed, but we don't need them.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[wm4]

On Wed, 29 Nov 2017 09:09:14 -0700
Pavel Koshevoy  wrote:

> On Tue, Nov 28, 2017 at 12:47 AM, Tobias Rapp  wrote:
> > On 27.11.2017 17:14, Pavel Koshevoy wrote:  
> 
> 
> 
> >> Personally, I would prefer if the bundled external headers were
> >> installed together with ffmpeg public headers (so nvenc/cuda/etc...
> >> weren't simply private headers within ffmpeg).  There are some nvenc
> >> APIs I need to query hardware capabilities to avoid setting nvenc
> >> codec parameters that would cause the codec to fail to initialize via
> >> ffmpeg apis.  Given that ffmpeg already includes the headers that
> >> declare those APIs I've been able to use them without installing nvenc
> >> SDK separately, but since they are private headers in the ffmpeg
> >> source tree it feels dirty to do that.  
> >
> >
> > Your use-case looks like an argument for moving the external headers into
> > some separate repository. Not that I personally care much about bundling or
> > not bundling. To me the more important question seems to be whether to
> > auto-enable the encoders/decoders that depend on the external headers and
> > libraries or not.  
> 
> 
> Yeah, that would be cleaner, but it does bring up the maintenance
> burden that Nicolas has mentioned.  As long as the headers are in the
> ffmpeg tree -- the maintenance burden is on ffmpeg.  When the headers
> are moved to an external repo it would not necessarily be an ffmpeg
> projects maintenance burden, but then who should be maintaining it?
> The vendor?

Generally we should encourage the vendor to maintain such things.

I think what really needs to be discussed in a broader context are
patch-and-run code dumps. It can't be right that someone can get
complex patches merged and then disappear, and then _we_ have to put
lots of effort into not breaking it. That's true for all kinds of
contribution, including non-company ones.

What really irks me is that nvidia is not giving us any support for
supporting their stuff. AFAIK the current headers are the last MIT
licensed ones, and future headers are closed? And there's no API
documentation or help either. But most of that code written was done by
ffmpeg developers, who have some commitment to maintain it.

Seems to be getting quite offtopic though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Pavel Koshevoy]

On Tue, Nov 28, 2017 at 12:47 AM, Tobias Rapp  wrote:
> On 27.11.2017 17:14, Pavel Koshevoy wrote:



>> Personally, I would prefer if the bundled external headers were
>> installed together with ffmpeg public headers (so nvenc/cuda/etc...
>> weren't simply private headers within ffmpeg).  There are some nvenc
>> APIs I need to query hardware capabilities to avoid setting nvenc
>> codec parameters that would cause the codec to fail to initialize via
>> ffmpeg apis.  Given that ffmpeg already includes the headers that
>> declare those APIs I've been able to use them without installing nvenc
>> SDK separately, but since they are private headers in the ffmpeg
>> source tree it feels dirty to do that.
>
>
> Your use-case looks like an argument for moving the external headers into
> some separate repository. Not that I personally care much about bundling or
> not bundling. To me the more important question seems to be whether to
> auto-enable the encoders/decoders that depend on the external headers and
> libraries or not.


Yeah, that would be cleaner, but it does bring up the maintenance
burden that Nicolas has mentioned.  As long as the headers are in the
ffmpeg tree -- the maintenance burden is on ffmpeg.  When the headers
are moved to an external repo it would not necessarily be an ffmpeg
projects maintenance burden, but then who should be maintaining it?
The vendor?

Pavel.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[wm4]

On Wed, 29 Nov 2017 15:45:28 +
"Mironov, Mikhail" <mikhail.miro...@amd.com> wrote:

> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Paul B Mahol
> > Sent: November 29, 2017 10:16 AM
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>  
> > Subject: Re: [FFmpeg-devel] AMD external header
> > 
> > On 11/29/17, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:  
> > > 2017-11-29 15:58 GMT+01:00 wm4 <nfx...@googlemail.com>:
> > >  
> > >> Well, don't worry too much. People like him are, as some would say,
> > >> toxic members of the community. Frequent drama and flame wars  
> > happen.  
> > >> (And here's where I wished ffmpeg were a properly managed project.)  
> > >
> > > Look who's talking!
> > >
> > > Given that you started a fork of FFmpeg repeating ancient lies and
> > > stating you don't support FFmpeg anymore:
> > > Why do you post here?  
> > 
> > Because he like to argue with toxic people like you.
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel  
> 
> Hi,
> This conversation is very entertaining but leads us nowhere. 
> May I suggest to go down to business of enabling HW encoders by default?
> Yesterday Mark submitted the initial implementation and I really want 
> to thank him for his mentoring and participation - it was very useful. 
> The submission doesn't have AMD header so AMD encoder is off in any default 
> build.
> I counted responses to my posts and found six people are for the default 
> enabling 
> of HW blocks one way or another: by including headers or pulling them out 
> automatically using git (I guess via submodules?). 
> Two people want to remove external headers and disable default HW 
> acceleration. 
> Question is: how to move forward on practical terms? I really don’t know how 
> this team makes such decisions.
> Or maybe it is impasse case and  all want to keep things the way they are 
> today?

We don't automatically check out git repos as part of the build
process. That means the user will have to get those headers to build
AMD support. AMD support could still be autodetected, and enabled if
the headers are available.

This is not different from how it works with Intel and vaapi/qsv, so I'd
say that's fair.

Do you agree with this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Compn]

On Wed, 29 Nov 2017 15:45:28 +, "Mironov, Mikhail"
 wrote:
> May I suggest to go down to business of enabling HW encoders by default?
> Yesterday Mark submitted the initial implementation and I really want 
> to thank him for his mentoring and participation - it was very useful. 
> Question is: how to move forward on practical terms? I really don’t know how 
> this team makes such decisions.
> Or maybe it is impasse case and  all want to keep things the way they are 
> today?

probably wait a few days until the maintainer of hwaccels can chime in,
possibly with some more reviews.

please be patient.

-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: November 29, 2017 10:16 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] AMD external header
> 
> On 11/29/17, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> > 2017-11-29 15:58 GMT+01:00 wm4 <nfx...@googlemail.com>:
> >
> >> Well, don't worry too much. People like him are, as some would say,
> >> toxic members of the community. Frequent drama and flame wars
> happen.
> >> (And here's where I wished ffmpeg were a properly managed project.)
> >
> > Look who's talking!
> >
> > Given that you started a fork of FFmpeg repeating ancient lies and
> > stating you don't support FFmpeg anymore:
> > Why do you post here?
> 
> Because he like to argue with toxic people like you.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Hi,
This conversation is very entertaining but leads us nowhere. 
May I suggest to go down to business of enabling HW encoders by default?
Yesterday Mark submitted the initial implementation and I really want 
to thank him for his mentoring and participation - it was very useful. 
The submission doesn't have AMD header so AMD encoder is off in any default 
build.
I counted responses to my posts and found six people are for the default 
enabling 
of HW blocks one way or another: by including headers or pulling them out 
automatically using git (I guess via submodules?). 
Two people want to remove external headers and disable default HW acceleration. 
Question is: how to move forward on practical terms? I really don’t know how 
this team makes such decisions.
Or maybe it is impasse case and  all want to keep things the way they are today?
Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Hendrik Leppkes]

On Wed, Nov 29, 2017 at 4:07 PM, Carl Eugen Hoyos  wrote:
> 2017-11-29 15:58 GMT+01:00 wm4 :
>
>> Well, don't worry too much. People like him are, as some would say,
>> toxic members of the community. Frequent drama and flame wars happen.
>> (And here's where I wished ffmpeg were a properly managed project.)
>
> Look who's talking!
>
> Given that you started a fork of FFmpeg [...] Why do you post here?

Forking is an integral part of open-source development. Everytime you
clone a repository and develop in it, you're already forking.
Claiming that this should exclude anyone from contributing back to the
upstream project goes against every fundamental concept that
open-source is all about.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Compn]

On Wed, 29 Nov 2017 16:16:12 +0100, Paul B Mahol 
wrote:

> On 11/29/17, Carl Eugen Hoyos  wrote:
> > 2017-11-29 15:58 GMT+01:00 wm4 :
> >
> >> Well, don't worry too much. People like him are, as some would say,
> >> toxic members of the community. Frequent drama and flame wars happen.
> >> (And here's where I wished ffmpeg were a properly managed project.)
> >
> > Look who's talking!
> >
> > Given that you started a fork of FFmpeg repeating ancient lies
> > and stating you don't support FFmpeg anymore:
> > Why do you post here?
> 
> Because he like to argue with toxic people like you.

carl, wm4 and paul please ignore flames. please?

no reason to continue these flames and not on the mailing list
for sure.

nicolas is entitled to his opinion and licensing choices. no single dev
speaks for the entire project.

wm4 is entitled to fork whatever open source project he wants, and hes
welcome to post here and review patches and be a developer.

carl you dont have to respond to every aggressive post. nor do you have
to attack people.

paul and wm4 please stop insulting developers and calling them names.

-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[wm4]

On Wed, 29 Nov 2017 10:23:54 -0500
Compn  wrote:

> On Wed, 29 Nov 2017 15:58:29 +0100, wm4  wrote:
> 
> > On Tue, 28 Nov 2017 16:09:57 +
> > "Mironov, Mikhail"  wrote:  
> > > 
> > > I wanted to stay out of license issues and this forum is oriented more 
> > > towards 
> > > technical discussion but I can't resist putting my two cents: Yes, HW 
> > > manufactures
> > >  live out of HW sell. And yes, integration with products like ffmpeg 
> > > should benefit them (us).
> > > But they(us) do not sell software. The enablement of HW acceleration adds 
> > > features to ffmpeg project.  
> > > And we do it ourselves. We also intend to contribute more. So it is 
> > > mutually beneficial.  Isn't it?  
> > 
> > Well, don't worry too much.   
> 
> as an mplayer user who had to go looking to find a bunch of sdk headers
> and hope that the instructions written 2 years ago still point to a
> working URL, i feel a lot of pain in this thread.
> 
> svn has svn externals, where a svn checkout would pull from other svn
> repositories.
> 
> i am assuming git has the same thing? if so these headers could go in
> an external repo, but a ffmpeg git pull would pull them down? are there
> any objections to that ?
> 
> that would cut down on our objections and maintainership and git
> history concerns... i think? so long as its easy for non amd users to
> flip a config switch to disable pulling those amd headers down.

The ffmpeg repository is for the ffmpeg code, it's not a meta build
system.

But anyone is free to propose a repository with a script that
automatically pulls in most dependencies and builds ffmpeg. There are
actually a lot of those around for various software, but if you feel
like having an "official" one would improve the situation, go ahead.

Regarding non-working URLs, that can happen with external repositories
too, of course. For important enough stuff we could host them alongside
the ffmpeg repository, and we could indeed create a "vendor-sdks" git
repository, that would contain AMD, nvidia, and avisynth headers.

The point is that none of this should clutter the ffmpeg repo itself.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[wm4]

On Wed, 29 Nov 2017 16:07:36 +0100
Carl Eugen Hoyos  wrote:

> 2017-11-29 15:58 GMT+01:00 wm4 :
> 
> > Well, don't worry too much. People like him are, as some would say,
> > toxic members of the community. Frequent drama and flame wars happen.
> > (And here's where I wished ffmpeg were a properly managed project.)  
> 
> Look who's talking!
> 
> Given that you started a fork of FFmpeg repeating ancient lies
> and stating you don't support FFmpeg anymore:
> Why do you post here?

You won't hear any lies from me. But it's well known that you twist the
truth whenever it fits you.

Anyway, this is the upstream project for ffmpeg-mpv, so why wouldn't I
post here?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Compn]

On Wed, 29 Nov 2017 15:58:29 +0100, wm4  wrote:

> On Tue, 28 Nov 2017 16:09:57 +
> "Mironov, Mikhail"  wrote:
> > 
> > I wanted to stay out of license issues and this forum is oriented more 
> > towards 
> > technical discussion but I can't resist putting my two cents: Yes, HW 
> > manufactures
> >  live out of HW sell. And yes, integration with products like ffmpeg should 
> > benefit them (us).
> > But they(us) do not sell software. The enablement of HW acceleration adds 
> > features to ffmpeg project.  
> > And we do it ourselves. We also intend to contribute more. So it is 
> > mutually beneficial.  Isn't it?
> 
> Well, don't worry too much. 

as an mplayer user who had to go looking to find a bunch of sdk headers
and hope that the instructions written 2 years ago still point to a
working URL, i feel a lot of pain in this thread.

svn has svn externals, where a svn checkout would pull from other svn
repositories.

i am assuming git has the same thing? if so these headers could go in
an external repo, but a ffmpeg git pull would pull them down? are there
any objections to that ?

that would cut down on our objections and maintainership and git
history concerns... i think? so long as its easy for non amd users to
flip a config switch to disable pulling those amd headers down.

-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Paul B Mahol]

On 11/29/17, Carl Eugen Hoyos  wrote:
> 2017-11-29 15:58 GMT+01:00 wm4 :
>
>> Well, don't worry too much. People like him are, as some would say,
>> toxic members of the community. Frequent drama and flame wars happen.
>> (And here's where I wished ffmpeg were a properly managed project.)
>
> Look who's talking!
>
> Given that you started a fork of FFmpeg repeating ancient lies
> and stating you don't support FFmpeg anymore:
> Why do you post here?

Because he like to argue with toxic people like you.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Carl Eugen Hoyos]

2017-11-29 15:58 GMT+01:00 wm4 :

> Well, don't worry too much. People like him are, as some would say,
> toxic members of the community. Frequent drama and flame wars happen.
> (And here's where I wished ffmpeg were a properly managed project.)

Look who's talking!

Given that you started a fork of FFmpeg repeating ancient lies
and stating you don't support FFmpeg anymore:
Why do you post here?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[wm4]

On Tue, 28 Nov 2017 16:09:57 +
"Mironov, Mikhail"  wrote:

> > 
> > Pavel Koshevoy (2017-11-27):  
> > > That is unnecessarily un-diplomatic and will likely offend the
> > > contributors from nvidia and amd.  
> > 
> > Well, I find offensive that they benefit from my work yet make extra efforts
> > to make sure I cannot benefit from theirs. Maybe I should start putting my
> > contributions under GPL and not LGPL, what do you think?
> >   
> > > Personally, I would prefer if the bundled external headers were
> > > installed together with ffmpeg public headers (so nvenc/cuda/etc...
> > > weren't simply private headers within ffmpeg).  There are some nvenc
> > > APIs I need to query hardware capabilities to avoid setting nvenc
> > > codec parameters that would cause the codec to fail to initialize via
> > > ffmpeg apis.  Given that ffmpeg already includes the headers that
> > > declare those APIs I've been able to use them without installing nvenc
> > > SDK separately, but since they are private headers in the ffmpeg
> > > source tree it feels dirty to do that.  
> > 
> > I understand it is more convenient for you than what the vendors provide,
> > but why should the effort of making things more convenient be carried by
> > the FFmpeg developers?
> > 
> > It has a non-negligible cost: more testing required, git grep pollution, 
> > all the
> > while giving these companies an unfair advantage against the companies that
> > play by the rules of Libre software and inciting them to continue in that
> > direction.
> > 
> > I think the whole compat directory is misguided, but these headers for
> > external libraries are the worse of it.
> > 
> > Regards,
> > 
> > --
> >   Nicolas George  
> 
> I wanted to stay out of license issues and this forum is oriented more 
> towards 
> technical discussion but I can't resist putting my two cents: Yes, HW 
> manufactures
>  live out of HW sell. And yes, integration with products like ffmpeg should 
> benefit them (us).
> But they(us) do not sell software. The enablement of HW acceleration adds 
> features to ffmpeg project.  
> And we do it ourselves. We also intend to contribute more. So it is mutually 
> beneficial.  Isn't it?

Well, don't worry too much. People like him are, as some would say,
toxic members of the community. Frequent drama and flame wars happen.
(And here's where I wished ffmpeg were a properly managed project.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[wm4]

On Mon, 27 Nov 2017 02:15:12 +
"Mironov, Mikhail"  wrote:

> Hi,
> I would like to summarize thoughts on several threads on this forum related 
> to the issue of including AMD/AMF header file into FFmpeg source tree. 
> It looks like they reflect some policies formal or informal.
> Mark tried to create some policy regarding this issue but wasn't successful. 
> I believe a policy is always created to reach some goal. 
> So my summary will be in form of triad: 
> policy->goal->possible action
> I will skip all arguments, you already read them.
> #1
>policy: do not include external headers
>goal: minimize maintenance efforts and increase stability of the project
>action: remove NVidia headers
> #2
>policy: keep certain headers in the tree based on some criteria
>goal: provide certain level of convenience for ordinary users
>action: include AMD header
> #3
>   policy: do whatever is needed to achieve the goal
>   goal: achieve neutrality in relation to HW vendors
>   action: remove NVidia headers or add AMD header
> 
> Since these policies contradict each other, some priorities should be set 
> and I don't know how to do it. Personally I like #2 the most, but this is not 
> my call.
> But my point is that by keeping NVidia headers in the tree and not allowing 
> AMD header, 
> FFmpeg development team breaks all three policies and do not achieve any goal.
> If this is what you want maybe you should state this explicitly on the 
> "About" page 
> as Mark suggested: 
> "No external headers may be added to the ffmpeg tree, unless they are for 
> AviSynth or Nvidia"
> At least it will be clear for all users and developers. 
> You may say that you will include only headers hard to get. But does it mean 
> that AMD must 
> obscure access to the headers to be included? I hope not.

I'd definitely say adding the nvidia and AviSynth headers was a
mistake. Only headers for basic OS compatibility should be allowed. A
good example for such headers would the atomics emulation or msvcrt
compatibility. In general, the allowed external code/headers are
supposed to support things guaranteed by standards (like C or POSIX),
not third-party libraries like vendor-specific drivers or SDKs.

At this point, the nvidia and avisynth headers are probably considered
against the rules. But as the damage is done and removal would cause
problems to certain people, they're "grandfathered". Mark Thompson put
that into words by making them explicit exceptions to the rule.

(Though I think the avisynth headers should be removed because they're
far less useful than nvidia drivers.)

It also should be made clear that nvidia does not somehow receive
preferred treatment over other vendors. In fact, if someone were to
send a patch to move the nvidia headers to a separate repository, I'd
definitely give it a OK (though I have no special say in this and it
depends on other devs too.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> 
> Pavel Koshevoy (2017-11-27):
> > That is unnecessarily un-diplomatic and will likely offend the
> > contributors from nvidia and amd.
> 
> Well, I find offensive that they benefit from my work yet make extra efforts
> to make sure I cannot benefit from theirs. Maybe I should start putting my
> contributions under GPL and not LGPL, what do you think?
> 
> > Personally, I would prefer if the bundled external headers were
> > installed together with ffmpeg public headers (so nvenc/cuda/etc...
> > weren't simply private headers within ffmpeg).  There are some nvenc
> > APIs I need to query hardware capabilities to avoid setting nvenc
> > codec parameters that would cause the codec to fail to initialize via
> > ffmpeg apis.  Given that ffmpeg already includes the headers that
> > declare those APIs I've been able to use them without installing nvenc
> > SDK separately, but since they are private headers in the ffmpeg
> > source tree it feels dirty to do that.
> 
> I understand it is more convenient for you than what the vendors provide,
> but why should the effort of making things more convenient be carried by
> the FFmpeg developers?
> 
> It has a non-negligible cost: more testing required, git grep pollution, all 
> the
> while giving these companies an unfair advantage against the companies that
> play by the rules of Libre software and inciting them to continue in that
> direction.
> 
> I think the whole compat directory is misguided, but these headers for
> external libraries are the worse of it.
> 
> Regards,
> 
> --
>   Nicolas George

I wanted to stay out of license issues and this forum is oriented more towards 
technical discussion but I can't resist putting my two cents: Yes, HW 
manufactures
 live out of HW sell. And yes, integration with products like ffmpeg should 
benefit them (us).
But they(us) do not sell software. The enablement of HW acceleration adds 
features to ffmpeg project.  
And we do it ourselves. We also intend to contribute more. So it is mutually 
beneficial.  Isn't it?
Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Nicolas George]

Pavel Koshevoy (2017-11-27):
> That is unnecessarily un-diplomatic and will likely offend the
> contributors from nvidia and amd.

Well, I find offensive that they benefit from my work yet make extra
efforts to make sure I cannot benefit from theirs. Maybe I should start
putting my contributions under GPL and not LGPL, what do you think?

> Personally, I would prefer if the bundled external headers were
> installed together with ffmpeg public headers (so nvenc/cuda/etc...
> weren't simply private headers within ffmpeg).  There are some nvenc
> APIs I need to query hardware capabilities to avoid setting nvenc
> codec parameters that would cause the codec to fail to initialize via
> ffmpeg apis.  Given that ffmpeg already includes the headers that
> declare those APIs I've been able to use them without installing nvenc
> SDK separately, but since they are private headers in the ffmpeg
> source tree it feels dirty to do that.

I understand it is more convenient for you than what the vendors
provide, but why should the effort of making things more convenient be
carried by the FFmpeg developers?

It has a non-negligible cost: more testing required, git grep pollution,
all the while giving these companies an unfair advantage against the
companies that play by the rules of Libre software and inciting them to
continue in that direction.

I think the whole compat directory is misguided, but these headers for
external libraries are the worse of it.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

Your use-case looks like an argument for moving the external headers 
into some separate repository. Not that I personally care much about 
bundling or not bundling. To me the more important question seems to be 
whether to auto-enable the encoders/decoders that depend on the external 
headers and libraries or not.


At least nvenc will stay as auto-enable even with out-of-tree headers, 
except that it will obviously check if it has the required headers 
available.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Tobias Rapp]

On 27.11.2017 17:14, Pavel Koshevoy wrote:

On Mon, Nov 27, 2017 at 8:25 AM, Nicolas George  wrote:

Mironov, Mikhail (2017-11-27):

#1
policy: do not include external headers
goal: minimize maintenance efforts and increase stability of the project
action: remove NVidia headers


Add to the goal: avoid being complicit of free-riders on the Libre
software bandwagon.


That is unnecessarily un-diplomatic and will likely offend the
contributors from nvidia and amd.

Personally, I would prefer if the bundled external headers were
installed together with ffmpeg public headers (so nvenc/cuda/etc...
weren't simply private headers within ffmpeg).  There are some nvenc
APIs I need to query hardware capabilities to avoid setting nvenc
codec parameters that would cause the codec to fail to initialize via
ffmpeg apis.  Given that ffmpeg already includes the headers that
declare those APIs I've been able to use them without installing nvenc
SDK separately, but since they are private headers in the ffmpeg
source tree it feels dirty to do that.


Your use-case looks like an argument for moving the external headers 
into some separate repository. Not that I personally care much about 
bundling or not bundling. To me the more important question seems to be 
whether to auto-enable the encoders/decoders that depend on the external 
headers and libraries or not.


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

Am 27.11.2017 um 03:15 schrieb Mironov, Mikhail:

Hi,
I would like to summarize thoughts on several threads on this forum related
to the issue of including AMD/AMF header file into FFmpeg source tree.
It looks like they reflect some policies formal or informal.
Mark tried to create some policy regarding this issue but wasn't successful.
I believe a policy is always created to reach some goal.
So my summary will be in form of triad:
policy->goal->possible action
I will skip all arguments, you already read them.
#1
policy: do not include external headers
goal: minimize maintenance efforts and increase stability of the project
action: remove NVidia headers
#2
policy: keep certain headers in the tree based on some criteria
goal: provide certain level of convenience for ordinary users
action: include AMD header
#3
   policy: do whatever is needed to achieve the goal
   goal: achieve neutrality in relation to HW vendors
   action: remove NVidia headers or add AMD header

Since these policies contradict each other, some priorities should be set
and I don't know how to do it. Personally I like #2 the most, but this is not 
my call.
But my point is that by keeping NVidia headers in the tree and not allowing AMD 
header,
FFmpeg development team breaks all three policies and do not achieve any goal.
If this is what you want maybe you should state this explicitly on the "About" 
page
as Mark suggested:
"No external headers may be added to the ffmpeg tree, unless they are for AviSynth 
or Nvidia"
At least it will be clear for all users and developers.
You may say that you will include only headers hard to get. But does it mean 
that AMD must
obscure access to the headers to be included? I hope not.


I also want to mention, while I prefer to include the header, if the 
final decision is to get rid of them(which imo is the only viable other 
option), I will not fight that.


In that case I would move the nvidia headers to a repository on 
github.com/FFmpeg, if that's ok with everyone, to keep them in a 
somewhat ffmpeg-official state.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

Personally, I would prefer if the bundled external headers were
installed together with ffmpeg public headers (so nvenc/cuda/etc...
weren't simply private headers within ffmpeg).  There are some nvenc
APIs I need to query hardware capabilities to avoid setting nvenc
codec parameters that would cause the codec to fail to initialize via
ffmpeg apis.  Given that ffmpeg already includes the headers that
declare those APIs I've been able to use them without installing nvenc
SDK separately, but since they are private headers in the ffmpeg
source tree it feels dirty to do that.


Well that is definitely not going to happen.
Nobody will watch over API/ABI compatibility in those headers.
If you need them, get them yourself.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Pavel Koshevoy]

On Mon, Nov 27, 2017 at 8:25 AM, Nicolas George  wrote:
> Mironov, Mikhail (2017-11-27):
>> #1
>>policy: do not include external headers
>>goal: minimize maintenance efforts and increase stability of the project
>>action: remove NVidia headers
>
> Add to the goal: avoid being complicit of free-riders on the Libre
> software bandwagon.

That is unnecessarily un-diplomatic and will likely offend the
contributors from nvidia and amd.

Personally, I would prefer if the bundled external headers were
installed together with ffmpeg public headers (so nvenc/cuda/etc...
weren't simply private headers within ffmpeg).  There are some nvenc
APIs I need to query hardware capabilities to avoid setting nvenc
codec parameters that would cause the codec to fail to initialize via
ffmpeg apis.  Given that ffmpeg already includes the headers that
declare those APIs I've been able to use them without installing nvenc
SDK separately, but since they are private headers in the ffmpeg
source tree it feels dirty to do that.

Pavel.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Nicolas George]

Mironov, Mikhail (2017-11-27):
> #1
>policy: do not include external headers
>goal: minimize maintenance efforts and increase stability of the project
>action: remove NVidia headers

Add to the goal: avoid being complicit of free-riders on the Libre
software bandwagon.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Timo Rothenpieler
> Sent: November 27, 2017 5:08 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] AMD external header
> 
> Am 27.11.2017 um 03:15 schrieb Mironov, Mikhail:
> > Hi,
> > I would like to summarize thoughts on several threads on this forum
> > related to the issue of including AMD/AMF header file into FFmpeg source
> tree.
> > It looks like they reflect some policies formal or informal.
> > Mark tried to create some policy regarding this issue but wasn't successful.
> > I believe a policy is always created to reach some goal.
> > So my summary will be in form of triad:
> > policy->goal->possible action
> > I will skip all arguments, you already read them.
> > #1
> > policy: do not include external headers
> > goal: minimize maintenance efforts and increase stability of the project
> > action: remove NVidia headers
> > #2
> > policy: keep certain headers in the tree based on some criteria
> > goal: provide certain level of convenience for ordinary users
> > action: include AMD header
> 
> As I have stated before, I am fine with shipping the header, and would prefer
> it over having to collect a bunch of headers from various repositories.
> To limit it a bit, I'd say in-tree external headers should be limited to 
> header-
> only interfaces to system-libraries(The nvidia and amd drivers count as
> system libs) or other extreme cases like AviSynth.

This sounds like a good policy. How would we move from there on practical terms?

> 
> > #3
> >policy: do whatever is needed to achieve the goal
> >goal: achieve neutrality in relation to HW vendors
> >action: remove NVidia headers or add AMD header
> >

Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> >
> > I also noticed that recently there is a lot of activity to add full Nvidia
> decoders  to FFmpeg (VC1, MPEG4, VP8, VP9 etc.).
> > I am guessing this is to overcome DXVA or VAAPI shortcoming. What about
> AMD? We also have them.
> >
> >
> 
> DXVA2/D3D11VA work perfectly fine, on Windows i see no huge reason to
> use NVDEC (and the same can probably be said for whatever AMD
> solution) - and in fact from a user (and developer) perspective its much nicer
> to just use the same hwaccel on all hardware. But Linux is another matter. I
> don't know how well AMD works with VAAPI or VDPAU (if at all), but at least
> for NVIDIA VDPAU has its issues and VAAPI is not supported at all (except
> with a VAAPI VDPAU adapter, which  has the same issues, obviously)
> 
> Until you guys actually provide Linux support, adding a HWAccel might not be
> that advantageous for the user-base.

Thanks for the explanations. I don’t want to add more codecs just for sake of 
adding.
I will check if DXVA2/D3D11VA implementation has shortcomings and propose 
additions 
only if it is really needed. The same on Linux: we will see what driver team 
will provide on 
Linux and if AMF-based codec are needed to be integrated.
I will concentrate more on GPU color converter filter: with it user should be 
able to 
create fully accelerated pipeline.

> 
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

Am 27.11.2017 um 03:15 schrieb Mironov, Mikhail:

Hi,
I would like to summarize thoughts on several threads on this forum related
to the issue of including AMD/AMF header file into FFmpeg source tree.
It looks like they reflect some policies formal or informal.
Mark tried to create some policy regarding this issue but wasn't successful.
I believe a policy is always created to reach some goal.
So my summary will be in form of triad:
policy->goal->possible action
I will skip all arguments, you already read them.
#1
policy: do not include external headers
goal: minimize maintenance efforts and increase stability of the project
action: remove NVidia headers
#2
policy: keep certain headers in the tree based on some criteria
goal: provide certain level of convenience for ordinary users
action: include AMD header


As I have stated before, I am fine with shipping the header, and would 
prefer it over having to collect a bunch of headers from various 
repositories.
To limit it a bit, I'd say in-tree external headers should be limited to 
header-only interfaces to system-libraries(The nvidia and amd drivers 
count as system libs) or other extreme cases like AviSynth.



#3
   policy: do whatever is needed to achieve the goal
   goal: achieve neutrality in relation to HW vendors
   action: remove NVidia headers or add AMD header





smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

I also noticed that recently there is a lot of activity to add full Nvidia 
decoders  to FFmpeg (VC1, MPEG4, VP8, VP9 etc.).
I am guessing this is to overcome DXVA or VAAPI shortcoming. What about AMD? We 
also have them.


The primary motivation here is that nvidia abandoned vdpau, so to access 
more modern decoder features, which on Windows are easily available 
through DXVA2/D3D11VA, you are forced to use their API.


If AMD properly supports all those(most prominently VP9 and 10/12bit) 
via vaapi/dxva, there shouldn't be a reason for another API.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Hendrik Leppkes]

On Mon, Nov 27, 2017 at 4:00 AM, Mironov, Mikhail
 wrote:
>
> I also noticed that recently there is a lot of activity to add full Nvidia 
> decoders  to FFmpeg (VC1, MPEG4, VP8, VP9 etc.).
> I am guessing this is to overcome DXVA or VAAPI shortcoming. What about AMD? 
> We also have them.
>
>

DXVA2/D3D11VA work perfectly fine, on Windows i see no huge reason to
use NVDEC (and the same can probably be said for whatever AMD
solution) - and in fact from a user (and developer) perspective its
much nicer to just use the same hwaccel on all hardware. But Linux is
another matter. I don't know how well AMD works with VAAPI or VDPAU
(if at all), but at least for NVIDIA VDPAU has its issues and VAAPI is
not supported at all (except with a VAAPI VDPAU adapter, which  has
the same issues, obviously)

Until you guys actually provide Linux support, adding a HWAccel might
not be that advantageous for the user-base.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Carl Eugen Hoyos]

2017-11-27 4:00 GMT+01:00 Mironov, Mikhail <mikhail.miro...@amd.com>:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Carl Eugen Hoyos
>> Sent: November 26, 2017 9:36 PM
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] AMD external header
>>
>> 2017-11-27 3:32 GMT+01:00 Mironov, Mikhail
>> <mikhail.miro...@amd.com>:
>> >> -Original Message-
>> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>> Behalf
>> >> Of Carl Eugen Hoyos
>>
>> >> Also, imo you have not really explained which users would have an
>> >> advantage if FFmpeg includes the AMD header.
>> >
>> > It is more a question to people who included NVidia headers.
>>
>> I don't think my question can be answered by Nvidia users or developers.
>> You are the exclusive recipient for my question.
>>
>> > It was for convenience, isn't it?
>>
>> That is possible and I assume you want the AMD headers added for
>> convenience but that wasn't my question.
>
> In my many years of using FFmpeg as a library and as a tool I saw a lot of 
> people who build FFmpeg
> on they own as I do. One, but not all reasons for a custom build is desire to 
> debug whole application
> with one tool and on Windows many people still use Visual Studio so they make 
> a build with VS,
> which is not available in places like zeranoe.
> Another reason is to make minimum feature set needed to their app.

Thank you for the useful explanation!

> At the same time for many real-time applications a software encoder is not an 
> option.

> So these developers will appreciate default support for both GPUs.

But if all above only applies to developers (and not to users) I still
believe it is not necessary to add the header, simply because
every developer will manage to download a header from your
github page.

[...]

> What about AMD? We also have them.

I believe Hendrik answered to that argument some time ago,
others disagreed.

I can only state that the more often you repeat it, the stronger I
feel urged to request a code cleanup including documentation
for the header before it gets added.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> 
> Nobody is against adding AMD specific encoders and hwaccels. The issue for
> some seems to be the inclusion of external headers.
> 
> Currently, nothing in our policy is against it, and as I and Philip already
> stated, your additions shouldn't be gated on a potential future policy change
> about bundled headers, so your patch can initially go in with the header.

I sent this email in response to Mark's who stated that he will not include the 
header. 
I understand the delayed decision about external headers and will be OK with 
any 
outcome as long as it is universal.

> 
> > I also noticed that recently there is a lot of activity to add full Nvidia
> decoders  to FFmpeg (VC1, MPEG4, VP8, VP9 etc.).
> > I am guessing this is to overcome DXVA or VAAPI shortcoming. What about
> AMD? We also have them.
> 
> Simply put, those developers wanted to write those features.
> 
> dxva2 and d3d11va work just fine with AMD hardware, for that matter. And
> nobody stops you or anyone to write similar hwaccels for AMD specific APIs.

If it makes sense I would like to add decoders as well as accelerated converter 
as soon as encoder is in.

Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[James Almer]

On 11/27/2017 12:00 AM, Mironov, Mikhail wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Carl Eugen Hoyos
>> Sent: November 26, 2017 9:36 PM
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] AMD external header
>>
>> 2017-11-27 3:32 GMT+01:00 Mironov, Mikhail
>> <mikhail.miro...@amd.com>:
>>>> -Original Message-
>>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>> Behalf
>>>> Of Carl Eugen Hoyos
>>
>>>> Also, imo you have not really explained which users would have an
>>>> advantage if FFmpeg includes the AMD header.
>>>
>>> It is more a question to people who included NVidia headers.
>>
>> I don't think my question can be answered by Nvidia users or developers.
>> You are the exclusive recipient for my question.
>>
>>> It was for convenience, isn't it?
>>
>> That is possible and I assume you want the AMD headers added for
>> convenience but that wasn't my question.
> 
> In my many years of using FFmpeg as a library and as a tool I saw a lot of 
> people who build FFmpeg 
> on they own as I do. One, but not all reasons for a custom build is desire to 
> debug whole application 
> with one tool and on Windows many people still use Visual Studio so they make 
> a build with VS, 
> which is not available in places like zeranoe. 
> Another reason is to make minimum feature set needed to their app.
> At the same time for many real-time applications a software encoder is not an 
> option. 
> So these developers will appreciate default support for both GPUs. Everything 
> related to 
> game streaming (OBS), DVR, could gaming, wireless virtual reality etc. are 
> use cases and real users behind.
> Again we are talking about ease of access, not about impossibility.
> I would like to see that people set few parameters and encoding would happen 
> without additional going through hoops.

Nobody is against adding AMD specific encoders and hwaccels. The issue
for some seems to be the inclusion of external headers.

Currently, nothing in our policy is against it, and as I and Philip
already stated, your additions shouldn't be gated on a potential future
policy change about bundled headers, so your patch can initially go in
with the header.

> I also noticed that recently there is a lot of activity to add full Nvidia 
> decoders  to FFmpeg (VC1, MPEG4, VP8, VP9 etc.). 
> I am guessing this is to overcome DXVA or VAAPI shortcoming. What about AMD? 
> We also have them.

Simply put, those developers wanted to write those features.

dxva2 and d3d11va work just fine with AMD hardware, for that matter. And
nobody stops you or anyone to write similar hwaccels for AMD specific APIs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: November 26, 2017 9:36 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] AMD external header
> 
> 2017-11-27 3:32 GMT+01:00 Mironov, Mikhail
> <mikhail.miro...@amd.com>:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Carl Eugen Hoyos
> 
> >> Also, imo you have not really explained which users would have an
> >> advantage if FFmpeg includes the AMD header.
> >
> > It is more a question to people who included NVidia headers.
> 
> I don't think my question can be answered by Nvidia users or developers.
> You are the exclusive recipient for my question.
> 
> > It was for convenience, isn't it?
> 
> That is possible and I assume you want the AMD headers added for
> convenience but that wasn't my question.

In my many years of using FFmpeg as a library and as a tool I saw a lot of 
people who build FFmpeg 
on they own as I do. One, but not all reasons for a custom build is desire to 
debug whole application 
with one tool and on Windows many people still use Visual Studio so they make a 
build with VS, 
which is not available in places like zeranoe. 
Another reason is to make minimum feature set needed to their app.
At the same time for many real-time applications a software encoder is not an 
option. 
So these developers will appreciate default support for both GPUs. Everything 
related to 
game streaming (OBS), DVR, could gaming, wireless virtual reality etc. are use 
cases and real users behind.
Again we are talking about ease of access, not about impossibility.
I would like to see that people set few parameters and encoding would happen 
without additional going through hoops.

I also noticed that recently there is a lot of activity to add full Nvidia 
decoders  to FFmpeg (VC1, MPEG4, VP8, VP9 etc.). 
I am guessing this is to overcome DXVA or VAAPI shortcoming. What about AMD? We 
also have them.

Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Carl Eugen Hoyos]

2017-11-27 3:32 GMT+01:00 Mironov, Mikhail :
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Carl Eugen Hoyos

>> Also, imo you have not really explained which users would have an
>> advantage if FFmpeg includes the AMD header.
>
> It is more a question to people who included NVidia headers.

I don't think my question can be answered by Nvidia users
or developers. You are the exclusive recipient for my question.

> It was for convenience, isn't it?

That is possible and I assume you want the AMD headers added
for convenience but that wasn't my question.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: November 26, 2017 9:25 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] AMD external header
> 
> 2017-11-27 3:15 GMT+01:00 Mironov, Mikhail
> <mikhail.miro...@amd.com>:
> 
> > I will skip all arguments, you already read them.
> 
> That's great, but I believe you forgot to add the fourth option.

I just wanted to start a discussion. Please state what is fourth option?
Though, I put it as a policy which is slightly different from option. 

> 
> Also, imo you have not really explained which users would have an
> advantage if FFmpeg includes the AMD header.

It is more a question to people who included NVidia headers. It was for 
convenience, isn't it?
Are you saying that there is a difference and it is based on easy access of the 
header?
> 
> Carl Eugen
> (who has never used any hardware encoder)
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Carl Eugen Hoyos]

2017-11-27 3:15 GMT+01:00 Mironov, Mikhail :

> I will skip all arguments, you already read them.

That's great, but I believe you forgot to add the fourth option.

Also, imo you have not really explained which users
would have an advantage if FFmpeg includes the AMD header.

Carl Eugen
(who has never used any hardware encoder)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel