On 11/05/2017 11:12 PM, Jan Ekstrom wrote:
I also feel like whatever this rule would look like, it's already practiced
that way. There isn't really a way not do decide this on a case by case
basis. Luckily it's not something that comes up every other day.
If someone would submit random third part
On Sun, Nov 5, 2017 at 10:40 PM, Timo Rothenpieler
wrote:
> For once, there should be a good reason to do so.
>
Agreed.
> In case of nvidia the headers in this form is otherwise unobtainable, and
> it's also partially modified specifically for use in ffmpeg.
> Getting the original headers is als
On Sun, Nov 05, 2017 at 06:59:42PM +, Mark Thompson wrote:
> On 05/11/17 18:42, Carl Eugen Hoyos wrote:
> > 2017-11-05 19:35 GMT+01:00 Mark Thompson :
> >> On 05/11/17 18:28, Carl Eugen Hoyos wrote:
> >>> 2017-11-05 15:24 GMT+01:00 Mark Thompson :
> On 30/10/17 19:51, Mark Thompson wrote:
How about:
"No external headers may be added to the ffmpeg tree, unless they are for AviSynth
or Nvidia."
I don't think a strict "no external headers" rule makes sense or is a good idea
at all. Specially if there are seemingly arbitrary exceptions.
If such a rule is to be added at all, it sh
On 05/11/17 20:04, Timo Rothenpieler wrote:
> Am 05.11.2017 um 19:59 schrieb Mark Thompson:
>> On 05/11/17 18:42, Carl Eugen Hoyos wrote:
>>> 2017-11-05 19:35 GMT+01:00 Mark Thompson :
On 05/11/17 18:28, Carl Eugen Hoyos wrote:
> 2017-11-05 15:24 GMT+01:00 Mark Thompson :
>> On 30/10/1
On 05/11/17 19:01, Nicolas George wrote:
> Le quintidi 15 brumaire, an CCXXVI, Mark Thompson a écrit :
>> +AviSynth and Nvidia are exempt from this prohibition on external headers.
>
> So if somebody wants to add new headers, they just have to propose a
> patch to this sentence to add another exce
Am 05.11.2017 um 19:59 schrieb Mark Thompson:
On 05/11/17 18:42, Carl Eugen Hoyos wrote:
2017-11-05 19:35 GMT+01:00 Mark Thompson :
On 05/11/17 18:28, Carl Eugen Hoyos wrote:
2017-11-05 15:24 GMT+01:00 Mark Thompson :
On 30/10/17 19:51, Mark Thompson wrote:
"No external headers may be incl
On 11/5/2017 3:42 PM, Carl Eugen Hoyos wrote:
> 2017-11-05 19:35 GMT+01:00 Mark Thompson :
>> On 05/11/17 18:28, Carl Eugen Hoyos wrote:
>>> 2017-11-05 15:24 GMT+01:00 Mark Thompson :
On 30/10/17 19:51, Mark Thompson wrote:
>>>
"No external headers may be included in the ffmpeg tree."
>>>
Le quintidi 15 brumaire, an CCXXVI, Mark Thompson a écrit :
> +AviSynth and Nvidia are exempt from this prohibition on external headers.
So if somebody wants to add new headers, they just have to propose a
patch to this sentence to add another exception? I will not vote for a
proposal like that.
On 05/11/17 18:42, Carl Eugen Hoyos wrote:
> 2017-11-05 19:35 GMT+01:00 Mark Thompson :
>> On 05/11/17 18:28, Carl Eugen Hoyos wrote:
>>> 2017-11-05 15:24 GMT+01:00 Mark Thompson :
On 30/10/17 19:51, Mark Thompson wrote:
>>>
"No external headers may be included in the ffmpeg tree."
>>>
>>
2017-11-05 19:35 GMT+01:00 Mark Thompson :
> On 05/11/17 18:28, Carl Eugen Hoyos wrote:
>> 2017-11-05 15:24 GMT+01:00 Mark Thompson :
>>> On 30/10/17 19:51, Mark Thompson wrote:
>>
>>> "No external headers may be included in the ffmpeg tree."
>>
>> So you suggest to remove the Nvidia header?
> If t
On 05/11/17 18:28, Carl Eugen Hoyos wrote:
> 2017-11-05 15:24 GMT+01:00 Mark Thompson :
>> On 30/10/17 19:51, Mark Thompson wrote:
>
>> "No external headers may be included in the ffmpeg tree."
>
> So you suggest to remove the Nvidia header?
If that specific policy is adopted then it would have t
2017-11-05 15:24 GMT+01:00 Mark Thompson :
> On 30/10/17 19:51, Mark Thompson wrote:
> "No external headers may be included in the ffmpeg tree."
So you suggest to remove the Nvidia header?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.or
On 30/10/17 19:51, Mark Thompson wrote:
>
> Hi all,
>
> The recent submission of AMD AMF patches including a builtin header prompted
> me to think further about what external API headers should actually be
> included in the tree.
>
> For the AMD headers (like V4L2 previously), it seems entirel
Le primidi 11 brumaire, an CCXXVI, Carl Eugen Hoyos a écrit :
> License-wise, it of course makes not difference if linking
> is done at compile-time, at startup or at run-time.
Yes it does. License-wise, what makes a difference is whether you
distribute code for which you do not own the copyright
2017-11-01 1:34 GMT+01:00 Mark Thompson :
> On 01/11/17 00:29, Carl Eugen Hoyos wrote:
>> 2017-11-01 1:23 GMT+01:00 Mark Thompson :
>>
>>> Or libx264, which also lacks headers inside ffmpeg. (We
>>> could dynamically load libx264 using reverse-enginereed
>>> non-GPL headers and then be able to ena
On Wed, Nov 01, 2017 at 12:34:45AM +, Mark Thompson wrote:
> On 01/11/17 00:29, Carl Eugen Hoyos wrote:
> > 2017-11-01 1:23 GMT+01:00 Mark Thompson :
> >
> >> Or libx264, which also lacks headers inside ffmpeg. (We
> >> could dynamically load libx264 using reverse-enginereed
> >> non-GPL head
On 01/11/17 00:29, Carl Eugen Hoyos wrote:
> 2017-11-01 1:23 GMT+01:00 Mark Thompson :
>
>> Or libx264, which also lacks headers inside ffmpeg. (We
>> could dynamically load libx264 using reverse-enginereed
>> non-GPL headers and then be able to enable it everywhere!
>
> But only with --enable-g
2017-11-01 1:23 GMT+01:00 Mark Thompson :
> Or libx264, which also lacks headers inside ffmpeg. (We
> could dynamically load libx264 using reverse-enginereed
> non-GPL headers and then be able to enable it everywhere!
But only with --enable-gpl, making the stunt less useful.
Anyway, this wasn't
On 01/11/17 00:17, Mark Thompson wrote:
> On 01/11/17 00:07, Carl Eugen Hoyos wrote:
>> 2017-11-01 1:04 GMT+01:00 Mark Thompson :
>>> This is why I'm concerned that we are facilitating anti-open
>>> behaviour from Nvidia by making it easier to use the
>>> closed software than more open alternatives
On 01/11/17 00:07, Carl Eugen Hoyos wrote:
> 2017-11-01 1:04 GMT+01:00 Mark Thompson :
>> This is why I'm concerned that we are facilitating anti-open
>> behaviour from Nvidia by making it easier to use the
>> closed software than more open alternatives.
>
> But you do agree that there is nothing
2017-11-01 1:04 GMT+01:00 Mark Thompson :
> This is why I'm concerned that we are facilitating anti-open
> behaviour from Nvidia by making it easier to use the
> closed software than more open alternatives.
But you do agree that there is nothing "open" about the AMD
driver in question?
Carl Eugen
On 31/10/17 23:52, Carl Eugen Hoyos wrote:
> 2017-10-31 17:52 GMT+01:00 Mark Thompson :
>> On 31/10/17 16:34, Timo Rothenpieler wrote:
>
>>> We're not bundling entire 3rd party libs in-tree here, just
>>> API headers for system/driver APIs.
>>
>> What exactly would the policy be, then?
>>
>> "Exte
2017-10-31 17:52 GMT+01:00 Mark Thompson :
> On 31/10/17 16:34, Timo Rothenpieler wrote:
>> We're not bundling entire 3rd party libs in-tree here, just
>> API headers for system/driver APIs.
>
> What exactly would the policy be, then?
>
> "External headers for a system/driver API may be included i
On 31/10/17 16:34, Timo Rothenpieler wrote:
> Removing the nvenc/cuvid headers from the tree would imply the following
> procedure for anyone wanting to build ffmpeg with nvenc/cuvid:
>
> Register with nvidia to get access to their Video SDK Downloads.
> Extract the headers from their massive SDK
Removing the nvenc/cuvid headers from the tree would imply the following
procedure for anyone wanting to build ffmpeg with nvenc/cuvid:
Register with nvidia to get access to their Video SDK Downloads.
Extract the headers from their massive SDK.
Patch them so that ffmpeg can make use of them. The
On 10/30/2017 4:16 PM, Jan Ekstrom wrote:
On Mon, Oct 30, 2017 at 9:51 PM, Mark Thompson wrote:
PPS:
The position stated above would imply removing the avisynth headers. Can
anyone who uses it comment on what would be required for that?
Avisynth headers are available from the Avisynth SDK
On Mon, Oct 30, 2017 at 9:51 PM, Mark Thompson wrote:
> PPS:
>
> The position stated above would imply removing the avisynth headers. Can
> anyone who uses it comment on what would be required for that?
Avisynth headers are available from the Avisynth SDK that comes with
each installer of Avisy
Hi all,
The recent submission of AMD AMF patches including a builtin header prompted me
to think further about what external API headers should actually be included in
the tree.
For the AMD headers (like V4L2 previously), it seems entirely silly to include
them - they are available upstream i
29 matches
Mail list logo
