From: ffmpeg-devel on behalf of Compn
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"
wrote:
> Do you t
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
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
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/
> -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
>
> O
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
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
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
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
_
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
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
___
ffmpe
> -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
>
> O
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 hav
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 transcodin
>
> 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/listi
> -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 +
>
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 avoi
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 suppo
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/dec
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
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 clo
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 head
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 nv
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 ar
cussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] AMD external header
> >
> > On 11/29/17, Carl Eugen Hoyos wrote:
> > > 2017-11-29 15:58 GMT+01:00 wm4 :
> > >
> > >> Well, don't worry too much. People li
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:
> -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 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
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 he
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 discussi
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
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
> > manufacture
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
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 o
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
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 t
>
> 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
>
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 un
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
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 t
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 reg
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 cau
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
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,
--
> -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
> >
> > 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 se
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 reg
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
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.
>
>
DXVA
de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] AMD external header
>>
>> 2017-11-27 3:32 GMT+01:00 Mironov, Mikhail
>> :
>> >> -Original Message-
>> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>> Behalf
>> &
>
> 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
> ab
de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] AMD external header
>>
>> 2017-11-27 3:32 GMT+01:00 Mironov, Mikhail
>> :
>>>> -Original Message-
>>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>> Behalf
>>
> -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 :
>> -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
> -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 :
> 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 ne
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 belie
57 matches
Mail list logo
